[georss] Transport of Toponyms with GeoRSS

Tue Aug 15 20:22:40 EDT 2006

Just for fun, take a look at the two attached documents (relatively short). 
These were developed by the internet crowd in the IETF for discussion, 
although they have been gathering dust until the IETF solves the location 
payload issues for ECRIT and RADIUS.

Anyway, this discussion reminded me of these authors work. There may be 
something useful as related to this discussion thread.

Cheers

Carl

----- Original Message ----- 
From: "Ron Lake" <rlake at galdosinc.com>
To: "Josh at oklieb" <josh at oklieb.net>; <georss at lists.eogeo.org>
Sent: Tuesday, August 15, 2006 5:53 PM
Subject: Re: [georss] Transport of Toponyms with GeoRSS

> Hi,
>
> Placement of labels is one of the knotty aspects of toponymy. The easy
> part is assigning names to features. The harder part is placing name
> labels on maps.  Most GIS systems do this by binding presentation and
> content- meaning that label "features" are created that associate the
> labels with geospatial locations.  Of course these locations need not be
> co-incident with the feature in question and are usually NOT. Automated
> label generation and placement in an environment that strictly separates
> presentation and content is possible, but is unlikely to meet with
> presentation requirements of cartographers - meaning that there will be
> ambiguities or that one must use mechanisms that provide names through
> means other than fixed labels on the screen (e.g. touch a feature and
> see its name).
>
> Ron
>
> -----Original Message-----
> From: georss-bounces at lists.eogeo.org
> [mailto:georss-bounces at lists.eogeo.org] On Behalf Of Josh at oklieb
> Sent: August 15, 2006 3:54 PM
> To: georss at lists.eogeo.org
> Subject: Re: [georss] Transport of Toponyms with GeoRSS
>
> Aye, there's the rub. What is it you are describing with a toponym?
> The resource described by the RSS entry (probably not in general a
> toponym) or the "feature-ness" of the resource which is bestowed upon
> it by GeoRSS.
>
> It seems you want to construct a link with two characteristics: a
> zoom-in action and a label to suggest what is geographically being
> zoomed in to. The former could be addressed with the "radius"
> attribute; the latter is probably a use case for adding a "name" or
> "featurename" attribute to georss:point / georss:where.
>
> Just a heads up that applying georss to update w3c geo (and thereby
> also making it more palatable to the microformat-ists) means in all
> likelihood coming up with an rdf serialization of georss. This means
> that the attributes we have hung on the georss properties such as
> georss:point cannot be there (being properties themselves, they can
> only describe a node or concept). This means either turning
> somersaults conceptually or moving the attributes up into separate
> rss properties, e.g. (rss 1.0)
>
> <item rdf:about=
>       'http://www.oreillynet.com/pub/wlg/8466?CMP=OTC-TY3388567169'>
>   <title>Live Coverage XML 2005 (Tuesday Keynotes)</title>
>   <link>http://www.oreillynet.com/pub/wlg/8466?CMP=OTC-TY3388567169</
> link>
>   <description>
>    <![CDATA[A live look at the XML Keynotes and seminal
> talks.]]>
>   </description>
>   <dc:creator>Kurt Cagle</dc:creator>
>   <dc:date>2005-11-15T07:45:58-08:00</dc:date>
>   <georss:featuretypetag>TGN:City</georss:featuretypetag>
>   <georss:featurename>US_Cities:Albany</georss:featurename>
>   <georss:radius>5000</georss:radius>
>   <georss:point> 46.183 -123.816</georss:point>
> </item>
>
> In essence, the <title> property describes the item resource, while
> the <georss:featurename>  property describes the item "feature"
>
> I'll look for the time to explain this more graphically.
>
> --Josh
>
> On Aug 15, 2006, at 6:27 PM, Allan Doyle wrote:
>
>>
>> On Aug 15, 2006, at 18:09, noiv wrote:
>>
>>>> Couldn't you simply use the RSS "title" field for the link?
>>>>
>>>> Mikel
>>>
>>> Hi Mikel,
>>>
>>> thanks for input. Publishers use the title tag as a description
>>> of the content. I think there is no chance to convince for example
>>> Reuters and have toponyms only as title.
>>>
>>> Which tag is designed to describe the coordinates
>>> of a GeoRSS feed entry in a human readable way?
>>>
>>
>> Is this perhaps the difference between RSS and a microformat? My
>> impression is that microformats are meant to encapsulate information
>> that is meant to still show up on the web page whereas RSS is really
>> not meant to be "human readable" in the sense of being shown directly
>> on a web page.
>>
>> Thus if you have a microformat + CSS, you can see something useful.
>> If you have RSS + CSS that's not always the case, you may also need
>> some XSLT or some other processing to make it "pretty" again.
>>
>> One of these days we need to work out the microformat serialization
>> of GeoRSS. Ideally by working together with the microformat folks.
>>
>> Allan
>>
>>> --
>>> noiv - ExploreOurPla.net
>>> _______________________________________________
>>> georss mailing list
>>> georss at lists.eogeo.org
>>> http://lists.eogeo.org/mailman/listinfo/georss
>>
>> -- 
>> Allan Doyle
>> +1.781.433.2695
>> adoyle at eogeo.org
>>
>>
>>
>> _______________________________________________
>> 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 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: draft-daviel-kaegi-html-geo-tag-07.txt
Url: http://lists.eogeo.org/pipermail/georss/attachments/20060815/c1359664/attachment.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: draft-daviel-kaegi-http-geo-header-05.txt
Url: http://lists.eogeo.org/pipermail/georss/attachments/20060815/c1359664/attachment-0001.txt 