[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 ?]

Moritz Lennert mlennert at club.worldonline.be
Mon Sep 10 05:48:35 PDT 2012


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 ?

Just brainstorming...

Moritz


More information about the grass-dev mailing list