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

[Raj Singh]

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 at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss