[georss] Multiple GeoRSS representations in one feed?

Sat Oct 21 06:23:22 EDT 2006

It was an interesting day!
Hope that Raj will pick up the great discussion that followed his presentation on WFS Basic, 
which ranged from "this is nice, but way too difficult for your regular web developer" to 
"dumbing down standards will lead to the downfall of civilization". 
Clearly balancing the perspectives of everyone from hackers to pros is a difficult thing :) 
and that's something GeoRSS has done well.

But of course in the compromise there is confusion .. http://www.georss.org/blog/?p=38
And that's something we need to do a better job of explaining, 
ie translating this discussion thread into an accessible developer resource.

So there's issues of when and how GML and Simple profiles are used, 
how other parts of the RSS/Atom structure can be purposed for geodata applications (like the ids, resource links, timestamps),
and how the folksonomic properties are used,
and more ..

I second the feeling that it's time to iterate on usage and examples. 
There's a lot of fertile ground to explore here, at version 1.0. 
Simply blogging the experiments might be a useful toe dip.

One thing I've tried is using "relationshiptypetag" to specify image overlays.
http://brainoff.com/weblog/2006/08/26/1184

-Mikel

----- Original Message ----
From: "raj at rajsingh.org" <raj at rajsingh.org>
To: georss at lists.eogeo.org
Sent: Friday, October 20, 2006 7:34:08 PM
Subject: Re: [georss] Multiple GeoRSS representations in one feed?

Mikel and I spent the day at the UK geospatial mashup event today  
<http://www.opengeospatial.org/node/615>, and one point he made in his  
talk was that no one has done much with the 'folksonomic' tags  
featuretype and relationshiptag (bottom of  
http://www.georss.org/model.html). I have a feeling that they could be  
highly relevant here. Anyone want to dip their toe in this water and  
mock up some examples?

---
Raj

Quoting "Josh at oklieb" <josh at oklieb.net>:

> Hi,
>
> On Oct 20, 2006, at 11:45 AM, Jason Birch wrote:
>
>> Wow,
>>
>> I'm interested to see all of the discussion.  I can live with
>> simple for
>> now, but it would be great if there were a "recommendation" that
>> clients
>> display the highest-complexity feature they are capable of.  Then I
>> could embed both a simple feature and a gml feature in the same
>> item (so
>> I don't need to worry about different ID's).  I do like the idea of
>> pushing the envelope, but I also have a responsibility to my
>> citizens to
>> be as inclusive as possible.
>>
>> As far as conceptually discrete features within a single item...
>> you're
>> right, there are cases where a single concept (hospitals in a certain
>> region) occurs over multiple locations.  MultiGeometry would solve
>> this,
>> but it would likely be abused by bloggers talking about unrelated
>> locations in the same item.  Perhaps there needs to be the ability to
>> tag Geo's with IDs and then reference them from within the article
>> like
>> #mylocation1, #mylocation2 ?
>
> Even GeoRSS GML excludes multigeometries because of their complexity.
> As far as a client sifting through a bag of georss elements to figure
> out what they can render, it is still a problem in defining what the
> complexity "ranking" is, or what the relationship between a
> georss:point and a georss:line in the same entry might be (one might
> assume the point is a middlepoint, but maybe it's a centroid or the
> starting point, or something else).
>
>
> We try to keep to the principle that RSS is clear news about
> something, not the something itself or multiple ambiguous
> perspectives on the something. So GeoRSS shouldn't try to represent
> the full geographic complexity of information, just simple location
> "news".  Better to reference separate GML features that do the former.
>
> Now what your use case might be the driver towards is a revisit of
> GeoRSS to microformats. The idea would be that GeoRSS could be simple
> news about an HTML resource which has geotagged span's and div's to
> refine the geographic concept of the presented information. Yes, Pat,
> you could even include that tagged HTML in the atom "content" element
> (but I didn't really say that).
>
> We made a proposal originally for this geotagging, but have something
> of a disjunction with microformats. It would be good to be compatible
> with the microformat "movement" but the latter emphasizes tags being
> visible as text in addition to being visualizable on a map. Not sure
> that coordinate text strings popping up all over an HTML page is
> good idea in the case of geotags. It would be good to resolve this soon.
>
>>
>> I'm hoping to attach shapes to things like fire calls, new building
>> permits, featured parks or trails, etc, etc.
>>
>> No site yet, but it's for work (City of Nanaimo).  I'm pretty lucky
>> here, but politics are still harder than technical...
>>
>> Jason
>>
>> -----Original Message-----
>> From: georss-bounces at lists.eogeo.org
>> [mailto:georss-bounces at lists.eogeo.org] On Behalf Of Andrew Turner
>> Sent: Friday, October 20, 2006 08:18
>> To: georss at lists.eogeo.org
>> Subject: [georss] Multiple GeoRSS representations in one feed?
>>
>> On 10/20/06, Carl Reed OGC Account <creed at opengeospatial.org> wrote:
>>> An interesting conundrum. Perhaps what we need is the simple ability
>>> for a RSS/GeoRSS payload to provide a URI or URL reference to an
>>> external package of content structured as a GML document.
>>
>> Sounds interesting - though I don't know if I would call that a
>> "simple
>> ability". :)
>>
>> The simplest method would just be the inclusion of 2
>> representations of
>> the same "geometry" in a single feed. This allows current clients to
>> read & display.
>>
>> Though another conflict would be - how does someone include multiple
>> Points or Lines for an item, but aren't necessarily connected? For
>> example, I want to include 5 locations of hospitals in a single item -
>> or do I need to make those separate items?
>>
>> Andrew
>> _______________________________________________
>> georss mailing list
>> georss at lists.eogeo.org
>> http://lists.eogeo.org/mailman/listinfo/georss
>> _______________________________________________
>> georss mailing list
>> georss at lists.eogeo.org
>> http://lists.eogeo.org/mailman/listinfo/georss
>
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss
>

_______________________________________________
georss mailing list
georss at lists.eogeo.org
http://lists.eogeo.org/mailman/listinfo/georss