[GRASS-user] v.import and v.proj errors

Hello list,

I downloaded generalized coastlines from: http://openstreetmapdata.com/data/generalized-coastlines and as they are in mercator projection (epsg:3857) and I’m working in eu_laea, i wanted to use v.import to reproject (and subset to my region) on the fly… but I can’t get v.import nor v.proj to work…

This is the command I’m using (copied from the GUI) and the error:

v.import input=coastlines_z8.shp epsg=3857 datum_trans=0 → the same with whatever value > 0 that I put here

WARNING: All available OGR layers will be imported into vector map <coastlines_z8>
Projection information updated
WARNING: All available OGR layers will be imported into vector map <coastlines_z8>
Importing </home/veroandreo/gisdata/coastlines-generalized-3857/coastlines_z8.shp> …
WARNING: All available OGR layers will be imported into vector map <coastlines_z8>
Check if OGR layer <coastlines_z8> contains polygons…
Default driver / database set to:
driver: sqlite
database: $GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db
Importing 30179 features (OGR layer <coastlines_z8>)…

Building topology for vector map coastlines_z8@PERMANENT
Registering primitives…
30179 primitives registered
2796082 vertices registered
Building areas…
[…]
Reprojecting <coastlines_z8>…
Reprojecting primitives …
WARNING: pj_transform() failed: failed to load datum shift file
ERROR: Unable to re-project vector map coastlines_z8@PERMANENT from <temp_import_location_12909>
ERROR: Unable to to reproject vector <coastlines_z8>

Moreover, if I use datum_trans=-1 which is supposed to throw the list of parameters, I get the following error:

v.import input=coastlines_z8.shp epsg=3857 datum_trans=-1

ERROR: No output format specified, define one of flags -p, -g, -j, or -w
Traceback (most recent call last):
File “/home/veroandreo/software/grass-7.3.svn/dist.x86_64
-pc-linux-gnu/scripts/v.import”, line 290, in
sys.exit(main())
File “/home/veroandreo/software/grass-7.3.svn/dist.x86_64
-pc-linux-gnu/scripts/v.import”, line 158, in main
datum_trans=options[‘datum_trans’])
File “/home/veroandreo/software/grass-7.3.svn/dist.x86_64
-pc-linux-gnu/etc/python/grass/script/core.py”, line 410, in
run_command
return handle_errors(returncode, returncode, args,
kwargs)
File “/home/veroandreo/software/grass-7.3.svn/dist.x86_64
-pc-linux-gnu/etc/python/grass/script/core.py”, line 329, in
handle_errors
returncode=returncode)
grass.exceptions.CalledModuleError: Module run None
[‘g.proj’, ‘epsg=3857’, ‘datum_trans=-1’] ended with error
Process ended with non-zero return code 1. See errors in the
(error) output.

Then, I created a new location from the .prj and imported the file. So, I went to my target location to reproject with the good old v.proj but I get the same warning message at the end and the file is not projected:

v.proj location=mercator mapset=PERMANENT input=coastlines_z8

WARNING: pj_transform() failed: failed to load datum shift file
ERROR: Unable to re-project vector map coastlines_z8@PERMANENT from

In conclusion:

  1. can someone illustrate on what datum_trans means in v.import, what number goes there and/or provide a working example, please?

  2. what is the datum shift file and where is it supposed to be?

Thanks a million in advance for any help/hint!

Best,
Vero

ps1: I’m using grass 73 svn r69040M under Fedora 24
ps2: my way-around to get the file imported was: opening the mercator file in qgis, saving as eu_laea and importing with v.in.ogr into my eu_laea location (suboptimal, but works)

>as they are in mercator projection (epsg:3857) and I'm working in eu_laea

