Can GeoRSS and KML converge on a geometry encoding?

[Sean Gillies]

Andrew, you reported in your blog last fall that KML may switch over to
GML 3 geometries. If that were true, wouldn't it make sense for the next
iteration of GeoRSS to recommend the same practice? Seems to me this
could simplify the situation for feed and KML processors.

Sean
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[Ron Lake]

Hi,

Yes this is under discussion at the OGC.

Ron

-----Original Message-----
From: georss-bounces@...
[mailto:georss-bounces@...] On Behalf Of Sean Gillies
Sent: April 10, 2008 5:14 PM
To: GeoRss
Subject: (SCL: 4) [georss] Can GeoRSS and KML converge on a geometry
encoding?

Andrew, you reported in your blog last fall that KML may switch over to
GML 3 geometries. If that were true, wouldn't it make sense for the next
iteration of GeoRSS to recommend the same practice? Seems to me this
could simplify the situation for feed and KML processors.

Sean
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss
_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[joshli]

GeoRSS GML already uses GML 3 geometries, just not all possibilities.  
KML, if/when it supports GML 3, is unlikely as well to support all  
possible GML 3 geometries. There are specific options in KML for 3D  
handling, though, which are not in GML at all. I was just suggesting  
earlier that providing a place for them to be expressed in GeoRSS  
might make it more straightforward for GE to handle feeds and KML  
together.

Sean, are you and Charlie going to make some sort of a conference  
line / IRC channel available tomorrow, or should we try to do  
something more inclusive at another time (e.g. next week).

-Josh

On Apr 10, 2008, at 10:14 AM, Sean Gillies wrote:

> Andrew, you reported in your blog last fall that KML may switch over  
> to
> GML 3 geometries. If that were true, wouldn't it make sense for the  
> next
> iteration of GeoRSS to recommend the same practice? Seems to me this
> could simplify the situation for feed and KML processors.
>
> Sean
> _______________________________________________
> georss mailing list
> georss@...
> http://lists.eogeo.org/mailman/listinfo/georss

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[Sean Gillies]

I'm not thinking about arcs and hemispherical patches, or 3D
visualization, but about dimensionality of positions. 3D position lists
are not allowed in GeoRSS GML, are allowed in KML 2.2, and I imagine
that they will be an option in KML 3. Some of you have the inside track
on KML, right? I'm just suggesting we could steer GeoRSS to where KML is
headed.

#geo-web-rest on freenode

http://groups.google.com/group/geo-web-rest/web/atom-geo-interop-the-2nd

Sean

Joshua Lieberman wrote:

> GeoRSS GML already uses GML 3 geometries, just not all possibilities.  
> KML, if/when it supports GML 3, is unlikely as well to support all  
> possible GML 3 geometries. There are specific options in KML for 3D  
> handling, though, which are not in GML at all. I was just suggesting  
> earlier that providing a place for them to be expressed in GeoRSS  
> might make it more straightforward for GE to handle feeds and KML  
> together.
>
> Sean, are you and Charlie going to make some sort of a conference  
> line / IRC channel available tomorrow, or should we try to do  
> something more inclusive at another time (e.g. next week).
>
> -Josh
>
> On Apr 10, 2008, at 10:14 AM, Sean Gillies wrote:
>
>> Andrew, you reported in your blog last fall that KML may switch over  
>> to
>> GML 3 geometries. If that were true, wouldn't it make sense for the  
>> next
>> iteration of GeoRSS to recommend the same practice? Seems to me this
>> could simplify the situation for feed and KML processors.
>>
>> Sean
>> _______________________________________________
>> 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

[Sean Gillies]

Oh yes, I know it is. I'm asking in perhaps a too roundabout way where
the discussion is going.

What are we converging to and when?

Sean

Ron Lake wrote:

> Hi,
>
> Yes this is under discussion at the OGC.
>
> Ron
>
> -----Original Message-----
> From: georss-bounces@...
> [mailto:georss-bounces@...] On Behalf Of Sean Gillies
> Sent: April 10, 2008 5:14 PM
> To: GeoRss
> Subject: (SCL: 4) [georss] Can GeoRSS and KML converge on a geometry
> encoding?
>
> Andrew, you reported in your blog last fall that KML may switch over to
> GML 3 geometries. If that were true, wouldn't it make sense for the next
> iteration of GeoRSS to recommend the same practice? Seems to me this
> could simplify the situation for feed and KML processors.
>
> Sean
> _______________________________________________
> georss mailing list
> georss@...
> http://lists.eogeo.org/mailman/listinfo/georss
>

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[joshli]

