[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