QGIS » QGIS Application

Just checked that 1.6.0 is not affected. Due this issue, we are keeping our GIS labs on 1.6.0 release, as EPSG:25884 is the most used coordinate system in our university.

marisn - wrote:

Just tested 1.7.4 on Linux and found out that it suffers from the same issue.

The problem also does relate to a change in GDAL were most of the +datum= parameters were dropped and +towgs84= parameters were inserted. QGIS now ignores +datum=, if there's no match found.

EPSG:25884 and EPSG:2100 are only different by +towgs84 parameter:

$ gdalsrsinfo -o proj4 Baltic_93TM_QGIS_test.prj 
'+proj=tmerc +lat_0=0 +lon_0=24 +k=0.9996 +x_0=500000 +y_0=0 +ellps=GRS80 +units=m +no_defs '
$ gdalsrsinfo -o proj4 epsg:25884
'+proj=tmerc +lat_0=0 +lon_0=24 +k=0.9996 +x_0=500000 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs '
$ gdalsrsinfo -o proj4 epsg:2100
'+proj=tmerc +lat_0=0 +lon_0=24 +k=0.9996 +x_0=500000 +y_0=0 +ellps=GRS80 +towgs84=-199.87,74.79,246.62,0,0,0,0 +units=m +no_defs '

WKT of the shape:

PROJCS["ETRS89_TM_Baltic93",
    GEOGCS["GCS_ETRS89",
        DATUM["ETRS_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",24],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]

I don't know when (and why) +datum was removed from gdal output of proj.4 strings, but the problem here is that .prj files do not have +towgs84 parameters.

In gdal 1.9 this can be fixed with the config option GDAL_FIX_ESRI_WKT=TOWGS84
see OGRSpatialReference::morphFromESRI() and GDAL #4345

$ GDAL_FIX_ESRI_WKT=TOWGS84 gdalsrsinfo -o proj4 Baltic_93TM_QGIS_test.prj
'+proj=tmerc +lat_0=0 +lon_0=24 +k=0.9996 +x_0=500000 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs '

Perhaps this config option could be added to the GGis environment? How does master deal with this problem?

marisn - wrote:

Unfortunately issue is back in master.

1.9.0-Master
QGIS code revision 078f5b8

Running GDAL 1.8.1

This should be fixed with GDAL 1.9 (see the commit)

Forgot to add version information:

QGIS versija 1.9.0-Master
QGIS code revision ad437bf
Compiled against GDAL/OGR 1.9.1
Running against GDAL/OGR 1.9.1

Also fix only for OGR >1.9.x is unacceptable, as due to QGIS + OGR layer encoding issues, it's not possible to read/write shapefiles with GDAL/OGR 1.9.x (yes, shapefile encoding still doesn't work at all when QGIS runs with GDAL/OGR 1.9.1!) and thus GDAL/OGR 1.8.x is the only option for many QGIS users.

marisn - wrote:

Forgot to add version information:

QGIS versija 1.9.0-Master
QGIS code revision ad437bf
Compiled against GDAL/OGR 1.9.1
Running against GDAL/OGR 1.9.1

Also fix only for OGR >1.9.x is unacceptable, as due to QGIS + OGR layer encoding issues, it's not possible to read/write shapefiles with GDAL/OGR 1.9.x (yes, shapefile encoding still doesn't work at all when QGIS runs with GDAL/OGR 1.9.1!) and thus GDAL/OGR 1.8.x is the only option for many QGIS users.

not sure, but aren't both gdal issues?

Giovanni Manghi wrote:

not sure, but aren't both gdal issues?

Well. No. They both are QGIS issues triggered by changes in GDAL/OGR/Proj. GDAL/OGR doesn't mandate EPSG code to operate on datasets. I don't know if it's QGIS doing the wrong guess or GDAL/OGR, still end result is clear - QGIS uses wrong CRS, OGR tools use right one. As long as QGIS was using just datasets .prj file contents, it was fine.

Here's example how to check it:

ogr2ogr -s_srs epsg:2100 -t_srs epsg:4326 est_gre.shp estonia_generalized.shp
ogr2ogr -s_srs epsg:25884 -t_srs epsg:4326 est_bal.shp estonia_generalized.shp
ogr2ogr -t_srs epsg:4326 est_raw.shp estonia_generalized.shp

As goes for encoding issues - I'm fed up with them. It's still not possible to specify correct encoding in layer preferences or when adding vector dataset AND get data in specified encoding. Pointing out that there are also issues on QGIS side is threated like blasphemy. Still most likely I will reopen bugs when GDAL/OGR 1.9.2 will come out and issue will still exist.

Pointing out that there are also issues on QGIS side is threated like blasphemy.

I'm sorry but you are plain wrong. If you check you will see I'm the top bug reporter (or the second one, anyway I'm the top one in the last 3 years) -> I have no interest in not reporting a QGIS bug, on the other hand I'm very interested in hunting any possible bug.

Here the point is to keep the tracker as clean as possible, avoiding to have open tickets that are not right/necessary and eventually redirecting the issue upstream to other projects trackers.

Still most likely I will reopen bugs when GDAL/OGR 1.9.2 will come out and issue will still exist.

I have no reason to not believe you, anyway we will see as soon as qgis will be compiled against gdal 1.9.2

In any case if the latest gdal version available has the issue described here fixed, I don't understand why this should be left open. But anyway I will leave the last word to someone else.

marisn - wrote:

As long as QGIS was using just datasets .prj file contents, it was fine.

That's part of the problem. QGIS doesn't use the .prj directly and AFAIK never did. It only uses it to find a match in the srs.db and actually use the projection defined there.

And finding that match became more complex after the GDAL change, because the datum parameter was dropped from GDAL and replaced with the towgs84 parameter. And therefore QGIS would fail to recognize those as there wasn't an exact match anymore and in turn produce a user CRS. So people started to complain about user CRSs instead of EPSG CRSs. So the detection was relaxed a bit by ignoring the +datum parameter, if there's no match otherwise.

Unfortunately there are some CRSs that are only different by the datum parameter - the above two being one of those pairs. And QGIS did pick the first hit even if there are more than one.

42a9d0193 changes that. So now, QGIS produces a user crs for estonia_generalized.shp now. BTW Baltic_93TM_QGIS_test.shp still worked for me. Still a compromise and hopefully not one that breaks other things.

As goes for encoding issues - I'm fed up with them.

Welcome to the club.

It's still not possible to specify correct encoding in layer preferences or when adding vector dataset AND get data in specified encoding. Pointing out that there are also issues on QGIS side is threated like blasphemy.

"threated" should have been "treated", shouldn't it? No one is threatening anyone, right?