[Geomoose-users] GeoMOOSE v1.1 issues

[Jim Klassen]

General Issues:
1) The tools that are on by default are not "checked" in the catalog
view. Layers and Views work fine so this may be a configuration issue.
<service title="Previous Zoom" type="internal" default="true"
locked="true" command="NavHistory.previous()"
icon="shared/images/toolbar/arrow_left.jpg"
highlight="shared/images/toolbar/arrow_left_selected.jpg"
selectable="false"/>

Popup Related:
1) If you make a popup sticky and then close it with the "x" in the top
corner the popup will be sticky until a pan/zoom (if you hover over the
point again)

2) Getting popups to appear over lines (roads) is a little less than
predictable.

3) Turning a layer off when it is selected as the active layer for
popups leaves GeoMOOSE in a bit of an odd state.
 * No tool is selected at all.
 * The any sticky popups remain visible.

4) The the radio button in visible layers don't remain in sync with Flag
in the Catalog. (The flags seem to follow the radio buttons but not the
other way around.)

New Feature Thoughts:
1) Change Visible Layers to something like Active Layers. Then add a
check box next to the radio button which will enable and disable the
layer. Possibly remove the radio button in favor of the flags. The mode
of operation would be the check mark in catalog would add or remove the
layer from the "active layers" list. The red "X" in Active Layers would
remove the layer from the Active Layers list. The new check box in the
active layers list would control if the layer is fetched and visible.

This way once a user gets the list of layers they are interested in from
the catalog (and saves their settings (via guss)) they would generally
not have to go back to the catalog in regular work.

2) Instead of using the title= elements contents directly for tracking
the objects within the framework, use the entire path to the
layer/service by including the names of the parent groups. The
motivation here is so layers with the same title (which could easily
happen when included mapbooks) do not cause the interface to act all
weird. 

Optionally, it might be nice to add an id= element that is used in lieu
of title= which would be the "computer friendly" version of the title.
The motivation here is to more closely match how the WMS/WFS standards
catalog layers. For backwards compatability, "id" could be set to the
contents of "title" if "id" is not specified in the mapbook.

3) Extend the <group src=/> mechanism to support direct reading of WMS
services. Something along the lines of:
<group title="My Favorite WMS Server" src="/wms?" type="wms:1.1.1"/>
GeoMOOSE would then fetch the GetCapabilities document and manufacture
the required DOM elements for a mapbook to fetch the layers from the WMS
and insert that mapbook as is already done for the <group src=/>
machanism.  

(Note: /wms? would have to be setup on the GeoMOOSE server as a real WMS
server or as a reverse proxy to one. If it is a reverse proxy there may
be a issue with the OnlineResource urls returned from the
GetCapabilities request not being local URLs. If only fetching images
from the WMS this may work though.)

Jim Klassen
City of St. Paul