[OSGeo-Standards] OpenSearch Geo: BBox and Geometry

Pedro Gonçalves pereira.goncalves at gmail.com
Fri Mar 11 03:37:51 EST 2011


Hi Volker 

thanks, you're right
while simple clients will surely only support a single spatial query mechanisms there can be the case where a search engine supports both the geo:box and geo:geometry 
(at least we support this in our EO catalogue)  and the specification is not clear enough regarding what should be the behavior 
I'll add a sentence describing this case

Let me know if you have any more questions/comments/suggestions because I'm now updating the document for a new release with all the inputs received   

best regards

Pedro

On Mar 8, 2011, at 11:34 PM, Volker Mische wrote:

> I don't think this adds additional complexity, but clarity. Implementers
> would face this problem, if the specification gives the answer it's
> great (just like GeoJSON defines that the geometry types have that
> spatial camel case. It makes things so much easier if they are specified).
> 
> Cheers,
>  Volker
> 
> 
> On 03/08/2011 11:51 AM, Carl Reed wrote:
>> Volker -
>> 
>> As a general approach, returning clipped geometry might be asking a bit
>> much of the server. One can always define pathological cases that if we
>> try to solve ends up increasing the complexity of the interface or
>> encoding. This is an issue we face in the OGC on a regular basis. Last
>> week at the OGC Bonn meetings, I believe that the related discussion
>> about OpenSearch and complexity of the query is to keep the spec as
>> simple as possible and not to introduce undue complexity - but I will
>> let others peak on this topic.
>> 
>> Regards
>> 
>> Carl
>> 
>> ----- Original Message ----- From: "Volker Mische"
>> <volker.mische at gmail.com>
>> To: <standards at lists.osgeo.org>
>> Sent: Tuesday, March 08, 2011 11:43 AM
>> Subject: [OSGeo-Standards] OpenSearch Geo: BBox and Geometry
>> 
>> 
>>> Hi all,
>>> 
>>> I haven't found anything in the current OpenSearch Geo draft about the
>>> semantics of having multiple spatial operators at the same time.
>>> 
>>> For example you have a query with a bounding box and a geometry. As I
>>> think in terms of a web mapping client I would expect that such a query
>>> returns the intersection ("boolean and") of those geometries.
>>> 
>>> Think of a geometry that queries everything within Germany. When you are
>>> zoomed in pretty close into Germany (you don't see any borders), you
>>> want to return only the points in the current bounding box, not the
>>> whole of Germany. When you zoom out to see the whole of Europe, you
>>> obviously don't want to have data other than the one within Germany.
>>> 
>>> I think an "boolean and" should lead to sensible results no matter which
>>> operations are combined (even with geo:name or geo:radius).
>>> 
>>> Cheers,
>>> Volker
>>> _______________________________________________
>>> Standards mailing list
>>> Standards at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/standards
>>> 
>> 
> 
> _______________________________________________
> Standards mailing list
> Standards at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/standards



More information about the Standards mailing list