[georss] Geolocation by reference

[Andrew Turner]

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.

I think that the current GeoRSS mechanisms of 'relationshiptag',  
'featuretypetag' and 'featurename' are under-defined (from an  
application/example perspective) and therefore rarely used.

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?


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


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