<br><font size=2 face="sans-serif">Lidiriel,</font>
<br><font size=2 face="sans-serif"> All
PDS, ISIS2, and ISIS3 drivers should support detached labels for the simple
raw (or ISIS3 tiled) formats (now the PDS reader doesn't support detached
JP2 images yet). There have been a few fixes in the last few months
for these planetary readers so try to stick with 1.6.x.</font>
<br>
<br><font size=2 face="sans-serif">The minimal PDS driver was implemented
because it was similar to ISIS2 thus it is not very robust. The goal for
all these drivers was to mainly capture the projection information for
GIS/RS applications thus it is not meant for non-projected or raw PDS (EDR)
images. There are MANY non-standard PDS images in the wild (e.g. missing
projection parameters, incorrect offsets for X,Y corners, odd labels),
so it can be very hard to generate a generic PDS reader which checks for
all the known issues. One future goals I had was to utilize an existing
PDS library to enhance the currently used very simple label parser that
we wrote and Frank fixed up for us. There are a few good library examples
discussed here: http://www.orrery.us/node/44 . However, PDS3 has a short
life span ahead of it. There are talks of a new PDS2010 standard
to replace PDS3. This will probably be available in 2010 or 2011. </font>
<br>
<br><font size=2 face="sans-serif">Simple fixes for current PDS label that
would be great for one, like yourself, or other to implement. </font>
<br><font size=2 face="sans-serif">1.) PDS detached label that points to
JP2 image. Currently the PDS reader only support raw images</font>
<br><font size=2 face="sans-serif">2.) Band name propagation (or other
metadata? that can be easily mapped into GDAL).</font>
<br>
<br><font size=2 face="sans-serif">But any changes or enhancements would
be welcome. I really hope the PDS itself will get behind this driver and
help to support its ongoing development. I think they (PDS at JPL) are
using to create browse jpeg images for the new Mercury images. There are
just not many good readers out there for PDS (Nasaview has it place but
is not very useful). And really hope they will consider GDAL support for
the new PDS2010 format - whatever that will be. Maybe they will even choose
to be compatible to an existing format! I can only hope.</font>
<br>
<br><font size=2 face="sans-serif">Again, I never meant for this reader
to support raw EDR images because those come in many different styles of
compressions (e.g. MOC can have none, discrete cosine transform or Walsh-Hadamard
transform compression). It is currently intended for only map-projected
raw PDS3 images.</font>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br><font size=2 face="sans-serif">Trent</font>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Frank Warmerdam <warmerdam@pobox.com></b>
</font>
<br><font size=1 face="sans-serif">Sent by: gdal-dev-bounces@lists.osgeo.org</font>
<p><font size=1 face="sans-serif">01/14/2009 10:55 AM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">lidiriel <ludovic.mercier@gmail.com></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">gdal-dev@lists.osgeo.org</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: [gdal-dev] improve PDS and Isis
drivers</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt>lidiriel wrote:<br>
> hi,<br>
> <br>
> I work with several pds files and i have many idea for improve<br>
> driver :<br>
> <br>
> Add several domaine (for obtain a classification) with standard<br>
> Metadata like describe in "PDS standars reference" document
(chapter5<br>
> v3.7) each domain can contains a minimum number of keys.<br>
> <br>
> domaine name (dn): LABEL_STANDARDS<br>
> keys : PDS_VERSION_ID, DD_VERSION_ID, LABEL_REVISION_NOTE<br>
> <br>
> dn : FILE_CHARACTERISTICS<br>
> keys: RECORD_TYPE, RECORD_BYTES, ...<br>
> <br>
> dn : IDENTIFICATION_DATA_ELEMENTS<br>
> keys: DATA_SET_ID ...<br>
> <br>
> <br>
> implementation of reading a detached data in first time for ISIS2<br>
> driver :<br>
> ("filename", nnn) (chapter 5 page 13 of PDS specification
v3.7)<br>
> Many of my data use this last notation and for using gdal i will must<br>
> implemented this in priority.<br>
<br>
Lidiriel,<br>
<br>
I am reasonably supportive of adding capture and exposure of metadata<br>
from PDS, ISIS2 and ISIS3 datasets in some appropriate fashion. I'd<br>
be open to appropriate patches though I'm not inclined to do much more<br>
directly as implementation than I have already done, unless my original<br>
client (USGS) demonstrated an interest.<br>
<br>
I believe we do have some support for detached datasets. Perhaps
that<br>
is only in ISIS3? I would be happy to have detached support also
added<br>
in ISIS2.<br>
<br>
Best regards,<br>
-- <br>
---------------------------------------+--------------------------------------<br>
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com<br>
light and sound - activate the windows | http://pobox.com/~warmerdam<br>
and watch the world go round - Rush | Geospatial Programmer
for Rent<br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
gdal-dev@lists.osgeo.org<br>
http://lists.osgeo.org/mailman/listinfo/gdal-dev<br>
</tt></font>
<br>