[georss] GeoRSS Validation Service?

Tue Feb 27 21:03:23 EST 2007

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/