<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Guido,<br><br>Thanks for you thoughts.<br><br>However, this proposal is not about styling.<br><br>It is specifically about geometry and its rendering in KML. The elements proposed for addition specify how to interpret XML components WITHIN the geometry elements.<br><br>If you have, for example, a polygon geometry with Z values as elevation in PostGIS you'd like to send to KML, the <altitudeMode> tag must be present and set to absolute or relativeToGround to enable this Z value.<br><br>This is quite different from the <Styles> tag which is separate from the geometry in the KML schema.<br><br>You are right that this addition is not essential. As I found that I needed these tags within my geometry elements I figured out how to use Python and the Genshi Templating engine with XPATH to insert them. I posted a whole page with background and an example of how I did this on the PostGIS wiki (<a href="http://postgis.refractions.net/support/wiki/index.php?PostgisAndPython">http://postgis.refractions.net/support/wiki/index.php?PostgisAndPython</a>).<br><br>However, my response after figuring out XPATH and Genshi, is that it would ideal to just bypass that extra hack and send valid 3D geometry directly from the AsKML() function. You don't loose anything by adding these options. But with their addition you gain the major ease of being able to create valid 3D KML by wrapping the PostGIS geometry like this:<br><br><KML header> <KML Styles> <ST_AsKML() 3D geometry from PostGIS><KML Footer><br><br>Cheers,<br><br>Dane<div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><br><div><div>On Feb 20, 2008, at 11:20 PM, <a href="mailto:guido.lemoine@jrc.it">guido.lemoine@jrc.it</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">In effect, this issue is about styling of KML, and not so<br>much about the real data itself. I wonder whether postgis<br>should be concerned with that too much.<br><br>askml() produces only partial KML fragments anyway, so you<br>always have to make an effort, external to postgis, to<br>produce valid KML for display in GE (e.g. using XSLT).<br>This may as well include styling.<br><br>I'm not suggesting this is not a good idea, but IMHO, it's<br>not essential.<br><br>GL<br><br><br><blockquote type="cite">-- Original Message --<br></blockquote><blockquote type="cite">From: Dane Springmeyer <<a href="mailto:blake@hailmail.net">blake@hailmail.net</a>><br></blockquote><blockquote type="cite">To: PostGIS Users Discussion <<a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a>><br></blockquote><blockquote type="cite">Date: Tue, 19 Feb 2008 09:45:14 -0800<br></blockquote><blockquote type="cite">Subject: [postgis-users]<br></blockquote><blockquote type="cite"><span class="Apple-tab-span" style="white-space:pre"> </span>Re: [postgis-devel] Proposal for supporting Extrude, Tesselate,<br></blockquote><blockquote type="cite"><span class="Apple-tab-span" style="white-space:pre"> </span>and Altitudemode options in PostGIS KML generator<br></blockquote><blockquote type="cite">Reply-To: PostGIS Users Discussion <<a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a>><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">As far as the KML proposal and syntax, I think both Paul and Martin's<br></blockquote><br><blockquote type="cite">suggestions are good improvements.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">What about providing a string parameter which can supply the various<br></blockquote></blockquote><br><blockquote type="cite"><blockquote type="cite">options in a human-readable format?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">E.g. "extrude=1 tesselate=0 altitudeMode=clampToGround"<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Easy to read, easy to parse, easy to extend...<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">If I had to choose between them I think the ease of reading of this<br></blockquote><blockquote type="cite">approach above is the nicest, if not most grass=like.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Thanks so much to Eduin for pulling this together.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Anyone have more thoughts?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Cheers,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Dane<br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">postgis-users mailing list<br></blockquote><blockquote type="cite"><a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br></blockquote><blockquote type="cite"><a href="http://postgis.refractions.net/mailman/listinfo/postgis-users">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br></blockquote><br><br>_______________________________________________<br>postgis-users mailing list<br><a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>http://postgis.refractions.net/mailman/listinfo/postgis-users<br></blockquote></div><br></div></body></html>