[Mass-Market-GEO] OpenSearch Geo feedback
Carl Reed OGC Account
creed at opengeospatial.org
Fri Nov 16 14:16:12 EST 2007
OpenSearch Geo feedbackJust to follow up on Frank's comments, it would be really nice if the expression (at least at the information model level) of a geo-point/line/poly where the same across multiple specs/standards. For example, GeoRSS GML point. We are now using the same expression for a point geometry in the OASIS geo-oasis GML profile, the IETF PIDF-LO geoshape application schema, and a IEEE 1451 standard. In all cases, the expression of a point geometry is consistent with ISO 19107 and GML 3.1.1.
As to coordinate order for a poly, why not follow what is expressed in ISO 19107 and GML 3.x.x?? Again for consistency and harmonization across communities of use.
----- Original Message -----
From: Frank.Steggink at bentley.com
To: mass-market-geo at opengeospatial.org
Sent: Friday, November 16, 2007 10:05 AM
Subject: [Mass-Market-GEO] OpenSearch Geo feedback
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?
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.
Mass-Market-GEO mailing list
Mass-Market-GEO at opengeospatial.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mass-Market-GEO