On Fri, Nov 10, 2017 at 6:43 PM, Markus Metz <markus.metz.gisw...@gmail.com> wrote: > > > > On Fri, Nov 10, 2017 at 6:08 PM, Vaclav Petras <wenzesl...@gmail.com> wrote: > > > > Hi all, > > > > I'm trying to understand a change of behavior between 7.2 and trunk. With 7.2, I can do the following: > > > > curl -SL http://fatra.cnr.ncsu.edu/foss4g2017/nc_tile_0793_016_spm.zip \ > > > nc_tile_0793_016_spm.zip && unzip nc_tile_0793_016_spm.zip > > > > grass72 -c EPSG:3358 ~/grassdata/crs_test -e > > grass72 ~/grassdata/crs_test2/PERMANENT/ --exec r.in.lidar input=nc_tile_0793_016_spm.las output=count_10 method=n -e -n resolution=10 > > > > The last step (r.in.lidar) fails in current trunk because the projection don't match. Here is the difference (name, datum and swapped lat_1 and lat_2): > > > > GRASS LOCATION PROJ_INFO is: > > name: NAD83(HARN) / North Carolina > > datum: nad83harn > > lat_1: 36.16666666666666 > > lat_2: 34.33333333333334 > > > > Import dataset PROJ_INFO is: > > name: NAD_1983_StatePlane_North_Carolina_FIPS_3200 > > datum: nad83 > > lat_1: 34.33333333333334 > > lat_2: 36.16666666666666 > > > > 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. Markus M > > > > > Here is the lasinfo reference: > > > > PROJCS["NAD_1983_StatePlane_North_Carolina_FIPS_3200", > > GEOGCS["GCS_North_American_1983", > > DATUM["North_American_Datum_1983", > > SPHEROID["GRS_1980",6378137,298.257222101]], > > PRIMEM["Greenwich",0], > > UNIT["Degree",0.0174532925199432955]], > > PROJECTION["Lambert_Conformal_Conic_2SP"], > > PARAMETER["False_Easting",609601.22], > > PARAMETER["False_Northing",0], > > PARAMETER["Central_Meridian",-79], > > PARAMETER["Standard_Parallel_1",34.33333333333334], > > PARAMETER["Standard_Parallel_2",36.16666666666666], > > PARAMETER["Latitude_Of_Origin",33.75], > > UNIT["Meter",1]] > > > > `r.in.lidar -p` in both 7.2 and trunk gives: > > > > +proj=lcc +lat_1=34.33333333333334 +lat_2=36.16666666666666 +lat_0=33.75 +lon_0=-79 +x_0=609601.22 +y_0=0 +datum=NAD83 +units=m +no_defs > > > > `g.proj -p` gives the following in 7.2 and trunk in locations created by 7.2 and trunk: > > > > -PROJ_INFO------------------------------------------------- > > name : NAD83(HARN) / North Carolina > > datum : nad83harn > > ellps : grs80 > > proj : lcc > > lat_1 : 36.16666666666666 > > lat_2 : 34.33333333333334 > > lat_0 : 33.75 > > lon_0 : -79 > > x_0 : 609601.22 > > y_0 : 0 > > no_defs : defined > > -PROJ_EPSG------------------------------------------------- > > epsg : 3358 > > -PROJ_UNITS------------------------------------------------ > > unit : meter > > units : meters > > meters : 1 > > > > I don't know how to resolve it besides using -o but I don't know how to justify it and why there is a difference (I don't see it in the recent proj-related commits). > > > > Thank you, > > Vaclav > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/grass-dev >
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
