[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 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.

Markus M