[Qgis-developer] [Fwd: Re: [Qgis-user] projection bug?]

[Maciej Sieczka]

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