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

[Richard Duivenvoorde]

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