[georss] Geolocation by reference

Mon Nov 12 14:44:59 EST 2007

Hi Andrew:

There are a number of places GML geometries are used outside of GML
features both within and outside of GML itself.  While I would argue
there is bigger bang for the buck in using GML completely - there is
certainly nothing wrong with not doing that.  The use of where in geoRSS
is correct in that it uses a property in GML speak as the container for
the GML objects.  On the other hand I agree completely that interacting
with a WFS means consuming features - i.e. meaningful application
objects.  I think the distinction between KML and GML on this score is a
question of whether you want presentation (KML) or content (GML).  Yes
you can carry some data content in the KML but there is no way to create
kinds of things and that is not the intent.

Cheers

From: georss-bounces at lists.eogeo.org
[mailto:georss-bounces at lists.eogeo.org] On Behalf Of Andrew Turner
Sent: November 12, 2007 9:57 AM
To: Sean Gillies
Cc: georss at lists.eogeo.org
Subject: Re: [georss] Geolocation by reference

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.sec
tion.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/3ece7207/attachment-0001.html 