[MetaCRS] A CS-Map usage scenario

[Norm Olsen]

Hello Howard . . .

- Does CS-Map read/write/interpret GeoTIFF keys?
No.  CS-MAP has no knowledge of GeoTIFF keys.

- I presume CS-Map does vertical datums.  Is describing those with GeoTIFF keys and WKT a problem?
CS-MAP does support 3-D operations in a limited way, but not vertical datums explicitly.  In the case of a 3D datum transformation (Molodensky, 7Parameter, Bursa/Wolf, etc) CS-MAP's 3D conversions will use and return the third dimension.  In the case of the NADCON conversion for the 48 states, a 3D conversion will use the VERTCON conversion technique to provide a vertical datum shift.  Other than this, there is no explicit support for vertical datums.

- What would be considered CS-Map's "public API" and how would one going about linking and using CS-Map in your own software?
I have been working on the documentation (sporadically I admit as we have a code cut-off next week) for the API.  There are two API's which are supported, a High Level Interface and a High Performance Interface.  See attached document for some cut and pastes from the existing documentation which is not quite ready for open source.

Pardon my ignorance, but with regard to "a convenient way to interact with SRSs", what do you mean by an SRS.

Norm

-----Original Message-----
From: metacrs-bounces at lists.osgeo.org [mailto:metacrs-bounces at lists.osgeo.org] On Behalf Of Howard Butler
Sent: Wednesday, February 04, 2009 9:10 AM
To: metacrs at lists.osgeo.org
Subject: [MetaCRS] A CS-Map usage scenario

All (well, Norm, mostly),

I develop a library called libLAS (http://liblas.org) that implements
the ASPRS LAS specification.  The spec defers its handling of SRS
information and basically says "use GeoTIFF keys," which is fine
except for the fact that GeoTIFF keys aren't human readable and few
softwares can interpret them.  Users of libLAS would like to not have
to worry about the guts of GeoTIFF key handling, and I would like for
libLAS to optionally provide linkage to handle the translation and
interpretation of the GeoTIFF keys.

For the libLAS 1.0 release, we used libgeotiff directly to turn the
GeoTIFF keys into a proj4 string and pass that around.  This was fine
for the 1.0 release but proj4's expressiveness is limited.  SRSNames
and EPSG codes disappear and kill your ability to have transitive
SRSs.  If I understand correctly, proj4 also doesn't do vertical datums.

For the next libLAS release, I would like to improve the situation.
Here's what I see as options, and I was hoping for some guidance on
what to do:

1) Plug my ears and close my eyes and say that proj4 is all anyone
would ever need :)
2) Provide an interface directly to the GeoTIFF keys and make the
users figure out how to interpret them.
3) Link to GDAL for OSR support.  This could provide GTIFGetOGISDefn
and GTIFSetFromOGISDefn which could do GDAL's WKT flavor <-> GeoTIFF
keys.  No vertical datum support as far as I know.
4) Use CS-Map.

I know how to do options 1-3, but I don't know if option 4 is viable.
A few questions come to mind, which I could maybe answer by diving
into the source code, but I was hoping for quicker answers :)

- Does CS-Map read/write/interpret GeoTIFF keys?
- I presume CS-Map does vertical datums.  Is describing those with
GeoTIFF keys and WKT a problem?
- What would be considered CS-Map's "public API" and how would one
going about linking and using CS-Map in your own software?

I would be interested to hear if there are options that I hadn't
considered for my usage scenario above.  I would like for libLAS to
provide a convenient way to interact with SRSs, but maybe this
minefield is too dense and too large.  Maps that tell me where not to
step would be greatly appreciated :)

Howard
_______________________________________________
MetaCRS mailing list
MetaCRS at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/metacrs