[Geoserver-users] Creating ExternalGraphic SLD links with concatenated values

GeoServer GeoServer User
1

I’m working on a project that has many different types of icons associated with different categories of features in a database. The graphics reside in the web directory of the same machine that is running Geoserver, and are used in other web-based applications besides Geoserver. At the moment, I am hard coding the URL links to the icons in my SLD file’s section. I would like to update this so that I use the database “ICONNAME” attribute which is being returned with my data, but I’m having trouble concatenating the URL and image name together.

How it currently looks:



image/png

How I would like it to look:



image/png

Is it possible for me to nest the ogc:PropertyNameICONNAME</ogc:PropertyName> value inside of the ExternalGraphic element this way?

Roger

2

Roger Andre ha scritto:

I'm working on a project that has many different types of icons associated with different categories of features in a database. The graphics reside in the web directory of the same machine that is running Geoserver, and are used in other web-based applications besides Geoserver. At the moment, I am hard coding the URL links to the icons in my SLD file's <ExternalGraphic> section. I would like to update this so that I use the database "ICONNAME" attribute which is being returned with my data, but I'm having trouble concatenating the URL and image name together.

How it currently looks:
<Graphic>
  <ExternalGraphic>
    <OnlineResource xlink:type="simple" xlink:href="http://12.345.67.89/BMGF/MapIcons/PROJ_LOCATION_9cdf63_symbologia2_30x30.gif&quot;/&gt;
    <Format>image/png</Format>
  </ExternalGraphic>
</Graphic>

How I would like it to look:
<Graphic>
  <ExternalGraphic>
    <OnlineResource xlink:type="simple" xlink:href="http://12.345.67.89/BMGF/MapIcons/&lt;ogc:PropertyName&gt;ICONNAME&lt;/ogc:PropertyName&gt;&quot;/&gt;
    <Format>image/png</Format>
  </ExternalGraphic>
</Graphic>

Is it possible for me to nest the <ogc:PropertyName>ICONNAME</ogc:PropertyName> value inside of the ExternalGraphic element this way?

Eh, I wish it was possible, but unfortunately the SLD standard
does not allow for that. xlink:href is a static string, to allow
for a dynamic address (which would have a number of interesting applications) we'd need something like:

  <Graphic>
    <ExternalGraphic>
      <DynamicOnlineResource xlink:type="simple">
http://12.345.67.89/BMGF/MapIcons/&lt;ogc:PropertyName&gt;ICONNAME&lt;/ogc:PropertyName&gt;
      </DuynamicOnlineResource>
      <Format>image/png</Format>
    </ExternalGraphic>
  </Graphic>

To support such a use case we would have to break strict compatibility
with the SLD standard and rool our own extension

Cheers
Andrea

3

Ok, is there any other way you can think of setting up the SLD so that it doesn’t have graphic values hard-coded into it? I saw an example of “database driven styling” that shows color values coming from the DB, so it seemed like there was a chance it might apply (somehow) to graphics as well.

           <PolygonSymbolizer>
            <Fill>
              <CssParameter name="fill"><ogc:PropertyName>income_color</ogc:PropertyName></CssParameter>
              <CssParameter name="fill-opacity">0.5</CssParameter>

            </Fill>
            <Stroke>
              <CssParameter name="stroke"><ogc:PropertyName>income_color</ogc:PropertyName></CssParameter>
              <CssParameter name="stroke-width">1</CssParameter>

            </Stroke>
          </PolygonSymbolizer>

Thanks,

Roger

On Feb 18, 2008 11:40 PM, Andrea Aime <aaime@anonymised.com> wrote:

Roger Andre ha scritto:

I’m working on a project that has many different types of icons
associated with different categories of features in a database. The
graphics reside in the web directory of the same machine that is running
Geoserver, and are used in other web-based applications besides
Geoserver. At the moment, I am hard coding the URL links to the icons
in my SLD file’s section. I would like to update this
so that I use the database “ICONNAME” attribute which is being returned
with my data, but I’m having trouble concatenating the URL and image
name together.

How it currently looks:



image/png

How I would like it to look:



image/png

Is it possible for me to nest the
ogc:PropertyNameICONNAME</ogc:PropertyName> value inside of the
ExternalGraphic element this way?

Eh, I wish it was possible, but unfortunately the SLD standard
does not allow for that. xlink:href is a static string, to allow
for a dynamic address (which would have a number of interesting
applications) we’d need something like:

http://12.345.67.89/BMGF/MapIcons/ogc:PropertyNameICONNAME</ogc:PropertyName>

image/png

To support such a use case we would have to break strict compatibility
with the SLD standard and rool our own extension

Cheers
Andrea

–

Roger André
GIS Developer/Analyst
CH2M HILL
Enterprise Management Solutions

Tel: 425.233.3042

4

Roger Andre ha scritto:

Ok, is there any other way you can think of setting up the SLD so that it doesn't have graphic values hard-coded into it? I saw an example of "database driven styling" that shows color values coming from the DB, so it seemed like there was a chance it might apply (somehow) to graphics as well.

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

This is because OGC decided that a CSSParameter can be made up
using ogc:Expression components (PropertyName being one)
whilst the reference to an external graphic is just an xs:string,
that is, a constant.

If you don't have many possible symbols you can makes
lots of Rule objects, each filtering on a different attribute
value. Something like:

<Rule>
   <Filter>
     <ogc:PropertyIsEqualTo>
        <ogc:PropertyName>attribute</ogc:PropertyName>
        <ogc:Literal>10</ogc:Literal>
     </ogc:PropertyIsEqualTo>
   </Filter>
   <GraphicSymbolizer>
     ....
</Rule>

and have a rule for each different value. It goes way verbose
very quickly, but at least it's supported by the SLD standard
as is.

Cheers
Andrea