[GRASS-dev] Location EPSG code storage

[Hamish]

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