[Gdal-dev] Adding Fugawi .JPR Support to GDAL
warmerdam at pobox.com
Wed Aug 25 16:04:21 EDT 2004
Christian Doenges wrote:
> we want to add Fugawi .JPR file support to our application. I would like to
> put this into GDAL, since I guess that's where it belongs.
> .JPR is an extension to ESRI worldfile, where the 6 standard lines are
> followed by a set of key=value pairs. The graphics themselves can be in
> BMP, TIFF, JPEG, GIF, or PNG format.
> While I'm at it, I would like to change the interface even further to be
> int GDALReadWorldFile( const char * pszBaseFilename,
> GDALDataset *pDataset,
> const char *pszExtension,
> where the ellipsis denotes a variable number of pszExtension parameters.
> That way the number of calls can be reduced to 13 and the code will be
> streamlined somewhat.
> What do you think? I would really like to know if there is something that I
> overlooked or if you have a better suggestion for handling this.
What are the name=value items in the .JPR file? Are you planning to
apply them to the GDALDataset as metadata? I would note that ESRI sometimes
products .wld files with a much of projection parameters right in the .wld file.
So, if you are going to read beyond the first six lines you will need to be
careful to verify what you fin are Fugawi values, and not ESRI extensions
to the world file.
I have a couple of other notes:
o I prefer that you define a new version of GDALReadWorldFile() and just
have the old version call into the new version with appropriate
arguments if possible ... of possibly even duplicate the code. It may
be hard to get all places where GDALReadWorldFile() is used, some of
which are in private code bases. You might want to call the new version
o I like the idea of passing a list of extensions as a variable argument list.
o I am nervous about having GDALReadWorldFile() try and apply it's results
directly to a GDALDataset. For one thing, if you do this by calling the
SetGeoTransform() methods, some of the drivers may get confused and thing
this is the outside application calling, and that something on disk should
be updated. It also makes it harder to use the function for something other
than setting information directly on a dataset. I would suggest we stick
with passing a GeoTransform to set, and potentially also passing a char ***
into which a metadata list could be assigned if it is read from the
Thus we might have:
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.
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.
With the given caveats it sounds like a great improvement.
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
More information about the Gdal-dev