[gdal-dev] Buffer unit
Jaak Laineste (Nutiteq)
jaak at nutiteq.com
Thu Oct 10 03:16:42 PDT 2013
On 09.10.2013, at 22:57, Jukka Rahkonen <jukka.rahkonen at mmmtike.fi> wrote:
> Iván Sánchez Ortega <ivan <at> sanchezortega.es> writes:
>
>>
>> El Miércoles, 9 de octubre de 2013 07:33:43 Federico Jurio escribió:
>>> Dear all, I am using WGS84 (4326) and would like to buffer based on meters
>>> and not degrees. [...]
>>> Can someone please point me in the right direction?
>>
>> If you have a working PostGIS instance, you can get your geometries as
> PostGIS
>> geographies, then run st_buffer on them. PostGIS will take care of the dirty
>> work of finding a more-or-less appropiate projection for buffering the
>> geography.
>>
>>> [buffering in degrees] is the easy way and i'm sure that the accuracy isn't
>>> the best.
>>> [reprojecting] probably doesn't have the best performance.
>>
>> This begs the question: What do you want to achieve? Accuracy, or performance?
>>
>> Personally, if PostGIS geographies aren't available, I'd rather reproject
>> whole geometries into WGS84 UTM (EPSG:326xx) depending on the centroid's
>> longitude, then buffer, then project back into WGS84 lat-lon (EPSG:4326).
>>
>> Best,
>
> Hi,
>
> How about using all that on-the-fly with the amazing OGR Spatialite dialect?
>
> ogrinfo -dialect sqlite
> -sql "select
> transform(buffer(transform(geometry,26915),10000),4326) as geometry2
> from states limit 4" states.shp
>
> So, transform 4 features from the Geoserver demo shapefile "states.shp" from
> EPSG:4326 into 26915, create 10000 metre buffer while in 26915 and transform
> the buffered features back to EPSG:4326.
>
> Try it, it's fast. If you think that there are too many vertices in the
> result, add "SimplifyPreserveTopology" into SQL. Buffer can sometimes make
> self-intersections into the resulting polygon but that's no problem either
> because you can correct them in-th-fly by adding "MakeValid" into SQL. The
> hardest part is to keep trac of all the paranthesis :)))))
Isn't there really better solution than dual-transformation? The problem with this is that you need pick a projection wisely, and there is no global projection what you can use without having big distortions nearer to poles (in the case of Mercator for example. You need to use projection depending on particular location, and even then you would have transformation errors.
Root problem is that most JTS/GEOS, including buffer() implementations can do cartesian math only. Good solution would be to implement buffer function from latitude/longitude directly, say buffer(lat,lon,buffer_meters). Any takers?
Jaak
More information about the gdal-dev
mailing list