[GRASS-dev] [GRASS GIS] #3161: different results by v.in.ogr --ui and vector import wizzard (data shift)

[GRASS GIS]

#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 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
 }}}

 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
 }}}
 and
 {{{
 g.proj -p
 georef="D:\temp\Gesamtgewaessernetz_v11_Tirol\Gesamtgewaessernetz_v11_Tirol_epsg31287.shp"
 }}}
 identical?

 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).

 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.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/3161#comment:1>
GRASS GIS <https://grass.osgeo.org>