Guest post from my colleague Patrick Lorch who wrote up what we did the other day in order to view a whole bunch of tiled images in a directory in QGIS (I did some mild editing to his posts. Mistakes are mine). The great thing about the approach is that is generalizeable to most tools that use GDAL for their raster API. This is part … Continue reading Efficient delivery of raster data part 4
Subdivision of geographic data is a panacea to problems you didn’t know you had. Maybe you deal with vector data, so you pre-tile your vector data to ship to the browser to render– you’re makin’ smaller data. Maybe you use cutting edge PostGIS so you apply ST_Subdivide to keep your data smaller than the database page size like Paul Ramsey describes here. Smaller’s better… . Or perhaps you … Continue reading (Whichever tiler you use) and efficient delivery of raster data (image pyramid layer) (update2)
In a previous couple of posts (this one, and this one), we dealt with point rotations, first with bounding box searches, and then with nominal use of operators. First we create a function to do our angle calculations, then use select to loop through all the records and do the calculations. Within our function, first we find our first (in this case) five nearest streets … Continue reading Cartography and USGS — Fake Building Footprints in PostGIS now with distance operator (part 2)
A perennial favorite on this blog is “GeoServer and efficient delivery of raster data (image pyramid layer)“. I am neither the last nor the first authority on this topic (check the GeoSolutions blog for authoritative work on GeoServer and raster, also look to the GeoServer documentation), but I’ve had some good experiences with serving rasters in GeoServer, especially using image pyramid layers Read the original, … Continue reading GeoServer and efficient delivery of raster data (image pyramid layer) (update)
Normally, my blog is a bit of a monologue. It’s not a bad thing, but can be a little lonely. Every now and then I get a great (and often doubtful) comments, which enhances things considerably. What follows is some dialog about the LiDAR shootout series, largely between Etienne and Pierre, posted with their permission: Pierre: “Etienne, Stephen, “I really appreciate the benchmark work you … Continue reading Dialog– What qualifies as a benchmark? Part 1
In reviewing the final numbers and charts from Etienne and Pierre, above are the results we see. The only revision is a moderate increase in speed for the PG Raster query. Final results in speed for lastools– ~350,000 points per second. In other words– off-the-charts fast. And the initial RMSE of ~25 feet was a mistake– it is probably closer to 0.2 feet. Stay tuned … Continue reading LiDAR Shootout! — New Chart, Final Results
For a couple of months now I’ve been corresponding with Etienne Racine and Pierre Racine out of Montreal Laval University in Quebec City. They decided to take on the problem of finding the speed and accuracy of a number of different techniques for extracting canopy height from LiDAR data. They have been kind enough to allow me to post the results here. This will be … Continue reading LiDAR Shootout!
In a previous post, I restructured the contour data for display in GeoServer, e.g.: UPDATE base.contours_2 SET div_10 = CAST( contours_2.elevation % 10 AS BOOLEAN ), div_20 = CAST( contours_2.elevation % 20 AS BOOLEAN ), div_50 = CAST( contours_2.elevation % 50 AS BOOLEAN ), div_100 = CAST( contours_2.elevation % 100 AS BOOLEAN ), div_250 = CAST( contours_2.elevation % 250 AS BOOLEAN ); The SLD styling … Continue reading Contours– Symbolized from a single table
Naively structured data is my bane– the desire (and need) to get stuff done so often overtakes the time needed to do things the better way. So, we bootstrap. A long time ago, we managed to load in a few tens of gigs of contour data into PostGIS, partitioned it into 2ft, 10ft, 20ft, 50ft, 100ft and 250ft tables using select queries with a modulus … Continue reading Contours– Structuring PostGIS data for viewing with GeoServer
A while back, I had the idea of creating a hash of geometry in order to create a unique constraint on geometry to avoid duplicate geometries in a PostGIS table. It works. It’s slow, but it works. I haven’t used it since. What I really wanted to do though was be able to detect if geometries were similar as well (not just detect identical geometries), … Continue reading PostgreSQL and Fuzzy Hashes– a natural combo?
Smathermather's Weblog 