[Qgis-developer] SRS DB maintenance

Radim Blazek radim.blazek at gmail.com
Mon Jun 3 10:19:51 PDT 2013


On Mon, Jun 3, 2013 at 6:42 PM, Jürgen E. <jef at norbit.de> wrote:
> Hi Radim,
>
> On Mon, 03. Jun 2013 at 17:41:24 +0200, Radim Blazek wrote:
>> But in fact, at this moment, we do maintain 3906 records in tbl_srs in
>> resources/srs.db and occasionally we add requested missing records but it is
>> difficult to trace down what/why/when was changed and it is not clear which
>> records from resources/srs.db are necessary addition to GDAL and what is just
>> duplication.
>
> 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.

OK, in that case let us throw away everything from srs.db. What I am
worrying about is that GDAL developers will be reluctant to accept new
CRS. It took years to convince Frank to add a single switch to krovak
projection without which it was completely unusable in GIS
applications.

> 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.
>
> I just remember problems when the definitions in our database and the installed
> GDAL's differed (eg. when +towgs84 was added to GDAL).
>
> But I think that the stuff in our database might be useful to some users and
> even if it isn't it doesn't do any harm.

At least it makes confusion.

>> If we decide to fully rely on GDAL we should do it 100%, that means we should
>> delete everything from resources/srs.db but that means that QGIS becomes
>> suddenly unusable for people who contributed missing CRS to QGIS but not to
>> GDAL.
>
>> I don't say that we should maintain the whole database but we should have an
>> option to add what is missing. My suggestion is to fill empty srs.db by data
>> from GDAL during compilation/installation and then add missing CRS from a
>> text file. The initial version of the file with additional CRS could be
>> created as difference of current resources/srs.db and GDAL if it gives
>> reasonable data (not too many records).
>
> 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?

I was suggesting to overwrite the data from GDAL if necessary (towgs84
missing/wrong in GDAL), but it is problematic to decide which value is
better.

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

Which cases exactly? Are there important the values we added manually
to the srs.db or is it important to have full srs.db in cases when
GDAL data are not available or crssync cannot be run?

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

Well, still it is not clear to me if we maintain something or not. My
impression is that we do it half way. Either don't keep any addition
in to CRS DB in QGIS at all or do it transparently.

Radim

>
> Jürgen
>
> --
> Jürgen E. Fischer         norBIT GmbH               Tel. +49-4931-918175-31
> Dipl.-Inf. (FH)           Rheinstraße 13            Fax. +49-4931-918175-50
> Software Engineer         D-26506 Norden               http://www.norbit.de
> committ(ed|ing) to Quantum GIS                         IRC: jef on FreeNode
>
> --
> norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
> Rheinstrasse 13, 26506 Norden
> GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502
>


More information about the Qgis-developer mailing list