Hi Richard,
I'll try to adress some of your questions.
Richard Duivenvoorde pisze:
Maciej Sieczka wrote:
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
QGIS developers I guess. And I'm asking if they can/want to do this.
, or who has arguments against it?
I'm also curious.
IF that is fixed, we get rid of the 'trailing-k-factor--bug isn't it?
This is what I *suspect*. A QGIS developer please correct me.
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?
Yes. Yesterday Mateusz has taken this task, but there is one thing
holding him off - see comment 9, 10 in [1].
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?
Like I wrote in my previous email I'll wait with updating the srs.db
until bug [1] in GDAL stable branch is solved.
QGIS depends on SRS matching in proj4 format. The bug [1] corrupts
numeric values of SRSs in proj4 format in GDAL. SRS matching against
GDAL>=1.5 in proj4 format, either string or numeric wise, is broken
currently.
Thus, updating the QGIS srs.db now would not improve anything much yet -
even though we get rid of the "extra zeros i k" issue by trimmimg them
of from srs.db, there would still be the problem that QGIS would have
eg. k=0.9993 for EPSG:2180, while GDAL would have k=0.9993000000000001
and SRS matching would not work anyway.
If we are in line with the postgis and other srs definitions, that
would fix some problems also isn't it?
Definitely keeping the SRS definitions for PROJ.4, GDAL, QGIS and
PostGIS would prevent some headaches.
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
This can be obtained from the EPSG dataset.
(e.g. I know the dutch epgs is still wrong....).
You mean it's wrong in the EPSG dataset or in QGIS? You can verify the
actual status on the EPSG Registry website [2] and if it's wrong there
ask them to fix it [3].
If we can find (or build) a central source for this (it's not in the
official epgs-mdb isn't it?),
It is there. Table 'epsg_coordinatereferencesystem' column 'deprecated'.
it can maybe included in the srs-lists/db's (extra column, extra
group?) so users can see this?
If I'm able to do it I'll try to create a group of deprecated SRSs when
I'll be updating the srs.db.
5) the fact that certain projections have more then ONE possible
parameter-string, and the srs-list reveres back to a
'default/general'-parameters.
I'm not sure I understand what you mean. Could you elaborate?
Maciek
[1]http://trac.osgeo.org/gdal/ticket/2036
[2]http://www.epsg-registry.org
[3]http://www.epsg.org/Comms/Comment.asp
_______________________________________________
Qgis-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-user
