[georss] GeoRSS Validation Service?

Tue Feb 27 16:58:34 EST 2007

Brian,

On Feb 27, 2007, at 12:05 PM, Knoth, Brian D. wrote:

> Peter,
>
> I just raised the exact issue(s) that you are raising this month. You
> could catch up on that email trail here:
> http://lists.eogeo.org/pipermail/georss/2007-February/000962.html
>
> We need support for multiple geometries, as well as, being able to
> specify specific time periods for those geometries within our RSS
> feeds. My suggestion was to allow for gml:EnvelopeWithTimePeriod in  
> the
> geoRSS GML profile. I think the need for these capabilities is  
> probably
> more universal than you are giving it credit for.

So far, "we" appears to be a small constituency. That might change in  
the future. You haven't answered any of the arguments against your  
proposed changes or responded to suggested alternatives, only  
reiterated how much your particular suggestion was needed. Even  
though the georss "process" is pretty freeform it does need to  
involve give-and-take and working across many specific requirements  
to a common denominator.
>
> In any regard, I did not make any progress with this argument here
> (even after receiving a favorable vote for the capability). So, like
> you, we will need to abandon geoRSS in favor of a more expressive
> implementation.

Out of the GeoRSS constituency, it was hardly a quorum, as Allan  
pointed out. Several alternatives were also provided to allow  
adherence to the existing spec while adding the application-specific  
capabilities you desire. If none of them is acceptable, then I wish  
you luck in your search for a balance of capability and ubiquity more  
favorable to your needs.

>
> brian
>
> -----Original Message-----
> From: georss-bounces at lists.eogeo.org
> [mailto:georss-bounces at lists.eogeo.org] On Behalf Of Peter Borissow
> Sent: Tuesday, February 27, 2007 11:55 AM
> To: Joshua Lieberman; georss at lists.eogeo.org
> Subject: Re: [georss] GeoRSS Validation Service?
>
> 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.
>
> 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.
>
> 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.
>
> I really appreciate all your comments/feedback. I hope you'll consider
> my use case in further revisions of the spec.
>
> 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/
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss