[Mass-Market-GEO] OpenSearch Geo feedback

Carl Reed OGC Account creed at opengeospatial.org
Fri Nov 16 15:48:05 EST 2007


OpenSearch Geo feedbackFrank -

As Arliss pointed out, GML is agnostic to the order of the coordinates used to express the exterior of a polygon. We need to remember that GML IS NOT a format but is instead XML schema for encoding just about any type of geographic content. As such, it is content model and format neutral. That is why GML does not specify such things as coordinate order for polys. This is also why GML has elements such as "exterior" and "interior".

Cheers

Carl
 
  ----- Original Message ----- 
  From: Frank.Steggink at bentley.com 
  To: mass-market-geo at opengeospatial.org 
  Sent: Friday, November 16, 2007 1:11 PM
  Subject: Re: [Mass-Market-GEO] OpenSearch Geo feedback


  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 10.2.2.1 (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.)

  Frank



------------------------------------------------------------------------------
  From: mass-market-geo-bounces+frank.steggink=bentley.com at opengeospatial.org [mailto:mass-market-geo-bounces+frank.steggink=bentley.com at opengeospatial.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 coplanar.

  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.

  Frank



------------------------------------------------------------------------------
  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.

   

  Arliss
    


------------------------------------------------------------------------------

  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 suggestions. 

  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? 

  Template: http://example.com/?q={searchTerms}&pw={startPage?}&center={geo:point?}&r={geo:radius?}&format=rss 
  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 this?

  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 client?

  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.

  Regards, 

  Frank Steggink 



------------------------------------------------------------------------------


  _______________________________________________
  Mass-Market-GEO mailing list
  Mass-Market-GEO at opengeospatial.org
  https://mail.opengeospatial.org/mailman/listinfo/mass-market-geo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mail.opengeospatial.org/mailman/private/mass-market-geo/attachments/20071116/4657177e/attachment.htm 


More information about the Mass-Market-GEO mailing list