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

[Marco Hugentobler]

Hi all,

I think switching to numeric representations of proj parameters would require 
major changed both in the program code and in the srs.db. That's probably why 
nobody volunteered to do so. 
Also, there will be feature freeze for 1.0 end of June and the probability to 
introduce many bugs with a reorganistion of code in qgsspatialrefsys.cpp and 
srs.db is very high.

My suggestion is to change the entries in srs.db once the major distros have 
gdal >= 1.4.4 bundled and then no longer supports the old entry style.

Afaik, the qgis postgres provider is not affected by the zero ending problem 
because it uses QgsSpatialRefSys::createFromSrid(int), so only searches in 
the database according to postgis srs id.

Regards,
Marco

Am Sonntag 11 Mai 2008 12:50:42 schrieb 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
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer



-- 
Dr. Marco Hugentobler
Institute of Cartography
ETH Zurich
Technical Advisor QGIS Project Steering Committee