Hi Brian, hi everybody, I am the one who worked out a simple writer for GeTiff files. I had no time yet to take a look at the javadocs you sent out, I might do that next week. Besides that all I can say about my experience with the current support for GeoTiff files in ImageIO is that I really would like to have more support when it comes to writing the GeoTiff tags back to the file which is quite poor right now (this is the reason why I add to use an external package to accomplish writing geotiff files).
As soon as I have the time to take a closer look at those javadocs I will give you some more fedback even because I am rewriting these days a more general and optimized reader/writer for geotiff files through ImageIO . Ciao, Simone On 10/13/05, Bryce L Nordgren <[EMAIL PROTECTED]> wrote: > Brian, > > 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. > > 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.. > > 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. > > 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. :) > > Bryce > > [EMAIL PROTECTED] wrote on 10/12/2005 06:40:18 PM: > > > This is helpful information & thanks for forwarding the message. > > > > Please note that we are not guaranteeing that we will add this GeoTIFF > > support, only that it is being considered and we wanted to get some > feedback > > on it. > > > > Thanks, > > > > Brian > > > > On Thu, 13 Oct 2005, Martin Desruisseaux wrote: > > > > > Brian Burkhalter a écrit : > > >> So would the addition of improved GeoTIFF handling such as > > described by the > > >> posted javadoc help in any way? Would you be able to replace > yourexisting > > >> GeoTIFF reader? (I'm saying you would replace just asking whetherthis > one > > >> would be sufficient.) > > > > > > I think it would help, and I'm very interrested in replacing our > current > > > GeoTIFF reader by this one. It is hard to be sure before we try to do > the > > > switch, but I believe that the proposed API is exactly what we need. > > > > > > I forwarded the GeoTIFF request for comment on the Geotools mailing > list a > > > few days ago, since I'm not the author of the "geotiff reading" > > part (I only > > > wrote the "coordinate transformations" and "image processing" > > parts). I plan > > > to take a close look to GeoTIFF myself when I will have a chance, > > but it may > > > take a few months... I will certainly try to replace our current reader > by > > > the proposed one at this time. > > > > > > Thanks for yours work, > > > > > > Martin. > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > ---------------- > > 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. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
