Application: gvSIG desktop » gvSIG tools: Vector editing

=================================================================

 New gvSIG 2.1+ vector editing support

=================================================================

-------------------

 Technical design

-------------------

:Company:   gvSIG Association 

:Author:    DiSiD Corporation, S.L.

:Revision:  $Rev: $

:Date:      $Date: $

:Copyright: 

.. contents::

   :depth: 2

   :backlinks: none

.. sectnum::

   :depth: 2

   :start: 1

.. |year| date:: %Y

.. header:: 

   .. class:: headertable

   +-----------------------+-------------------------+

   |.. class:: left        |.. class:: right         |

   |                       |                         |

   | Requisitos            |###Page###               |

   +-----------------------+-------------------------+ 

.. footer:: 

    .. include:: <isonum.txt>

    .. class:: left

    *New gvSIG 2.1+ vector editing support - Technical design*

    |copy| |year| ** 

Introduction

=============

gvSIG 2.1 provides vector editing support, which was already available since gvSIG 1.9, and has been migrated and adapted to the newer versions. But from the user point of view it lacks usability and an uniform way of interacting with the user. A lot of the editing tools provided in gvSIG are lacking from the usability point of view, as well as the limitations they have.

From the point of view of a developer, it is a bit cumbersome to develop new vector editing tools, with too much responsability given to each tool implementation. Also there is not a well defined API to be able to use the vector editing support out of the user interface.

To be able to solve those problems, a new project has been started to create a new vector editing implementation, from the core editing support to each of the editing tools. To make the most of it, a new list of funtional and technical requirements have been gathered, and a new functional analysis has been performed.

This document is the technical design of the new vector editing library and support for gvSIG 2.1+, taking into account the new requirements and the functional analysis.

First, a list of new technical requirements gathered while creating the technical design will be listed to have a bit of context of the proposed design. Next, the APIs and implementations of the different modules of the editing support will be defined.

Technical requirements

=======================

* As this may be a mid/long term project, a way to be able to coexist the old vector editing implementation with the new one must be provided. The idea is for the user to be able to install the new editing support and disable the old one, without needing another gvSIG desktop installation. That means no changes to gvSIG core projects need to be performed, or the ones to perform must be compatible with the old vector editing.

* The way to integrate de editing support in gvSIG, taking into account the previous requirement is to use MapControl Behavior objects.

* Andami Extension objects will be used to register the vector editing tools, managing also the status (enabled, active, ...) required by Andami while being added as toolbar buttons and menu entries.

* An editing tool library must be implemented which allows to use it not only from the user interface, like for example a gvSIG personalization, an addon or a script.

Technical design

=====================

To have a bit of context of the proposed design, we will first provide a description of how should work the new editing support for an example tool, and some needs for the editing library API and SPI. Next, the API, SPI, implementation and other packages will be defined.

Example use case description

-------------------------------

When gvSIG is launched, a EditingExtension registers an EditingBehavior in MapControl to provide user interaction with the editing tools. When an EditingTool is started, the EditingBehavior will interact with the tool to:

* Get the first/next parameter required by the tool

* Get the information of a parameter: type, description, ...

* Get a Geometry to represent the current editing status.

The EditingBehavior responsability will be to interact with the user to provide the EditingTool with the required parameters. That interaction will be performed through three different ways:

* Left button mouse clicks: mainly used to get map locations.

* Contextual menu options: to select between available options or open a dialog with a form to fill the required parameter values.

* Through the text console.

Each editing tool or group of tools have an Extension which registers the related toolbar buttons and menu entries, as well as register the editing tools in the editing library SPI. Also the Extension must be able to activate the editing tool when the user clicks in the related toolbar button or menu entry. That means an Extension will require to interact with the editing library for the following actions:

* Register an editing tool.

* Ask if an editing tool is enabled or active for the current context.

* Start an editing tool.

With this context, an example use case of a editing tool to create a Curve geometry will be as follows:

* The user clicks on the create Curve button, and the related Extension activates the CurveEditingTool.

* The EditingBehavior asks the tool for a mouse icon to use, or uses a default one.

* The EditingBehavior asks the tool for the first parameter.

* The CurveEditingTool responds with a parameter of type *List of Points*.

* The EditingBehavior activates a message in the console asking for the X,Y values of the next Point. 

* The user has then three options to provide the point: 

  * Click with the mouse left button in the map.

  * Write in the console the X,Y values of the point.

  * Opens the contextual menu and select the option to provide the X,Y values, which will open a dialog with a form to write the two values.

* Each time the user moves the mouse cursor, the EditingBehavior requests the tool a Geometry to draw with the current context and the map location of the mouse cursor. In this case, the Geometry will be a Curve created with the user already defined points and, as the last point, the current mouse cursor location.

* Once the value of the point is provided by the user to the EditingBehavior (through mouse, dialog or console), it creates a Point and provides the value to the tool and asks for another Point to the user, with an option to allow the user to end the Curve:

  * With a mouse left button double click.

  * With a value in the console (*?E?*)

  * With an option in the contextual menu.

* This process is repited until the user ends the list of points.

* The EditingBehavior notifies the tool the list of Points is finished.

* The tool creates a curve with the provided points, and a Feature is created and inserted into the current Layer FeatureStore.

* The tool ends and it is activated again by default. The user may create another Curve or activate another tool.

* In any point of the process, the user may activate another tool o pulse the *Esc* to finish the current tool execution and start again. **NOTE: if the user has already provided some data, ?ask him to confirm the cancelation and lose the data?**

API

----

