[opensearch:370] updating Draft 2 of OpenSearch Geo extensions

[Jo Walsh]

dear all,

I would like to make some changes to the Draft 2 version of OpenSearch
Geo extensions (and change the main link to the updated draft).

Discussion of / background to the proposed changes is here:
http://unlock.posterous.com/opensearch-geospatial-in-progress

In short this would involve adding the geo:geometry property and
geo:name , deprecating the use of geo:locationString, that would bring
the whole thing in line with the version in the Open Geospatial
Consortium CSW "part document".

But i don't know how to update the page at
http://www.opensearch.org/Specifications/OpenSearch/Extensions/Geo/1.0/Draft_2
- is it just wiki markup underneath - DeWitt / others can you send me a
copy to patch?
Any objections?

cheers,


jo
--

--
You received this message because you are subscribed to the Google Groups "OpenSearch" group.
To post to this group, send email to opens...@googlegroups.com.
To unsubscribe from this group, send email to opensearch+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensearch?hl=en.

[Oscar Fonts]

Jo,

> Any objections?

I'm +1 on deprecating {geo:locationString?} in favour of {geo:name?}.

But I doubt on the need for {geo:geometry} parameter, defined simply
as a "Well-Known Text" expression. Well Known Text syntax [1] provides
for many geometry types: point, linestring, polygon, triangle,
polyhedralsurface, TIN, multipoint, multilinestring, multipolygon and
geometrycollection; either in 2D or 3D, and optionally with linear
referencing. I question if this expressiveness is necessary, as
probably we won't need polyhedralsuface or 3D filtering.

So I ask if it would'nt be better to add a simpler {geo:multipolygon?}
parameter, coherent with the {geo:polygon} syntax, to cover the need
you addressed in the GENESI-DR project. And get rid of unnecessary
complexity.

If the case we decide that it is worth using a 'geometry' WKT
parameter, we could explicitly state in the wiki which of the
geometric expressions are meant to be supported. For instance, 2D-only
geometries: point, linestring, polygon, multi-idem, and
geometrycollection. In this case, I propose to deprecate the
{geo:polygon} parameter, to avoid redundancy and geometry
serialization syntax incoherences across parameters.

Any other thoughts?


> I don't know how to update the page at
> http://www.opensearch.org/Specifications/OpenSearch/Extensions/Geo/1.0/Draft_2

If you are uncomfortable with wiki markup, send me the modifications
and I'll add them.

Cheers,

Oscar.


---
[1] HERRING, J. R. (editor) (2006) “OpenGis® Implementation
Specification for Geographic information – Simple feature access –
Part 1: Common architecture. Version 1.2.0” Open Geospatial Consortium
Inc. Ref. OGC 06-103r3. Chapter 7: Well-known Text Representation for
Geometry. http://www.opengeospatial.org/standards/sfa#downloads
(pp.53-63)
---


2010/5/4 Jo Walsh <meta...@gmail.com>:

> dear all,
>
> I would like to make some changes to the Draft 2 version of OpenSearch Geo
> extensions (and change the main link to the updated draft).
>
> Discussion of / background to the proposed changes is here:
> http://unlock.posterous.com/opensearch-geospatial-in-progress
>
> In short this would involve adding the geo:geometry property and geo:name ,
> deprecating the use of geo:locationString, that would bring the whole thing
> in line with the version in the Open Geospatial Consortium CSW "part
> document".

[DeWitt Clinton]

Ahh, I think I locked down all of the spec pages to prevent drive-by spam (of which I clean up enough as it is!).  

Jo -- If you send me your opensearch.org wiki username (you may need to create one) I'll add you to a group that can edit this page.

Also CC-ing Andrew, original author of the Geo extension, to make sure he sees this thread and has a chance to chime in if he wants.

-DeWitt

[Jo Walsh]

