Ok, here we go. sld:
Bodenbedeckung
Gebäude
art
0
25000
#D2D2D2
1.0
#000000
0.4
Wald, Hecken, übrige Bestockte
art
28
art
30
art
31
25000
image/gif
20
#000000
0.4
saemtliche BB
art
0
art
28
art
30
art
31
25000
#FFFFFF
#000000
0.4
and the resulting query:
SELECT “oid”, “art”, encode(asBinary(force_2d(“wkb_geometry”),‘XDR’),‘base64’) FROM “public”.“kva_av_bdbed” WHERE (“wkb_geometry” && GeometryFromText(‘POLYGON ((618949.2201284027 240541.9555220589, 618949.2201284027 240615.2555220589, 619043.8201284026 240615.2555220589, 619043.8201284026 240541.9555220589, 618949.2201284027 240541.9555220589))’, -1) AND ((“art” = 0 OR (“art” = 28 OR “art” = 30 OR “art” = 31)) OR (lower(“art”) != lower(0) AND lower(“art”) != lower(28) AND lower(“art”) != lower(30) AND lower(“art”) != lower(31))))
Is there a way to prevent GeoServer from “lowering”? I tried to set the value to e.g. 31.0 instead of 31 (http://geotools.codehaus.org/Expression+Improvements), but this does not help.
Stefan
-----Ursprüngliche Nachricht-----
Von: Andrea Aime [mailto:aaime@anonymised.com]
Gesendet am: Sonntag, 22. März 2009 14:51
An: Ziegler Stefan
Cc: geoserver-users
Betreff: Re: [Geoserver-users] problems with sld filter,
postgresql 8.3
and geoserver 1.7.3
Ziegler Stefan ha scritto:
Hi
I running into some problems upgrading our productive
GeoServer (1.6) on
our intranet server where we use Postresql 8.3.3. The resulting sql
query looks like this:
SELECT “oid”, “art”,
encode(asBinary(force_2d(“wkb_geometry”),‘XDR’),‘base64’) FROM
“public”.“kva_av_bdbed” WHERE (“wkb_geometry” &&
GeometryFromText(‘POLYGON ((606159.7701284027 230239.6055220589,
606159.7701284027 230380.00552205893, 606348.9701284027
230380.00552205893, 606348.9701284027 230239.6055220589,
606159.7701284027 230239.6055220589))’, -1) AND ((“art” = 0
OR (“art” =
28 OR “art” = 30 OR “art” = 31)) OR lower(“art”) != lower(0)))
The problem is the lower()-function which seems not to work with
non-string values [1] with Postgresql 8.3 and onwards. Same
query works
with GeoServer 1.6 and Posgresql 8.3 because of the missing lower()
functions calls in the query and GeoServer 1.7.3 and Posgresql 8.1.
Mumble, lowering both side of a comparisong seems to imply that art
is being compared in a case insensitive way. How was that
filter built?
Also curious that only the last comparison uses the lower function,
and not the other ones?
Cheers
Andrea
–
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Ziegler Stefan ha scritto:
Ok, here we go. sld:
<StyledLayerDescriptor version="1.0.0"
xmlns="http://www.opengis.net/sld"
xmlns:gml="http://www.opengis.net/gml"
xmlns:ogc="http://www.opengis.net/ogc"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd">
<NamedLayer>
<Name>Bodenbedeckung</Name>
<UserStyle>
<FeatureTypeStyle>
<!-- scale 1:1 to 1:25000 -->
<Rule>
<Name>Gebäude</Name>
<ogc:Filter>
<ogc:PropertyIsEqualTo>
<ogc:PropertyName>art</ogc:PropertyName>
<ogc:Literal>0</ogc:Literal>
</ogc:PropertyIsEqualTo>
</ogc:Filter>
<MaxScaleDenominator>25000</MaxScaleDenominator>
<PolygonSymbolizer>
<Fill>
<CssParameter name="fill">#D2D2D2</CssParameter>
<CssParameter name="fill-opacity">1.0</CssParameter>
</Fill>
<Stroke>
<CssParameter name="stroke">#000000</CssParameter>
<CssParameter name="stroke-width">0.4</CssParameter>
</Stroke>
</PolygonSymbolizer>
</Rule>
<Rule>
<Name>Wald, Hecken, übrige Bestockte</Name>
<ogc:Filter>
<ogc:Or>
<ogc:PropertyIsEqualTo>
<ogc:PropertyName>art</ogc:PropertyName>
<ogc:Literal>28</ogc:Literal>
</ogc:PropertyIsEqualTo>
<ogc:PropertyIsEqualTo>
<ogc:PropertyName>art</ogc:PropertyName>
<ogc:Literal>30</ogc:Literal>
</ogc:PropertyIsEqualTo>
<ogc:PropertyIsEqualTo>
<ogc:PropertyName>art</ogc:PropertyName>
<ogc:Literal>31</ogc:Literal>
</ogc:PropertyIsEqualTo>
</ogc:Or>
</ogc:Filter>
<MaxScaleDenominator>25000</MaxScaleDenominator>
<PolygonSymbolizer>
<Fill>
<GraphicFill>
<Graphic>
<ExternalGraphic>
<OnlineResource xlink:type="simple"
xlink:href="wald.gif" />
<Format>image/gif</Format>
</ExternalGraphic>
<Size>
<ogc:Literal>20</ogc:Literal>
</Size>
</Graphic>
</GraphicFill>
</Fill>
<Stroke>
<CssParameter name="stroke">#000000</CssParameter>
<CssParameter name="stroke-width">0.4</CssParameter>
</Stroke>
</PolygonSymbolizer>
</Rule>
<Rule>
<Name>saemtliche BB</Name>
<ogc:Filter>
<ogc:And>
<ogc:PropertyIsNotEqualTo>
<ogc:PropertyName>art</ogc:PropertyName>
<ogc:Literal>0</ogc:Literal>
</ogc:PropertyIsNotEqualTo>
<ogc:PropertyIsNotEqualTo>
<ogc:PropertyName>art</ogc:PropertyName>
<ogc:Literal>28</ogc:Literal>
</ogc:PropertyIsNotEqualTo>
<ogc:PropertyIsNotEqualTo>
<ogc:PropertyName>art</ogc:PropertyName>
<ogc:Literal>30</ogc:Literal>
</ogc:PropertyIsNotEqualTo>
<ogc:PropertyIsNotEqualTo>
<ogc:PropertyName>art</ogc:PropertyName>
<ogc:Literal>31</ogc:Literal>
</ogc:PropertyIsNotEqualTo>
</ogc:And>
</ogc:Filter>
<MaxScaleDenominator>25000</MaxScaleDenominator>
<PolygonSymbolizer>
<Fill>
<CssParameter name="fill">#FFFFFF</CssParameter>
</Fill>
<Stroke>
<CssParameter name="stroke">#000000</CssParameter>
<CssParameter name="stroke-width">0.4</CssParameter>
</Stroke>
</PolygonSymbolizer>
</Rule>
</FeatureTypeStyle>
</UserStyle>
</NamedLayer>
</StyledLayerDescriptor>
and the resulting query:
SELECT "oid", "art", encode(asBinary(force_2d("wkb_geometry"),'XDR'),'base64') FROM "public"."kva_av_bdbed" WHERE ("wkb_geometry" && GeometryFromText('POLYGON ((618949.2201284027 240541.9555220589, 618949.2201284027 240615.2555220589, 619043.8201284026 240615.2555220589, 619043.8201284026 240541.9555220589, 618949.2201284027 240541.9555220589))', -1) AND (("art" = 0 OR ("art" = 28 OR "art" = 30 OR "art" = 31)) OR (lower("art") != lower(0) AND lower("art") != lower(28) AND lower("art") != lower(30) AND lower("art") != lower(31))))
Is there a way to prevent GeoServer from "lowering"? I tried to set the value to e.g. 31.0 instead of 31 (http://geotools.codehaus.org/Expression+Improvements), but this does not help.
I've tried to quickly reproduce with some postgis data I have
without luck. Can you open a bug report on jira.codehaus.org
adding full SLD and a sql dump of your postgis data, complete
enough to reproduce the issue?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.