[mapserver-users] WFS client layer not drawn: missing .gfs file?

[Michael Schulz]

Hi Frank,

thanks for your comments that made me put ms_debug all thru the code ;-)

The problem is on my and/or mapservers side... The wfs getfeature
response I'm consuming has the namespace location for gml also
attached to the first featureMember tag (don't ask me why ... though i
think this is not really an error):
- msWFSLayerWhichShapes in mapwfslayer.c around line 1035 initializes
the char array szHeader[2000] and reads the getfeature response,
- then some tests search thru this array, e.g. checking whether it is
valid gml but no featureMembers,
- because the first featureMember tag has the namespace attribute
(<gml:featureMember xmlns:gml="http://www.opengis.net/gml">) it does
not get caught by the test "strstr(szHeader,"featureMember>") == NULL"
in line 1067 (the ">" is the culprit), and then because there are a
lot of attributes for the featuretype the closing featureMember tag is
not included anymore in the szHeader array and we're done thinking we
have gml but no results ...

Well, not sure what to do, at the moment it works by removing the ">"
from the tests. But what a final solution might look like? Increase
size of szheader?

Cheers and thanks, Michael




2008/10/27 Frank Warmerdam <warmerdam at pobox.com>:
> Michael Schulz wrote:
>>
>> Hi,
>>
>> I have a problem with gml reading/writing when used in an umn
>> mapserver environment: I have a mapserver WFS client layer, that is
>> not displayed when the getfeature response of the remote wfs-server
>> has too many featuretype attributes. If I reduce the number of
>> attributes in the featuretype the layer gets drawn correctly.
>> Apparently at a certain amount of attribute fields (>15 non-geometry
>> attributes) the layer is not drawn anymore.
>>
>> The interesting thing is, that when the layer gets drawn, the .tmp.gml
>> and tmp.gfs files are created normally in mapservers tmp dir. When it
>> is not drawn only the .tmp.gml is present. I have tested it with an
>> older gdal/ogr version (1.3.2) but also with the latest (1.5.3) one.
>> When i run "ogr2ogr -f "GML" new.gml
>> umn_wfslayer_lot_of_attributes.tmp.gml " then new.gml and new.xsd are
>> created without problems.
>
> Michael,
>
> I'm quite surprised.  So you are saying that ogr2ogr can read the GML
> file but MapServer cannot?  Are you convinced that the new.gml is
> correct?  Are you sure that your MapServer tests really used 1.3.2 and
> 1.5.3?
>
> I would be interested in testing with a GML file with "too many attributes
> to read" with MapServer though if the commandline tools are working fine
> against it there may be little I can learn.
>
>> Is it normal that the ogr gml reader/writer uses the older .gfs format
>> when used in mapserver environment and the .xsd format when invoked
>> from the command line?
>
> Modern OGR versions create the .xsd when writing GML datasets in
> a simplified GML profile.  But when reading foreign datasets a gfs
> file is used to cache information on the GML schema, feature count,
> and extents.  So, essentially this is normal behavior.
>
> Best regards,
> --
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>
>



-- 
-----------------------------------------------------------
Michael Schulz
mschulz at webgis.de

in medias res
Gesellschaft für Informationstechnologie mbH

In den Weihermatten 66
79108 Freiburg

Tel  +49 (0)761 556959-5
Fax +49 (0)761 556959-6

http://www.webgis.de / http://www.zopecms.de
-----------------------------------------------------------
Geschäftsführer: Stefan Giese, Dr. Christof Lindenbeck
Eingetragen im Handelsregister HRB 5930 beim Amtsgericht Freiburg