Sean,

3D position lists are entirely allowed in GeoRSS GML. It simply  
requires specifying a 3D CRS, just as in GML and eventually in KML.  
This is an additional option from GeoRSS Simple, which doesn't provide  
a place for additional CRS's.

The 3D equivalent to epsg:4326 I believe is epsg:4979:


<georss:where>
<gml:Point>
<gml:pos srsName="epsg:4979" srsDimension="3">42.3453 -156.2342 45</
gml:pos>
</gml:Point>
</georss:where>

--Josh

On Apr 10, 2008, at 11:03 AM, Sean Gillies wrote:

> I'm not thinking about arcs and hemispherical patches, or 3D
> visualization, but about dimensionality of positions. 3D position  
> lists
> are not allowed in GeoRSS GML, are allowed in KML 2.2, and I imagine
> that they will be an option in KML 3. Some of you have the inside  
> track
> on KML, right? I'm just suggesting we could steer GeoRSS to where  
> KML is
> headed.
>
> #geo-web-rest on freenode
>
> http://groups.google.com/group/geo-web-rest/web/atom-geo-interop-the-2nd
>
> Sean
>
> Joshua Lieberman wrote:
>> GeoRSS GML already uses GML 3 geometries, just not all possibilities.
>> KML, if/when it supports GML 3, is unlikely as well to support all
>> possible GML 3 geometries. There are specific options in KML for 3D
>> handling, though, which are not in GML at all. I was just suggesting
>> earlier that providing a place for them to be expressed in GeoRSS
>> might make it more straightforward for GE to handle feeds and KML
>> together.
>>
>> Sean, are you and Charlie going to make some sort of a conference
>> line / IRC channel available tomorrow, or should we try to do
>> something more inclusive at another time (e.g. next week).
>>
>> -Josh
>>
>> On Apr 10, 2008, at 10:14 AM, Sean Gillies wrote:
>>
>>> Andrew, you reported in your blog last fall that KML may switch over
>>> to
>>> GML 3 geometries. If that were true, wouldn't it make sense for the
>>> next
>>> iteration of GeoRSS to recommend the same practice? Seems to me this
>>> could simplify the situation for feed and KML processors.
>>>
>>> Sean
>>> _______________________________________________
>>> 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

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[David Burggraf]

Josh, what do you mean by 'eventually in KML'. The CRS specified in KML has always been a lon/lat/alt Geographic CRS, but just recently formally specified in OGC V2.2--it is analogous to the 2D Geographic CRS OGC:CRS84, but 3D. The alt values, when not specified default to 0.

David.

-----Original Message-----
From: georss-bounces@... on behalf of Joshua Lieberman
Sent: Thu 10/04/2008 08:53
To: GeoRss georss@...
Subject: Re: [georss] Can GeoRSS and KML converge on a geometry encoding?

Sean,

3D position lists are entirely allowed in GeoRSS GML. It simply 
requires specifying a 3D CRS, just as in GML and eventually in KML. 
This is an additional option from GeoRSS Simple, which doesn't provide 
a place for additional CRS's.

The 3D equivalent to epsg:4326 I believe is epsg:4979:


<georss:where>
<gml:Point>
<gml:pos srsName="epsg:4979" srsDimension="3">42.3453 -156.2342 45</
gml:pos>
</gml:Point>
</georss:where>

--Josh

On Apr 10, 2008, at 11:03 AM, Sean Gillies wrote:

