Bryce,
Thanks for your comments. Please see below.
Comment one:
One thing you should be very careful to do is to stress that you are
providing metadata access only! It will always be the responsibility of a
plugin for a particular application to adapt between the metadata (which
you provide access to) and the application's internal notions of the
geospatial concepts involved. As a warning, you've already received a
request for conversion from x/y to lat/lon (more generally, other map space
coordinates) as a response to this request for comments.
Your support should terminate at the point where your code would need to
start _understanding_ what is being encoded. :) You are just the taxi
driver. As long as the passenger can provide content, you drive it to the
destination.
I concur. As an aside, I once wrote a comprehensive, extensible terrestrial
coordinate conversion library (in C) so I know exactly the level of complexity
you're talking about here. And yes, it did support vertical datums. ;-)
Casual usage of the term "GeoTIFF reader" should either cease entirely or
should be qualified by _repeating_ that you only provide convenience
methods for properly encoding and decoding the geospatial metadata.
Otherwise, people will continually whine that you're not able to reproject
to UTM from Geographic Lat/Lon, etc..
I don't think I used the term "GeoTIFF reader" but maybe someone else did.
The intent of the sub-package is merely to simplify read-write access to the
GeoKeys. In my initial proposal this is via convenience methods but that could
change. I think in fact it would be more in keeping with the spirit of Java
Image I/O to provide the GeoKeys via an alternate XML schema.
Comment two:
I wrote the current geotiff reader for Geotools. There are approximately
five or six classes involved, most of which exist only to adapt the
metadata into the Geotools coordinate reference system framework. The
process of extracting metadata from the GeoTIFF file is accomplished by a
single class written by Mike Nidel. Others in Geotools undertook the task
of adding write capability and extracted a "metadata composer" from the
BEAM library. The result is a rather unseemly aggregation of code from a
variety of sources, possessing no common design.
I scrupulously avoided looking at any other implementations of GeoTIFF
metadata support to avoid any possible licensing issues so I don't know what
your code looks like.
As the pathetically lazy and eternally distracted module maintainer for the
Geotiff module in Geotools, I would most eagerly replace the current
Metadata IO code with your code. As noted above, this is not equivilant
with replacing the entire GeoTIFF reader plugin. :)
We are most pleased to have any assistance in improving the GeoTIFF support
whether that be via comments on our proposed design or actual coding (we of
course would need the contributor's agreement to be on file).
Thanks,
Brian
----------------
Brian Burkhalter
Java Multimedia, Imaging, and Graphics
Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any
unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
