Please note, that in spite of the fact that the datum.table shows same transformation parameters, different nad83 datums are different (it is not just a different name for the same datum) and there are different EPSG codes associated with the relevant CRS. You can find more about it here (or just google it) https://confluence.qps.nl/pages/viewpage.action?pageId=29855153 <https://confluence.qps.nl/pages/viewpage.action?pageId=29855153>
Supposedly, the shift from NAD83(86) to NAD83(HARN) can be done with the NGS NADCON program (I have not checked it out) (http://www.ngs.noaa.gov/TOOLS/Nadcon/Nadcon.shtml <http://www.ngs.noaa.gov/TOOLS/Nadcon/Nadcon.shtml>). Helena > On Nov 10, 2017, at 5:30 PM, Markus Metz <markus.metz.gisw...@gmail.com> > wrote: > > > > On Fri, Nov 10, 2017 at 8:46 PM, Vaclav Petras <wenzesl...@gmail.com> wrote: > > > > On Fri, Nov 10, 2017 at 2:21 PM, Markus Metz > > <markus.metz.gisw...@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 > > > > > _______________________________________________ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev Helena Mitasova Professor at the Department of Marine, Earth, and Atmospheric Sciences and Center for Geospatial Analytics North Carolina State University Raleigh, NC 27695-8208 hmit...@ncsu.edu http://geospatial.ncsu.edu/osgeorel/publications.html "All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.”
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
