[georss] GeoRSS Validation Service?

Wed Feb 28 14:36:02 EST 2007

I think I mentioned this once before. Perhaps one way out of this conundrum 
is for the group to define and document a consistent approach as to how to 
express extensions to GeoRSS GML. The OGC Architecture Board is having a 
really strong discussion on "core" (read simple or relatively so) standards 
and then how to define extensions that enable broader, but still 
interoperable, functionality. The core/extension discussion also includes 
the relationship of this approach to the "complete" standard and profiles of 
that standard.

Anyway, until the georss community decides on an approach to easily define 
extensions and have community agreement on those extensions, then this issue 
will arise over and over with the net effect potentially being fragmentation 
of approaches.

Regards

Carl

----- Original Message ----- 
From: "Peter Borissow" <peter.borissow at yahoo.com>
To: "Joshua Lieberman" <josh at oklieb.net>; <georss at lists.eogeo.org>
Sent: Tuesday, February 27, 2007 7:03 PM
Subject: Re: [georss] GeoRSS Validation Service?

> Hi Josh-
>    Please see my comment below.
>
> ----- Original Message ----
> From: Joshua Lieberman <josh at oklieb.net>
> To: Peter Borissow <peter.borissow at yahoo.com>; georss at lists.eogeo.org
> Sent: Tuesday, February 27, 2007 4:34:20 PM
> Subject: Re: [georss] GeoRSS Validation Service?
>
>
> Peter,
>
> On Feb 27, 2007, at 11:54 AM, Peter Borissow wrote:
>
>> There are really 2 seperate issues here:
>>
>> (1) GeoRSS does not support the full range of gml geometries
>> (2) GeoRSS does not support multiple geometries for a single item/
>> entry
>>
>> My use case is really quite simple. I wish to represent the most
>> significant locations referenced in a single news article. For
>> example, in a given day in Iraq there may be multiple bombings. A
>> single article will detail where the bombings took place (Baghdad,
>> Mosel, Samarra, etc.). Rather than creating multiple entries for
>> the same article, I'd like to use a gml Multipoint geometry type in
>> the "where" tag.
>
> And you're quite sure that you're happy with no identifying
> information for each point other than the link to the article?
> Nothing which says "Mosul", "Baghdad", etc? Just trying to be clear
> about this.
>
> [PB] Yes. The "where" node should be limited to describing a spatial 
> coordinates.
>
>
>>
>> It seems to me that GeoRSS ought to support ANY valid gml geometry
>> - regardless of current browser/client support. It's confusing at
>> best to claim that GeoRSS supports GML when in fact it only
>> supports point, lines, and polygons.
>
> There is no software in existence which supports "ANY valid gml
> geometry", and successes at GML usability over years have required
> GML profiles for not only interoperability but even operability.
> GeoRSS never claimed to support all of GML, in fact this is why it
> supports a defined, limited profile of GML.
>
> [PB] GML is a beast, I agree. However, I still don't understand why the 
> "where" node can't support other gml types. I'm all for keeping things 
> simple and so I definately understand the resistance to change. However, I 
> think that limiting the universe to points lines and polygons is a little 
> too simplistic.
>
>
>>
>> The use-case for supporting multiple, different geometries (e.g.
>> points and lines) for a single item/entry is arguably unique and I
>> personally can live without it.
>>
>> I guess in the meantime I'll have to create my own psuedo-GeoRSS
>> schema to support a wider range of gml geometries.
>
> Do consider the option of providing GeoRSS "+" by sticking to the
> spec in the georss:where element and adding your extension elsewhere
> (e.g. atom:content or just by mixing GML elements from your own
> application schema (e.g. PointCollectionOfInterest) into the item.
>
> [PB] Yes, I am considering it now - something akin to KML's MultiGeometry 
> type.
>
>
>>
>> I really appreciate all your comments/feedback. I hope you'll
>> consider my use case in further revisions of the spec.
>
> Your contributions to interesting use cases are appreciated, and yes,
> I'm sure there will be more discussion of it.
>
>
>>
>> Best Regards,
>> Peter
>>
>>
>>
>>
>>
>> ----- Original Message ----
>> From: Joshua Lieberman <josh at oklieb.net>
>> To: georss at lists.eogeo.org; Peter Borissow <peter.borissow at yahoo.com>
>> Sent: Monday, February 26, 2007 10:30:24 PM
>> Subject: Re: [georss] GeoRSS Validation Service?
>>
>>
>> On Feb 26, 2007, at 5:46 PM, Andrew Turner wrote:
>>
>>> On 2/26/07, Joshua Lieberman <josh at oklieb.net> wrote:
>>>> Peter,
>>>>
>>>> There was much (months, years) discussion of this, and the decision
>>>> came out in favor of simplicity. It is more complicated for a client
>>>> to represent and work with a complex multiple geometry; and it is
>>>> more difficult to figure out its purpose, e.g. which point
>>>> corresponds to which part or aspect of the referenced Web resource.
>>>> For the same reason, only one georss:where element is allowed per
>>>> item.
>>>>
>>>> If the aim is to represent a region for the resource, an envelope or
>>>> polygon does the job more simply and clearly.
>>>>
>>>
>>> I am in agreement with you on this Peter - it seems like there should
>>> be a simple way to have multiple geometries per item. Simple use
>>> cases:
>>> 1) Item talks about hospitals in a city, want Points for hospital
>>> locations
>>> 2) Item is a story about a trip, want Points and lines to reference
>>> the hikes/locations visited
>>
>> I am really in sympathy about these use cases, however it is
>> important to point out that GeoRSS does not add features, it adds
>> geometry properties to turn other content into features. Neither
>> multiple geometry properties nor multi-geometries changes that. In
>> the use cases above, the multiple geometries are actually referring
>> to physical objects / locations with separate identies, i.e. separate
>> features.
>>
>> This is in contrast to some town boundaries, which have one feature
>> identity but need multiple inner and outer rings to represent it.
>> There are surprisingly few real cases for multipoints, perhaps
>> sprinkler heads on a field or something else where there are no
>> attributes or properties not shared among all of the points.
>>
>> The conflict seems to be between a view of a resource (e.g. Web page)
>> as a single  feature and a view of items within the Web page as
>> separate features.
>>
>> It appears that XHTML 2.0 (draft) goes a long ways towards helping,
>> as it allows sensible tagging (about -> property -> content
>> attributes for meta, span, div, etc). These tags  do in fact work now
>> in browsers (ie are ignored), but they are unfortunately not valid
>> XHTML 1.0 nor HTML 4.0.1.
>>
>> In any case, it's still one RSS/Atom item < - > one feature. One way
>> around the conflict then might be two feeds. An item referring to a
>> Web page would have one georss geometry (e.g. envelope), but the
>> atom:content could hold another feed with one (named, linked) item
>> and geometry property per distinct feature such as hospital within
>> the Web page; or the first feed could link to the second feed without
>> containing it.
>>
>> There should be a way to build this without breaking something else,
>> but it might have to wait for XHTML help to be a general solution.
>>
>> --Josh
>>
>>>
>>> both of these use cases aren't solved by having multiple items. The
>>> solution I've seen so far is to use Microformats within the content
>>> itself to mark adr or geo, but this really isn't an entirely
>>> satisfactory solution and uses a different technology.
>>>
>>> What I would hope emerge would be a way to have multiple
>>> <georss:point> (or whatever) for use case 1, or that include a
>>> reference to an element (div or something) within the content for use
>>> case 2.
>>>
>>> Perhaps there is someone that can put out an example of a currently
>>> supported solution we can all use in the meantime?
>>>
>>> Andrew
>>
>>
>>
>> ______________________________________________________________________
>> ______________
>> TV dinner still cooling?
>> Check out "Tonight's Picks" on Yahoo! TV.
>> http://tv.yahoo.com/
>
>
>
> ____________________________________________________________________________________
> Never miss an email again!
> Yahoo! Toolbar alerts you the instant new Mail arrives.
> http://tools.search.yahoo.com/toolbar/features/mail/
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss 