1

Has anyone tried to store nation-wide lat/long ranges as a look-up table?

For example: If you had a polygon dataset that covered the entire US (for example, county polygons). And you wanted to look up any lat/long combination and return which county it is located within. Wouldn't it be possible to break the county data into say, 50m x 50m cells and assign lat/long ranges to each to make a giant matrix of all lat/longs in the US with assigned county attributes?

Has this been done?

  • 2
    If you were to use a system like PostGIS, you would simply write a query that took the lat and lon you were interested in, build a point geometry object, intersect it with the county polygons, and return the COUNTY_NAME... you wouldn't have to prep any more data than your counties... – DPSSpatial May 16 '16 at 22:04
  • 2
    Why would you do it that way... sure it's possible but the true power of GIS is in Contains or Within statements in geometry operators; creating blocks of 'state' is inherently inaccurate on the boundary between two (or more) state polygons, a simple geometry check is much more accurate and takes less space. – Michael Stimson May 16 '16 at 22:34
  • 1
    You're talking about a 'spatial index' and yes it has been done. Don't reinvent the wheel. What software are you using? – user2856 May 17 '16 at 11:41
1

I've tried this approach. It's a fast way to do this, compared to the usual way, but it has limitations.

The usual way

The traditional way to do this is a spatial join. You read off the county name attribute of the first polygon you find which the point overlaps.

The quickest way is to import these polygons into Postgres with shp2pgsql and do something like this (assuming you imported in WGS84). I've not tested this.

SELECT 
    county_name 
FROM 
    counties
WHERE 
    ST_Intersects(counties.geom, ST_MakePoint(longitude, latitude)) AND
    counties.geom && ST_MakePoint(longitude, latitude) 

(the last line speeds things up by only examining counties whose bounding boxes contain the point)

With rasters

Your idea about building this with rasters is something I've done in the past using Python and GDAL. This involves converting the polygons to a raster (in your example, each pixel would be 50m x 50m). In QGIS this is under Raster > Conversion > Polygon to Raster. You'd need to allocate a unique integer to each county first, which would become the value of the raster in each cell.

Doing spatial joins of large numbers of polygons and points can be prohibitively slow, but GDAL can find the pixel corresponding to a geographical location really quickly, and sampling the raster at that point is really quick too.

I found using this technique let me spatially join 1 million points to several hundred polygons in a couple of minutes, something which took 12 hours using a normal spatial join in QGIS. (I didn't compare it to the postgresql approach, so I'm not sure how it compares)

The downside is a lack of accuracy and incorrect classifications.

Spatially joining a point to a polygon will give correct results. Doing it with a raster means that some points may be mis-allocated to a neighbouring county if it is close enough to the boundary. But you have the same problem if you simplify the polygon geometries to speed up the normal spatial join.

Having said that, a 50m resolution grid over the US will probably need a huge amount of memory.

It's a trade-off; speed versus accuracy. Choose one :)

  • 1
    You could probably hybridize the search with some clever programming, use the raster for speed with cells completely covered by polygons and where more than one possibility exists (indeterminate, cell straddles a polygon boundary with a special value) then resolve using vector operators... just depends on how important speed is. I would say hybridizing would always give the correct result mostly faster and less CPU intensive; this might be as low as a few percent needing vector resolution. – Michael Stimson May 17 '16 at 0:49
  • this is not quite what I meant. I'm more seeking examples of converting data to a table of lat/long coordinate ranges. And then using that table to look up the locations of any lat/long pair rather than using a GIS. – MMB May 17 '16 at 16:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.