6

I have hundreds of CSV files in one folder that I would like to convert to shapefile with ogr2ogr, but I am not able to get the desired EPSG:3067 - I get EPSG:3047 instead.

First, I used the following command to convert CSV to shapefile with no luck (the shapefile was EPSG:3047):

for /R %f in (*.csv) do ogr2ogr -s_srs EPSG:4326 -t_srs EPSG:3067 -oo X_POSSIBLE_NAMES=Lon* -oo Y_POSSIBLE_NAMES=Lat*  -f "ESRI Shapefile" "%~dpnf.shp" %f

Then I used the second command and tried to reproject to EPSG:3067 with the following command, but still the result was EPSG:3047:

for /R %f in (*.shp) do ogr2ogr -a_srs EPSG:3067  -f "ESRI Shapefile" "%~dpnf_newepsg.shp" %f

The only way I can make it work is to manually open the CSV in QGis, file by file, and then save them as shapefile with EPSG:3067.

Am I missing something here?

EDIT Using command ogrinfo -al -so test.shp on newly created shapefile returns the following information:

Layer SRS WKT: PROJCS["ETRS89_TM35FIN_E_N", GEOGCS["GCS_ETRS_1989", DATUM["European_Terrestrial_Reference_System_1989", SPHEROID["GRS_1980",6378137,298.257222101]], PRIMEM["Greenwich",0], UNIT["Degree",0.017453292519943295]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",27], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",500000], PARAMETER["false_northing",0], UNIT["Meter",1]]

According to this it should be EPSG:3067..? But in QGis it still appears as EPSG:3047.

  • I would guess that the error happens in QGIS. What srs GDAL reports with ogrinfo -al -so xxx_newepsg.shp? – user30184 Jun 25 '18 at 12:21
  • I suggest to use -t_srs EPSG:3067 to reproject in the second line. -a_srs only assigns a CRS, and does no recomputation of coordinates. BTW I don't see EPSG:3047 in your commands. – AndreJ Jun 25 '18 at 15:37
  • @user30184 Updated my first post. – Maicen21 Jun 25 '18 at 18:12
  • @AndreJ I tried with -t_srs EPSG:3067, but still the new shapefile is EPSG:3047. Thank you for the idea. My goal was to have shapefile in EPSG:3067, so my commands also contained EPSG:3067. – Maicen21 Jun 25 '18 at 18:15
6

According to spatialreference.org , EPSG 3067 and EPSG 3047 have the same same proj4 parameters (but not the same extent, as 3067 is defined for Finland and 3047 is defined for the entire 35N UTM zone). I also checked the OGC WKT and they are equivalent (same false Easting and Northing...)

http://epsg.io/3047

EPSG 3047: +proj=utm +zone=35 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

http://spatialreference.org/ref/epsg/etrs89-etrs-tm35fin/proj4/

EPSG 3067: +proj=utm +zone=35 +ellps=GRS80 +units=m +no_defs

If you are expecting a difference between the two, then you could build your own definition in proj4 standard.

EDIT: user30184 spotted the difference between the two CRS: epsg3047 is using Northing-Easting while epsg3067 is using easting-northing. The proj4 should therefore be updated for axis switch. From this discussion on orsgeo.org forum, you can see that:

The +axis switch takes three character arguments defining the axis
orientation of the coordinate system.  The possible values are:

'e' - easting
'w' - westing - an x/longitude with the opposite sign to normal.
'n' - northing
's' - southing - a y/latitude with the opposite sign to the normal.
'u' - up - normal z
'd' - down - a z/elevation with the opposite sign to the normal.

According to that, here would be the updated (explicit) proj4 strings:

EPSG 3047 (UTM zone 35N (N-E))=> neu:

+proj=utm +zone=35 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs +axis=neu  

EPSG 3067 (TM35FIN(E,N)) => enu:

+proj=utm +zone=35 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs +axis=enu 

for changing from 3067 to 3047, you could also use (in proj4 v >=5)

+proj=axisswap +order=2,1

  • 4
    There is a difference between EPSG:3067 and EPSG:3047 if you look at the latest official source opengis.net/def/crs/EPSG/0/3047. The difference is that EPSG:3047 is using Northing-Easting axis order. QGIS comes probably with an older version of the EPSG database or perhaps it drops axis order altogether. Using one or another code should not have an effect when working with QGIS as long as you do not need to use GML format. – user30184 Jun 25 '18 at 12:19
  • Thank you for the very thorough explanation! Although I found a workaround (first creating EPSG:4326 shapefiles with ogr2ogr and then reprojecting to EPSG:3067 using QGIS native plugin "Reproject layer" in Batch Processing mode) I will accept it aslo as a solution. – Maicen21 Jun 26 '18 at 18:47
0

Maybe do this in two steps? First convert to shp, then reproject. Could be a source of error. If necessary, or you're lazy, build a model and batchrun that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.