I assume eu_laea is epsg: 3035 (http://epsg.io/3035)?

if yes, epsg3035 is dedicated to the area of Europe.

is the generalized coastlines data for the whole world?

maybe world wide data in epsg:3857 (http://epsg.io/3857) can't be
reprojected into a epsg:3035 location without too much distortion?

my workflow in such cases where only a subregion of worldwide data is needed
: I use the clip mechanism of ogr2ogr [1] in order to clip out my region and
reproject only this clipped area.

HTH

[1] http://www.gdal.org/ogr2ogr.html

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/v-import-and-v-proj-errors-tp5279106p5279112.html
Sent from the Grass - Users mailing list archive at Nabble.com.

Hi Helli,

···

2016-08-02 11:37 GMT-03:00 Helmut Kudrnovsky <hellik@web.de>:

as they are in mercator projection (epsg:3857) and I’m working in eu_laea

I assume eu_laea is epsg: 3035 (http://epsg.io/3035)?

if yes, epsg3035 is dedicated to the area of Europe.

is the generalized coastlines data for the whole world?

yes and yes

maybe world wide data in epsg:3857 (http://epsg.io/3857) can’t be
reprojected into a epsg:3035 location without too much distortion?

mhm… I see… and it makes sense…

my workflow in such cases where only a subregion of worldwide data is needed
: I use the clip mechanism of ogr2ogr [1] in order to clip out my region and
reproject only this clipped area.

HTH

it does, indeed :slight_smile: (I wonder what is qgis using then to make the global data re-projection…)

I also tried with clipping to my region inside v.import (which is maybe equivalent to your trick with ogr2ogr?), but got the same error every time… boh… would be anyway useful to clarify what this “datum_trans” option means.

thanks much!

vero

would be anyway useful to clarify what this "datum_trans" option means.

an example of the datum Hermannskogel [1] aka MGI [2].

this datum goes back to the Austrian-Hungary monarchy which covered the area
of Austria, Hungary, Slovenia, etc.

this datum was used in all these countries, but adapted for several regions
(have look at [3]).

this means that you can use the MGI datum for Austria, the Balcan countries
etc, but you have to use different +towgs parameters adapted for the
respective regions/countries which is needed for reprojection.

and here the "datum_trans" option is needed to define these different +towgs
parameters.

HTH

[1] https://de.wikipedia.org/wiki/Datum_Austria
[2] https://de.wikipedia.org/wiki/MGI
[3] http://epsg.io/?q=MGI

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/v-import-and-v-proj-errors-tp5279106p5279130.html
Sent from the Grass - Users mailing list archive at Nabble.com.

On 02/08/16 17:24, Veronica Andreo wrote:

Hi Helli,

2016-08-02 11:37 GMT-03:00 Helmut Kudrnovsky <hellik@web.de
<mailto:hellik@web.de>>:

     >as they are in mercator projection (epsg:3857) and I'm working in
    eu_laea

    I assume eu_laea is epsg: 3035 (http://epsg.io/3035)?

    if yes, epsg3035 is dedicated to the area of Europe.

    is the generalized coastlines data for the whole world?

yes and yes

    maybe world wide data in epsg:3857 (http://epsg.io/3857) can't be
    reprojected into a epsg:3035 location without too much distortion?

mhm... I see... and it makes sense...

    my workflow in such cases where only a subregion of worldwide data
    is needed
    : I use the clip mechanism of ogr2ogr [1] in order to clip out my
    region and
    reproject only this clipped area.

    HTH

it does, indeed :slight_smile: (I wonder what is qgis using then to make the global
data re-projection...)

I also tried with clipping to my region inside v.import (which is maybe
equivalent to your trick with ogr2ogr?), but got the same error every
time... boh... would be anyway useful to clarify what this "datum_trans"
option means.

I can confirm the issue when using v.in.ogr + v.proj, when using the file to define the location:

grass73 -c /data/GEODATA/OSM/coastlines-generalized-3857/coastlines_z8.shp /data/GRASS/DATA7/test_3857/
v.in.ogr /data/GEODATA/OSM/coastlines-generalized-3857/coastlines_z8.shp

and then in the EPSG 3035 location:

v.proj location=test_3857 mapset=PERMANENT input=coastlines_z8
Reprojecting primitives ...
ATTENTION: pj_transform() a échoué: failed to load datum shift file
ERREUR :Unable to re-project vector map <coastlines_z8@PERMANENT> from
         <test_3857>

However, when I create the 3857 location using the EPSG code, it works:

grass73 -c epsg:3857 /data/GRASS/DATA7/test_3857_epsg/
[...]
v.proj location=test_3857_epsg mapset=PERMANENT input=coastlines_z8

success.

There is a difference in the projection definition between the two:

diff -u test_3857/PERMANENT/PROJ_INFO test_3857_epsg/PERMANENT/PROJ_INFO
--- test_3857/PERMANENT/PROJ_INFO 2016-08-02 18:24:25.965809631 +0200
+++ test_3857_epsg/PERMANENT/PROJ_INFO 2016-08-02 18:28:18.427085934 +0200
@@ -7,7 +7,5 @@
  x_0: 0.0
  y_0: 0
  k: 1.0
-nadgrids: @null
  wktext: defined
  no_defs: defined
-over: defined

Erasing the 'nadgrids: @null' from the first allows to reproject.

The .prj file of the original shapefile contains:

EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs +over"]

I guess the issue comes from how this is handled...

Moritz--
Département Géosciences, Environnement et Société
Université Libre de Bruxelles
Bureau: S.DB.6.138
CP 130/03
Av. F.D. Roosevelt 50
1050 Bruxelles
Belgique

tél. + 32 2 650.68.12 / 68.11 (secr.)
fax + 32 2 650.68.30

Thanks Helli and Moritz for help :slight_smile:

[…]

···

I can confirm the issue when using v.in.ogr + v.proj, when using the file to define the location:

grass73 -c /data/GEODATA/OSM/coastlines-generalized-3857/coastlines_z8.shp /data/GRASS/DATA7/test_3857/
v.in.ogr /data/GEODATA/OSM/coastlines-generalized-3857/coastlines_z8.shp

and then in the EPSG 3035 location:

v.proj location=test_3857 mapset=PERMANENT input=coastlines_z8
Reprojecting primitives …
ATTENTION: pj_transform() a échoué: failed to load datum shift file
ERREUR :Unable to re-project vector map coastlines_z8@PERMANENT from
<test_3857>

However, when I create the 3857 location using the EPSG code, it works:

grass73 -c epsg:3857 /data/GRASS/DATA7/test_3857_epsg/
[…]
v.proj location=test_3857_epsg mapset=PERMANENT input=coastlines_z8

success.

yeah, I just tested here with the same result… so, creating the 3857 location with the coastlines .shp file then produces the error when reprojecting to 3035 because of this extra “nadgrids: @null” in the .prj… good to know :slight_smile:

There is a difference in the projection definition between the two:

diff -u test_3857/PERMANENT/PROJ_INFO test_3857_epsg/PERMANENT/PROJ_INFO
— test_3857/PERMANENT/PROJ_INFO 2016-08-02 18:24:25.965809631 +0200
+++ test_3857_epsg/PERMANENT/PROJ_INFO 2016-08-02 18:28:18.427085934 +0200
@@ -7,7 +7,5 @@
x_0: 0.0
y_0: 0
k: 1.0
-nadgrids: @null
wktext: defined
no_defs: defined
-over: defined

Erasing the ‘nadgrids: @null’ from the first allows to reproject.

The .prj file of the original shapefile contains:

EXTENSION[“PROJ4”,“+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs +over”]

I guess the issue comes from how this is handled…

It seems so… Thank you very much to both for your time!!!

Vero