[Mass-Market-GEO] OpenSearch Geo feedback

Frank.Steggink at bentley.com Frank.Steggink at bentley.com
Fri Nov 16 15:11:35 EST 2007

Arliss, Carl,
With regard to point 1. Never mind, I overlooked it indeed (wrong
search). It appears that the order should be counterclockwise, if it is
relevant. From GML 3.1, section (gml:SurfaceType, gml:Surface):
"The orientation of the surface is positive ("up"). The orientation of a
surface chooses an "up" direction through the choice of the upward
normal, which, if the surface is not a cycle, is the side of the surface
from which the exterior boundary appears counterclockwise." ("Up" is
towards the viewer.) It is also mentioned in OGC Abstract Specification
Topic 1 (thanks to Carl, who pointed to ISO:19107, which is AS 1).
Despite this, I still can't find it in GML 3.2.1 (section 10.5.10,
SurfaceType, Surface).
Anyways, this proves my point that it is hard to get consensus on what
the "correct" vertex order is, so IMHO it is better not to rely on this.
Carl, do you mean to say that a point should not be expressed as
separate lat/lon pairs, or as a single tuple, but it should be expressed
in its GML form, like <gml:Point><gml:pos>43.25
-123.45</gml:pos></gml:Point>? I wonder how this could be expressed as
an OpenSearch parameter. Can an extension define constraints on
parameters, like formatting? (The same applies for polygons.)


mass-market-geo-bounces+frank.steggink=bentley.com at opengeospatial.org
[mailto:mass-market-geo-bounces+frank.steggink=bentley.com at opengeospatia
l.org] On Behalf Of Frank.Steggink at bentley.com
Sent: Friday, November 16, 2007 14:09
To: arliss.whiteside at baesystems.com; mass-market-geo at opengeospatial.org
Subject: Re: [Mass-Market-GEO] OpenSearch Geo feedback

Hello Arliss,
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


Hello list, 

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? 

Example: http://example.com/?q=pizza&center=43.25,-123.45&format=rss
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
question :)

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.


Frank Steggink 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mail.opengeospatial.org/mailman/private/mass-market-geo/attachments/20071116/1e0d44c2/attachment.htm 

More information about the Mass-Market-GEO mailing list