Maris: > >> Options: > >> a) add a new key-value pair to PROJ_INFO > >> + all information is stored in single place > >> + projection information reading/writing code is > >> already inplace > >> - it needs to be changed to deal with a new key-value pair > >> - breaks backwards compatibility Markus: > > For sure it breaks it? I didn't look at the routines. Martin: > I am not sure in which sense it could break the backwards > compatibility. The Key_Value structure for PROJ_INFO will > have one more item called "epsg" (or not if not defined).
Hi, this does require some thought. The seemingly obvious answer is to add a new epsg: 12345 line to PROJ_INFO, but I'm not sure that's the best idea. Rather, adding a new PROJ_EPSG file may be the better answer. reasoning: as I see it the trouble is not that we are losing computer- needed numbers, as the epsg code is expanded to its components. Is the motivation to record the epsg number mainly for human- readable metadata? in the same way as if you define a datum: it will be expanded to ellps:, a:, es:, f:, ... in the PROJ_INFO file. what happens if the user edits the file and the datum: no longer lines up with its expanded components? which terms will be used? probably that doesn't get touched much for datum:, but I suspect it could be a much more common problem for a new epsg: key as proj terms like false eastings, northings, and lon_0 are much more volatile, and epsg codes much less definitive than say a huge international congress in 1924 or 1984 coming up with a single datum standard. so is the core of the wish to simply record the meta-data of what the original EPSG code was, as a helpful aid to humans? If so, it doesn't need to be in the PROJ_INFO file at all, if it were in a PROJ_EPSG file then 'g.proj -p' could `cat` it the same way that PROJ_UNITS gets printed. one possibility is that we could add a epsg: code to PROJ_INFO and just always ignore it, but that seems like a recipe for bad assumptions to be made later on & would only cause trouble with the only upside being that it looks a bit cleaner on the surface. I suspect for proj4 the order of terms may determine which version of +init:epsg= or +other terms would take priority. how critical is it for the shapefile.prj files and WKT to export the epsg number in addition to the expanded datum and projection terms? ISTR that WKT can have some free-form text area we can take advantage of (in the same way as is done/was proposed to hold the +towgs84 terms which WKT had no formal way of recording) without the string matching heuristics/headaches how correct is it to re-insert AUTHORITY: EPSG... into the regular part of the WKT instead of some free-form part if we don't guarantee that it actually matches the expanded terms? should g.setproj delete the PROJ_EPSG file when it runs? perhaps Paul is lurking and could offer some perspective? perhaps we should cc the PROJ4 mailing list for repercussions we haven't considered? Hamish _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
