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

mlennert · September 1, 2012, 4:02pm

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.

I guess that 1) is probably easier to implement than 2) ?

Moritz

On 17/08/12 17:35, Moritz Lennert wrote:

Hello,

I have a fundamental question about distances in GRASS, also in relation
to buffers, that I stumbled upon trying to help a student who tried to
draw buffers around cities indicating the maximum distance airplanes
could fly at different times in history.

To test, I used the World Mercator projection:

+proj=merc
+lon_0=0
+k=1
+x_0=0
+y_0=0
+no_defs
+a=6378137
+rf=298.257223563
+towgs84=0.000,0.000,0.000
+to_meter=1

This projection has obvious deformations the further you get from the
equator, and thus distances are seriously distorted[1].

Using GRASS 6.5 to create a buffer of 6000km around Belgium gives a map
which shows a circular buffer [2].

Using the distance measuring tool in the wxGUI confirms that the
distance from Belgium to the buffer line in all directions is around
6000km.

However, the actual distance is very different, especially towards the
North: According to CloudMade's routing website based on OSM data
northern tip of Norway is only ~3500km by car from Brussels, so very far
from 6000km.

I get exactly the same results using r.grow.distance and r.cost.

For comparison, I used a simple Plate Carree projection:

+proj=eqc
+lat_ts=0
+lat_0=0
+lon_0=0
+x_0=0
+y_0=0
+no_defs
+a=6371007
+b=6371007
+to_meter=1

Distortions are obviously different [3]. And the 6000km buffer is also
positioned differently compared to the land masses [4]. Again, measuring
the distances with the wxGUI distance tool gives me ~6000km in all
directions.

So, my question: which "distance" is used for measurement and for buffer
creation ? A distance based buffer in map units should lead to deformed
buffers in most projection systems. Is there anyway to achieve such
deformed buffers and correct distance measures ?

Moritz

[1] http://164.15.12.207/grass/distances/worldmercator.png
[2] http://164.15.12.207/grass/distances/buffer_worldmercator.png
[3] http://164.15.12.207/grass/distances/platecarree.png
[4] http://164.15.12.207/grass/distances/buffer_platecarree.png

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

mlennert · September 4, 2012, 4:57pm

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 ?

Moritz

Markus_Metz · September 7, 2012, 7:05am

On Tue, Sep 4, 2012 at 6:57 PM, Moritz Lennert
<mlennert@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.

Markus M

mlennert · September 7, 2012, 7:45am

On 07/09/12 09:05, Markus Metz wrote:

On Tue, Sep 4, 2012 at 6:57 PM, Moritz Lennert
<mlennert@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) ?

Moritz

Markus_Metz · September 9, 2012, 2:34pm

On Fri, Sep 7, 2012 at 9:45 AM, Moritz Lennert
<mlennert@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@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

mlennert · September 10, 2012, 12:48pm

On 09/09/12 16:34, Markus Metz wrote:

On Fri, Sep 7, 2012 at 9:45 AM, Moritz Lennert
<mlennert@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@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

Markus_Metz · September 12, 2012, 11:48am

On Mon, Sep 10, 2012 at 2:48 PM, Moritz Lennert
<mlennert@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@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@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