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
