Maciej Sieczka wrote:
QGIS fails to recognize many SRSes at layer load time, due to a
change in GDAL [1].
[1]http://www.nabble.com/forum/ViewPost.jtp?post=16592790&framed=y
anybody has a solution to this?
The only "solution" I know of for now is to revert back to GDAL 1.4.2
(the last release not including the mentioned change).
Another would be to trim off the spurious zeros from k parameter in QGIS
srs.db. Although this would break compatibility between QGIS and GDAL <
1.4.4 it should not be an issue as GDAL 1.4.2 is pretty old now.
However, deleting these zeros might break QGIS interaction with POSTGIS,
as even the newest 1.3.3 release stores k paramaters with extra zeros in
spatial_ref_sys table, column 'proj4text column'. QGIS devs - is this
guess correct? I already asked about that on the ML but here was no
response. Any feedback will be very appreciated so it can be decided if
deleting these zeros is safe.
Ideally, QGIS should compare numerical values of SRS parameters, not
strings as it does now, so that eg. it considered 0.999300 equal 0.9993
and no problem. QGIS devs - could this be applied?
Note that there is another related bug in GDAL > 1.4.4 [1], which also
prevents SRS recognition is QGIS. Fixed in trunk, awaiting to be
backported to 1.5 stable branch. Once this is done and once we decide if
to delete the offending zeros in srs.db, I'll get back to updating
srs.sb to match the latest EPSG database used in PROJ and GDAL.
Hi Maciej and others,
just to be sure I still understand the discussion about these
'srs'-problems:
1) comparing srs as numeric or string, OR revert back to older GDAL:
I'm not able to change the comparing part of the SRS parameters myself.
But it seems reasonable to me to do so?
Who can, or who has arguments against it?
IF that is fixed, we get rid of the 'trailing-k-factor--bug isn't it?
2) GDAL-bug
We as qgis-team cannot do something on the GDAL problem, is it? Just
wait till it's in the stable branch for us?
Maybe we should write a wiki-page for this stuff so people who build
both GDAL and QGIS themselves can be aware of these problems, and can
make a decision of what GDAL-version to use on that ...
3) generating the srs.db by epgs_tr.py
Who is trying to update the epsg_tr.py for the qgis srs.db now?:
http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/python/scripts/epsg_tr.py
Is that you Maciej, or are you or Frank waiting on the GDAL-problem to
be fixed?
If we are in line with the postgis and other srs definitions, that would
fix some problems also isn't it?
4) the fact that certain srs's are deprecated, or not ok (anymore).
This kind of information is not only interesting for QGIS users, but
also for other users of the srs-list.
Is somebody aware of a 'list' of deprecated of not to be used
epsg-parameters (e.g. I know the dutch epgs is still wrong....).
If we can find (or build) a central source for this (it's not in the
official epgs-mdb isn't it?), it can maybe included in the
srs-lists/db's (extra column, extra group?) so users can see this?
5) the fact that certain projections have more then ONE possible
parameter-string, and the srs-list reveres back to a
'default/general'-parameters.
If we could include this info into the srs.db also, we could point users
to a information source (wiki page) where there is some info about the
usable param-strings?
Regards,
Richard Duivenvoorde
_______________________________________________
Qgis-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-user
