On Fri, Sep 7, 2012 at 9:45 AM, Moritz Lennert <[email protected]> wrote: > On 07/09/12 09:05, Markus Metz wrote: >> >> On Tue, Sep 4, 2012 at 6:57 PM, Moritz Lennert >> <[email protected]> wrote: >>> >>> On 01/09/12 18:02, Moritz Lennert wrote: >>>> >>>> >>>> Leaving below mail as record of my original issue, I would to raise the >>>> fundamental question of whether it would be feasible >>>> >>>> 1) to (optionally) provide geodesic instead of planar distances when >>>> measuring, even if the location is in a projected coordinate system. >>>> E.g. QGIS provides the possibility in distance measuring to check a box >>>> to activate geodesic distance >>>> >>>> 2) to (optionally) allow the creation of buffers based on geodesic >>>> distances, again in a projected location, which would imply non-circular >>>> buffers. >>>> >>> >>> Exploring my exploration of this in the hope that someone might share an >>> interest: >>> >>> r.buffer actually provides the possibility of geodesic buffering when >>> used >>> in a lat-long location. Would it be difficult to implement the same in >>> v.buffer ? >> >> >> The short answer is yes, it will be difficult. The GRASS-internal >> vector buffering algorithm has a number of bugs, the only vector >> buffering method that is AFAICT bug-free is v.buffer in trunk with >> GEOS support which uses the GEOS buffering algorithm which in turn >> does not (yet?) support geodesic distances in latlong. > > > Ok, thanks for the answer. This means that efforts should be put into > including this into GEOS and in the mean time, maybe write a small script > v.buffer.geodesic that uses r.buffer. > > Since we're on it: any idea about question 1) ?
I guess this feature would need to be implemented on both library and module level. A library function to first project to latlong, then calculate geodesic distance would be needed. Modules could then get an option to use geodesic distance, as long as it is not a pseudo xy projection, and make use of the new library function if requested. There may be a lot of pitfalls with such a feature. Markus M _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
