[ka-Map-users] layer controls - your opinion requested
jacob.delfos at maunsell.com
Tue Aug 2 19:50:57 EDT 2005
Sounds like you got it all worked out already :)
Still some comments inline...
» -----Original Message-----
» From: ka-map-users-bounces at lists.maptools.org
» [mailto:ka-map-users-bounces at lists.maptools.org] On Behalf Of
» Paul Spencer
» Sent: 3 August 2005 05:39
» To: ka-map-users at lists.maptools.org
» Subject: [ka-Map-users] layer controls - your opinion requested
» hello ka-mapers!
» I'm soliciting feedback on how the layer control (kaLegend)
» works. It
» currently serves my purposes in most cases but it could stand some
» I am not going to build a completely flexible template-based
» legend ala
» mapserver legend templates, but I am open to suggestions on
» how to make
» the existing layer control more flexible - others can build different
» layers controls if they wish :>
» Currently it works by assuming that everything with no group
» (or in the
» group named __base__) is part of a group labelled 'Base' in the
» interface. This special group cannot be turned off as it.
I think the nature and purpose of Ka-map makes groups a 'must', and if you're building a serious website to go live, it's not much effort to define a group for all items you want on there. I wouldn't expect the BASE layer to be used on a live site, only for development, so I wouldn't worry too much about any aspects of it. Though I think it might as well have a toggle-box.
» Any other groups in the map file are loaded as separately
» elements in the legend control, one checkbox per group.
» For each group, you can expand it to show the mapserver
» legend for that
» group (based on the LEGEND object in the map file, not a
» legend template).
» For each group, you can control the visibility and the opacity on the
» client side. The visibility is handled via the checkbox.
» There is no
» visible way to control opacity (any more) but it could be added by a
» third party if they wished - instead, you can control the opacity via
» the map file by adding metadata "opacity" "50" on the first
» layer in any
» (Are there other things we could control on a layer-by-layer basis?)
Would it be crazy to have a combobox with pre-defined (in metadata?) attribute names of labels that can be controlled by the user (e.g. "roadname", "roadlength", "no labels")? The labels would sit in a separate layer that is not loaded by default. Probably too much work to implement, though.
» Its pretty obvious that the name 'Base' is not particularly suited to
» most applications ... Also, it may be desirable to have one or more
» 'groups' of layers that cannot be turned on/off ... but perhaps have
» variable opacity etc.
» I think one solution to this is to provide more metadata in
» the map file
» that can control the functionality of the legend. What I am
» thinking of doing is removing the magic 'Base' group and instead
» allowing groups to have visibility controls or not via metadata:
» visibility_control: true/false
» This could optionally be expanded to include:
» opacity_control: true/false
» The default for both would be 'false' if not explicitly set to 'true'
» (i.e. missing or any other value than true)
As above, wouldn't worry about "customizability" of BASE group. Why would you want to make it impossible to turn off a layer or change its opacity though? Might as well not show it in the layer-control/legend at all then (treat it as background), to reduce clutter and keep things simple (strength of Ka-map is its simplicity from the user's perspective, in my opinion). So you'd have a metadata item called "show_in_legend".
» Group/Layer order is currently not fully respected in that
» the special
» 'Base' layer is kept at the bottom on the client side. In making the
» above change, I would also remove this restriction so that the static
» layers could be placed anywhere in the map drawing order and
» have that
» respected on the client side.
Think items should appear in legend in same order as they are stacked. As above, wouldn't worry about BASE layer.
» For performance reasons, we turn off all unnecessary layers during
» dragging. I would propose to change this to either:
» 1) turn off only layers that have visibility_control set to true
» - OR -
» 2) provide another metadata to control which layers are left on when
» dragging (I'm open to suggestions on naming for this, plus defaults)
Performance is everything (determines whether user stays on your site or forgets it forever). I would suggest a "preload" metadata item, that controls whether a layer is loaded when it's turned off or not. I noticed a strong performance decrease as number of layers increases.
» Finally, what should we do with layers that have no group
» set? Perhaps
» they could still go into a special 'Base' group? Or
» 'Ungrouped Layers'?
As above, I think the essence of Ka-map is having layers combined in groups, to increase performance and simplicity. Only use BASE for development, not for live site.
» If there is any other functionality or any objection/changes to the
» stuff I've mentioned here, please post on the list to get
» your opinion
» heard :)
Actually..... :) I like the way the legend, scalebar, etc have been combined into one div (the "reference" div). I've dumped a search-tool into it as well. I think that div is highly suitable for being made 'draggable', so it can be moved around as a toolwindow. That way, it's not in the way of the map at times.
My suggestions are only suggestions, not requests (no pressure!). I'm very happy with Ka-Map as it is.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ka-Map-users