[Mass-Market-GEO] OpenSearch Geo feedback
Frank.Steggink at bentley.com
Frank.Steggink at bentley.com
Fri Nov 16 14:08:34 EST 2007
Thanks for your reply. However, I have a few remarks.
1. The OGC Abstract Specification Topic 3 doesn't talk about vertex
order at all. (It only talks about different kinds of relationships
between coordinate systems). Also, GML (3.1 or 3.2.1) doesn't bother
with the vertex order either (or I can't find it). It just mentions that
a polygon is defined by a set of boundary curves which should be
The fact that it is complex is the reason I'm raising this issue, in
order to get clarity. Perhaps I'm not right, and Andrew should correct
me if necessary, but a large part of the target audience of the Geo
extension will never have heard of the OGC. So, the bar should be as low
as possible, but without any ambiguity.
2. The bounding box definition in the Geo extension of OpenSearch, where
maxX can be smaller than minX, looks to be in accordance with OWS Common
1.1.0 and WCS 1.1.1, so this is fine.
From: Whiteside, Arliss E (US SSA)
[mailto:arliss.whiteside at baesystems.com]
Sent: Friday, November 16, 2007 13:03
To: Frank Steggink; mass-market-geo at opengeospatial.org
Subject: RE: [Mass-Market-GEO] OpenSearch Geo feedback
FYI, you are considering issues that have been discussed in various
existing OGC public documents. However, these issues are often more
complex than you would like to consider. For example, the:
1) Order of vertices in a polygon is specified in GML and OGC Abstract
Specification Topic 3.
2) Crossing the antimeridian longitude (not the non-straight
international dateline) by a bounding box is discussed in Clauses 10.2
and D.13 of OWS Common 1.1.0 and Clause 7.6 of WCS 1.1.1.
From: Frank.Steggink at bentley.com
Sent: Friday, November 16, 2007 9:05 AM
To: mass-market-geo at opengeospatial.org
Subject: [Mass-Market-GEO] OpenSearch Geo feedback
I've just read the Geo extension of OpenSearch, and have a few
Lat and lon parameters: maybe it's just me, but I would prefer only one
parameter for location. Now you'll need two parameters to describe one
location. How about geo:point?
This way you'll also avoid a potential problem that the second parameter
should be present if the first one has been given. (Both are optional.)
Polygon parameter: there is some discussion about the order of the
vertexes. Andrew suggested clockwise order here. At the GeoRSS list
there is a question about the suggested polygon order, and the ESRI
Shapefile spec says that (the exterior of) a polygon should be also in
clockwise order. I think it is pretty hard to enforce this. An example:
if a client lets a user draw a polygon as the search area, the client
should not forget to reorder the vertexes if the user has drawn it
counter clockwise. Do you expect that all potential clients will do
The reason for the vertex order is to determine what is inside or
outside the polygon, especially near the international date line. If
unambiguity is necessary, it can also be achieved by inserting multiple
points when the longitude difference between two points will be really
bigger than 180 degrees. But also in this case it depends on the client
if it will check this. What approach would be the easiest for most
Maybe it is better to make an exception for the longitude range in this
case, so that the longitudes can exceed 180 when the date line is
crossed? This was allowed in WFS 1.1.1 for bounding boxes, but it's no
longer mentioned in WFS 1.3.0, so I guess this suggestion is out of the
How is crossing the date line actually handled for the box parameter? If
maxX < minX, does it mean that the box crosses the date line?
Lastly, I'm wondering if there are already some clients and servers out
there using this draft of the OpenSearch Geo extension.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mass-Market-GEO