On Mon, Sep 10, 2012 at 2:48 PM, Moritz Lennert <[email protected]> wrote: > On 09/09/12 16:34, Markus Metz wrote: >> >> 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. > > > Would it be at least possible to enable this in the measurement tool in the > GUI without having to modify many modules or libraries ?
The GUI could use cs2cs to translate coordinates to latlong. Geodesic distance calculations are done by libgis with G_begin_geodesic_distance() and G_geodesic_distance(). The GUI could duplicate the relevant code, but code duplication is IMHO not a good idea. Maybe a dedicated module to calculate distances and a flag to calculate geodesic distances would help? Markus M > > Just brainstorming... > > Moritz _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
