Format.GML: introduce geometryType

[bartvde]

Currently in parseFeature the parser loops over all possible geometry types, but if a client already knows the geometry type, this is a bit of a waste. In my test it took about 200 ms less time on this loop for 100 features.

Would it be an idea to introduce a geometryType APIProperty, so people knowing the geometryType can set it on the format?

[bartvde]

patch implementing geometryType on Format.GML

[bartvde]

Ofcourse this will only work for GML files which don't have multiple geometry types. But I think an application developer will figure that out themselves if they use it.

[euzuro]

See #1639

[tschaub]

add geometryTypes (non-api) property

[tschaub]

Oh, the goodness of tests. I don't think the original patch does what it is intended to do. Features are still created even if geometryType is set. These features just have undefined geometry.

I think a better solution would be to have a geometryTypes array (as I included in my patch). I also don't think we need to throw this in the API this close to a release.

Anyway, this one needs more work. Bart, thanks for the patch. Please include tests to demonstrate that the changes do what you expect if you'd like to push this for a future release.

[tschaub]

Actually, perhaps this was known (that it doesn't really stop feature parsing) - but I think it is confusing. If we add a geometryTypes filter, then the parser should only parse features with those geometry types.

[crschmidt]

Not touched since 2.7, moving forward.