[OpenLayers-Dev] GML format - unsupported geometry type: box

Eric Lemoine eric.lemoine at camptocamp.com
Wed Jul 22 01:33:02 EDT 2009

Hi François

 I do not really have answers to your questions - I hope others will -
but I'd have one comment on what we should do with GML features with a
bounding box but without a geometry.

I'd be -1 on creating geometries without coordinates and just bounds
(option 3), because an OpenLayers geometry's bounds represent the
bounds of the geometry's coordinates. I don't like the idea of
creating a geometry from the gml:BoundedBy (option 2) either, because
gml:BoundedBy and feature.geometry represent two different things -
gml:BoundedBy is the feature's bounding box while feature.geometry is
the feature's geometry. So, among your options, option 2 is the one
that makes the most sense to me. And in addition to option 2 I think
we could make the GML format parse the gml:BoundedBy/gml:Box element
and place the result either in feature.bounds if there's no geometry
or in feature.geometry.bounds if there's a one.

What do you think?

On Tuesday, July 21, 2009, Francois Van Der Biest
<francois.vanderbiest at camptocamp.com> wrote:
> Hi list,
> Using the recently added getFeatureInfo control + format, I came
> across a weird behovior.
> It happens while parsing such a GML response, using the default GML format :
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <msGMLOutput
>          xmlns:gml="http://www.opengis.net/gml"
>          xmlns:xlink="http://www.w3.org/1999/xlink"
>          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>         <Sentiers_littoraux_layer>
>                 <Sentiers_littoraux_feature>
>                         <gml:boundedBy>
>                                 <gml:Box srsName="EPSG:2154">
>                                         <gml:coordinates>132292.317102,6855471.709639
> 135474.476817,6858074.765441</gml:coordinates>
>                                 </gml:Box>
>                         </gml:boundedBy>
>                         <DEPARTEMENT>Finistere</DEPARTEMENT>
>                 </Sentiers_littoraux_feature>
>         </Sentiers_littoraux_layer>
> </msGMLOutput>
> I got such an error : "Unsupported geometry type : Box"
> So I opened a ticket [1], and created a patch to parse Box geometries,
> as it's currently done for Envelopes.
> But I was not really happy nor confident with it, since a Box is not a
> true geometry. Yet, Envelopes are currently converted to polygon
> geometries...
> So, I think we need to choose between those three solutions :
>  - either we remove parsing of envelopes and do not commit parsing of
> box, beacuse they're not true geometries (option 1)
>  - or we commit the parsing of box, which transforms into a polygon
> geometry  (option 2)
>  - or we create empty geometries, with just their bbox filled. (option
> 3). In that case, I think we would'nt be able to take into account
> envelopes (at least, just their bbox).
> All these options break "format reversibility", but, if it's feasible,
> option (3) seems the least destructive.
> I would personally be in favor of options (3) or (1).
> I'd be happy to hear from you on that.
> Thank's,
> F.
> [1] http://trac.openlayers.org/ticket/2191
> PS1 : BTW, why are we always using format.GML (and no v2 or v3) to
> parse gml getFeatureInfo responses ?
> Is it because such responses always conform to GML v1 ? The WMS spec
> remains elusive about this.
> PS2 : I'm wondering if the above GML response (which is provided by
> this mapserver WMS :
> http://geolittoral.application.equipement.gouv.fr/wms/metropole) is
> correct. Does GML allow sending a bbox without the true geometry ? Any
> GML specialist out there ?
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev

Eric Lemoine

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac, Cedex

Tel : 00 33 4 79 44 44 96
Mail : eric.lemoine at camptocamp.com

More information about the Dev mailing list