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

Tim Sutton tim at linfiniti.com
Mon Jun 9 09:31:02 EDT 2008


Hi Maciej

Rest assured we will include your updates before the feature freeze.
Richard is our srs.db maintainer so I suggest he should be the first
stop in evaluating this.

Regards

Tim

2008/6/9 Maciej Sieczka <tutey at o2.pl>:
> 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
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>



-- 
Tim Sutton
QGIS Project Steering Committee Member - Release Manager
Visit http://qgis.org for a great open source GIS
openModeller Desktop Developer
Visit http://openModeller.sf.net for a great open source ecological
niche modelling tool
Home Page: http://tim.linfiniti.com
Skype: timlinux
Irc: timlinux on #qgis at freenode.net


More information about the Qgis-developer mailing list