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.vanderbi...@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@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.lemo...@camptocamp.com http://www.camptocamp.com _______________________________________________ Dev mailing list Dev@openlayers.org http://openlayers.org/mailman/listinfo/dev
