Possible to add AT_GIS_GRID ( EPSG::5891)

[c716307]

Is it possible to integrate AT_GIS_GRID in your plug-in ?
Download of the gsb-File: http://www.bev.gv.at/portal/page?_pageid=713,2103845&_dad=portal&_schema=PORTAL
Details on it (in german): http://isticktoit.net/?p=371
AT_GIS_GRID is recommended for transformation of MGI (epsg:4312) to ETRS89 (epsg:4258).

[gioman]

yes is certainly possible and have already been asked here

#9

anyway before doing it I need to know a few things (one you already answered, the CRSs supported by this grid):

is the ntv2 grid freely reditributable? any license? what are the EPSG codes of the CRSs supported by ths grid? can you provide data (or link to) to test the transformation? Thanks!

[c716307]

Hi! Thx for the quick reply.
in QGIS 2.2 it was possible to integrate it directly in the srs.db - that's what I documented here: http://isticktoit.net/?p=371 - it seems not possible anymore... I made an issue here http://hub.qgis.org/issues/13372
I think it is because of the sync between the srs.db and proj4 ? So I came to your Plug-In
The Austrian National Mapping Agency offers the gsb for free download: http://www.bev.gv.at/portal/page?_pageid=713,2105660&_dad=portal&_schema=PORTAL - I can't find any use-restrictions belonging to the download.
The AT_GIS_GRID supports transformations from the Austrian MGI-System to ETRS89 (MGI (epsg:4312) to ETRS89 (epsg:4258)). It should work for epsg-codes 31254-31259 to 4258(ETRS89). Inofficially it also has more accuracy for transforming 31254-31259 to epsg:4326(GCS WGS84)

[gioman]

ok, will add this grid/transformations as soon as I have a little spare time. Cheers!

[gioman]

support added in 4fc96aa

a new version of the plugin has already been published. Tests wlecome as I don't have the proper sample data to make them myself.

[c716307]

Thx a lot ! I will test it the next 2 days with sample-data and do a comparison to verify it. Flo

[c716307]

Did a test with a vector-layer and it produced an empty new transformed Shapefile at first. Problem was defining a Shapefile for output - if you just define a directory it works.
Second problem is that the result is different to doing it with QGIS-internal gsb-configuration. I have seen that your Script uses GDAL/OGR - i have to investigate how QGIS does it internal with a individual transformation defined in the srs.db (using the same gsb-File). I will also cross check it with ArcMap.

[gioman]

Did a test with a vector-layer and it produced an empty new transformed Shapefile at first. Problem was defining a Shapefile for output - if you just define a directory it worked.

The output must be left empty, and it will create a "temporary" shapefile (output will be placed inside /tmp) or you must define an output (with full path and file name and extension).

Second problem is that the result is different to doing it with QGIS-internal gsb-configuration. I have seen that your Script uses GDAL/OGR - i have to investigate how QGIS does it internal with a individual transformation defined in the srs.db (using the same gsb-File). I will also cross check it with ArcMap.

The plugin is based on OGR2OGR, so if the output is wrong a few things may be possible: 1) the CRS parameters I used are wrong (see the code) 2) ogr2ogr for some reason produce a different result. The second would be weird, because it always worked as expected also for other countries. For a country I know well (Portugal) the result obtained with ogr2ogr are the same obtained by adding the transformation in QGIS srs.db

[gioman]

I would help if you cold sent me a sample dataset. This must include a layer in 4312 and another version of the same layer in 4258 (of course the second not obtained using the same transformation we want to test here, the best datasets are from official sources, like the same map but published in different years, with different CRSs).

[c716307]

Hello! Attached is a sample dataset - Naturwaldzellen2014_ErhebungW....shp is in a local Austrian system (with MGI). I attached 2 transformed datasets derived from it - one I transformed with ArcMap and the AT_GID_GRID.gsb and the other one with QGIS manipulating the srs.db. Both of them look identical. Maybe you can give the dataset a try with the PlugIn. You have to rename the attached PNG to ZIP)

[c716307]

When the command produces empty SHPs this error-message may be helpful:

[gioman]

The plugin supports the transformation between 4312 and 4258. The parameters (proj4) are hardcoded in the plugin, and they include the ntv2 grid. If you use a input layer with a CRS that does not match the transformation it could very well give the error you see, especially if the transformation if between geographical CRSs and you use a projected one (or vice versa).

I made a copy of "Naturwaldzellen2014_ErhebungWaldplan" to 4312 (from 31254, same datum no precision loss) and then used the plugin to transform to 4258: the result is identical to the other two vectors you attached.

[gioman]

the result is identical to the other two vectors you attached.

correction, is almost identical. There is a ~0.1 mm along the Y axis and a ~0.007mm along the X one.

[c716307]

Thx a lot, was able to reproduce it. Defining the source-layer as 4312 works well. On the other hand it indicates that the hardcoded proj4 parameters in the PlugIn would require an extra definition for each common zone in Austria using MGI (because it does not recognise 4312 as "regional code"). In this case the following transformations would be necessary:
epsg:31254 (MGI / Austria GK west) --> epsg:4258 (ETRS89)
epsg:31255 (MGI / Austria GK central) --> epsg:4258 (ETRS89)
epsg:31256 (MGI / Austria GK east) --> epsg:4258 (ETRS89)
epsg:31257 (MGI / Austria GK M28) --> epsg:4258 (ETRS89)
epsg:31258 (MGI / Austria GK M31) --> epsg:4258 (ETRS89)
epsg:31259 (MGI / Austria GK M34) --> epsg:4258 (ETRS89)

The problem defining a target file (SHP) in the parameters-box always results in an error (Screenshot) - using the temporary output or "hardcoding" the target in the box (not using the "file selector") works well.

[gioman]

indicates that the hardcoded proj4 parameters in the PlugIn would require an extra definition for each common zone in Austria using MGI

yes. I just had time to had the transformation between geographical MGI and ETR89. For the others please file a new ticket here as a reminder for me, or even better propose a patch.

The problem defining a target file (SHP) in the parameters-box always results in an error (Screenshot) - using the temporary output or "hardcoding" the target in the box (not using the "file selector") works well.

This do no happen here, as the the "..." button can be safely clicked to choose "save to file" and then chose a location and name for output. If there is any issue here is most likely about Processing itself... what version of it are you using?

[c716307]

Hi! I had a look at your Code - I'll try to generate ans test all 6 variants for Austria. It will take 1-2 weeks time.

[gioman]

Hi! I had a look at your Code - I'll try to generate ans test all 6 variants for Austria. It will take 1-2 weeks time.

added here b7116fd

[c716307]

Hi ! Looks good in your code - 2 days ago I started to collect the ogr2ogr for AT_GIS-GRID for all six EPSG-Codes and published it (http://isticktoit.net/?p=1234#more-1234). I have also tested all transformation-possibilities (ArcMap, QGIS internal, Your PlugIn, ogr2ogr CLI) with the same dataset and all result have been identical.