[georss] WAS: GeoRSS Validation Service? RETURNING TO: multiple locations and time

Thu Mar 1 07:26:29 EST 2007

Peter, I hear all that on geometric representation and airspaces and
such. But, don't those answer more of the question as to "what" that
thing is, rather than "where" the thing is (which, I believe, is what
georss is all about).  

I'm not very familiar with the entire gammet of GML objects, but
anything that acts like a container for multiple locations with times
sounds like a good thing to me. As much as I want to be able to
represent multiple locations for an item, I still believe that the
intent of RSS and geoRSS to be simple is a good one. More precisely, in
the words of Einstein, "as simple as possible, but no simpler". I feel
it's sufficient enough to be able to represent the boundaries of an
airspace as a cube (EnvelopeWithTimePeriod) in geoRSS, with the
understanding that the rss <link> would be able to access a higher
fidelity geospatial representation. The geoRSS would still allow rough
deconfliction and visualization. 

brian

________________________________

	From: Peter Borissow [mailto:peter.borissow at yahoo.com] 
	Sent: Wednesday, February 28, 2007 4:51 PM
	To: Knoth, Brian D.; Mikel Maron; Andrew Turner
	Cc: georss at lists.eogeo.org
	Subject: Re: [georss] WAS: GeoRSS Validation Service? RETURNING
TO: multiple locations and time

	I'm glad to see that you're on board with the idea of multiple
geometries.

	Multiple location representations for an item are already
supported by gml (e.g. MultiPoint). If GeoRSS supported the full range
of GML geometries, then this would be a non-issue.

	As for the case for incorporating other gml geometries (eg.
Arcs, Beziers, Circles, etc.) all I can say is this - there are
organizations out there that are modeling physical features using these
data types (e.g. arcs for flight routes, pie shaped wedges representing
the area of coverage taken by a camera, ellipses for relative
positions, etc.). 

	And what about 3D geometries - restricted airspace as an
example?

	Again, I just don't understand why we have to limit ourselves
to points, lines, and polygons.

	Thanks,
	Peter

	----- Original Message ----
	From: "Knoth, Brian D." <bknoth at mitre.org>
	To: Peter Borissow <peter.borissow at yahoo.com>; Mikel Maron
<mikel_maron at yahoo.com>; Andrew Turner <georss at highearthorbit.com>
	Cc: georss at lists.eogeo.org
	Sent: Wednesday, February 28, 2007 3:38:23 PM
	Subject: RE: [georss] WAS: GeoRSS Validation Service? RETURNING
TO: multiple locations and time

	Peter,

	As much as I agree with the need for multiple location
representations for an item, I'm finding it difficult to understand the
need for such a broad spectrum of geometric shapes for representing a
position. Just wondering if you could maybe give an example of a
position that needs a more complicated geospatial representation than
what is already there. I'm not sure right now what it means to be "at a
line segment or at a polygon or circle" for those already in there.
Feel free to respond directly to me if you'd like to take it offline.
Thanks,

	brian

________________________________

		From: Peter Borissow [mailto:peter.borissow at yahoo.com] 
		Sent: Wednesday, February 28, 2007 9:15 AM
		To: Mikel Maron; Andrew Turner; Knoth, Brian D.
		Cc: georss at lists.eogeo.org
		Subject: Re: [georss] WAS: GeoRSS Validation Service?
RETURNING TO: multiple locations and time

		Great Idea!

		Here's another question you might consider adding - one
that I haven't found the answer for:

		Why doesn't GeoRSS support the full range of GML
geometries?

		Thanks,
		Peter

		----- Original Message ----
		From: Mikel Maron <mikel_maron at yahoo.com>
		To: Andrew Turner <georss at highearthorbit.com>; "Knoth,
Brian D." <bknoth at mitre.org>
		Cc: georss at lists.eogeo.org
		Sent: Wednesday, February 28, 2007 8:45:03 AM
		Subject: Re: [georss] WAS: GeoRSS Validation Service?
RETURNING TO: multiple locations and time

		Nice initiative, to pull the discussions into more
referencible artifacts. 
		My concern is that an html faq page may quickly grow
stale, and that not everyone has access to it.
		Perhaps we could have an "FAQ" category on the blog,
