Landscape Position and McNab Indices (cont.)

I typed that last one too quickly– too many typos, but my wife says I’m not supposed to revise blogs, but move on… . So, for clarity, let’s talk a little more about McNab indices.  Field-derived McNab indices are a measure of average angle from the observer to the horizon (mesoscale landform index), or from the observer to another field person a set distance away, … Continue reading Landscape Position and McNab Indices (cont.)

Cost of nearest neighbor search depending on distance

A quick review of costs to search with increasing distances.  Reference this original post for the code being run. SELECT DISTINCT ON(g1.gid)  g1.gid as gid, g2.gid as gid_ground, g1.x as x, g1.y as y, g2.z as z, g1.z – g2.z as height, g1.the_geom as geometry FROM veg As g1, ground As g2    WHERE g1.gid <> g2.gid AND ST_DWithin(g1.the_geom, g2.the_geom, 3.5)    ORDER BY g1.gid, … Continue reading Cost of nearest neighbor search depending on distance

Further optimization of the PostGIS LiDAR Vegetation Height Query

There’s much to be said for knowing your data in order to best optimize the analysis of it.  Beyond all other bits of cleverness, having a functional understanding of your problem is the first step toward conceiving an intelligent and efficient solution. One thing that I didn’t do two posts ago was to spend any time deciding how far out the search for nearby points … Continue reading Further optimization of the PostGIS LiDAR Vegetation Height Query

PostGIS and LiDAR, the saga completes?

I have to thank this post for the code that follows http://postgis.refractions.net/pipermail/postgis-users/2009-June/023660.html: I’ve been putting at this nearest neighbor for points problem for a few months now, never dedicating enough time to think in through, nor expending enough energy to be really great at SQL, let alone how it can be applied in spatial operations with an OGC compliant database like PostGIS.  But here’s my … Continue reading PostGIS and LiDAR, the saga completes?

Optimizing PostGIS Geometry Functions– Mmm. Donut.

Well, how can I PostGIS without referring back to BostonGIS.  One day I’ll know… .  But first, the Simpsons:  “Mmm… … Donut.” A while back I read Regina Obe’s BostonGIS post on “Map Dicing,” essentially using a grid to dice up an existing dataset to a small granularity in order to take full advantage of spatial indexing, etc..  The post really intrigued me, and is … Continue reading Optimizing PostGIS Geometry Functions– Mmm. Donut.

PostGIS and LiDAR– oops!

I won’t offer much prelude.  Read this post, and this post first… . Inadvertently I demonstrated the value of spatial indices, i.e. I meant to use them and didn’t.  In attempting to sort my tables by their spatial index I got the following errors: ALTER TABLE lidar_ground CLUSTER ON lidar_ground_the_geom_idx; ERROR:  “lidar_ground_the_geom_idx” is not an index for table “lidar_ground” ALTER TABLE lidar_veg CLUSTER ON lidar_veg_the_geom_idx; … Continue reading PostGIS and LiDAR– oops!

Rethinking PostGIS Analyses– Remembering to CLUSTER

Something’s been nagging at me as far as the level of optimization (or lack there-of) that I did to my database before my other posts of using PostGIS to analyze LiDAR data (e.g. this post).  It seemed my results were remarkably slow, but I couldn’t put my finger on why that was problematic. Then, as I was testing a smaller lidar dataset in order to … Continue reading Rethinking PostGIS Analyses– Remembering to CLUSTER

PostGIS and LiDAR, the saga continues

I ran these tests a while back, but I’m just getting to post them now.  These were run on a late model MacBook Pro, with a 2.4GHz Intel Core 2 Duo, with a couple of gigs of RAM on PostgreSQL.  In Postgre, if I run SELECT version(); I get: PostgreSQL 8.4.1 on i386-apple-darwin10.0.0, compiled by GCC i686-apple-darwin10-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493), 64-bit My … Continue reading PostGIS and LiDAR, the saga continues