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....
- 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 opensearch@googlegroups.com.
To unsubscribe from this group, send email to opensearch+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensearch?hl=en.

Jo,

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?

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 <metaz...@gmail.com>:

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

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

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

On 04/05/2010 17:05, DeWitt Clinton wrote:

Okay, this is done.

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

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

Jo Walsh said:

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.

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

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

On Thu, May 6, 2010 at 1:04 PM, Oscar Fonts <oscar.fonts.li...@gmail.com>wrote:

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

dear Oscar, thanks for this,

On 06/05/2010 12:04, Oscar Fonts wrote:

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

I would be happy to and should do it soon.

cheers,

jo

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

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