> I'm not thinking about arcs and hemispherical patches, or 3D
> visualization, but about dimensionality of positions. 3D position 
> lists
> are not allowed in GeoRSS GML, are allowed in KML 2.2, and I imagine
> that they will be an option in KML 3. Some of you have the inside 
> track
> on KML, right? I'm just suggesting we could steer GeoRSS to where 
> KML is
> headed.
>
> #geo-web-rest on freenode
>
> http://groups.google.com/group/geo-web-rest/web/atom-geo-interop-the-2nd
>
> Sean
>
> Joshua Lieberman wrote:
>> GeoRSS GML already uses GML 3 geometries, just not all possibilities.
>> KML, if/when it supports GML 3, is unlikely as well to support all
>> possible GML 3 geometries. There are specific options in KML for 3D
>> handling, though, which are not in GML at all. I was just suggesting
>> earlier that providing a place for them to be expressed in GeoRSS
>> might make it more straightforward for GE to handle feeds and KML
>> together.
>>
>> Sean, are you and Charlie going to make some sort of a conference
>> line / IRC channel available tomorrow, or should we try to do
>> something more inclusive at another time (e.g. next week).
>>
>> -Josh
>>
>> On Apr 10, 2008, at 10:14 AM, Sean Gillies wrote:
>>
>>> Andrew, you reported in your blog last fall that KML may switch over
>>> to
>>> GML 3 geometries. If that were true, wouldn't it make sense for the
>>> next
>>> iteration of GeoRSS to recommend the same practice? Seems to me this
>>> could simplify the situation for feed and KML processors.
>>>
>>> Sean
>>> _______________________________________________
>>> 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

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[David Burggraf]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi Josh, having read your message more carefully, I see that you are talking about the ability to specify other CRSs in KML.

 

There are a couple of important points to be aware of here:

 

1.       In KML it is possible to alter the CRS and people do it all the time without really knowing it. The geometry interpolation between positions is altered implicitly depending on certain KML parameters (altitudeMode, tessellate, and extrude). For example, if a polygon has altitudeMode set to clampToGround with tessellate=false, the line segments on the boundary of a polygon are in a Geocentric (WGS84) CRS, i.e. the polygon could cut through the earth’s surface. If instead tessellate is false, the boundary line segments are in a Geographic CRS, i.e. the polygon follows the earth’s curvature.

2.       KML and GML geometry harmonization was discussed in the OWS-5 Agile Geography thread and it was discovered that such a harmonization is much more complex than it seemed at the outset. The differences between KML and GML geometry are the attributes in KML mentioned above: altitudeMode, tessellate, and extrude. These attributes alter the representation of the geometry in ways that cannot matched with a simple alteration of an srsName value in GML. The conclusion was that no harmonization between KML and GML proposal would be made.

David.

 

 

 

From: georss-bounces@... [mailto:georss-bounces@...] On Behalf Of David Burggraf
Sent: April-10-08 9:33 AM
To: Joshua Lieberman; georss@...
Subject: Re: [georss] Can GeoRSS and KML converge on a geometry encoding?

 

 

Josh, what do you mean by 'eventually in KML'. The CRS specified in KML has always been a lon/lat/alt Geographic CRS, but just recently formally specified in OGC V2.2--it is analogous to the 2D Geographic CRS OGC:CRS84, but 3D. The alt values, when not specified default to 0.

David.

-----Original Message-----
From: georss-bounces@... on behalf of Joshua Lieberman
Sent: Thu 10/04/2008 08:53
To: GeoRss georss@...
Subject: Re: [georss] Can GeoRSS and KML converge on a geometry encoding?

Sean,

3D position lists are entirely allowed in GeoRSS GML. It simply 
requires specifying a 3D CRS, just as in GML and eventually in KML. 
This is an additional option from GeoRSS Simple, which doesn't provide 
a place for additional CRS's.

The 3D equivalent to epsg:4326 I believe is epsg:4979:


<georss:where>
<gml:Point>
<gml:pos srsName="epsg:4979" srsDimension="3">42.3453 -156.2342 45</
gml:pos>
</gml:Point>
</georss:where>

--Josh

On Apr 10, 2008, at 11:03 AM, Sean Gillies wrote:

