Moritz Lennert: > I don't have the feeling that either 4326 or 31370 > offer multiple possibilities for transform parameters, > but don't know for 100% sure.
no, they don't. LL WGS84 is just that (as long as we consider it the root coordinate system), and 31370 explicitly gives 7 term +towgs84= params AFAICT. AFAIU the ambiguity of which transform params to use comes only when +datum= is given without the hint of which path to take to get there. > But the way I read the above nabble thread (and especially > Frank's quote) the issue is that some projections are missing > in the proj and thus the QGIS database because of the multiple > transform possibilities strictly speaking the "projection" (lcc) is there and fine, but (AFAIU) the datum transform params for a given datum are left out if there are more than one option in the upstream EPSG database. But the +datum= name should still be given in that case. but I think that is a misdirection: in this case I think QGIS's srs.db is broken, missing *all* datum info not just the ambiguos transform params. The issue Frank raises still applies, but I do not think it is the main problem here. > (so when you use the default proj epsg file in GRASS the same > problem probably applies). No, in those cases GRASS prompts the user to pick the appropriate method from a list, with the default at the top of the list. the PROJ epsg file is not broken in this sense, only limited in the information it provides. the QGIS srs.db file is broken. FWIW GRASS uses its own $GISBASE/etc/datum*, etc/proj*, and etc/ogr_csv/* files, the PROJ epsg file is only used in the startup GUI location creation wizard (we should change that so they all use the same). The ogr_csv files are sync'd (typically by Markus) with the latest GDAL versions prior to each release or after each new upstream EPSG DB release. Note AFAIU the current PROJ epsg file awaits regeneration for minor FP tweaks arising from the latest atof() GDAL issue commits. string comparison of the scaling factor etc used by QGIS are no longer equal... > However both of the projections _are_ in the database and > QGIS recognizes them. but they are incomplete! compare the entry for epsg:31370 in /usr/share/proj/epsg and in /usr/share/qgis/resources/srs.sb (using sqlitebrowser or such). you will see the srs.db version is missing the +towgs84= part. (epsg:31370 is srs:1817 there, or just go to the layers proj properties in QGIS and look) > So, I'm not sure whether this is an issue with the epsg > codes, or rather a problem with the transformation code. incorrectly generated QGIS srs.db file I think. > But I think it's time to take this over to the relevant > QGIS and gvSIG (which has the same problem) mailing lists... qgis bugs: http://trac.osgeo.org/qgis/ticket/1035 http://trac.osgeo.org/qgis/ticket/1037 http://trac.osgeo.org/qgis/ticket/1079 Could you could create/find the gvSIG report? whole lotta qualifiers, Hamish _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
