[GRASS-dev] geodesic distances for measuring and buffers, even when working in planar coordinate system ? [was: Re: [GRASS-user] What distance is being measured and used for buffers ?]

[Markus Metz]

On Mon, Sep 10, 2012 at 2:48 PM, Moritz Lennert
<mlennert at club.worldonline.be> wrote:
> On 09/09/12 16:34, Markus Metz wrote:
>>
>> On Fri, Sep 7, 2012 at 9:45 AM, Moritz Lennert
>> <mlennert at club.worldonline.be>  wrote:
>>>
>>> On 07/09/12 09:05, Markus Metz wrote:
>>>>
>>>>
>>>> On Tue, Sep 4, 2012 at 6:57 PM, Moritz Lennert
>>>> <mlennert at club.worldonline.be>   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