[mapguide-internals] RFC60 - suggested XML XSD extensions

Trevor Wekel trevor.wekel at autodesk.com
Fri Mar 13 16:47:34 EDT 2009


Hi UV,

Have you considered adding the alpha channel to the color palette?  This may be useful when rendering dynamic layers on top of a set of tiled images.  Documentation on libgd.org seems to indicate that gdImageColorClosestAlpha will include transparency in the Euclidean distance calculation.  Libgd's alpha values only range from 0 to 128.

Thanks,
Trevor

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of UV
Sent: Thursday, March 12, 2009 4:42 AM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] RFC60 - suggested XML XSD extensions

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::DefaultTileServicePropertyColorPaletteCachingStra
>> tegy);
>>
>> 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
>
>   



More information about the mapguide-internals mailing list