[Qgis-developer] SRS DB maintenance
Radim Blazek
radim.blazek at gmail.com
Wed Jul 3 13:03:48 PDT 2013
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
More information about the Qgis-developer
mailing list