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

Roger Bedell roger at sylvanmaps.com
Wed Aug 25 16:38:54 EDT 2004

While we're in the vicinity,

How about the OziMap format? The ones I've seen have three tie points in
them, and need to be warped to bring them into a projection.


-----Original Message-----
From: gdal-dev-bounces at xserve.flids.com
[mailto:gdal-dev-bounces at xserve.flids.com] On Behalf Of Frank Warmerdam
Sent: Wednesday, August 25, 2004 2:04 PM
To: Christian Doenges
Cc: gdal-dev at remotesensing.org
Subject: Re: [Gdal-dev] Adding Fugawi .JPR Support to GDAL

Christian Doenges wrote:
> Hi,
> we want to add Fugawi .JPR file support to our application. I would like
> 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
> 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
products .wld files with a much of projection parameters right in the .wld
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

  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
    this is the outside application calling, and that something on disk
    be updated.  It also makes it harder to use the function for something
    than setting information directly on a dataset.  I would suggest we
    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
    world file.

Thus we might have:

int GDALReadWorldFileEx( const char *pszBaseFilename, double
                          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
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.

Best regards,
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

Gdal-dev mailing list
Gdal-dev at xserve.flids.com

More information about the Gdal-dev mailing list