Thanks Trent for your reply. I'm not sure to have completly understand your reponse (i don't speek english fluently :( ). But i have notice the interresting link http://www.orrery.us/node/44 for PDS Meta parser. I think that i will kept to use gdal and if is necessary for my work i will created several patch. I work on a software that it must load PDS file (mainly Isis2 EDR with separate binary data). Now i will upload a new patch for get metadata : isis2dataset.patch2 three domains : "LabelStandards", "FileCharacteristic", "Identification" and all other keyword are load in main domain : "".
regards On 16 jan, 18:31, Trent M Hare <[email protected]> wrote: > Lidiriel, > 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. > > 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. > > Simple fixes for current PDS label that would be great for one, like > yourself, or other to implement. > 1.) PDS detached label that points to JP2 image. Currently the PDS reader > only support raw images > 2.) Band name propagation (or other metadata? that can be easily mapped > into GDAL). > > 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. > > 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. > > Regards, > Trent > > Frank Warmerdam <[email protected]> > Sent by: [email protected] > 01/14/2009 10:55 AM > > To > lidiriel <[email protected]> > cc > [email protected] > Subject > Re: [gdal-dev] improve PDS and Isis drivers > > > > lidiriel wrote: > > hi, > > > I work with several pds files and i have many idea for improve > > driver : > > > Add several domaine (for obtain a classification) with standard > > Metadata like describe in "PDS standars reference" document (chapter5 > > v3.7) each domain can contains a minimum number of keys. > > > domaine name (dn): LABEL_STANDARDS > > keys : PDS_VERSION_ID, DD_VERSION_ID, LABEL_REVISION_NOTE > > > dn : FILE_CHARACTERISTICS > > keys: RECORD_TYPE, RECORD_BYTES, ... > > > dn : IDENTIFICATION_DATA_ELEMENTS > > keys: DATA_SET_ID ... > > > implementation of reading a detached data in first time for ISIS2 > > driver : > > ("filename", nnn) (chapter 5 page 13 of PDS specification v3.7) > > Many of my data use this last notation and for using gdal i will must > > implemented this in priority. > > Lidiriel, > > I am reasonably supportive of adding capture and exposure of metadata > from PDS, ISIS2 and ISIS3 datasets in some appropriate fashion. I'd > be open to appropriate patches though I'm not inclined to do much more > directly as implementation than I have already done, unless my original > client (USGS) demonstrated an interest. > > I believe we do have some support for detached datasets. Perhaps that > is only in ISIS3? I would be happy to have detached support also added > in ISIS2. > > Best regards, > -- > ---------------------------------------+-------------------------------------- > I set the clouds in motion - turn up | Frank Warmerdam, > [email protected] > light and sound - activate the windows |http://pobox.com/~warmerdam > and watch the world go round - Rush | Geospatial Programmer for Rent > > _______________________________________________ > gdal-dev mailing list > [email protected]http://lists.osgeo.org/mailman/listinfo/gdal-dev > > _______________________________________________ > gdal-dev mailing list > [email protected]http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
