[Proj] Proj API feature requests

[Frank Warmerdam]

Judd Taylor wrote:
>     I've been using the proj library through the C API for a couple of years
> now. Although I like the simplicity of the API, a couple of extensions would
> be useful to make some of the command line tool's functionality available in
> C code without having to parse the command line tool's output.
>     Here's a list of what features would have made my life easier in the
> past, and a couple of things that would make things easy enough that I could
> add more functionality to my programs:
>     1. Verbose configuraion information, similar to cmdline's '-v' (to be
> used to generate FGDC compliant metadata).
 >     2. Per-point characteristics, similar to cmdline's '-V'

Judd,

I hadn't looked into this before, but it seems that there is a library
entry point called pj_pr_list() which produces the "-v" style output.  You
can also see how the -V output is generated in src/proj.c but it requires
"intimate" access into the PJ object as implemented.

For similar purposes I implemented a pj_get_def() function which attempts
to return a "fully expanded" set of projection parameters in use for a particular
definition.  This should expand +init stuff, include default ellpisoids, units
and so forth.  I am not sure it is comprehensive though.

On the issue of producing FGDC compliant metadata describing a coordinate
system, I don't really feel that belongs in PROJ.4 itself.  While Gerald might
argue that I am too quick to shove everything but the kitchen sink into the
remotesensing.org version of PROJ.4, I have traditionally considered conversion
to and from other coordinate system definition approaches as a higher level
API issue to be done outside PROJ.4.  I have developed conversion capabilities
to various other format, most notably OGC WKT, in my OGRSpatialReference
library.  I could also imagine a way of converting to/from FGDC metadata
descriptions of a coordinate system there.  However, I don't have the time
to work on such a thing just now.

>     3. Error estimation similar to cmdline's '-S' option.

This is apparently done with the pj_factors() function.

>     4. Querying through the API of available projections and their
> information, as well cartesian units querying, similar to the cmdline's
> '-l', '-lP', '-lu', and '-le' options.
> 
>     Returning strings would work in a pinch, but it would be nice to get
> direct access to the data structures that hold this information. After a
> quick look at projects.h, it looks like the interesting structs are going to
> be: PJ_LIST, PJ_ELLPS, PJ_UNITS, PJ_DATUMS, PJ_ELLPS, PJ_UNITS,
> PJ_PRIME_MERIDIANS, FACTORS. Of course, direct access to the structs via the
> API makes might break backwards-compatibility if they change down the
> road... so maybe something else may work better.

I'm pretty sure you can just access these structures if you have included
projects.h though how to do so isn't particularly well documented.

As noted in other messages, it is desirable for many applications to provide
GUIs for building PROJ.4 configuration strings.  I think it would not be
appropriate to do this directly within PROJ.4 ... because as has become obvious
in the following messages there are *many* possible choices of GUI toolkit.

However, what I would like to see is for PROJ.4 to make information available
in some machine usable format on what options there are and how they can be
combined.  This should include the lists of projections, ellipsoids, units,
datums, and prime meridians but also it should "know" which arguments can
be used with which projections, and should carry a brief description of all
the components.  This would make it much easier for applications to build
GUIs.

Even returning the information in machine readable format is a fair effort
if you want to document all the per-projection parameters, but we could start
by returning all the information already found in the various tables, and then
add more details later.

>     For #2-3 above, a seperate function for pj_fwd(), pj_inv(), etc... would
> be nice as the extended information would be available, but if you don't
> want it you could just call the normal functions which should be faster.

I'm not sure what extended information you are talking about here.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent