[QGIS-trac] Re: [Quantum GIS] #1035: automated generation of srs.db (in line with postgis, proj and gdal)

[Quantum GIS]

#1035: automated generation of srs.db (in line with postgis, proj and gdal)
----------------------------------------------------+-----------------------
        Reporter:  rduivenvoorde                    |         Owner:  nobody           
            Type:  enhancement                      |        Status:  new              
        Priority:  minor: annoyance or enhancement  |     Milestone:                   
       Component:  Build/Install                    |       Version:  HEAD             
      Resolution:                                   |      Keywords:  srs.db projection
Platform_version:                                   |      Platform:  All              
        Must_fix:  No                               |   Status_info:  0                
----------------------------------------------------+-----------------------
Comment (by hamish):

 IMHO it is absolutely critical that srs.db be generated automatically. It
 is just too big a task to edit the 3500 standard EPSG codes by hand for
 every new release.


 The srs.db as now is broken. +towgs84= params are missing when they are
 part of the EPSG definition. The ambiguity arises when +datum=foo is given
 but there are multiple ways to get to foo, such as any number of local 3
 term, 7 term, or NTv2 distortion grid file transform methods.

 if the EPSG code includes +towgs84= you already have your explicit answer
 of which transform params to use. but those seem to be stripped out in
 QGIS's srs.db. e.g. EPSG code # 31370. also +datum= is in the EPSG file
 for NZMG (epsg 27200) but removed from QGIS's srs.sb entry. That's an
 example of one with multiple choices (see comment in bug #1079).

 So that missing info is nothing to do with the ambiguity cases AFAIK. (?)


 fyi, grass throws up a GUI in these cases asking the user which one they'd
 like to use:
 http://grass.osgeo.org/grass63/screenshots/images/grass63_startup2.png


 I think it is a great idea that work should go into adding a --qgis
 extension to GDAL's python epsg processing script. outsource it to the
 experts!
 For GRASS we (ie Markus) will typically sync and regenrate our
 $GISBASE/etc/ogr_csv/* files after each new GDAL release/before each one
 of our releases. It seems to work well. We also have datum.table,
 datumtransform.table, ellipse.table, and proj* files in our (share) etc/
 directory to draw from. You'd have to ask Paul Kelly for details of how it
 all works together.


 The k-factor bug is just a symptom I think, with the real cause being that
 QGIS is both out-of-sync with itself (srs.db and other internal code??)
 and expecting exact string matches. Both of which are rather brittle.
 see GRASS's libgis for code for removing trailing 0s from a numeric
 string.

 the change in GDAL which seemed to have raised the issue happened due to
 the replacement of atof() in the code with a i18n comma as decimal place
 capable version, which lead to FP differences in the lesser significant
 bits (well it being treated as something other than a string too). The new
 fn has been modified AFAIK in GDAL svn, but a new epsg file for proj has
 not yet been been generated (I checked the CVS yesterday). Use the epsg
 file that came with PROJ 4.5.0 if you are worried.

 the "towgs84-part in the parameter-list is no longer optional" is more to
 do with the change in gdal 1.5.0? regarding if datum transforms will
 happen if datum (or ellps?) params are explicity given on the from and +to
 coord systems.


 hope that helps, and that I'm not too confused by how this all fits
 together.

 summary: srs.db is broken as compared to proj's epsg text file. automate
 the generation of it ASAP or continue to feel the pain. eventually QGIS
 will need a datum picking GUI to resolve the ambigous cases. If doing
 exact string matching, make sure your sources are in sync.


 Hamish

-- 
Ticket URL: <http://trac.osgeo.org/qgis/ticket/1035#comment:5>
Quantum GIS <http://qgis.org>
Quantum GIS is an Open Source GIS viewer/editor supporting OGR, PostGIS, and GRASS formats