KML anyone

[cholmes (sent by Nabble.com)]

Hal Eden wrote:
> 
> 
> On Feb 18, 2006, at 11:03 PM, MAPSERVER-DEV automatic digest system  
> wrote:
> 
>> From: "cholmes (sent by Nabble.com)" <lists at NABBLE.COM>
>> Date: February 18, 2006 12:07:17 PM MST
>> Subject: Re: KML anyone
>>
>>
>>> We've actually made some good progress in KML support in GeoServer,  
>>> but one
>>> thing that we found is that KML output is actually better geared  
>>> for WMS
>>> instead of WFS.  Why?  Because KML is really a display format. If  
>>> you just
>>> use WFS, then your kml will look quite boring, since it's just the  
>>> data.
> 
>>okay, you've lost me.  i guess i don't know the distinction you are  
>>trying to make. i am generating style info along with my KML, but  
>>guess i don't know enough about WFS to know whether this is  
>>appropriate (it sounds like not, if i interpret your statement  
>>correctly).
> Yes, I'm basically saying the WFS isn't entirely appropriate, as by
> definition it is about returning data.  So it doesn't have the ability to
> do anything interesting with styles.  So a WFS will only return data that
> looks one way.  KML blurs the line, since it's 'elements', which in normal
> WFS/GML would be the attribute data, are actually about the display.  In
> GIS you don't really store style information alongside your real data.  
> 
> Using the WMS is more approrpriate, since it applies styles to your
> attribute data.  It works nicer with google earth, since you can have it
> request different styles, like a WMS normally does.  So basically my point
> is that putting style information in WFS is just not what a WFS was
> designed for - you'd only be able to request it one way, instead of having
> options, or even leaving it up to the client (as a full functioning
> WMS-SLD lets you do)
> 
> 
>>i guess i took the approach as path of least resistance, given that i  
>>was using mapgml.c as my starting point, and it seemed simpler to  
>>produce it from a WFS request than to patch it in elsewhere (that  
>>doesn't make the choice correct!)
> Makes sense.  But with a WMS you can also request different styles, that
> you just can't do in WFS.
> 
>>is KML only a display format or is it only a display format if all  
>>you use it for is display? (i use it other programs and manipulate it  
>>as data, although admittedly, it does end up being pushed back to GE  
>>for display).
> 
>>is WFS restricted to contain no style information, or is it that GML  
>>provides no style information?
> WFS is restricted per se to contain no style information.  But it's like
> putting style information at the data level, which just generally isn't
> the practice in GIS, afaik. But GML is super flexible, so you're welcome
> to  put style information in it.  KML is _more_ of a display format, since
> its elements have known 'styling' meangings, but of course it does
> actually contain coordinates of geometries, so you can use it as a data
> format.  But as a data format I think it doesn't provide the normal wealth
> of attribute information that WFS/GML does.  That said, KML will soon
> become a profile of GML, but it's sort of a hacky thing to do.  
> 
> Ultimately what I think makes the most sense is to have KML as both a WMS
> and WFS output.  SVG falls in about the same lines.  When you go through
> WFS you should get the default style, which is generally pretty boring. 
> But you get all the attribute information.  When you go through WMS you
> should get all the complex styling stuff, and indeed have the ability to
> request different styles.  
> 
> I personally wouldn't put the default style information in the KML/SVG WFS
> output, I'd keep it clean and boring, so as to allow others to do a
> transform to style as they like.  But I'm a bit of a purists about how the
> services should be used, I also find the WMS GetFeatureInfo to be hacky,
> as I think one should just use WFS.  So take my advice with a grain of
> salt
> 
>>i'd appreciate further insights (as i said, i'm not that  
>>knowledgeable about WFS issues).
> Cool, I hope this is helpful.
>>
>>> Instead it should follow the same rendering rules as the WMS style,  
>>> using
>>> either the mapserver rendering language or SLD (as GeoServer  
>>> does).  With
>>> this you can request a style, and have it appear the same as a jpeg  
>>> or as
>>> KML in your google earth.
> 
>>
>>> We do lack the z-coordinate stuff though, we basically just put in  
>>> a dummy 0
>>> coordinate for the required z, but it ends up looking fine, you  
>>> just can't
>>> do the crazy 3d stuff.
> 
>>i'm already using WMS layers to overlay onto GE. what i was trying to  
>>do was get at providing the z-coordinate info, when available.
> Yeah, this also speaks to going through the WMS, since you're already
> using the WMS in conjunction with GE.  You just want the WMS to return
> information that's more approrpriate to the application you're using, so
> want KML from it.
> 
> best regards,
> 
> Chris
> 
> 
>>
>> Chris
> 
> 
> 
--
View this message in context: http://www.nabble.com/KML-anyone-t1142762.html#a3054241
Sent from the Mapserver - Dev forum at Nabble.com.