[GRASS-dev] Different CRS matching in 7.2 and trunk

Markus Metz markus.metz.giswork at gmail.com
Fri Nov 10 14:30:28 PST 2017


On Fri, Nov 10, 2017 at 8:46 PM, Vaclav Petras <wenzeslaus at gmail.com> wrote:
>
> On Fri, Nov 10, 2017 at 2:21 PM, Markus Metz <
markus.metz.giswork at gmail.com> wrote:
> >
> > > >
> > > > 7.2 considers this OK while trunk considers this different. I'm not
sure which one is correct.
> > >
> > > In this case, 7.2 is correct, but 7.2 does not compare datums, i.e.
projections would be regarded as matching even with e.g. nad27 and nad83.
> > > The comparison of datums is new in 7.3 and needs some refinement.
> > >
> > > I will fix the comparison of swapped lat_1 and lat_2.
> >
> > Fixed in trunk r71656.
> >
> > The test for different datum names has been disabled again in trunk
r71657. There are several different datum names in lib/gis/datum.table that
apparently mean the same: same ellipsoid and same transformation
parameters. Apparently, GRASS does not provide a datum name when converting
projection information from GRASS to proj4 for reprojecting data.
>
>
> Thank you so much, Markus. This saves me a lot of trouble.

About avoiding trouble, the motivation of the stricter CRS comparison is to
avoid subsequent geolocation errors. If data have been imported and
differences in the CRS were not detected, it can become very difficult
later on in the processing to figure out the reason for geolocation errors
(different data not matching each other spatially). I'm not sure what to do
about different datum names. The current check relies on the test for
differences in ellipsoids.

Markus M

>
> (I'm working on a Jupyter Notebook where I need trunk.)
>
https://github.com/wenzeslaus/Notebook-for-processing-point-clouds-in-GRASS-GIS
>
> >
> >
> > Markus M
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20171110/b6ae25b5/attachment.html>


More information about the grass-dev mailing list