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

[Maciej Sieczka]

Richard Duivenvoorde pisze:

> this sounds all very good :-)
> 
> Three questions: - will this changes (Marco's and the new srs.db) 
> ship with 0.11?
> 
> - will there be a issue with people who try to build qgis with older 
> version of gdal/proj after this? In other words are we tied to a 
> specific set now? Or was that already be the case?
> 
> - the only 'open' issue then is the migration of non-epsg additions 
> in the old srs.db to the new srs.db?
> 
> Is it an idea to add some 'custom update script' to Maciej's script?
>  The purpose of this script will then be:
> 
> A) add non-standard-epsg records (from the old database)

Tim,

Regarding this - in srs.db there are srs_id 2673-2680, having epsg and
srid equal 0, 1000000-1000005, 102067 respectively. Would those be the
custom QGIS SRSs you once mentioned? Any other?

> B) fix 'errors' in the official epsg db (for example I know that the 
> first thing everybody in the netherlands does when installing a 
> proj-related program is to change the proj string of 28992 in the 
> nad/epsg file from <28992> +proj=stere +lat_0=52.15616055555555 
> +lon_0=5.38763888888889 +k=0.999908 +x_0=155000 +y_0=463000 
> +ellps=bessel +units=m +no_defs no_defs <> to <28992> +proj=sterea 
> +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.999908 
> +x_0=155000 +y_0=463000 +ellps=bessel +units=m 
> +towgs84=565.2369,50.0087,465.658,-0.406857330322398,0.350732676542563,-1.8703473836068,4.0812
>  +no_defs <>

Richard,

EPSG does not know anything about PROJ.4's stere or sterea. It is up to 
GDAL to choose PROJ.4 projection that matches the projection defined in 
the EPSG DB for a given SRS. There used to be an error in GDAL that it 
assumed stere for all stereographic SRS, while it came out that for 
Europe (at least Netherlands and Poland) a closer match is sterea. This 
was fixed, and for about 2 years now GDAL, including epsg_tr.py, uses 
sterea for these SRSs, which results also in a correct +proj for 
EPSG:28992 in the output of my script.

Regarding datum transformation - are there multpile datum transformation 
parameter sets for EPSG:28992? In case there are, GDAL (thus
epsg_tr.py, thus my script too) cannot decide for a single one, as
enforcing a sub-optimal one is as bad as not using any.

If you know for sure that there is a single, best datum transformation
for EPSG:28992, please report it upstream - at [1], and after done make
sure GDAL incorporates the fix.

> <900913> +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 
> +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs <> to be 
> able to handle google-map-mashups

Hmm. epsg_tr.py recognizes this code, yet it is not present in EPSG DB
and not in GDAL's pcs.csv. Only in GDAL's cubewerx_extra.wkt. I need to
think of these GDAL's overrides.

[1]http://www.epsg.org/Comms/Comment.asp

Maciek

-- 
Maciej Sieczka
www.sieczka.org