On Mon, Jun 3, 2013 at 6:42 PM, Jürgen E. <j...@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Reply via email to