[mapguide-internals] RFC30 is posted

[Leaf Li]

Answer in lines
 
I read in RFC that this Web API will depend on FDO. What does this mean? Would be directly linked to FDO or just using Feature Service or ?

[Leaf Li] Yes. It means Web API will depend on FDO directly and need link to FDO library directly because there is no a good way to construct a FDO configuration XML without calling to FDO override related functions and Feature Service can't satisfy requiement of ConfigDocument. In order to avoid the whole Web API linking to FDO, a new component (project) named Utility will be created which will link to FDO libary directly and ConfigDocument will be included in Utitlty component. In the future, we may add more utitlty to Utility component such as utility to create a default layer definition file.

----Leaf Li

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org <mailto:mapguide-internals-bounces at lists.osgeo.org> ] On Behalf Of Leaf Li
Sent: Friday, August 31, 2007 3:33 AM
To: mapguide-internals at lists.osgeo.org
Subject: RE: [mapguide-internals] RFC30 is posted

Answer in lines



Interesting idea.  I'd really like to see more information on:



- what overrides / parameters will be accessible for each of the various providers.  For instance, I'd like to see whether it will allow the specification of multiple layers and alternate styles from a WMS, the use of a specific image format, etc.  If you look on the FDO mailing list, there was a long thread from someone having difficulty generating WMS config documents.  Here's part of it:  http://www.nabble.com/RE%3A--mapguide-users--Advanced-WMS-provider-configuration-tf3567897s18162.html#a9967178 <http://www.nabble.com/RE%3A--mapguide-users--Advanced-WMS-provider-configuration-tf3567897s18162.html#a9967178>  <http://www.nabble.com/RE%3A--mapguide-users--Advanced-WMS-provider-configuration-tf3567897s18162.html#a9967178 <http://www.nabble.com/RE%3A--mapguide-users--Advanced-WMS-provider-configuration-tf3567897s18162.html#a9967178> >



[Leaf Li] Nearly all information that can be overrided will be accessable by MgConfigDocument. For Raster provider, MgRasterFileItem will provide all override information, which allows the specification of image location, insert point, resolution, rotation, comibination of multiple images. For WMS provider, MgRasterWmsItem will provide all override information which allows the specification of multiple layers, styles, image format, coordinate system, transparent, background color.



- whether this will work with the open source GDAL raster provider

[Leaf Li] Yes. It will work with the open source GDAL raster provider.



- whether this relies on GetSchemaMapping returning accurate results

[Leaf Li] It nearly doesn't relies on GetSchemaMapping. However,  if users want create a configuration based on an existing connection, we need call GetSchemaMapping in this time.



- how this ensures that valid config documents will be generated (validate against schema?)



[Leaf Li] When users add override information by AddOverrideInfo method, the feature class and its physical mapping will be created in the same time. MgConfigDocument will guarantee feature class and its physical mapping is valid.



Oh and most importantly... I recently wrote a PHP app to create a config document for the GDAL provider (including bounding boxes) by pointing to a directory on the server that contains images. (http://trac.osgeo.org/fdo/wiki/FdoGdalNotes#CreatingTileIndexConfigFiles <http://trac.osgeo.org/fdo/wiki/FdoGdalNotes#CreatingTileIndexConfigFiles>  <http://trac.osgeo.org/fdo/wiki/FdoGdalNotes#CreatingTileIndexConfigFiles <http://trac.osgeo.org/fdo/wiki/FdoGdalNotes#CreatingTileIndexConfigFiles> > )  Will this RFC make this job easier?  :)



[Leaf Li] Definitely.



----Leaf Li