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

[Maciej Sieczka]

Folks,

Now that the bug in GDAL [1] is fixed and backported to stable branch,
as well as included in the 1.5.2 RC3 [2] I have written a Shell script
to update QGIS srs.db, based on the installed PROJ.4 and GDAL tools
output. Attached.

The script creates an SQL plain text dump that can be imported into
SQlite db eg. using SQLite Database Browser's "Import > Database from
SQL file" tool.

The ellipsoids (tbl_ellipsoid) and projections (tbl_projection) tables
are created parsing the proj command output. I chose this approach,
because looking at the original tables content it seems the original
tables were created the same way.

The tbl_srs table is created parsing the epsg_tr.py output. EPSG codes
to process are taken from the installed GDAL's pcs.csv and gcs.csv files.

The script is rather self-explanatory. I have successfully used it to
create an updated srs.db and have been using the database with QGIS for
a couple of hours now. SRSs strings that were not recognizable by QGIS
due to infamous "k" parameter issue due to a change in GDAL [3] and QGIS
depending on string-wise SRS mathing [4] are now recogized fine.

Tables structure and final SQL statements creating the view and indices
were copied from the original srs.db shipped with QGIS trunk r8544,
after dumping it to a plain text format with SQLite Database Browser.

Please test/fix and let me know! If the tool is allright, I hope it can
be included in the QGIS repository and used to update the official
srs.db when necessary.

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.


[1]http://trac.osgeo.org/gdal/ticket/2036#comment:14
[2]http://www.nabble.com/forum/ViewPost.jtp?post=17545259&framed=y
[3]http://trac.osgeo.org/gdal/changeset/12625
[4]http://trac.osgeo.org/qgis/ticket/1037
[5]http://trac.osgeo.org/qgis/ticket/1120
[6]http://trac.osgeo.org/qgis/ticket/1085

-- 
Maciej Sieczka
www.sieczka.org


-------------- next part --------------
A non-text attachment was scrubbed...
Name: qgis_srs.sh
Type: application/x-sh
Size: 4549 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/qgis-developer/attachments/20080601/e8b08841/qgis_srs-0001.sh