I agree with Chris, the problem is on the SAX parser that produce
strange result when parsing WFS requests. For example I have logged
the following (that can be useful for fixing the problem):
the log have the following pattern:
The WFS query used for reproduce the result, has a property named: BURIED_DEP.
Note how. in the following
snipped log, the property name is truncated in: "BURIED_D" AND "EP",
becuase when the SAX parser
read the chunk, it read only 4096 characters, and do not see over that
limit .... :-( .... and more, if you try to add
a new property, or remove a property, if you are lucky, you will have
the right results only because the property' names
are not across chunks of data.
CUSTOM LOG FOLLOWS: (format::
<ClassName>:<method>:<message> )
.....
Query:addPropertyName: naoc:Pipeline_SpecialSections propertyName
DESIGN_COD
FeatureHandler:characters: start=4008 length= 10 s = DESIGN_FAC
Query:addPropertyName: naoc:Pipeline_SpecialSections propertyName
DESIGN_FAC
FeatureHandler:characters: start=4053 length= 10 s = HYDROSTATI
Query:addPropertyName: naoc:Pipeline_SpecialSections propertyName
HYDROSTATI
FeatureHandler:characters: start=4098 length= 8 s = BURIED_D
Query:addPropertyName: naoc:Pipeline_SpecialSections propertyName
BURIED_D
FeatureHandler:characters: start=0 length= 2 s = EP
Query:addPropertyName: naoc:Pipeline_SpecialSections propertyName EP
FeatureHandler:characters: start=37 length= 10 s = SUITABILIT
Query:addPropertyName: naoc:Pipeline_SpecialSections propertyName
SUITABILIT
FeatureHandler:characters: start=82 length= 6 s = RATING
Query:addPropertyName: naoc:Pipeline_SpecialSections propertyName RATING
FeatureHandler:characters: start=123 length= 7 s = COATING
Query:addPropertyName: naoc:Pipeline_SpecialSections propertyName
COATING
FeatureHandler:characters: start=165 length= 10 s = CONCRETE_C
Query:addPropertyName: naoc:Pipeline_SpecialSections propertyName
CONCRETE_C
....
Some help on fixing it ??
10x in advance.
Giacomo
Chris Holmes ha scritto:
I
think it may actually have to do with the limitations of the SAX
parser, but I thought we had a workaround for it. Like it'll only
chunk a certain number of characters at once.
Gabriel, I feel like you may have had this bug and/or a fix for it? I
know someone did. Maybe it didn't get ported over at some point?
Mark Presling wrote:
Hi all,
Sorry about the cross-list post but I'm not sure exactly where this
problem lies.
(Ignore until you read the sentence below)
598072759 [FINE] org.vfny.geoserver.servlets.AbstractService -
------------XML POST START-----------
<?xml version="1.0" encoding="UTF-8"?>
<GetFeature xmlns=*MailScanner has detected a possible fraud attempt
from "www.opengis.net" claiming to be* "http://www.opengis.net/wfs"
xmlns:gml=*MailScanner has detected a possible fraud attempt from
"www.opengis.net" claiming to be* "http://www.opengis.net/gml"
xmlns:ogc=*MailScanner has detected a possible fraud attempt from
"www.opengis.net" claiming to be* "http://www.opengis.net/ogc"
version="1.0.0" service="WFS" outputFormat="GML2"><Query
typeName="topp:roadevent_pnt"><ogc:PropertyName>roadeventid</ogc:PropertyName>
<ogc:Filter><ogc:And><ogc:Intersects><ogc:PropertyName>the_geom</ogc:PropertyName>
<gml:Polygon><gml:outerBoundaryIs><gml:LinearRing><gml:coordinates
decimal="." cs="," ts=" ">2224073.5294117643,5725938.522408964
2224073.5294117643,6077972.522408964
2740784.4985994394,6077972.522408964
2740784.4985994394,5725938.522408964
2224073.5294117643,5725938.522408964</gml:coordinates>
</gml:LinearRing>
</gml:outerBoundaryIs>
</gml:Polygon>
</ogc:Intersects>
<ogc:And><ogc:Not><ogc:PropertyIsGreaterThan><ogc:PropertyName>startdate</ogc:PropertyName>
<ogc:Literal>1.155523188718E12</ogc:Literal>
</ogc:PropertyIsGreaterThan>
</ogc:Not>
<ogc:Not><ogc:And><ogc:PropertyIsEqualTo><ogc:PropertyName>eventstatus</ogc:PropertyName>
<ogc:Literal>Closed</ogc:Literal>
</ogc:PropertyIsEqualTo>
<ogc:PropertyIsLessThan><ogc:PropertyName>enddate</ogc:PropertyName>
<ogc:Literal>1.154227188718E12</ogc:Literal>
</ogc:PropertyIsLessThan>
</ogc:And>
</ogc:Not>
<ogc:Not><ogc:PropertyIsEqualTo><ogc:PropertyName>eventstatus</ogc:PropertyName>
<ogc:Literal>Deleted</ogc:Literal>
</ogc:PropertyIsEqualTo>
</ogc:Not>
<ogc:Or><ogc:PropertyIsEqualTo><ogc:PropertyName>eventtype</ogc:PropertyName>
<ogc:Literal>Road Hazard</ogc:Literal>
</ogc:PropertyIsEqualTo>
<ogc:PropertyIsEqualTo><ogc:PropertyName>eventtype</ogc:PropertyName>
<ogc:Literal>Road Work</ogc:Literal>
</ogc:PropertyIsEqualTo>
<ogc:PropertyIsEqualTo><ogc:PropertyName>eventtype</ogc:PropertyName>
<ogc:Literal>Area Warning</ogc:Literal>
</ogc:PropertyIsEqualTo>
<ogc:PropertyIsEqualTo><ogc:PropertyName>eventtype</ogc:PropertyName>
<ogc:Literal>Compliment</ogc:Literal>
</ogc:PropertyIsEqualTo>
<ogc:PropertyIsEqualTo><ogc:PropertyName>eventtype</ogc:PropertyName>
<ogc:Literal>Complaint</ogc:Literal>
</ogc:PropertyIsEqualTo>
<ogc:PropertyIsEqualTo><ogc:PropertyName>*eventtype*</ogc:PropertyName>
<ogc:Literal>Damage Report</ogc:Literal>
</ogc:PropertyIsEqualTo>
</ogc:Or>
</ogc:And>
</ogc:And>
</ogc:Filter>
</Query>
</GetFeature>
------------XML POST END-----------
598072774 [FINE]
org.vfny.geoserver.wfs.requests.readers.GetFeatureXmlReader - just
parsed: [EMAIL PROTECTED]
598072774 [INFO] org.vfny.geoserver.servlets.AbstractService - handling
request:
Request: null
output format:GML2
max features:2147483647
version:
queries:
Query []
feature type: topp:roadevent_pnt
filter: [[ the_geom intersects POLYGON ((2224073.5294117643
5725938.522408964, 2224073.5294117643 6077972.522408964,
2740784.4985994394 6077972.522408964, 2740784.4985994394
5725938.522408964, 2224073.5294117643 5725938.522408964)) ] AND [NOT [
startdate > 1.155523188718E12 ] AND NOT [[ eventstatus = Closed ]
AND [ enddate < 1.154227188718E12 ]] AND NOT [ eventstatus = Deleted
] AND [[ eventtype = Road Hazard ] OR [ eventtype = Road Work ] OR [
eventtype = Area Warning ] OR [ eventtype = Compliment ] OR [ eventtype
= Complaint ] OR [ *ttype* = Damage Report ]]]]
[properties: roadeventid]
This is a WFS request sent to GeoServer 1.3.1 from uDig. Admittedly it
is quite a big filter but I can't really get away from that.
As you can see the last attribute filter in the XML post says "... or
eventtype = Damage Report". However, the parsed GeoTools filter below
that says "... OR [ ttype = Damage Report ]". This only happens when I
have this number of attribute filters turned on, if I reduce the number
by one everything works correctly.
The amount of truncation appears random as well. Sometimes the filter
ends up as "OR [ e = Damage Report ]".
Has anyone seen this before or know what can be done about it?
Thanks,
Mark
|
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
