Skip to end of metadata
Go to start of metadata

People

Student: Anthony Manfredi

Primary Mentor: Andrea Aime

Other Contacts: Tim Schaub, Saul Farber, Jody Garnett, Chris Holmes, Corey Horner, Cameron Shorter, Vincent Heurteaux

Goals of the Project

  • To design and implement an editor for SLD files with using JavaScript.
    Desired Features:
    • Standalone - editor is not tied to a particular program (uDig, MapBuilder, GeoServer)
    • Visual - users can preview the results of changes as they are made.
    • Intuitive - easy to learn but not cumbersome or limiting for the advanced user.

Interface

Here's my drawing of the interface layout, and the html layout so far:

The top bar is a series of tabs acting as a menu.

  • Main: Where the actual editing takes place
  • Save/Load: Create a new blank SLD; Save the current SLD to a file or PutStyle to a WMS; Load an existing SLD to a file or GetStyle from a WMS.
  • Options: Configuration options, such as which elements to show and which to hide for simplicity.
  • Defaults: Specify defaults to automatically fill in for new elements of various types.
  • Help: Help on the editor and SLDs in general
  • Preview: Options and settings for the preview area

The section dividers should be moveable, if possible.
In addition to the help menu, there will be informative descriptions that pop up on mouseover with a slight delay.

The List Area is at the left. The top item is the current level in the SLD hierarchy. Clicking on the arrow button next to it takes you up a level in the hierarchy. The items in the list below are the elements available at the current level. Clicking on an item in the list allows you to edit its attributes. Double-clicking on an item in the list sets that item as the current level, selects it, and updates the list.

  • Mutually Exclusive elements: the list will show both items linked and will only allow one to exist at a time.
  • Optional elements: the list item will have two buttons next to it allowing the element to be created or removed.
  • Multiple elements of the same type: Similar to the optional element, an element that can have multiple instances will have, in addition to create and remove buttons, a duplicate button.

The Data area is in the middle. It allows you to edit the attributes of the currently selected element. The buttons at the bottom allow you to save the fields, revert to the last saved values, or clear all the fields. Potentially, two more buttons could be added: Revert to Defaults and Save as Default.

  • What should the behavior be if the user makes changes in the data area and switches to another element without hitting apply or revert?

The Outline Area shows the structure of the SLD document and the user's current location within it. The elements are collapsible, and the current element is selected. Clicking on an element in this area sets it as the current level and updates the List and Data areas accordingly.

The Preview Area is an OpenLayers-based visual preview of the current style. The details of this can be set in the Preview tab. Perhaps there should be an Update button on the map, to avoid updating the map every time the user hits Apply or changes elements.

Code

Code Structure

Each SLD Element is a JavaScript Object. There is a base SLD object, which may contain NamedLayer and UserLayer objects, and so on. The toString method of each of these objects returns the appropriate SLD text for that element, and recursively calls toString on the objects it contains. In this way, it is easy to print out the entire SLD accurately.

These objects are initially created empty. When the "Apply" button is pressed in the interface, the appropriate fields will be updated via the object's utility methods. Pressing "Revert" will reload the data from the object.

Question: How to do validation?
It is probably best not to require the SLD to always be well-formed, as this could be annoying to the user. All required fields should be designated as such in the interface (red text color?), and we will keep track of how many required fields are empty. If there are no empty required fields, then the SLD should be well-formed. It would also be useful for the user to be able to zoom to elements with empty required fields. Perhaps a new menu tab: "Validation."

  • When should data from the page update the data structures?
    • when user hits apply/ok button.
  • How should multiple elements of the same type be handled under my current organizational approach?
    • see about using string-based instantiation
  • Need encoding for ogc filters and expressions

General Questions

  • Browser compatibility issues?
  • How to do visual previews?
    • OpenLayers
  • Which features should be implemented first, and which can wait?
    • Zoom rules are important
  • How should the UI be organized? What do users like and dislike about existing editors?

Design Notes

Important Features (from geoserver-devel discussion):

  1. create a new SLD file
  2. modify an existing SLD file
  3. able to work with the standard GetStyle, PutStyle calls foreseen
    by the SLD WMS extensions
  4. save a new or modified SLD
  5. specify where the file is saved

uDig Editor:

The Good:
  • Icons in the layer tab reflect the actual style
  • Map window shows style in context, scale number display is helpful.
  • Easy to access and change values
  • Ability to directly edit the XML
  • Able to view and edit SLDs from remote servers
  • Drag-and-drop layer reordering
The Bad:
  • Zoom rules seem buggy. I set min scale to 1,000,000 on a layer and it is still visible at 1:869,756. Likewise, max scale is 5,000,000 and the roads are not visible until 1:4,000,000. However, the numbers appear correct in the XML. This could be a problem with the display or an incorrect scale being shown.
  • Many options are unlabeled in the editor.
  • Options that are labeled are not described.
  • Large amounts of wasted space in the left tab, and simple view.

MapBuilder Editor:

The Good:
  • Everything is labeled, but still not described
  • less wasted space
The Bad:
  • No featuretype selected?
  • unable to directly edit XML
  • forced to use color selector instead of typing in a hex color
  • I feel that having the preview on the left and the editing space on the right is counterintuitive
  • difficult to figure out how to load SLDs and actually apply changes; interface doesn't "flow"

qgis Editor

This isn't exactly a SLD editor, but it is very similar.

The Good:
  • Interface is uncluttered
  • Related options are grouped together, both in tabs and within a single window
  • Interface flows from top to bottom
  • All options are labeled fairly clearly
  • Existing type and style is already filled in when editing a style
  • map is in a separate window
The Bad:
  • Some options run together visually
  • No option to create a style independently of data
  • cannot move map while editing
  • A layer may only have one non-scale rule
  • in equal interval, no way to specify colors to interpolate between
  • in equal interval, cannot edit multiple classes at once
  • must hit "apply" before changes can be seen
  • no undo/revert

Progress

ToDo:

  1. Finish class structure coding
  2. Make a bare-bones UI
    • Explore OpenLayers integration
  • (ongoing) Gather feedback from users on what they would like to see in an SLD editor

Completed:

  • Prepare initial interaction diagrams and UI mockups
  • Begin class structure coding
  • Read more about JavaScript/Dojo
  • Outline SLD structure
  • Explore development technology options (JavaScript, GWT, Wicket): Decided on JavaScript
  • Get access to Devel/Users mailing list, Wiki editing
  • Read SLD Specification
  • Install GeoServer, uDig, OpenLayers, MapBuilder, Dojo
  • Explore SLD in GeoServer, uDig, MapBuilder
  • Dojo Tutorial
  • JavaScript Tutorials
  • Initial Wiki Setup
  • Analyze existing SLD editors: what's good and what's bad (uDig, MapBuilder, qgis)
  • SVN commit access

Suggestions


  • No labels