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

[Roger Bedell]

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.

Roger

-----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
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.

Christian,

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
    GDALReadWorldFileEx().

  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
    world file.

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.

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
http://xserve.flids.com/mailman/listinfo/gdal-dev