[OSM-dev] projection for calculating distances in PostGIS

Marcus Wolschon Marcus at Wolschon.biz
Wed May 19 16:46:55 BST 2010

On Wed, May 19, 2010 at 5:29 PM, Stephen Cavilia <ailivac at gmail.com> wrote:

>> Why should that be slow?
>> I´m calculating a projected bounding-box for each element once ahead of time
>> and storing these. When doing the queries I only need to project my
>> query-location
>> to find the few elements where my query-loction is within the bounding-box.
>> Then I transform the few geometries found to compare the distance and sort.
> But the bounding boxes you have are stored in degrees, right? That means
> you can't do distance calculations without projecting every feature to
> an appropriate UTM. And reprojecting your entire database will take a
> long time.

The full geometries in the current code are  in WGS84 but the
bounding-boxes are projected
(currently all to 27700).

>>> One other possibility
>>> instead of using a nearest neighbour functionality is to do a search with
>>> ST_DWithin applying a ratio depending on the latitude.
>> That could work.
>> Calculate a WGS4-bounding box with a width and height depending on the loction
>> of the reference-point and select all geometries who intersect it.
>> Could I use utmzone() to calculate a good projection, then project my
>> reference-point
>> to it, create a bounding-box with that SRID of +- N meters, project that back to
>> WGS84 and do the range-query?
>> Then use that SRID in the distance-calculation of the resulting elements that
>> where found to intersect the bounding-box?
> This is what I would do. Calculate a rough lat-lon bounding box that
> approximates the area you want, filter any features that intersect that
> box, then reproject just those into UTM for calculating the actual
> distances. Or a more accurate geodesic/great circle distance, but UTM
> will be close enough over relatively small areas.

no need for great circle. We are talking about bounding-boxes of 500m-5Km .


More information about the dev mailing list