[fdo-internals] New RFC10 Is Posted

[Greg Boone]

[GB] After re-reading your email again, I think I misinterpreted your
response.... 

"Of course configuration files are also custom to the provider, so they
just transfer the provider specific-ness from API calls to the
application building custom config files per provider but passing
through a generic api."

[GB] Yes, this is true if an application wishes to create a generic
API/Application to build FDO configuration files. While a generic
API/Application can be designed to handle the overall creation and
management of configuration files, as well as the creation of logical
schema and spatial context definitions, the creation of
PhysicalSchemaMappings definitions will continue to require provider
specific knowledge at some level in the system.

Greg


-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Tuesday, September 11, 2007 12:06 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] New RFC10 Is Posted

See inline...

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Frank
Warmerdam (External)
Sent: Tuesday, September 11, 2007 11:21 AM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] New RFC10 Is Posted

Greg Boone wrote:
> Without such a
> configuration, there would be no means for a user to customize how an
> FDO logical schema is mapped to an underlying implementation. 

Greg,

I understood until you said "without".  I was under the impression that
this mapping can appear in configuration files as well.  Is that wrong?

Of course configuration files are also custom to the provider, so they
just transfer the provider specific-ness from API calls to the
application building custom config files per provider but passing
through a generic api.

[GB] I am getting confused. It seems we are going in circles a bit here.

There should be no distinction between the terms Override and
Configuration when it comes to FDO. They are the same. The "Overrides"
API concept was designed to control the programmatic creation of the
configuration file, specifically one or more PhysicalSchemaMappings
sections that exists along with the logical schema definition and the
spatial content definition. Maybe we should just standardize on the
terms configuration and configuration API and drop the use of the term
override. 

There is also no generic FDO API for creating a provider agnostic
PhysicalSchemaMapping as a part of creating a configuration file.
PhysicalSchemaMappings are provider specific entities, and thus require
a provider specific API to create and manipulate them.

> I would also like to clarify the purpose of altering the WMS Overrides
> API in order to specify the Image Format, as outlined in RFC10. The
> purpose of this method is not to allow a client to control the means
in
> which the provider (i.e. GDAL API) interprets the raster data returned
> from the server, nor is it intended to imply that the provider will
> translate the retuned image into the specified format. The purpose of
> the function call is to allow a client application to specify the
format
> in which the WMS server will generate the requested WMS image as the
> image is being returned to the WMS provider as a result of an FDO
select
> request.

I understood this.

 > According to the OGC WMS 1.3 specification, the legal and
> appropriate values for the format type are server specific and are
> advertised by the provider as a part of the server's capabilities
> response. Therefore, it will be the client's responsibility to know
the
> values that are legal and acceptable for a particular server or to use
> the IGetImageFormats custom command as specified in
> http://trac.osgeo.org/fdo/wiki/FDORfc6 to retrieve the legal values.
> Once the legal vaoues are known, they can be used to populate and
create
> the WMS configuration document.

Understood.  But in addition we restrict ourselves to only png, tiff and
jpeg.  Thus a server that only serves NITF, or JPEG2000 or HDF would be
un-usuable even though they might have worked just fine if we weren't
arbitrarily (ok, perhaps that is harsh - perhaps over-carefully?)
restricting
ourselves to a few common formats.

[GB] I know of no such server which serves such formats, nor have I seen
such formats discussed in any WMS Specification literature. We also have
not had any customer requests that I am aware of to support such
formats. However, if we can find examples of such servers and can test
against them then I would not see any reason to restrict ourselves from
allowing them to be specified. 

Secondly, I argue that we need not try and solve all possible scenarios
in one release. We know we cannot support all formats, specifically the
vector formats, and we know we can support al the GIF, PNG, JPG, TIF
formats. Let's start with these as a baseline, and expand support from
there. We should remember that we will be releasing this software into
production code and we have to maintain a high degree of confidence that
the software we release will perform as promised. 

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    | President OSGeo,
http://osgeo.org

_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals