[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
http://www.camptocamp.com
More information about the Dev
mailing list