[mapguide-internals] RFC60 - suggested XML XSD extensions
UV
uvwild at gmail.com
Thu Mar 12 06:42:26 EDT 2009
Here are my suggestions for the new XML data sets.
e.g. ColorPalette1.xml:
-----------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<ColorPalette xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="ColorPalette.xsd">
<Name>ComputedColorPalette</Name>
<Colors>
<Color>#000000</Color>
<Color>#000001</Color>
<Color>#000010</Color>
<Color>#000100</Color>
<Color>#001000</Color>
<Color>#010000</Color>
<Color>#100000</Color>
<Color>#111111</Color>
<Color>#ff0000</Color>
<Color>#00ff00</Color>
<Color>#0000ff</Color>
<Color>#ffffff</Color>
</Colors>
</ColorPalette>
-----------------------------------------------------
or ColorPalette2.xml:
-----------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<ColorPalette xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="ColorPalette.xsd">
<Name>ComputedColorPalette</Name>
<ResourceID>Library://MAPS/MyMapComputed.ColorPalette</ResourceID>
</ColorPalette>
-----------------------------------------------------
_with a ColorPalette.xsd:_
-----------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:complexType name="ColorPaletteType">
<xs:sequence>
<xs:element name="Name" type="xs:string">
<xs:annotation>
<xs:documentation>Name given to this
Palette</xs:documentation>
</xs:annotation>
</xs:element>
<xs:choice>
<xs:element name="ResourceId" type="xs:string">
<xs:annotation>
<xs:documentation>ResourceId of the
ColorPalette</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="Colors" type="ColorListType">
<xs:annotation>
<xs:documentation>Color list of the
ColorPalette</xs:documentation>
</xs:annotation>
</xs:element>
</xs:choice>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ColorListType">
<xs:sequence>
<xs:element name="Color" maxOccurs="255">
<xs:annotation>
<xs:documentation>The Color represented as a HTML value
#RRGGBB within XML tags. </xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="#[0-f]{6}"></xs:pattern>
<xs:length value="7" fixed="true"></xs:length>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:element name="ColorPalette">
<xs:annotation>
<xs:documentation>A ColorPalette is the collection of base
Colors as used in the map and its layers
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="ColorPaletteType"/>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:schema>
-----------------------------------------------------
whereas we need to add the following lines to the MapDefinition-1.0.0.xsd
maybe this should be renamed then to MapDefinition-1.0.1.xsd
the MapDefinitionType needs to be extended with the optional
ColorPalette and the ColorPaletteType needs to be defined or included
there also.
At this stage we can discuss to only use a ResourceID within the
MapDefinition instead of the complete XML type with the ColorListType
<xs:complexType name="MapDefinitionType">
.........
<xs:element name="BackgroundColor" type="xs:hexBinary">
<xs:annotation>
<xs:documentation>The background color to be used
with the MapDefinition</xs:documentation>
</xs:annotation>
</xs:element>
* <xs:element name="ColorPalette" type="ColorPaletteType"
minOccurs="0" maxOccurs="1">
<xs:annotation>
<xs:documentation>The ColorPalette defined by the
base colors of this MapDefinition.</xs:documentation>
</xs:annotation>
</xs:element>
* <xs:element name="Metadata" type="xs:string" minOccurs="0">
<xs:annotation>
<xs:documentation>Metadata regarding the
MapDefinition</xs:documentation>
</xs:annotation>
</xs:element>
.........
Bruce Dechant wrote:
> UV,
>
> Just to clarify. The changes required to support this should consist of:
>
> 1) A NEW resource type - ColorPalette. This hold the palette information.
> 2) A change to the Map Definition resource that references the NEW ColorPalette resource above.
>
> With the above changes I don't see a need for any server configuration settings. Perhaps you could clarify why you still think there needs to be one.
>
> The above could be expanded at a future date to support different color palettes per scale range. I would add this comment to your RFC to clarify the future direction.
>
> I would be more than happy to help you with the changes needed for the Map definition resource schema and for what the ColorPalette resource schema looks like. These changes need to be documented in the RFC.
>
> Note: I used the name ColorPalette above, as a suggested name only.
>
> Thanks,
> Bruce
>
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of UV
> Sent: Wednesday, March 04, 2009 10:49 PM
> To: MapGuide Internals Mail List
> Subject: Re: [mapguide-internals] RFC60 - PNG8 color palette improvements thoughts about user palette
>
> Thanks Bruce.
>
> The main coding challenge for me now is to find the code to access and
> store the resources.......
>
> About the user palette...
> I think this discussion might be misguided by the misconception that by
> changing the palette we could drastically change the looks.
> As much as this is desireable there is a major problem... The Renderer
> uses the base colors of the map to create truecolor images.
> The current algorithm only affects the color quantization to an 8bit
> (gif/png whatever) image.
> Thus, if we apply a random palette to this quantization step we only
> create funny looking images.
> _The base colors from the map definition and layer definitions are still
> used to compute the truecolor image from the map!!!!_
>
> (e.g. I supplied a palette in my test setup which was missing one
> important base color. The result was a map which had the original
> problem of differing base colors in adjoining tiles. )
>
> So the only application for providing an external colormap to this
> algorithm is to include _additional _colors which are not the base colors.
> For the map itself the color quantization which is achieved by including
> the base colors from the map and layer definition and force those
> into the quantization algorithm does the right thing IMHO.
> So the user can provide a UserColorPalette with /additional/ base colors
> which will be merged with the computed ones.
>
> _So my suggestion for a closure of RFC60:_
>
> Create a resource for the ComputedBaseColorPalette. This should be part
> of the MapDefinition.
> The GetTile function looks for the MapDefinion.ComputedBaseColorPalette.
> If this is not available a new one is created by Parsing all
> LayerDefinitons and the MapDefinitions to compute a new Palette from
> those colors and then stored.
>
> Any change to the MapDefintion removes this ComputedBaseColorPalette.
> (ClearTileCache hook maybe??)
>
> In addition a UserProvidedColorPalette can be referenced or included in
> the MapDefinition.
> If it exists it will be added to the ComputedBaseColorPalette _before
> _doing the 8bit color quantization.
> This can be useful to include colors for symbols etc. (unless there is
> an easy way to parse the symbol library for color definitions)
>
> ------------
> To extend the scope later we can add UserProvidedColorPalette also to
> LayerDefinitions and a Method which parses the Map with a given zoom level
> to add up all colors found. Just for the base colors this seems an
> overkill.
>
>
> Everyone happy with this?
>
>
> Bruce Dechant wrote:
>
>> Uv,
>>
>> This is a great idea for improving the quality of the base maps.
>>
>> As Jason suggested having the color palette information defined in the map definition is nice. Ideally, a NEW ColorPalette resource could be added and then referenced by the Map Definition resource. This would allow them to be reused across multiple maps if needed and allow for quick editing/modifying by only having to adjust one palette that may apply to several maps.
>>
>> As for which memory caching strategy to use I would suggest you make this configurable as it is very easy to add one and access it:
>>
>> You could add a NEW property to the serverconfig.ini file under the [TileServiceProperties] section, ex: ColorPaletteCachingStrategy
>>
>> The code below is some sample code for reading this setting from the ini file.
>>
>> MgConfiguration* configuration = MgConfiguration::GetInstance();
>>
>> configuration->GetIntValue(
>> MgConfigProperties::TileServicePropertiesSection,
>> MgConfigProperties::TileServicePropertyColorPaletteCachingStrategy,
>> colorPaletteCachingStrategy,
>> MgConfigProperties::DefaultTileServicePropertyColorPaletteCachingStrategy);
>>
>> The above would give the most flexibility in fine tuning the caching for the color palettes without actually requiring much more coding effort.
>>
>> Thanks,
>> Bruce
>>
>> -----Original Message-----
>> From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of UV
>> Sent: Sunday, March 01, 2009 6:59 PM
>> To: MapGuide Internals Mail List
>> Subject: [mapguide-internals] RFC60 - PNG8 color palette improvements please comment
>>
>> Hello,
>>
>> there is RFC60 place in the list and needs some commenting.
>> Currently, we are looking into a serverconfig.ini parameter
>> UseColorPalette in the TileServiceSection.
>> upon init of the tile cache this parses the map definition and produces
>> a palette with the map colors.
>> Those are then used in some 100 extra line of C code in AGGImageIo.cpp
>> to force those colors in
>> the map used for the PNG8 created from the truecolor tile passed in by
>> the rendering service.
>>
>> 1- which memory strategy is recommended for the color quantization? (3
>> options in the RFC (stack, fast heap, efficient heap))
>> 2 - is the ServerTileService the right place to put the code to collect
>> the map colors?
>> 3 - any suggestions regarding the naming and location of the color
>> palette within the map definition?
>>
>> Comments are welcome!
>> Also a few guiding remarks concerning the integration of the
>> configuration code would make extremely helpful
>> as just knowing where to start looking saves day of wasted code studies.
>> These things are missing in the architecture
>> docs so far.
>>
>> This is work in progress as there is a sponsor for it.
>> Thanks for your support.
>> UV
>>
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>
>>
>>
>
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ColorPalette.xml
Type: text/xml
Size: 244 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/mapguide-internals/attachments/20090312/a875ef72/ColorPalette.xml
More information about the mapguide-internals
mailing list