This page last changed on Jan 09, 2007 by jive.


Adding a module to provide an "Issues List" client service

Proposed By

Jody Garnett

Proposal Type

New Module Request

Assigned to release

Not intended for a GeoServer release (ie this is a community module), results in a dependency available for community projects.


Withdrawn - was decided a GSIP was not needed for a new module request.


JIRA task:

Email discussion:

Other wiki discussions:


Client applications have a need to share "issues". Such applications would request a list from GeoServer for resolution by the user. This resembles a bug tracker with the key addition that issues will usually reference a feature or geometry. More serious applications will make use of a workflow system (say JBoss) also resulting in a list of issues. This API will allow

Examples of an issue:

  • WFS feature validation error
  • workflow task


Much like the preferences module, the issues list module will take advantage of hibernate to back entries onto a database. Also similar to the preference module the resulting module will make available an API.

The IssuesAPI will be available:

  • via SpringRemoting for client applications
  • as a Bean for use in Spring wiring for other modules to use

Care will be taken during the construction of this API to allow for Issues to be retrived at two levels of granularity.

  • As an Issue List where isssues relationships are not fully explorered
  • On a per Issue basis, with all relationships resolved


The interface is subject to change; the initial cut is:

Issue List

This interface forms the API used by other GeoServer modules, and will be made available to client applications
via spring remoting.

interface IssueList 
  Set<String> getGroups()

  /** Shallow Issues, ie name, id, bounds, but not details like feature */
  List<Issue> getIssues(String groupId)

  /** Complete Issue, suitable for editing */
  Issue getIssue(String issueId)  

The uDig IIssuesList class provides some inspiration for this interface.


This class is based on the uDig Issue Model (and may be one in the same). Additional information may be required as we
make use of a JBoss workflow implementation. At the very least a memento construct should be available for both the client and
server side processes to store state associated with the issue (in an opaque fashion).

interface Issue {
  String getId()
  String getDescription()
  void setDescription()
  String getProperty(String key)
  void setProperty(String key, String value)
  Resolution getResolution()
  void setResolution(Resolution resolution)
  ? getBounds()
  ? getFeature()


interface Resolution {


  • Pablo Casado (Bluesphere/SENS)
  • [~rgould]
  • [~chorner]

Why not use existing WFS-T protocol instead of inventing your own. That way you can store your issues list on any WFS-T compliant server. Perhaps the basic WFS-T constucts are not enough? Can you perhaps go into a bit more detail about what the protocol will look like.

Posted by jdeolive at Aug 15, 2006 13:55

Justin brings up a good point. It might be best to use Geoserver as is and just set up a database that will store the issues, like a regular dataset. It will be quite the beast to tackle writing your own protocol and tieing it all in with transactionResponse.
More info will help us help you.

Posted by bowens at Aug 15, 2006 14:07

Certainly this the way we have made use of GeoServer for our collaboration work at PennState. The client uses WFS/T to store annotations for other users to view/modify as required. We can then use a mapbuilder client for general work and viewing but switch to uDig or somesuch to make bulk updates and more complex annotation.

Posted by ianturton at Aug 15, 2006 15:18

As was noted in the IRC logs, and worth repeating here, there is really nothing unique about an Issue - its just a Feature (that may or may not have any geometry).  Rather than putting effort into another hack it would be better to help bring the FM branch home so we cope with all the information objects we care about.

This is probably just a trivial case of a "join" between data stores - one holding issues features and others holding the features being referenced. The join itself would only be needed if you wanted to query - "find all the issues open on road features  updated since the issues list was created". Otherwise its simply a multivalued property of type gml:FeaturePropertyTime constrained to be "byReference"

Posted by rob_cto_sco at Aug 15, 2006 19:39

Hi, WFS-T was not of interest as we are trying to intergrate with other spring/hibernate components. You will see a hibernate datastore made available in the comming weeks. Sorry if that was not clear from the initial proposal.

Posted by jive at Aug 16, 2006 04:11

Yeah Rob I see your confusion (because Feature is mentioned in the Issue API), this is more an accident of using the validaiton toolkit as our first source of issues (and this is a mistake).

The fact that the validaiton process is reporting on state should be hidden from the general purpose issue interface. This would be a contract that a validation server module and a validation client module would determine between each other.

We better generalize the issue model used in uDig, sorry I did not review the uDig code earlier (was happpy to see something on the screen).

Posted by jive at Aug 16, 2006 04:21
Document generated by Confluence on May 14, 2014 23:00