> I'm not thinking about arcs and hemispherical patches, or 3D
> visualization, but about dimensionality of positions. 3D position 
> lists
> are not allowed in GeoRSS GML, are allowed in KML 2.2, and I imagine
> that they will be an option in KML 3. Some of you have the inside 
> track
> on KML, right? I'm just suggesting we could steer GeoRSS to where 
> KML is
> headed.
>
> #geo-web-rest on freenode
>
> http://groups.google.com/group/geo-web-rest/web/atom-geo-interop-the-2nd
>
> Sean
>
> Joshua Lieberman wrote:
>> GeoRSS GML already uses GML 3 geometries, just not all possibilities.
>> KML, if/when it supports GML 3, is unlikely as well to support all
>> possible GML 3 geometries. There are specific options in KML for 3D
>> handling, though, which are not in GML at all. I was just suggesting
>> earlier that providing a place for them to be expressed in GeoRSS
>> might make it more straightforward for GE to handle feeds and KML
>> together.
>>
>> Sean, are you and Charlie going to make some sort of a conference
>> line / IRC channel available tomorrow, or should we try to do
>> something more inclusive at another time (e.g. next week).
>>
>> -Josh
>>
>> On Apr 10, 2008, at 10:14 AM, Sean Gillies wrote:
>>
>>> Andrew, you reported in your blog last fall that KML may switch over
>>> to
>>> GML 3 geometries. If that were true, wouldn't it make sense for the
>>> next
>>> iteration of GeoRSS to recommend the same practice? Seems to me this
>>> could simplify the situation for feed and KML processors.
>>>
>>> Sean
>>> _______________________________________________
>>> 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

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[Raj Singh-2]

I added this example to http://georss.org/gml under "Coordinate  
Reference System Usage".
---
Raj


On Apr 10, 2008, at 11:53 AM, Joshua Lieberman wrote:

> Sean,
>
> 3D position lists are entirely allowed in GeoRSS GML. It simply
> requires specifying a 3D CRS, just as in GML and eventually in KML.
> This is an additional option from GeoRSS Simple, which doesn't provide
> a place for additional CRS's.
>
> The 3D equivalent to epsg:4326 I believe is epsg:4979:
>
>
> <georss:where>
> <gml:Point>
> <gml:pos srsName="epsg:4979" srsDimension="3">42.3453 -156.2342 45</
> gml:pos>
> </gml:Point>
> </georss:where>
>
> --Josh

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[Sean Gillies]

Ok.

So, georss:where has an implicit srsName and srsDimension (2), yes?
Because as I understand it the GML spec recommends against so
attributing points and positions or position lists. Wouldn't that
element be a better place to explicitly define srsName and srsDimension?

I think I'm starting to come around on georss:elev. Without it, a
producer has to either understand srsName and srsDimension, or needs
something like georss:where3d (with an implicit srsDimension=3).

Thanks for the discussion. Like I said, I missed it the first time
around, and the list archive wasn't very helpful.

Sean

Joshua Lieberman wrote:

> Sean,
>
> 3D position lists are entirely allowed in GeoRSS GML. It simply  
> requires specifying a 3D CRS, just as in GML and eventually in KML.  
> This is an additional option from GeoRSS Simple, which doesn't provide  
> a place for additional CRS's.
>
> The 3D equivalent to epsg:4326 I believe is epsg:4979:
>
>
> <georss:where>
> <gml:Point>
> <gml:pos srsName="epsg:4979" srsDimension="3">42.3453 -156.2342 45</
> gml:pos>
> </gml:Point>
> </georss:where>
>
> --Josh
>
> On Apr 10, 2008, at 11:03 AM, Sean Gillies wrote:
>
>> I'm not thinking about arcs and hemispherical patches, or 3D
>> visualization, but about dimensionality of positions. 3D position  
>> lists
>> are not allowed in GeoRSS GML, are allowed in KML 2.2, and I imagine
>> that they will be an option in KML 3. Some of you have the inside  
>> track
>> on KML, right? I'm just suggesting we could steer GeoRSS to where  
>> KML is
>> headed.
>>
>> #geo-web-rest on freenode
>>
>> http://groups.google.com/group/geo-web-rest/web/atom-geo-interop-the-2nd
>>
>> Sean
>>
>> Joshua Lieberman wrote:
>>> GeoRSS GML already uses GML 3 geometries, just not all possibilities.
>>> KML, if/when it supports GML 3, is unlikely as well to support all
>>> possible GML 3 geometries. There are specific options in KML for 3D
>>> handling, though, which are not in GML at all. I was just suggesting
>>> earlier that providing a place for them to be expressed in GeoRSS
>>> might make it more straightforward for GE to handle feeds and KML
>>> together.
>>>
>>> Sean, are you and Charlie going to make some sort of a conference
>>> line / IRC channel available tomorrow, or should we try to do
>>> something more inclusive at another time (e.g. next week).
>>>
>>> -Josh
>>>
>>> On Apr 10, 2008, at 10:14 AM, Sean Gillies wrote:
>>>
>>>> Andrew, you reported in your blog last fall that KML may switch over
>>>> to
>>>> GML 3 geometries. If that were true, wouldn't it make sense for the
>>>> next
>>>> iteration of GeoRSS to recommend the same practice? Seems to me this
>>>> could simplify the situation for feed and KML processors.
>>>>
>>>> Sean

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss

[Raj Singh-2]

Yeah I think you've got it, and I agree (Josh was probably just typing  
fast) the example should move the attributes to the geometry object  
like this:
<georss:where>
   <gml:Point srsName="epsg:4979" srsDimension="3">
     <gml:pos>42.3453 -156.2342 45</gml:pos>
   </gml:Point>
</georss:where>
---
Raj


On Apr 10, 2008, at 3:13 PM, Sean Gillies wrote:

> Ok.
>
> So, georss:where has an implicit srsName and srsDimension (2), yes?
> Because as I understand it the GML spec recommends against so
> attributing points and positions or position lists. Wouldn't that
> element be a better place to explicitly define srsName and  
> srsDimension?
>
> I think I'm starting to come around on georss:elev. Without it, a
> producer has to either understand srsName and srsDimension, or needs
> something like georss:where3d (with an implicit srsDimension=3).
>
> Thanks for the discussion. Like I said, I missed it the first time
> around, and the list archive wasn't very helpful.
>
> Sean
>
> Joshua Lieberman wrote:
>> Sean,
>>
>> 3D position lists are entirely allowed in GeoRSS GML. It simply
>> requires specifying a 3D CRS, just as in GML and eventually in KML.
>> This is an additional option from GeoRSS Simple, which doesn't  
>> provide
>> a place for additional CRS's.
>>
>> The 3D equivalent to epsg:4326 I believe is epsg:4979:
>>
>>
>> <georss:where>
>> <gml:Point>
>> <gml:pos srsName="epsg:4979" srsDimension="3">42.3453 -156.2342 45</
>> gml:pos>
>> </gml:Point>
>> </georss:where>
>>
>> --Josh
>>
>> On Apr 10, 2008, at 11:03 AM, Sean Gillies wrote:
>>
>>> I'm not thinking about arcs and hemispherical patches, or 3D
>>> visualization, but about dimensionality of positions. 3D position
>>> lists
>>> are not allowed in GeoRSS GML, are allowed in KML 2.2, and I imagine
>>> that they will be an option in KML 3. Some of you have the inside
>>> track
>>> on KML, right? I'm just suggesting we could steer GeoRSS to where
>>> KML is
>>> headed.
>>>
>>> #geo-web-rest on freenode
>>>
>>> http://groups.google.com/group/geo-web-rest/web/atom-geo-interop-the-2nd
>>>
>>> Sean
>>>
>>> Joshua Lieberman wrote:
>>>> GeoRSS GML already uses GML 3 geometries, just not all  
>>>> possibilities.
>>>> KML, if/when it supports GML 3, is unlikely as well to support all
>>>> possible GML 3 geometries. There are specific options in KML for 3D
>>>> handling, though, which are not in GML at all. I was just  
>>>> suggesting
>>>> earlier that providing a place for them to be expressed in GeoRSS
>>>> might make it more straightforward for GE to handle feeds and KML
>>>> together.
>>>>
>>>> Sean, are you and Charlie going to make some sort of a conference
>>>> line / IRC channel available tomorrow, or should we try to do
>>>> something more inclusive at another time (e.g. next week).
>>>>
>>>> -Josh
>>>>
>>>> On Apr 10, 2008, at 10:14 AM, Sean Gillies wrote:
>>>>
>>>>> Andrew, you reported in your blog last fall that KML may switch  
>>>>> over
>>>>> to
>>>>> GML 3 geometries. If that were true, wouldn't it make sense for  
>>>>> the
>>>>> next
>>>>> iteration of GeoRSS to recommend the same practice? Seems to me  
>>>>> this
>>>>> could simplify the situation for feed and KML processors.
>>>>>
>>>>> Sean
> _______________________________________________
> georss mailing list
> georss@...
> http://lists.eogeo.org/mailman/listinfo/georss

_______________________________________________
georss mailing list
georss@...
http://lists.eogeo.org/mailman/listinfo/georss