[georss] WAS: GeoRSS Validation Service? RETURNING TO: multiplelocations and time
Carl Reed OGC Account
creed at opengeospatial.org
Thu Mar 1 15:56:35 EST 2007
I believe that Peter and I are saying the same thing - provide best practice guidance on how to do extensions to GeoRSS GML without breaking the GeoRSS simplicity goal.
Regards
Carl
----- Original Message -----
From: Peter Borissow
To: Knoth, Brian D. ; Mikel Maron ; Andrew Turner
Cc: georss at lists.eogeo.org
Sent: Thursday, March 01, 2007 10:56 AM
Subject: Re: [georss] WAS: GeoRSS Validation Service? RETURNING TO: multiplelocations and time
One man's metadata is another man's data - it's all a matter of perspective.
I'm all for keeping things simple.
In fact, what can be simpler - the GeoRSS spec can say something like "we support gml geometries - use whatever gml geometry you want. Here are some examples. Please refer to the gml spec for more information."
So the question still stands - why not support the full set of gml geometries? Because it's too complicated? Because you're afraid that clients will shy away from georss if it gets any more complicated? I'm new to the group so I just don't understand the logic.
That said, I'll settle for at least multipoint, multiline, and multipolygon :)
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 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 to find your fit.
------------------------------------------------------------------------------
Need a quick answer? Get one in minutes from people who know. Ask your question on Yahoo! Answers.
------------------------------------------------------------------------------
_______________________________________________
georss mailing list
georss at lists.eogeo.org
http://lists.eogeo.org/mailman/listinfo/georss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.eogeo.org/pipermail/georss/attachments/20070301/b60c2015/attachment.html
More information about the georss
mailing list