and focus artifacting there. Or maybe in trac?

		----- Original Message ----
		From: Andrew Turner <georss at highearthorbit.com>
		To: "Knoth, Brian D." <bknoth at mitre.org>
		Cc: georss at lists.eogeo.org
		Sent: Wednesday, February 28, 2007 1:38:44 PM
		Subject: Re: [georss] WAS: GeoRSS Validation Service?
RETURNING TO: multiple locations and time

		On 2/27/07, Knoth, Brian D. <bknoth at mitre.org> wrote:
		> Peter,
		>
		> In any regard, I did not make any progress with this
argument here
		> (even after receiving a favorable vote for the
capability). So, like
		> you, we will need to abandon geoRSS in favor of a
more expressive
		> implementation.
		>

		There are many ideas and needs that come across GeoRSS
that fail to
		make it into the standard for whatever reason.

		What seems beneficial is to maintain a FAQ or history
of
		requests/proposals, their outcomes, and reasonings. And
finally, if it
		is not accepted *into* the standard, what people that
are working
		outside the 'standard' are all adopting.

		That way, if/when the discussion comes up again, we can
point to the
		'best suggested alternative' that others are using.
Others running
		into the same issue can use the common solution - and
anyone building
		tools can try and accommodate these cases.   And if
that feature does
		make it into the standard, everyone that was using that
ad-hoc
		solution can make the same transformation into the new
standard (which
		would have accounted for what people have been doing in
the meantime).

		This was illustrated by the Geonames discussion.
Location names was
		deemed to not make it into GeoRSS, so everyone that
needed it is using
		the Geonames namespace for location names.

		I've started to put these up on a FAQ page if that's
ok:
		http://georss.org/faq.html
		Andrew

		On 2/28/07, Knoth, Brian D. <bknoth at mitre.org> wrote:
		> Josh,
		>
		> If by Give-and-Take, you mean that I should go off
and implement my own
		> extension(s) or utilize some combination of existing
extensions for
		> time windows and locations (while providing a loose
referential linking
		> between them) to support what I need, then I feel I
have been very
		> accommodating this. These are the suggestions that
I've received and
		> I'm being forced to accept them because my original
recommendation to
		> this mailing list of simply allowing the GML
representation of space
		> with time in the geoRSS profile has been discarded.
		>
		> I just don't understand how an extension whose main
purpose which is to
		> represent location (ie, geoRSS:where) can ignore the
fact that stuff is
		> at a place at a specific time, usually for a period
of time, and then
		> at some other place for other period of time. This
fact just seems so
		> basic that to ignore it seriously limits the
applicability of geoRSS to
		> anything more than possibly just the world of
blogging. GE does a great
		> job of activating and deactivating things that are
outside of their
		> time windows when TimePeriods are specified in KML.
I've heard some
		> unsubstantiated rumors that GE may support geoRSS in
the future - if
		> that is the case, shouldn't the hooks at least be
inserted into geoRSS
		> now to begin preparing for that usage?
		>
		> So you are absolutely correct...I can build
proprietary extensions and
		> mechanisms for supporting this in our RSS feeds. I
have felt, and still
		> strongly do feel, that the proper place for this is
within a maturing
		> RSS extension such as geoRSS which, hopefully for its
own adoption
		> sake, can provide the building blocks necessary to
support
		> functionality required by not only the Flikrs and
blogs, but also
		> Enterprise RSS as well.
		>
		> VR
		> brian
		> _______________________________________________
		> georss mailing list
		> georss at lists.eogeo.org
		> http://lists.eogeo.org/mailman/listinfo/georss
		>

		-- 
		Andrew Turner
		ajturner at highearthorbit.com        42.4266N x 83.4931W
		http://highearthorbit.com <http://highearthorbit.com/>
Northville, Michigan, USA
		_______________________________________________
		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

________________________________

		Now that's room service! Choose from over 150,000
hotels 
		in 45,000 destinations on Yahoo! Travel
<http://travel.yahoo.com/hotelsearchpage;_ylc=X3oDMTFtaTIzNXVjBF9TAzk3N
DA3NTg5BF9zAzI3MTk0ODEEcG9zAzIEc2VjA21haWx0YWdsaW5lBHNsawNxMS0wNw-->
to find your fit.

________________________________

	Everyone is raving about the all-new Yahoo! Mail beta.
<http://us.rd.yahoo.com/evt=42297/*http://advision.webevents.yahoo.com/
mailbeta> 

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