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

[Richard Duivenvoorde]

Maciej, Marco,

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)

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 <>

another one is:
<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

these kind of 'fixes' could be collected in a 'post-processing' update?

What's your opinion about this?

Regards,

Richard Duivenvoorde




Marco Hugentobler wrote:
> Am Montag 23 Juni 2008 15:34:48 schrieb Maciej Sieczka:
>> Marco Hugentobler pisze:
>>> Unfortunately, I found some more occurences of GEOSRS_ID in the code.
>> So I understand we must preserve the original QGIS srsids, at least for
>> now - for the reason above and due to the fact there might be SRSs
>> present which are not included in EPSG database, as Tim mentioned -
>> right? If so, I'll modify the script to achieve this. Not today, maybe
>> tomorrow.
> 
> I think we must not preserve all srsids. For now it is only necessary to 
> insert the srsid value for wgs84 into qgis.h:
> 
> const long GEOSRS_ID = 2585; -> const long GEOSRS_ID = <new_wgs84_srs_id>;
> 
> And on my todo list is some coding that we don't need to change this line 
> everytime the srs.db is updated.
> 
> In nearly all cases, QGIS handles the srs with the proj4 string (exceptions 
> are some cases where QGIS needs a default crs and there is no default crs in 
> project file). So I don't think it is necessary to preserve the old srs ids.
> 
> Regards,
> Marco
> 
>> As to the "lonlat" vs "longlat" - AFAICS from my testing of gdalwarp and
>> gdaltransform, GDAL (1.5.2) does not support the shorter form - they
>> throw an error:
>>
>> ERROR 1: Translating source or target SRS failed:
>> +proj=latlon +ellps=WGS84 +datum=WGS84 +no_defs
>>
>> This means we should stick to the old "longlat" name in QGIS. Although
>> PROJ.4 defaults to the shorter "lonlat" these days, I verified it at
>> least supports both forms, so this should not be a problem.
>>
>> Maciek