[Geoserver-users] Dynamic ExternalGraphic icons from Attribute Properties

Michael_Frumin · June 11, 2007, 4:54am

[resend, something in the Nabble/SourceForge mailing list setup is funky]

A while back
(http://www.nabble.com/Dynamic-Colors%2C-from-Attributes-Propreties-tf3254992.html#a9048975)
I asked about passing thru parameters from the raw (i.e. postgis) data into
the SLD rendering. The example being if I stored a color for each feature
in the DB, could that color be called upon in the SLD. The answer was yes,
as such:

<PolygonSymbolizer><Fill>
<CssParameter
name="fill"><ogc:PropertyName>color</ogc:PropertyName></CssParameter>
</Fill></PolygonSymbolizer>

But now I'm getting even spicier. I am generating fancier data, in this
case lets say some pie charts or sparkline graphs, for each of many Point
features, each of which is named according to the 'id' column of the feature
in the DB. I should be able to do something like this to dynamically pull
in the different graphs as ExternalGraphic icons, but it certainly doesn't
work:

    <PointSymbolizer>
        <Graphic>
            <ExternalGraphic>
                <OnlineResource
                    xmlns:xlink="http://www.w3.org/1999/xlink"
                    xlink:type="simple"

xlink:href="http://example.com/sparklies/<ogc:PropertyName>id</ogc:PropertyName>\.png"/>
                <Format>image/png</Format>
            </ExternalGraphic>
       </Graphic>
    </PointSymbolizer>

the error I get (in the spanky new GeoServer inline SLD editor) is:
INVALID XML: The value of attribute "xlink:href" associated with an element
type "OnlineResource" must not contain the '<' character.

Now of course this makes sense from an XML formatting standpoint, but I
think there should be some way around it, in order to increase the power of
GeoServer for doing real good GIS and mapping. Please don't tell me to use
OpenLayers and make a WFS that uses JavaScript to pull in the icons. It's a
total pain (tho I may very well do it), but also then prohibits you from
automatically rendering a given map w/out human intervention.

more recently, I tried putting everything up through:
<PointSymbolizer>
<ogc:PropertyName>resource</ogc:PropertyName>
</PointSymbolizer>
but none of it gets passed the SLD validation (whereas using the
PropertyName inside other parts of the SLD does).

thanks,
mike
--
View this message in context: http://www.nabble.com/Dynamic-ExternalGraphic-icons-from-Attribute-Properties-tf3899597.html#a11055025
Sent from the GeoServer - User mailing list archive at Nabble.com.

Justin_Deoliveira · June 13, 2007, 12:54am

Hi Mike,

An interesting problem... kind of hard to get around the sld validation
problem. We might be able to get around the validation problem by
replacing "<" and ">" with "<" and ">" but i doubt the resulting
sld would be smart enough to handle this anyways.

Something like this is much more suitably implemented with templates...
although we would have to add support for generating and SLD document
via a template.

-Justin

mfrumin wrote:

[resend, something in the Nabble/SourceForge mailing list setup is funky]

A while back
(http://www.nabble.com/Dynamic-Colors%2C-from-Attributes-Propreties-tf3254992.html#a9048975)
I asked about passing thru parameters from the raw (i.e. postgis) data into
the SLD rendering. The example being if I stored a color for each feature
in the DB, could that color be called upon in the SLD. The answer was yes,
as such:

<PolygonSymbolizer><Fill>
              <CssParameter
name="fill"><ogc:PropertyName>color</ogc:PropertyName></CssParameter>
</Fill></PolygonSymbolizer>

But now I'm getting even spicier. I am generating fancier data, in this
case lets say some pie charts or sparkline graphs, for each of many Point
features, each of which is named according to the 'id' column of the feature
in the DB. I should be able to do something like this to dynamically pull
in the different graphs as ExternalGraphic icons, but it certainly doesn't
work:

    <PointSymbolizer>
        <Graphic>
            <ExternalGraphic>
                <OnlineResource
                    xmlns:xlink="http://www.w3.org/1999/xlink"
                    xlink:type="simple"

xlink:href="http://example.com/sparklies/<ogc:PropertyName>id</ogc:PropertyName>\.png"/>
                <Format>image/png</Format>
            </ExternalGraphic>
       </Graphic>
    </PointSymbolizer>

the error I get (in the spanky new GeoServer inline SLD editor) is:
INVALID XML: The value of attribute "xlink:href" associated with an element
type "OnlineResource" must not contain the '<' character.

Now of course this makes sense from an XML formatting standpoint, but I
think there should be some way around it, in order to increase the power of
GeoServer for doing real good GIS and mapping. Please don't tell me to use
OpenLayers and make a WFS that uses JavaScript to pull in the icons. It's a
total pain (tho I may very well do it), but also then prohibits you from
automatically rendering a given map w/out human intervention.

more recently, I tried putting everything up through:
<PointSymbolizer>
   <ogc:PropertyName>resource</ogc:PropertyName>
</PointSymbolizer>
but none of it gets passed the SLD validation (whereas using the
PropertyName inside other parts of the SLD does).

thanks,
mike

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

Andrea_Aime3 · June 13, 2007, 7:40am

mfrumin ha scritto:

[resend, something in the Nabble/SourceForge mailing list setup is
funky]

A while back (http://www.nabble.com/Dynamic-Colors%2C-from-Attributes-Propreties-tf3254992.html#a9048975)
I asked about passing thru parameters from the raw (i.e. postgis)
data into the SLD rendering. The example being if I stored a color
for each feature in the DB, could that color be called upon in the
SLD. The answer was yes, as such:

<PolygonSymbolizer><Fill> <CssParameter name="fill"><ogc:PropertyName>color</ogc:PropertyName></CssParameter>
</Fill></PolygonSymbolizer>

Yes, that's because the SLD spec assumes CSSParameter values can be
Expressions coming from the OGC Filter spec. CSSParameter extends
ParameterValueType, which is defined as:

<xsd:complexType name="ParameterValueType" mixed="true">
    <xsd:annotation>
      <xsd:documentation>
         The "ParameterValueType" uses WFS-Filter expressions to give
         values for SLD graphic parameters. A "mixed" element-content
         model is used with textual substitution for values.
       </xsd:documentation>
    </xsd:annotation>
    <xsd:sequence minOccurs="0" maxOccurs="unbounded">
      <xsd:element ref="ogc:expression"/>
    </xsd:sequence>
  </xsd:complexType>

But now I'm getting even spicier. I am generating fancier data, in
this case lets say some pie charts or sparkline graphs, for each of
many Point features, each of which is named according to the 'id'
column of the feature in the DB. I should be able to do something
like this to dynamically pull in the different graphs as
ExternalGraphic icons, but it certainly doesn't work:

<PointSymbolizer> <Graphic> <ExternalGraphic> <OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple"

xlink:href="http://example.com/sparklies/<ogc:PropertyName>id</ogc:PropertyName>\.png"/>
<Format>image/png</Format> </ExternalGraphic> </Graphic> </PointSymbolizer>

the error I get (in the spanky new GeoServer inline SLD editor) is: INVALID XML: The value of attribute "xlink:href" associated with an
element type "OnlineResource" must not contain the '<' character.

Here the SLD spec does not allow the usage of expressions, so this will
break during document validation (aka, we don't even start parsing it).

Now of course this makes sense from an XML formatting standpoint, but
I think there should be some way around it, in order to increase the
power of GeoServer for doing real good GIS and mapping. Please don't
tell me to use OpenLayers and make a WFS that uses JavaScript to pull
in the icons. It's a total pain (tho I may very well do it), but
also then prohibits you from automatically rendering a given map
w/out human intervention.

more recently, I tried putting everything up through: <PointSymbolizer> <ogc:PropertyName>resource</ogc:PropertyName> </PointSymbolizer> but none of it gets passed the SLD validation
(whereas using the PropertyName inside other parts of the SLD does).

Because you're going beyond the SLD spec XML schemas. I agree your use
cases are very interesting, and worth supporting, but there's nothing we
can do overnight about this, the only solution I see is to roll out our
own SLD extensions (if you have smarter ones, I'm all ears).

To support your case, we would need a new kind of external graphics that
allows elements to be Expressions, and not only plain strings or URLs.
So, we would have to hack the xsd, then create a new class in Geotools
to represent that new symbol type, then hack the parser to parse the new
class, then change the style evaluator (it's the part that mixes
features and styles to get the actual values out of expressions), and
finally modify the image cache not to cache those symbolizers, because
they are too many (the current cache is really dumb, a static, unbounded
hash map, so if you were able to hit geoserver with the request above,
you would make it OOM very soon).
If we're luck, that would take a full day of work, most probably 1.5 or
2, besides the time needed to check the modification is ok with the
other geotools developers.
Now, who finances this? I'm open to suggestions
Cheers
Andrea