[Qgis-developer] SRS DB maintenance

[Werner Macho]

Hi!

As I had some problems with non existing EPSG Codes in the srs.db
lately too .. I support Radim here ..
It seem's that something is going wroing here .. While most of the
world is covered not all EPSGs are available or being overwritten ..

Isn't there an official "latest" database that we can just take? Or
try to make it easy for the user to update the db if connected to the
internet sync db on QGIS start or something like that?

kind regards
Werner

On Wed, Jul 3, 2013 at 10:03 PM, Radim Blazek <radim.blazek at gmail.com> wrote:
> On Mon, Jun 3, 2013 at 6:42 PM, Jürgen E. <jef at norbit.de> wrote:
>> There shouldn't be any necessary addition to GDAL in our database.   If there
>> is stuff missing from GDAL, it should IMHO be added there and not to QGIS.
>> That's why I usually point people to GDAL instead of adding it to our database.
>>
>> I can't tell if anything in our database is/was a better definition than what
>> GDAL has or if anything we have and GDAL doesn't is necessary or useful to
>> anyone or just cruft.
>
> There are new EPSG and towgs84 params for 5513, 5514, 5221,
> 2065,102067, 4156 and 4818 in QGIS but they are deleted/overwritten by
> wrong values from GDAL by crssync (at least in weekly build for win).
> Until we manage to push them also into GDAL, I need to preserve
> somehow the correct values from resources/srs.db.
>
>> All definitions that are unique to QGIS are left untouched and everything else
>> is overwritten with what GDAL (for EPSG) or PROJ.4 (for non-EPSG) has.  So the
>> final srs.db wouldn't be any different from what is now used now, would it?
>
> Unfortunately no, the new EPSG codes which are not in GDAL are deleted.
>
>> The point is that it's not tied to any particular version of GDAL/PROJ.4 (and
>> we use various versions across all the platforms and distributions).
>>
>> IIRC keeping our srsid is also important in some cases - so starting a fresh
>> database from whatever GDAL/PROJ.4 version is installed, isn't that easy
>> either.
>>
>> I agree that the current CRS handling (and that IMHO not only applies to the
>> srs database) is far from optimal, but we didn't come up with anything better
>> so far and the current approach is at least easy to "maintain".
>
> It seems to be impossible to be maintained. I have correct EPSG codes
> but no way to get it into distribution.
>
> Radim
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer