On Oct 15, 3:47 pm, Kludge <[EMAIL PROTECTED]> wrote:
> I guess the root of the issue is much more fundamental in terms of how
> we think about this and similar issues. Take for example the OGC WMS
> (map image server) specification which allows consumers/clients to
> specify a "style" (this is called a Styled Layer Descriptor [SLD] in
> OGC lingo) for the features being requested. The server then takes
> the "style" parses it, and applys the encoded symbology before
> returning the image to the client. Ideally, this separation of
> concerns (data vs portrayal) is what is needed for GM. This
> functionality has been available to OGC services for almost a decade.
> I think it's an oversight in this context. It would be very useful
> for me to specify a "style", local or remote that GM can use to
> symbolize my features. These styles can then be shared (much like the
> UI "skin" concept) amongst others. I have implemented something like
> this where users can create a shared SLD in a web form that can be
> used by anybody/service. But I digress...
>
> What most of us need/want is to symbolize GeoRSS feeds any way we see
> fit for the purpose at hand. For example, if I am going to display
> the USGS earthquakes GeoRSS feed I don't want users to see blue
> pushpins, I want them to see circles that are colored and sized
> according to depth and magnitude. Make sense?
It sure does. I am in total agreement. The ability to apply KML
colors / styles / etc. on the fly is missing.
I looked the KML documentation. It supports something called a
"<styleURL>" but it is useless. The actual URL is hard coded in the
KML file similar to HTML with CSS. Unless I am missing something, you
cannot define shapes separately from styles with binding at run time.
If a "shell" KML file could indirectly reference a collection of
component KML files, redundancy & maintenance could be reduced.
For what it is worth, I have built KML files for every state in the US
except Hawaii & Alaska. I have eight duplicate copies for every state
in each of eight different colors.
For Michigan:
polylibs.googlepages.com/st26_000000.kml
polylibs.googlepages.com/st26_0000ff.kml
polylibs.googlepages.com/st26_00ff00.kml
polylibs.googlepages.com/st26_00ffff.kml
polylibs.googlepages.com/st26_ff0000.kml
polylibs.googlepages.com/st26_ff00ff.kml
polylibs.googlepages.com/st26_ffff00.kml
polylibs.googlepages.com/st26_ffffff.kml
each with 40% opacity. For large complex polys, mapsdt blows the
doors off the browser dependent implementations of GPoly. The tiles
are cacheable too.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Maps API" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Maps-API?hl=en
-~----------~----~----~----~------~----~------~--~---
