[Qgis-developer] script to update the srs.db

[Maciej Sieczka]

Dear QGIS devs,

You have feature freeze today, right? Is the fixed srs.db going to be
included in the next QGIS relese? Does it have to be done before the freeze?

As I wrote in my initial post there are problems pending. Quoting them
again below. Please, take a look at issues #1 and #2 and let's decide
what to do. The bug [5] mentioned in #3 is fixed by Jürgen (thanks!) and
the other one [6] I can't reproduce anymore (no matter if I use the
original QGIS' srs.db or the one created with my script) so I closed it.

Maciej Sieczka pisze:

> Problems:
> 
> 1. Due to changes in SRSs, projections and ellipsoids support in
> PROJ.4 and GDAL in last years, rows id's in the tables created by the
> script are now different than they were in the original srs.db.
> Therefore, at the SRS dialog startup, QGIS cannot find it's default
> ll/WGS84 SRS in the updated srs.db, because it searches for "select
> srid from tbl_srs where srs_id = 2585", which is now "SIRGAS / UTM
> zone 24S". Shouldn't QGIS rather search by EPSG number? EPSG codes
> never change.
> 
> 2. In some PROJ.4 version the name "longlat" was changed into
> "lonlat" (and "latlong" to "latlon"). However, epsg_tr.py creates
> proj4 strings with the old name. My script parses proj command for
> the list of available projections and epsg_tr.py for SRSs. Since
> "longlat" != "latlon", the "Geographic Coordinate Systems" list in
> the SRS dialog was not active. Once I changed the "latlon" in
> tbl_projection to "latlong" the list is back. What do we do? Should
> epsg_tr.py be changed to output "latlon" rather than "latlong", or
> should my script replace "latlong" instances?
> 
> 3. BTW I noticed that QGIS resets k factor to 0, no matter how the
> SRS is chosen (automatically by SRS matching at layer load, or
> manually). This is not related to my srs.db changes, it's
> reproducible with stock srs.db too. A huge bug [5]! Please squash it!
> And this one [6] too, is possible.

> [5]http://trac.osgeo.org/qgis/ticket/1120 
> [6]http://trac.osgeo.org/qgis/ticket/1085

-- 
Maciej Sieczka
www.sieczka.org