[Proj] Proj API feature requests

[Judd Taylor]

I guess I should have mentioned I'm using the remotesensing.org version of
the library...

More below...

----- Original Message ----- 
From: "Gerald Evenden" <gerald.evenden at verizon.net>
To: <proj at remotesensing.org>
Sent: Thursday, April 22, 2004 2:10 PM
Subject: Re: [Proj] Proj API feature requests


> I suggest you read some of the incomplete manual documentation of
> libproj4 on
>
> http://members.bellatlantic.net/~vze2hc4d/proj4/
>
> It contains a little more information on accessing some of the
> internals.
>

Thanks! Didn't know about that manual. It does answer alot of my questions.

> I have no idea what FGDC is so comment is difficult.
>

FGDC stands for the Federal Geographic Data Committee, a group that issues
metadata standards (among other things). Some of the more recent requests
for proposals we've been seeing require that geograpic data products
produced on the grant have metadata that conforms to the FGDC standard. I
can get some of the information I need from libproj. If I haven;t already
bored you enough about metadata, check out:
http://www.fgdc.gov/metadata/meta_stand.html.

> Prime meridians *are not* part of libproj4, so no comment.
>

Sorry, I just saw something possibly interesting in the projects.h header...
guess not.

> Most of what you request, although not necessarily documented is
> available
> by example in the [l]proj program.  The data structures referenced may
> be updated with different contents but the structure itself is likely to
> remain the same.
>
> I guess that part of what you want is a "tutorial" for each of the
> projections.(?)
> The library is not constructed with this in mind as it was designed as a
> filter program and expects the user to know how to perform cartographic
> projections and have a basic understanding of the necessary parameters.
>

Not really looking for a tutorial. I've been wanting to write a GUI where
users of my mapping software (which uses proj), can interactively create and
save configurations that include the parameters I pass to proj_init(). I'm
just thinking of populating menus, etc...

> As an aside, I had forgotten about some of the hyphen functions you
> mentioned
> and had to look them up myself.  These are all functions of the program
> [l]proj
> and not part of the library and except for changing proj to lproj I
> have not messed
> with its internals for years.  I only use it to test projections.
>
> My only concern is with the library and not with the program [l]proj
> which is
> distributed with the library as an example of how to use the library and
> as a reasonably usable filter function.  Certainly, write another
> interface
> to the library---I have for several applications like graphics.  But
> internal
> tables, structures are my concern and should not be tread upon without
> serious thought.
>

Thanks again,
    Judd


> On Apr 22, 2004, at 1:16 PM, 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'
> >     3. Error estimation similar to cmdline's '-S' option.
> >     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.
> >     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.
> >
> >     Any thoughts/ideas/volunteers?
> >
> > -Judd
> _____________________________________
> Jerry and the low riders: Daisy Mae and Joshua
>
> _______________________________________________
> Proj mailing list
> Proj at remotesensing.org
> http://www.remotesensing.org/mailman/listinfo/proj
>