#3161: different results by v.in.ogr --ui and vector import wizzard (data shift) ----------------------+--------------------------- Reporter: hellik | Owner: grass-dev@… Type: defect | Status: new Priority: blocker | Milestone: 7.2.0 Component: Vector | Version: svn-trunk Resolution: | Keywords: vector import CPU: x86-64 | Platform: MSWindows 7 ----------------------+---------------------------
Comment (by hellik): Replying to [comment:1 mmetz]: > Replying to [ticket:3161 hellik]: > > follwoing location > > > > {{{ > > g.proj -p > > -PROJ_INFO------------------------------------------------- > > name : MGI / Austria Lambert > > datum : hermannskogel > > ellps : bessel > > proj : lcc > > lat_1 : 49 > > lat_2 : 46 > > lat_0 : 47.5 > > lon_0 : 13.33333333333333 > > x_0 : 400000 > > y_0 : 400000 > > no_defs : defined > > towgs84 : 577.326,90.129,463.919,5.1366,1.4742,5.2970,2.4232 > > -PROJ_EPSG------------------------------------------------- > > epsg : 31287 > > -PROJ_UNITS------------------------------------------------ > > unit : meter > > units : meters > > meters : 1 > > }}} > > > The towgs84 parameters could be a problem. GDAL uses similar towgs84 parameters as default while GRASS uses as default > {{{ > towgs84 : 653,-212,449,0,0,0,0 > }}} the location was created by the location wizzard by EPSG:31287 and then the transformation for the region of Austria was used. trying {{{ g.proj -p epsg=31287 }}} in a EPSG:4326 and a EPSG:31287 location (both locations are created by the EPSG code, I get {{{ g.proj -p epsg=31287 -PROJ_INFO------------------------------------------------- name : MGI / Austria Lambert datum : hermannskogel ellps : bessel proj : lcc lat_1 : 49 lat_2 : 46 lat_0 : 47.5 lon_0 : 13.33333333333333 x_0 : 400000 y_0 : 400000 towgs84 : 577.326,90.129,463.919,5.137,1.474,5.297,2.4232 no_defs : defined -PROJ_EPSG------------------------------------------------- epsg : 31287 -PROJ_UNITS------------------------------------------------ unit : meter units : meters meters : 1 }}} so GRASS seems to choose the same +towgs84 parameter as the underlying gdal/ogr. > Since > > > and vector data (shapefile to import): > > > > {{{ > > INFO: Open of `Gesamtgewaessernetz_v11_Tirol_epsg31287.shp' > > using driver `ESRI Shapefile' successful. > > > > Layer name: Gesamtgewaessernetz_v11_Tirol_epsg31287 > > Metadata: > > DBF_DATE_LAST_UPDATE=2016-09-16 > > Geometry: Measured Line String > > Feature Count: 5095 > > Extent: (118287.824753, 197521.746410) - (833235.119008, 544697.312403) > > Layer SRS WKT: > > PROJCS["MGI_Austria_Lambert", > > GEOGCS["GCS_MGI", > > DATUM["Militar_Geographische_Institute", > > SPHEROID["Bessel_1841",6377397.155,299.1528128]], > > PRIMEM["Greenwich",0], > > UNIT["Degree",0.017453292519943295]], > > PROJECTION["Lambert_Conformal_Conic_2SP"], > > PARAMETER["standard_parallel_1",49], > > PARAMETER["standard_parallel_2",46], > > PARAMETER["latitude_of_origin",47.5], > > PARAMETER["central_meridian",13.33333333333333], > > PARAMETER["false_easting",400000], > > PARAMETER["false_northing",400000], > > UNIT["Meter",1]] > > }}} > does not report towgs84 parameters, GRASS might decide that > > > srs of location and data for import are matching. > > srs of location and data for import are '''not''' matching. > > Is the output of > {{{ > g.proj -p > }}} {{{ g.proj -p -PROJ_INFO------------------------------------------------- name : MGI / Austria Lambert datum : hermannskogel ellps : bessel proj : lcc lat_1 : 49 lat_2 : 46 lat_0 : 47.5 lon_0 : 13.33333333333333 x_0 : 400000 y_0 : 400000 no_defs : defined towgs84 : 577.326,90.129,463.919,5.1366,1.4742,5.2970,2.4232 -PROJ_EPSG------------------------------------------------- epsg : 31287 -PROJ_UNITS------------------------------------------------ unit : meter units : meters meters : 1 }}} the location was created by the location wizzard by EPSG:31287 and then the transformation for the region of Austria was used. > and > {{{ > g.proj -p georef="D:\temp\Gesamtgewaessernetz_v11_Tirol\Gesamtgewaessernetz_v11_Tirol_epsg31287.shp" > }}} > identical? > in an EPSG:4326 location I get: {{{ g.proj -p georef=D:\temp\Gesamtgewaessernetz_v11_Tirol\Gesamtgewaessernetz_v11_Tirol_epsg31287.shp Versuche mit OGR zu öffnen... ...erfolgreich beendet. -PROJ_INFO------------------------------------------------- name : MGI_Austria_Lambert datum : hermannskogel ellps : bessel proj : lcc lat_1 : 49 lat_2 : 46 lat_0 : 47.5 lon_0 : 13.33333333333333 x_0 : 400000 y_0 : 400000 no_defs : defined -PROJ_EPSG------------------------------------------------- epsg : 4326 -PROJ_UNITS------------------------------------------------ unit : Meter units : Meters meters : 1 }}} and in an EPSG:31287 location I get {{{ g.proj -p georef=D:\temp\Gesamtgewaessernetz_v11_Tirol\Gesamtgewaessernetz_v11_Tirol_epsg31287.shp Versuche mit OGR zu öffnen... ...erfolgreich beendet. -PROJ_INFO------------------------------------------------- name : MGI_Austria_Lambert datum : hermannskogel ellps : bessel proj : lcc lat_1 : 49 lat_2 : 46 lat_0 : 47.5 lon_0 : 13.33333333333333 x_0 : 400000 y_0 : 400000 no_defs : defined -PROJ_EPSG------------------------------------------------- epsg : 31287 -PROJ_UNITS------------------------------------------------ unit : Meter units : Meters meters : 1 }}} > If not, as v.import assumes, you might need to provide the EPSG code and the datum transformation parameters as input to v.import (which makes v.import more complicated as it was intended to be). > now declaring EPSG code and datum_trans in v.import: {{{ v.import --verbose epsg=31287 datum_trans=2 input=D:\temp\Gesamtgewaessernetz_v11_Tirol layer=Gesamtgewaessernetz_v11_Tirol_epsg31287 output=checkimport Creating temporary location for <D:\temp\Gesamtgewaessernetz_v11_Tirol>... Projektionsinformationen aktualisiert WARNING: All available OGR layers will be imported into vector map <Gesamtgewaessernetz_v11_Tirol> -PROJ_INFO------------------------------------------------- name : MGI / Austria Lambert datum : hermannskogel ellps : bessel proj : lcc lat_1 : 49 lat_2 : 46 lat_0 : 47.5 lon_0 : 13.33333333333333 x_0 : 400000 y_0 : 400000 no_defs : defined towgs84 : 577.326,90.129,463.919,5.1366,1.4742,5.2970,2.4232 -PROJ_EPSG------------------------------------------------- epsg : 31287 -PROJ_UNITS------------------------------------------------ unit : meter units : meters meters : 1 Importing <D:\temp\Gesamtgewaessernetz_v11_Tirol> ... Die Projektionsinformationen des Eingabedatensatzes und der aktuellen Location scheinen übereinzustimmen. Check if OGR layer <Gesamtgewaessernetz_v11_Tirol_epsg31287> contains polygons... Using native format Standard Treiber / Datenbank ist: Treiber: sqlite Datenbank: $GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db Importing 5095 features (OGR layer <Gesamtgewaessernetz_v11_Tirol_epsg31287>)... ----------------------------------------------------- Erstelle Topologie für die Vektorkarte <checkimport@PERMANENT>... Registriere Primitive... 5095 primitives registered 1505379 Vertices registriert Erzeuge Flächen... 0 areas built 0 isles built Füge Inseln hinzu... Füge Zentroide hinzu... Die Topologie wurde erstellt. Anzahl der Knoten: 10108 Anzahl der Primitive: 5095 Anzahl der Punkte: 0 Anzahl der Linien: 5095 Anzahl der Grenzen: 0 Anzahl der Zentroide: 0 Anzahl der Flächen: 0 Anzahl der Inseln: 0 Reprojecting <checkimport>... Eingabe der Projektionsparameter: +proj=lcc +lat_1=49 +lat_2=46 +lat_0=47.5 +lon_0=13.33333333333333 +x_0=400000 +y_0=400000 +no_defs +a=6377397.155 +rf=299.1528128 +towgs84=577.326,90.129,463.919,5.1366,1.4742,5.2970,2.4232 Eingabe des Einheitenfaktors: 1 Ausgabe der Projektionsparameter: +proj=lcc +lat_1=49 +lat_2=46 +lat_0=47.5 +lon_0=13.33333333333333 +x_0=400000 +y_0=400000 +no_defs +a=6377397.155 +rf=299.1528128 +towgs84=577.326,90.129,463.919,5.1366,1.4742,5.2970,2.4232 Ausgabe des Einheitenfaktors: 1 Using native format Reprojecting primitives ... Erstelle Topologie für die Vektorkarte <checkimport@data>... Registriere Primitive... 5095 primitives registered 1505379 Vertices registriert Erzeuge Flächen... 0 areas built 0 isles built Füge Inseln hinzu... Füge Zentroide hinzu... Die Topologie wurde erstellt. Anzahl der Knoten: 10108 Anzahl der Primitive: 5095 Anzahl der Punkte: 0 Anzahl der Linien: 5095 Anzahl der Grenzen: 0 Anzahl der Zentroide: 0 Anzahl der Flächen: 0 Anzahl der Inseln: 0 }}} > If the towgs84 parameters as reported by g.proj for the current location and for the input shapefile are not identical, this could be regarded as a bug in GRASS since the vast majority of GIS data is imported via r.in.gdal/v.in.ogr and GDAL/OGR automatically picks a preferred set of datum transformation parameters which GRASS should detect. > > In this case the datum transformation parameters selected by GDAL are > {{{ > towgs : 577.326,90.129,463.919,5.137,1.474,5.297,2.4232 > }}} > which is similar but not equal to those used in your location > {{{ > towgs84 : 577.326,90.129,463.919,5.1366,1.4742,5.2970,2.4232 > }}} > > In the end, the user has to decide if reprojection is needed or if the source srs and the location srs are similar enough to allow for using v.in.ogr -o (override projection check). After investigating the input data with g.proj georef=<data to be imported> and ogrinfo/gdalinfo. for me it's not clear, as I've choosen GUI -> ''import common formats'' and '''not''' GUI -> ''import of common formats with reprojection''. in this case I'm sure/assume my data is in the same srs and import should just works. it's quite confusing as v.in.ogr --ui imports the data correctly without the need of ''override projection check''. for me it's a regression, as I have to type ''v.in.ogr --ui'' to get correct results for a simple task of import data in the same srs as the location. -- Ticket URL: <http://trac.osgeo.org/grass/ticket/3161#comment:2> GRASS GIS <https://grass.osgeo.org> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev