[postgis-users] Re: [postgis-devel] Proposal for supporting Extrude, Tessel

[Martin Davis]

I would respectfully disagree...  Not on the philosophical grounds of 
styling vs data, but on the purely pratical ground that it would be a 
pain to try and inject the geometry attributes into the generated XML 
after the fact.

I can see why Google chose to embed the purely "geometric" styling 
parameters within the Geometry XML, but it's quite a pain for several 
reasons.  One is that this kills compatibility with GML (and thus 
prevents or at least makes it a lot more complex to reuse code that 
reads & writes GML).  I'm feeling this pain right now while working on 
improving the JTS GML API.

guido.lemoine at jrc.it 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 <blake at hailmail.net>
>> To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
>> 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 <postgis-users at postgis.refractions.net>
>>
>>
>> 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
>> postgis-users at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>     
>
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022