[georss] Geolocation by reference

Joshua Lieberman josh at oklieb.net
Fri Nov 9 22:42:31 EST 2007


Sean,

This is pretty similar to the idea behind georss:featurename, a  
qualified name which is resolvable to feature coordinates.  
Geonames.org is one source of such names, although they don't have to  
be placenames per se. In many cases, a direct link isn't so useful  
because the authoritative geometry isn't the right type or scale for  
the feed entries (e.g. detailed multi-polygon -> box), but could  
perhaps be extracted or updated automatically as needed.

atom:link elements are also being used to reference authoritative  
feature definitions for various purposes, e.g.

<link rel="http://www.geobase.ca/linktype/sourcefeature" href="http:// 
wfs.geobase.ca? 
service=WFS&version=1.1.0&request=GetFeature&featureid=admin.boundary. 
1M.muni.ottawa"/>

Cheers,

Josh

On Nov 9, 2007, at 6:59 PM, Sean Gillies wrote:

> GeoRSS has literal locations well covered. A possible use case for
> location by reference (hyperlink really) is coming up in my work and I
> want to run it by this group.
>
> My Pleiades project is collaborating with other digital classics
> projects to build out an ancient history web. Pleiades aims to be the
> authoritative gazetteer for the Greek and Roman civilizations; we
> maintain place name and locations resources that can be linked to from
> other projects for geographic context. For example, see this page  
> on the
> American Numismatic Society web site about a coin from the Xanthos  
> mint:
>
> http://publicserver.numismatics.org/collection/accnum/list? 
> accnum=1977.158.477&single=1
>
> The developers of the site are harvesting coordinates from the  
> Pleiades
> Xanthos record (http://pleiades.stoa.org/places/639166) and will be
> turning them around for use in their own GeoRSS feed (of mints). It
> works, but it's a fair amount of effort that has to be reimplemented
> from site to site across our little history web.
>
> I think there may be cause here to add more declarative syntax to the
> georss:where element. My initial idea is that georss:where could  
> have an
> optional src attribute exactly as atom:content can. The value of  
> the src
> attribute should be the URI of a GML document. Like so:
>
>   <atom:entry>
>   ...
>   <where src="http://example.com/locations/1.gml"/>
>   </atom:entry>
>
> where the resource at http://example.com/locations/1.gml would be
>
>   ...
>   <gml:Point>...</gml:Point>
>
> In this way the numismatists can reuse the authoritative Pleiades
> locations and need neither maintain their own duplicate database nor
> continually synch against Pleiades resources. The synchronization  
> could
> become built in.
>
> 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?
>
> Sean
>
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss



More information about the georss mailing list