[PROJ] idea: projection metadata

[Even Rouault]

Nyall,

> Just wanted to bounce an idea I had recently. I'd love to see proj
> gain an API for querying projection metadata, specifically:
> 
> - retrieve a list of all available projection methods
> - given a a projection, retrieve the description, classification,
> available forms, defined area, etc metadata listed at the top of
> projection documentation page

"defined area" wouldn't be directly possible on a projection method, as this 
depends on the value of the projection parameters.
And it is tricky to define. There is the conventional/typical area of use (as 
typically found in the EPSG database in the 'area_of_use_code' column of the 
'epsg_coordoperation' table), but sometimes the implementation is accurate 
enough so that you can use it on whole Earth with excellent numeric accuracy 
(like tmerc now).

> Does this sound like a desirable inclusion in the proj API?

I think that would be a nice addition.

If we push the idea to its limits, we could even consider generating the 
documentation pages entirely, or substantially, from that (but would require 
to embed substantial prose & formulas sometimes)

> I'm willing to chip away at this in spare time, but would love some
> pointers on a recommended approach to take to implement it...

I don't have a ready-made design for this, but some thoughts to consider to 
design one:

- the computational part of PROJ (src/projections/) hasn't changed much in its 
architecture since original PROJ from 40 years ago. So it is mostly C based, 
and relies on instanciating a PJ* object (a coordinate operation) from PROJ 
string parameters. So there is currently no separation between the projection 
method itself, and its instanciation has a coordinate operation. Some
C++ification could be envisionned, but would be a quite substantial task

Maybe something like:
class TMercProjectionMethod : public AbstractProjectionMethod
{
	getPROJNick() { return "tmerc"; }
   getName() { return "Transverse Mercator"; }
   getParameters() { return { { "lat_0", "Latitude of natural origin", 0.0 }, 
... } };
   other metadata methods

   // Not completely sure about below. They are more concepts associated to a 
projection / coordinate operation instance than the method itself.
   bool setup(PJ*); // equivalent of existing PJ *PROJECTION(utm) 
   // what to do with fwd, fwd3d, fwd4D, inv, etc... function pointers. 
virtual methods ?
}

- (I'm thinking that the above proposal is somehow wheel reinvention, but for 
the sake of brainstorming, I've let it...)
In the 'metadata' / ISO19111 part of PROJ, we have a OperationMethod class 
(which comes from http://docs.opengeospatial.org/as/18-005r4/18-005r4.html#58) 
in include/proj/coordinateoperation.hpp that would be the natural candidate 
for a standard-based solution.

- GDALbarn work hasn't tried to integrate intimately the historic 
computational part of PROJ and the metadata/WKT one. They're bridged together 
in the most minimal possible way. Mostly because there was already plenty 
enough to do with the new functionality, and trying to 'merge' everything in a 
consistent way would have been a good recipee to have nothing working at the 
end :-)

- PROJ 6 work has brought some metadata, by matching EPSG parameters for EPSG 
recognized projection methods (and a few PROJ specific ones added with the 
same formalism) to PROJ parameter names. This is done through hard-coded 
tables as you've seen recently. The EPSG metadata exists in the original EPSG 
postgresql dump, but isn't imported in proj.db. proj.db conversion_table mixes 
a bit content from original epsg_coordoperation, epsg_coordoperationmethod, 
epsg_coordoperationparam, epsg_coordoperationparamusage and 
epsg_coordoperationparamvalue tables.
(if you want to see the original epsg database, import the PostgreSQL dumps at 
the upper right of https://www.epsg-registry.org/)

- Database-based vs hard-coded: regarding the previous item, I decided for 
hard-coded tables, because I wanted proj.db to be optional for a number of 
simple situations. That is if you ingest a CRS WKT, you should be able to use 
it to create coordinate operations that don't require datum transformations 
without requiring the database (accesses to it will be attempted, and warnings 
will be issued if it is not found, but you'll get a valid result)

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com