[Qgis-developer] script to update the srs.db
tutey at o2.pl
Wed Jun 25 05:44:51 EDT 2008
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)
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
> +no_defs <>
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 , 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.
More information about the Qgis-developer