Format.GML.v2 and v3 fail when there's no geometry but bounds. JS error.

[fvanderbiest]

The case happens for instance with WFS getFeature when requesting attributes properties but no geometry, passing the propertyNames option to the WFST protocol's read method.

The error is caused by the GML format's base.js affecting bounds to feature.geometry, but feature.geometry is null. The proposed patch deals with that by affecting bounds to the feature instead of the inexistent geometry. I'm not sure crschmidt will agree with that ;-)

Tests are provided.

[elemoine]

The GeoJSON format always use feature.bounds for storing bounds read from a GeoJSON doc. François' patch perfect sense to me.

[bartvde]

Hmm, I've parsed geometryless GML before (both v2 and v3) and have not run into this. Let me check on Monday why I have not (I might have a local patch of some sort).

[bartvde]

Ah right, I get the difference now, Mapserver WFS does not output boundedBy per featureMember in this case, so that's why I did not run into this:

    <gml:featureMember>
      <rws:AAA64 gml:id="AAA64.19">
        <rws:OBJECTID>19</rws:OBJECTID>
        <rws:ROUTE>022</rws:ROUTE>
        <rws:ROUTE_CH>##022</rws:ROUTE_CH>
        <rws:COUNT>1</rws:COUNT>
        <rws:BEHEERDER>R</rws:BEHEERDER>
        <rws:LENGTH>8136.99</rws:LENGTH>
        <rws:SE_ANNO_CAD_DATA>&lt;null&gt;</rws:SE_ANNO_CAD_DATA>
        <rws:SHAPE>&lt;shape&gt;</rws:SHAPE>
      </rws:AAA64>
    </gml:featureMember>

[bartvde]

The only thing I wonder is should we not always set feature.bounds (like Eric says is done for GeoJSON). Instead of sometimes setting feature.geometry.bounds and sometimes feature.bounds. It seems inconsistent in this way to me, and if you read the APIdocs for bounds in OpenLayers.Feature.Vector, it is meant for server-side retrieved bounds.

[tschaub]

I agree with Bart here. This was a mistake on my part. The boundedBy element applies to the feature. I imagine there are cases where it might actually *not* be the bounds of the default geometry (but I don't have real experience with that sort of GML).

[tschaub]

set bounds on feature

[tschaub]

Note that I don't think we should distinguish between "set on server" and "calculated on client" here. If others agree, this suggests that we should invalidate the feature bounds when the geometry bounds is changed. I'm not interested in combining the issues here. Where it is important, the library uses geometry bounds anyway.

[bartvde]

Tim this looks good, please commit. Thanks for the work on this.

Tiny comment: in the first test_noGeom move "var bounds = feature.bounds;" up one line and use the variable already in the instanceof test.

[tschaub]

(In [9801]) Parse gml:boundedBy elements on features as feature.bounds instead of geometry.bounds. This fixes issues when GML comes without a geometry and it is a more correct representation of the element. r=bartvde (closes #2255)