[mapguide-internals] Moving more config options into MapDefintion Resource Headers (RFC?)

[Zac Spitzer]

how about exposing each base layer group as a virtual layer ?

my concern about rev'ing the xml is that it is a real barrier to
allowing more incremental improvements as we are
stuck with an xml schema which basically restricts changes to
every year or so.

using the header approach,it would be possible to add this functionality in
a 2.201 release, which is not feasible for a change to the map / layer defs

Autodesk could release this way as a service pack because it
wouldn't involve a change to any xml schema

so it looks like for 2.3 the xml will get rev'd :)

but it I think it would be good to allow the approach of
using information stored as generic properties via headers
to allow new map specific properties to be added to faciliate
new development and experiments

besides defining them, how much work is involved in
supporting per map settings?


On 27 March 2010 14:37, Zac Spitzer <zac.spitzer at gmail.com> wrote:
> from memory the WMS stuff uses the headers for more than just security,
> storing at least both projection and bounds attributes.
>
> On 27 March 2010 15:26, Zac Spitzer <zac.spitzer at gmail.com> wrote:
>> On 27 March 2010 14:56, Trevor Wekel <trevor_wekel at otxsystems.com> wrote:
>>> Hi Zac,
>>>
>>> Currently header information in the resource repository is used to define security attributes and metadata for the resource.  It is "extra" information that does not really define attributes of the resource.
>>>
>>> <ResourceDocumentHeader xsi:noNamespaceSchemaLocation="ResourceDocumentHeader-1.0.0.xsd">
>>>  <Security xsi:noNamespaceSchemaLocation="ResourceSecurity-1.0.0.xsd">
>>>    <Inherited>true</Inherited>
>>>  </Security>
>>> </ResourceDocumentHeader>
>>>
>>> I would consider image format, selection color, and the meta tile factor all attributes of a map definition.  As such, they should be included in the XML document.
>>
>> ok, but changing the xml for the map def blows away a tile cache
>>
>>>
>>> Jason also mentioned a separate base map (tile set definition).  There are a few ways to do this.  I would probably add the image format (two formats: normal and base layers), selection color, and meta tile factor to our current MapDefinition and then add a second "tile" MapDefinition to WebLayout and ApplicationDefinition.  As far as I know, both viewers render the base tiles as a separate div tag so it wouldn't be much work to point them at a different MapDefinition.
>>>
>>
>> i'd guess i'd rather a 'meta' map definition (collection?), which
>> WebLayout and ApplicationDefinition consume,
>> rather than having dual implementations
>>
>>> Since we are about to hit beta, I'm not sure if RFC90 should be considered for inclusion in 2.2.  According to our posted release process, no new features should be submitted after the beta.  http://mapguide.osgeo.org/releaseprocess.html.  Definitely something to consider.
>>
>> yup i concur about the 2.2, how about a minor point release, rather
>> than letting this sit in subversion
>> out of the hands of users for a long time, like RFC60 did?
>>
>> Just because Autodesk releases an annual MGE, doesn't mean MGOS has to
>>
>>>
>>> Also, any changes to MapDefinition or LayerDefinition right now would probably break cross compatibility between MGE and MGOS.  Studio wouldn't work with MGOS and Maestro may not work with MGE.
>>>
>>
>> hence my suggestion for attributes in headers which requires no
>> changes to MapDefinition or LayerDefinition, I'm thinking
>> primarily about ability to tweak the meta tile factor per map whilst
>> protecting my precious tile cache
>>
>>> Regards,
>>> Trevor
>>>
>>>
>>> _______________________________________________
>>> mapguide-internals mailing list
>>> mapguide-internals at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>
>>>
>>
>>
>>
>> --
>> Zac Spitzer
>> Solution Architect / Director
>> Ennoble Consultancy Australia
>> http://www.ennoble.com.au
>> http://zacster.blogspot.com
>> +61 405 847 168
>>
>
>
>
> --
> Zac Spitzer
> Solution Architect / Director
> Ennoble Consultancy Australia
> http://www.ennoble.com.au
> http://zacster.blogspot.com
> +61 405 847 168
>



-- 
Zac Spitzer
Solution Architect / Director
Ennoble Consultancy Australia
http://www.ennoble.com.au
http://zacster.blogspot.com
+61 405 847 168