On 04/05/2010 17:05, DeWitt Clinton wrote:
> Ahh, I think I locked down all of the spec pages to prevent drive-by
> spam (of which I clean up enough as it is!).
>

> Jo -- If you send me your opensearch.org <http://opensearch.org> wiki

> username (you may need to create one) I'll add you to a group that can
> edit this page.

Okay, this is done.

> Also CC-ing Andrew, original author of the Geo extension, to make sure
> he sees this thread and has a chance to chime in if he wants.

Ty, thanks Oscar for your thoughtful comments. I will admit to some
intention to stick with what is going through the OGC standards process
now - but that is bad behaviour technologically right, or could be.

So i would be interested to hear more evidence either way - about e.g.
whether the duetopia use cases can be met with a multipolygon - one
reason that t2 did it this way was lack of multipolygon support in
georss - perhaps it would be possible to patch georss. They will say
"but this is meant to be simple" and we will say "ah there are >2 simple
real-world use cases", etc.

In the meantime i will update the draft just with the non-contentious bits.

thanks,


jo

[Oscar Fonts]

Jo Walsh said:
> In the meantime i will update the draft just with the non-contentious bits.

Consensus proposal:

Add a {geo:geometry?} parameter that allows the following 2D WKT
expressions (in EPSG:4326):

* POINT
* LINESTRING
* POLYGON
* MULTIPOINT
* MULTILINESTRING
* MULTIPOLYGON
* GEOMETRYCOLLECTION

These are the same geometries described in OGC's CSW 2.0.2 CQL syntax,
so should be compatible with what is going on in CSW 3.0 WG.

It would be good to add a remark saying that in WKT the coordinates
are in (x, y) order, or (lon, lat) as opposed to the {geo:polygon?}
parameter, or GeoRSS.

Finally, {geo:polygon?} would be deprecated.

---
Jo, is this OK?
If yes, would you mind to add it to the draft 3 wiki?
(I can edit the wiki myself - but insecure with my English).

Thanks!

Oscar.

[Pedro Goncalves]

Hi Oscar

good proposal, I think with this we might get a good middle ground between the EO requirements and what is within the possibility of the majority of clients.

No need to say that the geo:geometry is being considered always as an optional feature of the search engine
More simple geo search servers might only support the geo:box (the minimal feature of a geo-enabled  search engine)

ciao

Pedro

[Jo Walsh]

dear Oscar, thanks for this,

On 06/05/2010 12:04, Oscar Fonts wrote:
> Consensus proposal:
>
> Add a {geo:geometry?} parameter that allows the following 2D WKT
> expressions (in EPSG:4326):
>
> * POINT
> * LINESTRING
> * POLYGON
> * MULTIPOINT
> * MULTILINESTRING
> * MULTIPOLYGON
> * GEOMETRYCOLLECTION
>
> These are the same geometries described in OGC's CSW 2.0.2 CQL syntax,
> so should be compatible with what is going on in CSW 3.0 WG.
>
> It would be good to add a remark saying that in WKT the coordinates
> are in (x, y) order, or (lon, lat) as opposed to the {geo:polygon?}
> parameter, or GeoRSS.
>
> Finally, {geo:polygon?} would be deprecated.

> Jo, is this OK?

This would be fine with me, as you note the spelled out and limited list
of acceptable WKT expressions has some precedent in OGC standards world
and this can be added to the OGC version of the spec without disrupting
that process...

> If yes, would you mind to add it to the draft 3 wiki?
> (I can edit the wiki myself - but insecure with my English).

I would be happy to and should do it soon.

cheers,


jo

[JasonM1]

Hi all.

 

In regards to updates to the Geo extensions draft 2 document it should be considering that the example for the KML response to an opensearch request violates the OGC KML 2.2 spec.

 

Another discussion shows an example using an ExtendedData element in the root Document with this metadata to conform to the spec.

https://groups.google.com/d/topic/opensearch/C1RVEZrUKhk/discussion

 

--jason