|
GeoRSS Multiple Locations, References & Excerpts
Sorry for not posting about this to the list earlier, but I wrote up
several proposal extensions to GeoRSS to handle: Multiple Locations
for a single 'Story', References to externally geometries, and
Excerpts.
My blog post outlining the ideas, and why the current proposal is
framed as such is in this post:
http://highearthorbit.com/georss-multiple-locations/Sean Gillies has already countered with some good thoughts & suggestions here:
http://zcologia.com/news/711/multiple-locations-in-georss/I also created a Proposals page on GeoRSS.org site with links to the proposals:
http://georss.org/proposalsI know these ideas have been discussed in the past, but then kind of
petered out. But I think there is immediate interest in nominally
agreeing to and implementing a solution in the very near term. In
fact, I would like to suggest that we have something ready for
Where2.0.
Also understand that this proposal is for "Simple" - I know there are
GML people that will point to the semantics of the proposal and wag
their fingers. I suggest to them to draft a tasty Semantic/GML
parallel version.
Thanks!
Andrew
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss
|
|
Re: GeoRSS Multiple Locations, References & Excerpts
Andrew Turner wrote:
> Sorry for not posting about this to the list earlier, but I wrote up
> several proposal extensions to GeoRSS to handle: Multiple Locations
> for a single 'Story', References to externally geometries, and
> Excerpts.
>
> My blog post outlining the ideas, and why the current proposal is
> framed as such is in this post:
> http://highearthorbit.com/georss-multiple-locations/>
> Sean Gillies has already countered with some good thoughts & suggestions here:
> http://zcologia.com/news/711/multiple-locations-in-georss/>
> I also created a Proposals page on GeoRSS.org site with links to the proposals:
> http://georss.org/proposals>
> I know these ideas have been discussed in the past, but then kind of
> petered out. But I think there is immediate interest in nominally
> agreeing to and implementing a solution in the very near term. In
> fact, I would like to suggest that we have something ready for
> Where2.0.
>
> Also understand that this proposal is for "Simple" - I know there are
> GML people that will point to the semantics of the proposal and wag
> their fingers. I suggest to them to draft a tasty Semantic/GML
> parallel version.
>
> Thanks!
> Andrew
Indeed, I'm -1 on this kind of multiple location. Geometries, with the
help of "featurename" and "excerpt", are turned into "lite" items that
no reader understands [1]. If it's going to be foreign to a reader, it
might as well be GML -- which already does all of this, of course (no
snark this time).
Feed threads (RFC 4685), on the other hand, are something that degrade
nicely for "dumb" readers. I wonder if this is where RSS and Atom geo
splits?
Sean
[1] GMaps *does* get the geometry items from an entry like Andrew proposes:
http://maps.google.com/maps?f=q&hl=en&geocode=&q=http:%2F%2Fzcologia.com%2Ffiles%2Fmulti-location.atom&ie=UTF8&ll=32.694866,-98.789062&spn=40.508018,68.90625&t=p&z=4but only by accident, and with great loss of information.
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss
|
|
Re: GeoRSS Multiple Locations, References & Excerpts
Andrew,
Thanks for stirring this up. I've had a GeoRSS 2.0 proposal sitting on
my desk for a long time but haven't gotten to it.
This may come as a bit of a shock, but I have to agree with Sean about
some of these things. Entries are already a pretty lightweight entity
and links are already a pretty good way to, well, link to additional /
voluminous resources for various purposes which may or may not be
specialized in the view of a particular client or user.
About multiple geometries: every time we've drilled down into the use
case for this, it has ended up being important to express their
relationships. Geometry "bags" are hardly every really usefully
expressive. One approach is to create relationships within a
collection which give meaning to the order. That gets more and more
specialized, though, as we saw a few months ago with various <dataset>
proposals.
The "story graph" is an interesting problem which GML btw does not yet
solve, but a graph of Atom entries is at once more compatible with
simple viewers and more robust in terms of expressiveness. Pointers
such as the threading proposal use would be the way to go (not sure
links couldn't do this as well), except that we don't seem to be there
yet referencing and managing entries as first class Web objects. Yes,
there is a unique identifier, but not necessarily a "home" URL.
The CGDI pilot, in leveraging GeoAtom, suggested some useful link
types to support this. I'll see if we can converge on a general
proposal next week at the OGC TC and post it for comment.
Josh
On Mar 19, 2008, at 12:13 PM, Andrew Turner wrote:
> Sorry for not posting about this to the list earlier, but I wrote up
> several proposal extensions to GeoRSS to handle: Multiple Locations
> for a single 'Story', References to externally geometries, and
> Excerpts.
>
> My blog post outlining the ideas, and why the current proposal is
> framed as such is in this post:
> http://highearthorbit.com/georss-multiple-locations/>
> Sean Gillies has already countered with some good thoughts &
> suggestions here:
> http://zcologia.com/news/711/multiple-locations-in-georss/>
> I also created a Proposals page on GeoRSS.org site with links to the
> proposals:
> http://georss.org/proposals>
> I know these ideas have been discussed in the past, but then kind of
> petered out. But I think there is immediate interest in nominally
> agreeing to and implementing a solution in the very near term. In
> fact, I would like to suggest that we have something ready for
> Where2.0.
>
> Also understand that this proposal is for "Simple" - I know there are
> GML people that will point to the semantics of the proposal and wag
> their fingers. I suggest to them to draft a tasty Semantic/GML
> parallel version.
>
> Thanks!
> Andrew
> _______________________________________________
> georss mailing list
> georss@...
> http://lists.eogeo.org/mailman/listinfo/georss_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss
|
|
 Re: GeoRSS Multiple Locations, References & Excerpts
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Andrew and I chatted a bit about this. One convincing argument for a georss:collection is that many publishers want to stick to a limited number of entries, say 10, and that if each "entity" or story is composed of multiple actual entires, each with a single geometry, then the publisher must choose between limiting the number of actual entities, or publishing a potentially large number of entries. In either case, it could be confusing for the user, using a vanilla feed reader that doesn't understand the convention of "link rel='related'". However, in order to support either way of encoding a multigeometry, feed readers would need to adapt. Of course, Mapufacture will be ready :). But there will be a
delay between spec decision and adoption, and one way to approach this is look to see which option causes the least pain in the interim. Unfortunately, I think both georss:collection and multiple entries encodings would break things in different ways. Curiously, Google Maps can already either, apparently their parser is just looking for any georss child nodes within an entry. Another factor, what I think Josh is describing, is that a collection increases the complexity of associating each geometry with other facets. For instance, each geometry might only apply for a particular timeframe, and be associated with a piece of media. We'd then need to come up with special case applications of other namespaces within the georss:collection, and who knows if anyone would ever even support that, if we ever possibly came to agreement in the standard. Keeping the "entry" as the primary holder of all these facets is the cleanest and surest way
forward. Also, Sean's proposal doesn't actually require any changes to the specification. This would be a big bonus to our process. It would be a recommended convention. No need for a GeoRSS 2.0. Really, I'm curious to hear opinion on these two proposals from the people clamouring for this support. What do everyblock and everytrail think of the options? -Mikel ----- Original Message ---- From: Joshua Lieberman < josh@...> To: GeoRss < georss@...> Sent: Wednesday, March 19, 2008 10:10:58 AM Subject: Re: [georss] GeoRSS Multiple Locations, References & Excerpts
Andrew, Thanks for stirring this up. I've had a GeoRSS 2.0 proposal sitting on my desk for a long time but haven't gotten to it. This may come as a bit of a shock, but I have to agree with Sean about some of these things. Entries are already a pretty lightweight entity and links are already a pretty good way to, well, link to additional / voluminous resources for various purposes which may or may not be specialized in the view of a particular client or user. About multiple geometries: every time we've drilled down into the use case for this, it has ended up being important to express their relationships. Geometry "bags" are hardly every really usefully expressive. One approach is to create relationships within a collection which give meaning to the order. That gets more and more specialized, though, as we saw a few months ago with
various <dataset> proposals. The "story graph" is an interesting problem which GML btw does not yet solve, but a graph of Atom entries is at once more compatible with simple viewers and more robust in terms of expressiveness. Pointers such as the threading proposal use would be the way to go (not sure links couldn't do this as well), except that we don't seem to be there yet referencing and managing entries as first class Web objects. Yes, there is a unique identifier, but not necessarily a "home" URL. The CGDI pilot, in leveraging GeoAtom, suggested some useful link types to support this. I'll see if we can converge on a general proposal next week at the OGC TC and post it for comment. Josh On Mar 19, 2008, at 12:13 PM, Andrew Turner wrote: > Sorry for not posting about this to the list earlier, but I wrote
up > several proposal extensions to GeoRSS to handle: Multiple Locations > for a single 'Story', References to externally geometries, and > Excerpts. > > My blog post outlining the ideas, and why the current proposal is > framed as such is in this post: > http://highearthorbit.com/georss-multiple-locations/> > Sean Gillies has already countered with some good thoughts & > suggestions here: > http://zcologia.com/news/711/multiple-locations-in-georss/> > I also created a Proposals page on GeoRSS.org site with links to the > proposals: > http://georss.org/proposals> > I know these ideas have been discussed in the past, but then kind of > petered out. But I think there is immediate interest in nominally > agreeing to and implementing a solution in the very near term. In > fact, I would like to suggest that we have something ready for > Where2.0. > > Also understand that this proposal is for "Simple" - I know there are > GML people that will point to the semantics of the proposal and wag > their fingers. I suggest to them to draft a tasty Semantic/GML > parallel version. > > Thanks! > Andrew > _______________________________________________ > georss mailing list > georss@...> http://lists.eogeo.org/mailman/listinfo/georss_______________________________________________ georss mailing list georss@...http://lists.eogeo.org/mailman/listinfo/georss_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss
|
|
Re: GeoRSS Multiple Locations, References & Excerpts
Joshua Lieberman wrote:
> Andrew,
>
> Thanks for stirring this up. I've had a GeoRSS 2.0 proposal sitting on
> my desk for a long time but haven't gotten to it.
>
> This may come as a bit of a shock, but I have to agree with Sean about
> some of these things. Entries are already a pretty lightweight entity
> and links are already a pretty good way to, well, link to additional /
> voluminous resources for various purposes which may or may not be
> specialized in the view of a particular client or user.
Joshua, I'm very happy to agree with you here.
>
> About multiple geometries: every time we've drilled down into the use
> case for this, it has ended up being important to express their
> relationships. Geometry "bags" are hardly every really usefully
> expressive. One approach is to create relationships within a
> collection which give meaning to the order. That gets more and more
> specialized, though, as we saw a few months ago with various <dataset>
> proposals.
>
> The "story graph" is an interesting problem which GML btw does not yet
> solve, but a graph of Atom entries is at once more compatible with
> simple viewers and more robust in terms of expressiveness. Pointers
> such as the threading proposal use would be the way to go (not sure
> links couldn't do this as well), except that we don't seem to be there
> yet referencing and managing entries as first class Web objects. Yes,
> there is a unique identifier, but not necessarily a "home" URL.
>
For Atom, at least, this "home" URL is the member edit link from RFC
5023, right? For example:
http://zcologia.com/kw/demo/domaine-hortus/atom-entry> The CGDI pilot, in leveraging GeoAtom, suggested some useful link
> types to support this. I'll see if we can converge on a general
> proposal next week at the OGC TC and post it for comment.
>
> Josh
Looking forward to it,
Sean
>
>
>
> On Mar 19, 2008, at 12:13 PM, Andrew Turner wrote:
>
>> Sorry for not posting about this to the list earlier, but I wrote up
>> several proposal extensions to GeoRSS to handle: Multiple Locations
>> for a single 'Story', References to externally geometries, and
>> Excerpts.
>>
>> My blog post outlining the ideas, and why the current proposal is
>> framed as such is in this post:
>> http://highearthorbit.com/georss-multiple-locations/>>
>> Sean Gillies has already countered with some good thoughts &
>> suggestions here:
>> http://zcologia.com/news/711/multiple-locations-in-georss/>>
>> I also created a Proposals page on GeoRSS.org site with links to the
>> proposals:
>> http://georss.org/proposals>>
>> I know these ideas have been discussed in the past, but then kind of
>> petered out. But I think there is immediate interest in nominally
>> agreeing to and implementing a solution in the very near term. In
>> fact, I would like to suggest that we have something ready for
>> Where2.0.
>>
>> Also understand that this proposal is for "Simple" - I know there are
>> GML people that will point to the semantics of the proposal and wag
>> their fingers. I suggest to them to draft a tasty Semantic/GML
>> parallel version.
>>
>> Thanks!
>> Andrew
>
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss
|
|
GeoRSS Location References
+1 on the 2nd location references proposal that uses <georss:polygon>
as an example. The first one, that uses <where>, is pretty convoluted.
I'm a -0 on that one.
ref: http://georss.org/proposals/external_geometry---
Raj
On Mar 19, 2008, at 11:13 AM, Andrew Turner wrote:
> Sorry for not posting about this to the list earlier, but I wrote up
> several proposal extensions to GeoRSS to handle: Multiple Locations
> for a single 'Story', References to externally geometries, and
> Excerpts.
>
> My blog post outlining the ideas, and why the current proposal is
> framed as such is in this post:
> http://highearthorbit.com/georss-multiple-locations/>
> Sean Gillies has already countered with some good thoughts &
> suggestions here:
> http://zcologia.com/news/711/multiple-locations-in-georss/>
> I also created a Proposals page on GeoRSS.org site with links to the
> proposals:
> http://georss.org/proposals>
> I know these ideas have been discussed in the past, but then kind of
> petered out. But I think there is immediate interest in nominally
> agreeing to and implementing a solution in the very near term. In
> fact, I would like to suggest that we have something ready for
> Where2.0.
>
> Also understand that this proposal is for "Simple" - I know there are
> GML people that will point to the semantics of the proposal and wag
> their fingers. I suggest to them to draft a tasty Semantic/GML
> parallel version.
>
> Thanks!
> Andrew
> _______________________________________________
> georss mailing list
> georss@...
> http://lists.eogeo.org/mailman/listinfo/georss_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss
|
|
Re: GeoRSS Location References
I'm -1 on that one (origin:
http://lists.eogeo.org/pipermail/georss/2007-November/001752.html,
IIRC). -0 on the first, which is more of an interesting idea than
something we should start implementing now.
I think some standard link relations (ala
http://lists.eogeo.org/pipermail/georss/2007-November/001755.html) might
do the trick.
Sean
Raj Singh wrote:
> +1 on the 2nd location references proposal that uses <georss:polygon>
> as an example. The first one, that uses <where>, is pretty convoluted.
> I'm a -0 on that one.
>
> ref: http://georss.org/proposals/external_geometry>
> ---
> Raj
>
>
> On Mar 19, 2008, at 11:13 AM, Andrew Turner wrote:
>> Sorry for not posting about this to the list earlier, but I wrote up
>> several proposal extensions to GeoRSS to handle: Multiple Locations
>> for a single 'Story', References to externally geometries, and
>> Excerpts.
>>
>> My blog post outlining the ideas, and why the current proposal is
>> framed as such is in this post:
>> http://highearthorbit.com/georss-multiple-locations/>>
>> Sean Gillies has already countered with some good thoughts &
>> suggestions here:
>> http://zcologia.com/news/711/multiple-locations-in-georss/>>
>> I also created a Proposals page on GeoRSS.org site with links to the
>> proposals:
>> http://georss.org/proposals>>
>> I know these ideas have been discussed in the past, but then kind of
>> petered out. But I think there is immediate interest in nominally
>> agreeing to and implementing a solution in the very near term. In
>> fact, I would like to suggest that we have something ready for
>> Where2.0.
>>
>> Also understand that this proposal is for "Simple" - I know there are
>> GML people that will point to the semantics of the proposal and wag
>> their fingers. I suggest to them to draft a tasty Semantic/GML
>> parallel version.
>>
>> Thanks!
>> Andrew
>> _______________________________________________
>> georss mailing list
>> georss@...
>> http://lists.eogeo.org/mailman/listinfo/georss>
> _______________________________________________
> georss mailing list
> georss@...
> http://lists.eogeo.org/mailman/listinfo/georss>
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss
|
|
Re: GeoRSS Location References
More specifics here:
http://atlantides.org/trac/concordia/wiki/AtomLocationByReferenceSean Gillies wrote:
> I'm -1 on that one (origin:
> http://lists.eogeo.org/pipermail/georss/2007-November/001752.html,
> IIRC). -0 on the first, which is more of an interesting idea than
> something we should start implementing now.
>
> I think some standard link relations (ala
> http://lists.eogeo.org/pipermail/georss/2007-November/001755.html) might
> do the trick.
>
> Sean
>
> Raj Singh wrote:
>> +1 on the 2nd location references proposal that uses <georss:polygon>
>> as an example. The first one, that uses <where>, is pretty convoluted.
>> I'm a -0 on that one.
>>
>> ref: http://georss.org/proposals/external_geometry>>
>> ---
>> Raj
>>
>>
>> On Mar 19, 2008, at 11:13 AM, Andrew Turner wrote:
>>> Sorry for not posting about this to the list earlier, but I wrote up
>>> several proposal extensions to GeoRSS to handle: Multiple Locations
>>> for a single 'Story', References to externally geometries, and
>>> Excerpts.
>>>
>>> My blog post outlining the ideas, and why the current proposal is
>>> framed as such is in this post:
>>> http://highearthorbit.com/georss-multiple-locations/>>>
>>> Sean Gillies has already countered with some good thoughts &
>>> suggestions here:
>>> http://zcologia.com/news/711/multiple-locations-in-georss/>>>
>>> I also created a Proposals page on GeoRSS.org site with links to the
>>> proposals:
>>> http://georss.org/proposals>>>
>>> I know these ideas have been discussed in the past, but then kind of
>>> petered out. But I think there is immediate interest in nominally
>>> agreeing to and implementing a solution in the very near term. In
>>> fact, I would like to suggest that we have something ready for
>>> Where2.0.
>>>
>>> Also understand that this proposal is for "Simple" - I know there are
>>> GML people that will point to the semantics of the proposal and wag
>>> their fingers. I suggest to them to draft a tasty Semantic/GML
>>> parallel version.
>>>
>>> Thanks!
>>> Andrew
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss
|
|
Re: GeoRSS Location References
I'd love to get the location references issue decided soon. We've been
sitting on this stuff too long. So let me summarize what I think is
out there right now.
Andrew proposed a couple options -- http://georss.org/proposals/external_geometry
-- that preserved some of the GeoRSS language in the link (either
<where> or the geometry element).
Josh and Sean support a strategy that's a more generic, universal way
of handling external references (see quoted text below) by working
with <atom:link>.
This leaves me with 2 questions:
1) Sean, does your proposal only work with Atom? Do we care?
Personally, I'm for dropping support of all the other "legacy" RSS
formats.
2) Is there any important advantage for software to know a little
about what the referenced link will contain prior to dereferencing it?
If so, then Andrew's ideas where you still have a <where>, <point>,
<line> or <polygon> is useful.
If the answer to #2 is not really, which I think it is, then I'm a big
+1 on going with something like what's shown at http://atlantides.org/trac/concordia/wiki/AtomLocationByReference
.
---
Raj
On Mar 28, 2008, at 8:03 PM, Sean Gillies wrote:
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss
|
|
Re: GeoRSS Location References
On Sun, Mar 30, 2008 at 11:18:11PM -0400, Raj Singh wrote:
> I'd love to get the location references issue decided soon. We've been
> sitting on this stuff too long. So let me summarize what I think is
> out there right now.
>
> Andrew proposed a couple options -- http://georss.org/proposals/external_geometry
> -- that preserved some of the GeoRSS language in the link (either
> <where> or the geometry element).
>
> Josh and Sean support a strategy that's a more generic, universal way
> of handling external references (see quoted text below) by working
> with <atom:link>.
>
> This leaves me with 2 questions:
> 1) Sean, does your proposal only work with Atom?
Insofar as GeoRSS has meaning within RSS2, I think that <atom:link> oes
as well.
> 2) Is there any important advantage for software to know a little
> about what the referenced link will contain prior to dereferencing it?
> If so, then Andrew's ideas where you still have a <where>, <point>,
> <line> or <polygon> is useful.
You can describe this in <atom:link rel="type">, perhaps?
Regards,
--
Christopher Schmidt
Web Developer
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss
|
|
Re: GeoRSS Location References
On Mar 30, 2008, at 11:25 PM, Christopher Schmidt wrote:
>> 1) Sean, does your proposal only work with Atom?
>
> Insofar as GeoRSS has meaning within RSS2, I think that <atom:link>
> oes
> as well.
Thinking about it a bit more, I guess it works fine. It just feels
really strange using <atom:link> in RSS2 or RSS1.
>
>
>> 2) Is there any important advantage for software to know a little
>> about what the referenced link will contain prior to dereferencing
>> it?
>> If so, then Andrew's ideas where you still have a <where>, <point>,
>> <line> or <polygon> is useful.
>
> You can describe this in <atom:link rel="type">, perhaps?
That's loading a lot of semantics into rel -- not only the fact that
it's a location, but also the type of geometry. And we'll also need to
signal whether the link is to simple georss or GML. But if people
really feel they need to know geometry type before dereferencing, fine
with me.
---
Raj
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss
|
|
Re: GeoRSS Location References
On Sun, Mar 30, 2008 at 11:41:56PM -0400, Raj Singh wrote:
> On Mar 30, 2008, at 11:25 PM, Christopher Schmidt wrote:
> >> 1) Sean, does your proposal only work with Atom?
> >
> > Insofar as GeoRSS has meaning within RSS2, I think that <atom:link>
> > oes
> > as well.
>
> Thinking about it a bit more, I guess it works fine. It just feels
> really strange using <atom:link> in RSS2 or RSS1.
>
> >
> >
> >> 2) Is there any important advantage for software to know a little
> >> about what the referenced link will contain prior to dereferencing
> >> it?
> >> If so, then Andrew's ideas where you still have a <where>, <point>,
> >> <line> or <polygon> is useful.
> >
> > You can describe this in <atom:link rel="type">, perhaps?
Er, I said 'rel' while thinking 'type'. Though 'type' doesn't really do
that either, since 'type' is usually mime-type.
>
> That's loading a lot of semantics into rel -- not only the fact that
> it's a location, but also the type of geometry. And we'll also need to
> signal whether the link is to simple georss or GML. But if people
> really feel they need to know geometry type before dereferencing, fine
> with me.
I don't really think you need to know it before dereferencing, but
that's something that others may nee to comment on.
Regards,
--
Christopher Schmidt
Web Developer
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss
|
|
Re: GeoRSS Location References
On Mar 30, 2008, at 11:57 PM, Christopher Schmidt wrote:
>>>> 2) Is there any important advantage for software to know a little
>>>> about what the referenced link will contain prior to dereferencing
>>>> it?
>>>> If so, then Andrew's ideas where you still have a <where>, <point>,
>>>> <line> or <polygon> is useful.
>>>
>>> You can describe this in <atom:link rel="type">, perhaps?
>
> Er, I said 'rel' while thinking 'type'. Though 'type' doesn't really
> do
> that either, since 'type' is usually mime-type.
>
>>
>> That's loading a lot of semantics into rel -- not only the fact that
>> it's a location, but also the type of geometry. And we'll also need
>> to
>> signal whether the link is to simple georss or GML. But if people
>> really feel they need to know geometry type before dereferencing,
>> fine
>> with me.
>
> I don't really think you need to know it before dereferencing, but
> that's something that others may nee to comment on.
but using the 'type' attribute sounds like a better place to solve the
GML or Simple question. Instead of overloading rel, define different
MIME types for them.
---
Raj
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss
|
|
Re: GeoRSS Location References
The hinting problem may have more to do with "is this a 10,000 node
polygon" than "is this a point or a line", which isn't helped by
geometry typing. We could help with that more by defining relation
URI's such as " http://www.georss.org/rel/alt/hires"
-Josh
On Mar 31, 2008, at 12:10 AM, Raj Singh wrote:
> On Mar 30, 2008, at 11:57 PM, Christopher Schmidt wrote:
>>>>> 2) Is there any important advantage for software to know a little
>>>>> about what the referenced link will contain prior to dereferencing
>>>>> it?
>>>>> If so, then Andrew's ideas where you still have a <where>,
>>>>> <point>,
>>>>> <line> or <polygon> is useful.
>>>>
>>>> You can describe this in <atom:link rel="type">, perhaps?
>>
>> Er, I said 'rel' while thinking 'type'. Though 'type' doesn't really
>> do
>> that either, since 'type' is usually mime-type.
>>
>>>
>>> That's loading a lot of semantics into rel -- not only the fact that
>>> it's a location, but also the type of geometry. And we'll also need
>>> to
>>> signal whether the link is to simple georss or GML. But if people
>>> really feel they need to know geometry type before dereferencing,
>>> fine
>>> with me.
>>
>> I don't really think you need to know it before dereferencing, but
>> that's something that others may nee to comment on.
>
> but using the 'type' attribute sounds like a better place to solve the
> GML or Simple question. Instead of overloading rel, define different
> MIME types for them.
>
> ---
> Raj
> _______________________________________________
> georss mailing list
> georss@...
> http://lists.eogeo.org/mailman/listinfo/georss_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss
|
|
Re: GeoRSS Location References
Come to think of it, there is an optional length attribute (text)
which can also help with this issue.
On Mar 31, 2008, at 12:19 AM, Joshua Lieberman wrote:
> The hinting problem may have more to do with "is this a 10,000 node
> polygon" than "is this a point or a line", which isn't helped by
> geometry typing. We could help with that more by defining relation
> URI's such as " http://www.georss.org/rel/alt/hires"
>
|
