[georss] Geolocation by reference

Andrew Turner ajturner at highearthorbit.com
Mon Nov 12 12:56:54 EST 2007 

On Nov 12, 2007, at 12:42 PM, Sean Gillies wrote:

> Andrew,
>
> The more I think about georss:where[@src], the bigger the issue raised
> by Barry Hunter appears. The atom:content[@src] mechanism is trivial
> because we already have existing representations (web pages) that  
> can be
> fetched and dropped straight into the content element. On the other
> hand, how many of us expose bare (meaning without feature
> member/collection containers)  GML geometries on the web? I've never
> seen one. In order to work with existing WFS (or whatever), the
> semantics of georss:where[@src] would have to differ from
> atom:content[@src], and I don't think that's right.
>
> Extending atom:link (like Josh suggested) with new relationships seems
> more and more the way to go. It's an Atom-only solution unless you
> extend RSS 1/2 feeds with atom:link, but that's fine with me. If
> OpenSocial takes off the Atom/Geo community is going to be huge.

Good points. This is what I suggested in this post on how to utilize  
GeoRSS & KML together:
    http://highearthorbit.com/a-proposal-georss-kml/

However, to address the "knowing how to pull in the content", using  
the type attibute at least lets you inform the user what kind of  
representation is at the other side. So it may be GML, or a more  
complex atom:entry, KML, or HTML. I don't know if there is actually a  
prescription for how to 'handle' the atom:content[@src]?

I guess one issue was that by using atom:link you're making a  
reference to the entire entry rather than saying it is just an  
alternate geographic representation.


> More comments below ...
>
> Andrew Turner wrote:
>> Let me say first that I really like this suggestion and think it  
>> has a
>> lot of uses. It also falls in line with similar cases such as
>> atom:category that can point to a scheme (what do you mean by  
>> 'book' or
>> 'red'). atom:content 'src' is an optional uri that software can  
>> use to
>> grab the actual content
>> (http://atompub.org/2005/01/10/draft-ietf-atompub- 
>> format-04.html#rfc.section.5.12.2)
>>
>>
>> So in Sean's case, he could point to a URI that would contain an  
>> updated
>> geometry. Or another use for him might be to point to a resource that
>> contained the location in various reference frames, such as WGS84, or
>> Ptolemy's coordinates, or whatever ancient cartographer that may have
>> mapped it at some point.
>>
>> I could also see that it would be useful for someone that wanted  
>> to just
>> publish simple points (or MBR, or simplified Polygon) of say, a
>> Country's border, but then reference a URI to point to a much
>> higher-resolution version.
>>
>> Another mechanism that could be used here instead of, or in  
>> addition to,
>> the potentially changing coordinates would be a toponymic location. I
>> believe Pat Cappelaere and Marc from GeoNames came up with a  
>> mechanism
>> for this. A topoynym location, esp. using a schema URI to say  
>> where the
>> definition of this location can be found, would be very useful.
>>
>
> IMO, extending atom:link handles the above very well.
>
>> I think that the current GeoRSS mechanisms of 'relationshiptag',
>> 'featuretypetag' and 'featurename' are under-defined (from an
>> application/example perspective) and therefore rarely used.
>
> Agreed. There is also a bit of redundancy in combination with Atom.
>
> One aspect of those that *is* useful: declaration of what the
> georss:where element means to the containing entry. At the risk of
> starting a completely new thread, that relationship may be better
> expressed by new georss:where attributes than by use of a GeoRSS
> relationship tag. In other words, I think something like:
>
>   <georss:where
>     scheme="http://example.com/vocabularies/x"
>     term="is-bounded-by">...</georss:where>

Good suggestion - I think somewhere in the archives someone pointed  
out a 'standard' ontology for geographic relationships that we could  
use nominally?

How would this work with multiple geometries for a single entry?  
Somehow referring to an element id within the content would be nice.

>
> with the no attribute case defaulting to "is-located-at" works.
>
>>
>> We're *way* behind on moving forward with some of the outstanding
>> 'feature requests' that we were thinking about for GeoRSS v1.2 (I
>> believe 1.1 was a 'bug fix'?). What say we put together this SRC
>> proposal, Toponym, Multiple Geometry and others as potential specs  
>> and
>> do an email discussion vote for a 1.2 update?
>>
>
> Working my proposal into GeoRSS in some form would be great. I'm also
> hoping to find some folks who would like to help me write a "best
> geospatial practices for Atom" document.

Well, it would help if you put up a page on the GeoRSS.org CMS kind  
of summarizing the proposal. A BP for GeoAtom would be great!

>
> Cheers,
> Sean
>
>>
>> On Nov 11, 2007, at 10:54 AM, Sean Gillies wrote:
>>
>>> Raj,
>>>
>>> The use case in your third paragraph is exactly what I want to  
>>> support.
>>>
>>> Sean
>>>
>>> Raj Singh wrote:
>>>> I agree, I too get nervous making location too much like content.
>>>> First let me say the src attribute on <where> sounds reasonable in
>>>> that it's pretty non-invasive, but I'm not sure what problem you're
>>>> solving.
>>>>
>>>> If the goal is to simplify the process of adding <where> to the
>>>> <entry> you could do that with a nice OpenLayers application to  
>>>> "drill-
>>>> down-to-my-location-while-looking-at other-known-locations".
>>>>
>>>> The location by reference makes sense if you expect the actual
>>>> location to change in the future (e.g. a more accurate location is
>>>> determined through later research), and people know that in this  
>>>> case
>>>> their <entry>'s location should change too.
>>>>
>>>> ---
>>>> Raj
>>>>
>>>>
>>>> On Nov 9, 2007, at 6:59 PM, Sean Gillies wrote:
>>>>
>>>>> There is precedent in Atom for remote sourcing, but only to my
>>>>> knowledge
>>>>> for atom:content. The src attribute feels pretty good to me,  
>>>>> though
>>>>> I do
>>>>> think that it has the potential to make location (which is  
>>>>> metadata) a
>>>>> bit too much of content (data). Does anybody have other ideas for
>>>>> non-literal locations?
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> --Andrew Turner
>> ajturner at highearthorbit.com      42.2774N x 83.7611W
>> http://highearthorbit.com              Ann Arbor, Michigan, USA
>> Introduction to Neogeography - http://oreilly.com/catalog/ 
>> neogeography
>>
>>
>>
>
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss

-- 
Andrew Turner
ajturner at highearthorbit.com      42.2774N x 83.7611W
http://highearthorbit.com              Ann Arbor, Michigan, USA
Introduction to Neogeography - http://oreilly.com/catalog/neogeography


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.eogeo.org/pipermail/georss/attachments/20071112/d31e104c/attachment-0001.html

More information about the georss mailing list