[gdal-dev] Re: [gfc-dev] GFC

[Liujian Qian]

>>>>> "Frank" == Frank Warmerdam <warmerda at h...> writes:

>> Yeah I agree with you. That's why I have the customHeader() methods in the importer
>> class. The idea is that GGridImporter puts whatever specialized information it deems
>> not of general interest in a custom header (an opaque block of data) of the GGrid.
>> It's the specialized GGrid subclasses, such as GDem or GRMImage, that can interpret
>> the custom header properly.

Frank> While this approach has some utility, it really gives very little opportunity
Frank> for code not specifically aware of that format (or class) to utilize the
Frank> data.

The thing is, even with the meta query mechanism you described below, if the
application code is not specifically aware of the format, how does it know
what names can be used to fetch the metadata associated with them? The problem
is that if you define a set of metadata names for each format, you quickly
lose the purpose of metadata, unless some sort of standard tags or metadata
names have been estabilished. Don't get me wrong though, I consider metadata
query/managment to be very useful to GDAL (and probably GFC as well),
for instance in the internal organization of format drivers, and isn't it 
always nice to have a database of meta data about all the formats GDAL 
understands. Hey you probably can add a GDALMetaManger to
maintain some kind of meta specification for each concrete GDALDataset
class.

This also gets me thinking about a flexible metadata management mechanism.
I think XML-based approach is a serious candidate. It is hiearchical and
it's just sooo flexible. And yeah you can have all the type information
in there as well. I just coined an example below for some LADSAT images :

<METADATA format_name = "LANDAST">
<NO_DATA_VALUE> ????	</NO_DATA_VALUE>
<DATA_TYPE>	int	</DATA_TYPE>
<AGENCY> NASA	</AGENCY>
<PERIOD>	12	</PERIOD>
<BAND id=1>
<NAME> green </NAME>
<SPECTRUM_RANGE> 0.45-0.575 </SPECTRUM_RANGE>
</BAND>
...
<BAND id=3>
<NAME> near infrared </NAME>
<SPECTRUM_RANGE> 0.70-0.83 </SPECTRUM_RANGE>
</BAND>
......
</METADATA>

This can have its own single xml file or it can stay with many other
<METADATA> records each specifying the metainfo of a format. You can
easily query this database with any existing XML parser. 
GFC already has a XML parser based on Clark's C expat package (very easy
to use), and I am thinking of more extended use of XML, not just for
metadata, but also for self-explained geo-dataset transfer over the
web. 

As far as I know, both FGDC and OGC are looking at XML very seriously
and some one has already implemeted the simple feature specification of
OpenGIS in XML... and here in Penn State we also have a group converting
all the FGDC metadata into XML formats....

Cheers,

L.J.

Frank> Within OGDI the updateDictionary() routine allows you to fetch a (potentially
Frank> long) string associated with a particular name. Some names are specific
Frank> to that format, and might not have meaning to much application code. 
Frank> Other names can be used to share extension data by convention between
Frank> a variety of drivers, and application code.

Frank> A similar approach was used with GeoGateway and the MetaDataIO() method. 

Frank> In GeoSoft DATs they also have a similar extension mechanism. 

Frank> My suggestion then is that you modify your customHeader() method to take
Frank> a name parameter, and perhaps to give a clue whether the returned data
Frank> can be interpreted as printable text, or only binary. 

Frank> In GeoGateway the Metadata mechanism was used for a variety of things
Frank> but well known conventions were established for some of them. For
Frank> instance a metadata item named "NO_DATA_VALUE" would contain as it's
Frank> value a string representation of the raster number which was considered
Frank> to be a no-data, or dummy value.

Frank> Metadata also provided a mechanism to return arbitrary text name value
Frank> pairs for specific formats. For instance the SpotSAR file format contained
Frank> a variety of interesting information about the acquisition parameters of
Frank> the dataset. They were all returned as metadata items where the name 
Frank> portion was prefixed by ``SpotSAR_''. The data didn't mean anything specific
Frank> to most applications, but a user could easily review it.

Frank> I haven't developed a metadata interface for GDAL yet. I have briefly
Frank> reviewed FDGC metadata standards from the states, and a couple of different
Frank> metadata representations, including the USGS/NASA ODL (Object Definition
Frank> Language?) for metadata. I don't know exactly how this will be handled
Frank> in GDAL, but I am thinking of going beyond the GeoGateway concept of a 
Frank> flag metadata dictionary to a (potentially) heirarchical set of information
Frank> and also to carry some typing information with the metadata. 

Frank> Best regards,

Frank> -----------------------------------+---------------------------------------
Frank> Who can give them back their lives | Frank Warmerdam, Software Developer
Frank> and all those wasted years? - Rush | URL http://members.home.com/warmerda
Frank> | warmerda at h...
Frank> ------------------------------------------------------------------------
Frank> Egroups is a FREE service thanks to NextCard Internet VISA.
Frank> Apply online now for an intro APR as low as 2.9%.
Frank> http://ads.egroups.com/click/137/2

Frank> Free Web-based e-mail groups -- http://www.eGroups.com


------------------------------------------------------------------------
Free Web-based e-mail groups -- http://www.eGroups.com