[georss] GeoRSS Validation Service?

[Joshua Lieberman]

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