This is the API of the vector editing library, which wil be based on the gvSIG tools PBI model (Provider Based Implementation).

* Project: org.gvsig.vectorediting/org.gvsig.vectorediting.lib/org.gvsig.vectorediting.lib.api

* Package: or.gvsig.vectorediting.lib.api

EditingManager (extends o.g.t.s.Manager)

*********************************************

The API will provide the following services:

* Provide an EditingService for an editing tool.

* Provide information of an editing tool:: EditingServiceInfo

EditingService (extends Service)

*****************************************************

* Start the edition.

* Provide the following parameter required by the tool

* Set the current parameter value.

* Provide a Geometry to draw the current editing context, taking into account the values previously provided by the user and a Point with the current mouse cursor location.

* Cancel the execution of the tool.

* ?Ask for the Geometries or Features created, updated or removed by the tool?

EditingServiceInfo

*****************************************************

* Provide read only information about a tool:

  * Tool name.

  * Tool description (?use as contextual help?)

  * Mouse icon.

  * The geometry type being managed.

  * If the tool creates new geometries.

  * The list of the parameters.

* Provide read only information about a tool parameter :: EditingServiceParameter

EditingServiceParameter

*****************************************************

* Provide read only information about a parameter:

  * Parameter name.

  * Parameter description (?use as contextual help?)

  * Parameter type: 

    * Location Point

    * List of Location Points

    * Option

    * Value (*?typed value: string, integer, ...?*)

    * New Geometry of a given type.

    * Selection of one or many geometries/features.  

SPI

-----

* Project: org.gvsig.vectorediting/org.gvsig.vectorediting.lib/org.gvsig.vectorediting.lib.spi

* Package: or.gvsig.vectorediting.lib.spi

EditingServiceManager (extends ProviderManager)

*****************************************************

* Registration of editing tools :: EditingProviderFactory.

EditingProviderServices (extends ProviderServices)

*****************************************************

* Store a new or updated Feature.

* Delete a Feature.

* ?Get the Symbol to draw a Geometry?.

* Create new Features based on another ones, following the common criteria about the alphanumeric information:

  * New Features created from an old one (ex: Split): clone all data, but the primary keys.

  * New Feature created from a set of Features (ex: Union): for every attribute, if the values are the same for all the source Features, ignoring null values, clone it. Otherwise leave as null.

DefaultEditingServiceInfo and DefaultEditingServiceParameter

**************************************************************

* Default implementations to be used by the tools.

EditingProviderFactory (ProviderFactory)

*****************************************************

* Provide information of the tool (see EditingManager's API).

* Provide information of a tool parameter (see EditingManager's API).

EditingProvider (Provider)

*****************************************************

* Provide the following parameter.

* Provide a Geometry to draw the current editing context (see EditingService's API).

* End the editing process and store changes.

* Cancel the editing process and discard changes. 

Implementation

----------------

* Project: org.gvsig.vectorediting/org.gvsig.vectorediting.lib/org.gvsig.vectorediting.lib.impl

* Package: or.gvsig.vectorediting.lib.impl

Provides the implementation of the library components, extending the related base tools implementations.

Editing Plugin

---------------

* Project: org.gvsig.vectorediting/org.gvsig.vectorediting.app/org.gvsig.vectorediting.app.mainplugin

* Package: or.gvsig.vectorediting.app.mainplugin

Provides the implementation of the main editing plugin, and integrates the editing library API, SPI and implementation in gvSIG.

EditingExtension

*****************************************************

Registers the EditingBehavior in MapContext, as well as the actions to activate/deactivate editing.

Also activates the console when editing is started, puts the selected layer store in editing mode, and notifies about the begin and end of editing mode.

EditingBehavior

*****************************************************

Implementation of Behavior which interacts with the editing tools.

.. admonition:: Doubt

   ?Create instead as an interface in the API, and create a default implementation in the library implementation?

BaseEditingServiceExtension

*****************************************************

Default implementation to be used by editing tool plugins. 

.. admonition:: Doubt

   Not sure if there is a mechanism to be able to have a single final implementation, or each extension must extend this one.

Other themes to take into account

-----------------------------------

Geometry construction

***********************

All geometries being constructed, not already available in the Geometry Library, must be added as operations.

Snappers

------------

Snapper support is defined in MapControl, with the current snappers available in the gvSIG main plugin. The current editing plugin only activates them and provides a configuration panel.

That panel should be moved out of the editing plugin to a new one, which also adds actions to enable or activate snappers by the user, also with a key shortcut.

Geometries composed of other geometries

-----------------------------------------

* A mechanism must be defined to allow a way for a tool to ask for new geometries, and the editing manager to be able to call other tools which create the required geometry type, in a kind of "reentering" mode.

  Two different approaches have been discussed:

  * The same EditingProvider should allow to create only Geometries instead of Features, with some kind of parameter or new methos.

  * Separate provider types, with the ones which create Features and other ones which create basic geometries.

Templates

----------------

As a future functionality, the user would be able to define templates for creating new Features, with default values for:

* Alphanumeric attributes

* Type of geometry

* Editing tool to use

* Simbology to apply

Now we are not going to implement this, but it would be nice if we could take this improvement into account so it could be implemented in the future without much changes.

Toolbar button with many option

---------------------------------

* As this needs support in Andami, for now all editing tools will be implemented simple. Ex: create a circle now asks first if the user wants to create it with center and radios or with three points. It should be implemented as two separated tools.

* In Andami it could be implemented as a way to group toolbar buttons in button menus, which could be defined through the config.xml file.