[Gdal-dev] Adding Fugawi .JPR Support to GDAL

[Christian Doenges]

On 25.08.2004, at 22:04, Frank Warmerdam wrote:
> int GDALReadWorldFileEx( const char *pszBaseFilename, double 
> *padfGeoTransform,
>                          char ***ppapszMetadata, char *pszExtention, 
> ... );
>
> If ppapszMetadata is NULL then we don't even try to read the metadata.

Frank / Ed,

I _was_ going to modify the GDALDataset directly, but I see that this 
is not such a good idea if it will break existing drivers. And you are, 
of course, right about private code bases.

Metadata is my original fall-back solution, but there are a number of 
issues with it (see below).


> Of course this does mean that each place where it is called must take 
> care of
> integrating metadata from the .JPR file into the other dataset 
> metadata but
> that might be a task worthy of driver by driver consideration anyways.

It's not an optimal solution, since I'll need to modify 5 drivers. 
Maybe I can create a single function that will do the modifications for 
all of the drivers? So the driver will do something similar to:

if (GDALReadWorldFileEx(....))
{
     GDALApplyMetataToDataset(this, papszMetadata);
}

Since the function will only need to work for BMP, TIFF, JPEG, GIF, and 
PNG, it may be possible. I'll have to look into this.


On 25.08.2004, at 22:04, Frank Warmerdam wrote:
> Ahh, I see.  So the .JPR file can contain the geotransform, GCPs and
> SRS.  That will be a bit involved to return to the caller properly.

Which is why I wanted to modify GDALDataset directly in the first 
place. ;-)

I think it will be best to define a 'standard' set of metadata for 
this. The projection could, for example, be turned into an OpenGIS WKT 
or an EPSG identifier. It would make sense to include rules such as not 
having GCPs if we have the geotransform matrix (and vice versa) so that 
the .JPR parser can reduce the complexity of the data the driver will 
have to deal with.

Having 'standard' metadata would also help with other formats that 
allow, for example, specification of useable map boundaries or insets 
into the map.


On 25.08.2004, at 22:27, Ed McNierney wrote:
> Unfortunately, the spec says that all of the fields are optional, 
> which makes it a little tricky to accurately identify the file.  You 
> may wish to insist that it have a filename ending in .jpr; otherwise I 
> think you'd need to check for all the possible keys and see if any are 
> present.

I don't know all the ESRI extensions to TFW, so I don't know if any 
conflict with the Fugawi extensions. Is there a specification?

If I can rule out conflicts, I will simply loop through the lines and 
match what I can. When I'm done, I will collect the data and cluster it 
into metadata, as outlined above.

If I can't rule out conflicts, I will insist on .jpr.

Best regards,
Christian
---
Christian Dönges
Use GPS data on Mac OS X! <http://www.truenav.com/>