[georss] elevation question

[Sean Gillies]

Joshua Lieberman wrote:
> Sean,
> 
> I think the situation is pretty similar. Most features are coded into  
> KML as 2D, with an option to plot at a certain level or just "stick"  
> to the ground. There is an increasing but still limited use of   
> features with 3D tuples, mostly in the form of models for buildings  
> and other infrastructure. There are some 3D tracks being published in  
> KML, but things like storm tracks I think are often published at some  
> single plausible level above the terrain and may also use the  
> "relativetoGround" option.
> 

I was away from the discussion when georss:elev was added, so I'm trying
to figure out the why of it.

KML being a fork of GML 1 (according to Ron Lake) with cs=',' and ts='
', a processor can derive the dimensionality of any given set of
coordinates. This allows producers to write 2D or 3D as they may.

With GML 3, a processor can derive dimensionality of a posList only if
the srsName and srsDimension are known. I guess that you (the elev
authors) decided to hide the srs details from producers and make
srsDimension=2 implicit? That prevents producers from making 3D position
lists, and requires an optional georss:elev. Is that more or less the story?

> Come to think of it, we might want to have a georss option which lets  
> whatever elevatiion data is provided be better interpreted by GE and  
> other 3D programs (e.g. absolute, relative, or clamped / zero  
> relative). In principle the CRS could take care of this as well, but  
> I'm not sure there is any easy way of specifying the vertical datum to  
> be whatever terrain model is being used.
> 
> --Josh

I'd just use an alternative KML representation for this.

Sean

> 
> 
> 
> On Apr 8, 2008, at 10:03 AM, Sean Gillies wrote:
> 
>> Why does GeoRSS recommend using 'georss:elev' over 3D tuples? 3D is
>> working out pretty well for KML.
>>
>> Joshua Lieberman wrote:
>>> No, that is not the case.
>>>
>>> If you have a single elevation generally associated with the item,  
>>> you
>>> can put that in the georss:elev or georss:floor property. As a
>>> property, it doesn't belong inside georss:where alongside an object
>>> such as gml:Point. Only one georss:where is supported per entry and
>>> one geometry (for now) per georss:where element, so there is no
>>> ambiguity.
>>>
>>> If you have a need for a more complicated representation, as you
>>> describe, then you are free to reference or specify a 3D / 4D / 5D
>>> coordinate reference system (CRS) and supply multidimensional tuples
>>> for every node, in accordance with ISO and OGC specifications for GML
>>> geometries as supported in the gmlgeorss profile. Then you can  
>>> specify
>>> elevations for separate nodes on a linestring as you describe.
>>>
>>> Cheers,
>>>
>>> Josh
>>>
>>> On Apr 8, 2008, at 1:05 AM, Makc wrote:
>>>
>>>> so, what you're saying is that elevation can no longerbe associated
>>>> neither with individual shapes (since it does not go inside
>>>> <georss:where>), not to mention individual vertices, and instead is
>>>> only available for whatever the parent item is in the XML, i.e.  
>>>> only 1
>>>> elevation per item?
>>>>
>>>> so, for example, a line with two vertices one at 1m and other at 10m
>>>> elevation is not representable in georss/gml format?
>>>>
>>>> On Tue, Apr 8, 2008 at 3:51 AM, Joshua Lieberman <josh at oklieb.net>
>>>> wrote:
>>>>> The schema updated for w3c geo 2007 makes georss:elev an  
>>>>> independent
>>>>> attribute at the same level as georss:where, e.g.
>>>>>
>>>>>> <georss:where>
>>>>>> <gml:point>
>>>>>>  <gml:pos>blah blah</gml:pos>
>>>>>> </gml:point>
>>>>>> </georss:where>
>>>>>>
>>>>>> <georss:elev>313</georss:elev>
>>>>>>
>>>>> Same in Georss Simple:
>>>>>
>>>>> <georss:point>42.213 -133.123</georss:point>
>>>>>
>>>>> <georss:elev>313</georss:elev>
>>>>>
>>>>> The schema for both of these is described at
>>>>> http://www.georss.org/xml/1.1/overview . The site needs some more
>>>>> updates,
>>>>> etc.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Josh
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Apr 7, 2008, at 8:33 PM, Raj Singh wrote:
>>>>>
>>>>>>
>>>>>> On Apr 7, 2008, at 4:34 PM, Makc wrote:
>>>>>>
>>>>>>> I have also found xsd file at
>>>>>>> http://www.georss.org/xml/1.0/georss.xsd, where elevation lands
>>>>>>> under
>>>>>>> whereAttrGroup. I am not too good with these xsd things, but my
>>>>>>> interpretation is that, whenever someone wants to use  
>>>>>>> elevation, it
>>>>>>> has to go inside <georss:where> together with <gml:something>,  
>>>>>>> like
>>>>>>>
>>>>>>> <georss:where>
>>>>>>> <gml:point>blah blah</gml:point>
>>>>>>> <georss:elev>313</georss:elev>
>>>>>>> </georss:where>
>>>>>>>
>>>>>>> and not, for example, like
>>>>>>>
>>>>>>> <georss:where>
>>>>>>> <georss:point>blah blah</georss:point>
>>>>>>> <georss:elev>313</georss:elev>
>>>>>>> </georss:where>
>>>>>>>
>>>>>>> which does not really make sense to me, but it's like what it  
>>>>>>> looks
>>>>>>> like ...
>>>>>>>
>>>>>> The XSD you reference only applies to GeoRSS GML
>>>>> (http://www.georss.org/gml
>>>>>> ).
>>>>>> There's no schema for GeoRSS Simple. In GeoRSS GML you would  
>>>>>> write:
>>>>>> <georss:where>
>>>>>> <gml:point>
>>>>>>  <gml:pos>blah blah</gml:pos>
>>>>>> </gml:point>
>>>>>> <georss:elev>313</georss:elev>
>>>>>> </georss:where>
>>>>>>
>>>>>> I can't help with figuring out which one is right for Simple...
>>>>>>
>>>>>> ---
>>>>>> Raj
>>>>>> _______________________________________________
>>>>>> 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
>