[georss] Can GeoRSS and KML converge on a geometry encoding?

Thu Apr 10 14:49:35 EDT 2008

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 at lists.eogeo.org
[mailto:georss-bounces at lists.eogeo.org] On Behalf Of David Burggraf
Sent: April-10-08 9:33 AM
To: Joshua Lieberman; georss at lists.eogeo.org
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 at lists.eogeo.org on behalf of Joshua Lieberman
Sent: Thu 10/04/2008 08:53
To: GeoRss georss at lists.eogeo.org
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 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
>>
>
> _______________________________________________
> 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

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