Guido,
Thanks for you thoughts.
However, this proposal is not about styling.
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.
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.
This is quite different from the <Styles> tag which is separate from
the geometry in the KML schema.
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 (http://postgis.refractions.net/support/wiki/index.php?PostgisAndPython
).
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:
<KML header> <KML Styles> <ST_AsKML() 3D geometry from PostGIS><KML
Footer>
Cheers,
Dane
On Feb 20, 2008, at 11:20 PM, [EMAIL PROTECTED] wrote:
In effect, this issue is about styling of KML, and not so
much about the real data itself. I wonder whether postgis
should be concerned with that too much.
askml() produces only partial KML fragments anyway, so you
always have to make an effort, external to postgis, to
produce valid KML for display in GE (e.g. using XSLT).
This may as well include styling.
I'm not suggesting this is not a good idea, but IMHO, it's
not essential.
GL
-- Original Message --
From: Dane Springmeyer <[EMAIL PROTECTED]>
To: PostGIS Users Discussion <[email protected]>
Date: Tue, 19 Feb 2008 09:45:14 -0800
Subject: [postgis-users]
Re: [postgis-devel] Proposal for supporting Extrude, Tesselate,
and Altitudemode options in PostGIS KML generator
Reply-To: PostGIS Users Discussion <[email protected]
>
As far as the KML proposal and syntax, I think both Paul and Martin's
suggestions are good improvements.
What about providing a string parameter which can supply the various
options in a human-readable format?
E.g. "extrude=1 tesselate=0 altitudeMode=clampToGround"
Easy to read, easy to parse, easy to extend...
If I had to choose between them I think the ease of reading of this
approach above is the nicest, if not most grass=like.
Thanks so much to Eduin for pulling this together.
Anyone have more thoughts?
Cheers,
Dane
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
