search

google-code-export / marinemap

Automatically exported from code.google.com/p/marinemap
Other
1 stars 2 forks source link

Icons for kmltree #480

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Currently there is no mechanism for a Feature to specify which icon will appear 
next to it's entry in the KMLTree. 

I'm looking for a solution that will allow for the following:

* Defining icons on a per-feature basis through the use of an .icon @property
* Some automated or easy way to colorize an icon based on classification.
* Some automated or easy way to change to icon to indicate sharing status, 
loading status, etc. Perhaps these are universal and handled by kmltree 
overlaying standard icon 'modifiers' on top of the icon?
* Points, Lines, Polygons and FeatureCollections should all have a default 
icon. 

Also need to think about how this info would get passed to the client: in the 
workspace doc? or as itemIcon kml properties?

Original issue reported on code.google.com by perrygeo...@gmail.com on 17 Feb 2011 at 5:05

GoogleCodeExporter commented 9 years ago 
Added ItemIcon to kml style output. This will eventually allow for 
programmatically determining icon in kmltree list. Next steps are in the 
kmltree js to support:

1) When you try to specify multiple ItemIcons associated with different states
(open, closed, error, fetching0, fetching1, and fetching2), kmltree
tries to concatenate all the urls resulting in an invalid image URL.

2) KMLtree does not appear to use the ItemIcon property on Placemarks
at all; instead relies on hardcoded css classes for polygons and lines
(no icon for points).

3) The gx:x, gx:y, gx:h, and gx:w tags are not supported which are essential to 
using the icon palette approach. Alternately we could just required separate 
images but the palette would be nice.

Original comment by perrygeo...@gmail.com on 23 Mar 2011 at 3:08

GoogleCodeExporter commented 9 years ago 
1) This can be fixed fairly easily in kmltree. I can't promise it will fully 
support all these different states, but at the very least the open/closed state 
can be supported.
see
http://code.google.com/p/kmltree/issues/detail?id=38

2) The Earth API doesn't have proper support for ItemIcon so it has to be 
supported by parsing the xml within kmltree. There are going to have to be some 
inefficient hacks to support this until the earth api adds support...

3) I don't think this is something we should count on being supported in 
kmltree in the near future. It's a non-trivial thing to implement, and a pretty 
recent vendor-specific addition to kml as it is. Individual 16x16 icons are 
plenty performant as is. I'd like to focus on other nuances in the CMS branch 
UI-side before worrying about that.

Original comment by underbluewaters on 30 Mar 2011 at 5:22

GoogleCodeExporter commented 9 years ago 
re 3).. Looks like the Earth plugin 6.0.2.2074 (API 1.008) adds support for 
gx:x, etc. Not sure if that helps us much if ItemIcon is still not exposed 
but...

http://code.google.com/apis/earth/documentation/releasenotes.html

Original comment by perrygeo...@gmail.com on 31 Mar 2011 at 1:52

GoogleCodeExporter commented 9 years ago 
The problem is that this is a really new version of the plugin. It would 
require re-implementing that api by parsing the gx tags to support people who 
haven't been auto-upgraded yet. I should be writing this stuff down somewhere, 
but I'm pretty sure what we have now will only require the June 14, 2010 
version of the plugin. That's pretty far back, but I've seen old versions like 
that still hanging around on some machines.

Original comment by underbluewaters on 31 Mar 2011 at 3:50

GoogleCodeExporter commented 9 years ago 
As discussed on 4/21 dev call - kml parsing to use itemicon may just be too 
costly when we can simply override the css. Conveniently, each feature in the 
kmltree has it's model_ui as a class. 

I checked in a revision that provides a view/url for a dynamic css file. This 
view will look at each registered model and include the output of it's css() 
class method. 

Right now the css classmethod is nice since it allows a lot of flexibility 
(need to support mutli-state icons or scroll on a sprite - no problem) but it 
complicates the simple use case of just supplying a single image url.  Not sure 
if that is a big deal or not? Thoughts?

Original comment by perrygeo...@gmail.com on 21 Apr 2011 at 11:47

GoogleCodeExporter commented 9 years ago 
If needed, we could simplify the simple use case... make an icon_url property 
and have the default Feature.css() method use that if available.

And here's a quick screenshot of it in action...
http://i.imgur.com/7Iw0o.png

Original comment by perrygeo...@gmail.com on 21 Apr 2011 at 11:50

GoogleCodeExporter commented 9 years ago 
Added an icon_url Option for the simple case. All seems to be working. Calling 
it done.

Original comment by perrygeo...@gmail.com on 22 Apr 2011 at 1:54