The old libFMap project was divided into a number of subprojects which provided the core functionality. These projects, in turn, generated various artefacts or .jar files, which also affect the dependencies that we will include in our projects.

The main projects that have emerged from the former FMap are:

• org.gvsig.fmap.geometry (libFMap_geometries)
• org.gvsig.fmap.dal (libFMap_dal)
• org.gvsig.fmap.dal.file (libFMap_dalfile)
• org.gvsig.fmap.dal.db (libFMap_daldb)
• org.gvsig.fmap.dal.index.spatial (libFMap_dalindex)
• org.gvsig.fmap.mapcontext (libFmap_mapcontext)
• org.gvsig.symbology
• org.gvsig.fmap.control (libFMap_controls)

The following section discusses some of the major changes in functionality.

In gvSIG 2.0 a separate project for geometry libraries has been constructed. It has evolved from what was in previous libraries and provides a separation between the API, implementation and operations on geometries.

There is development documentation available on the library, where we can see major changes at the API level, and a description of the model geometry that defines the library.

One of the major changes is that classes such as FShape have disappeared, and will be substituted by the interfaces available in the geometry library, such as Geometry and GeometryManager.

For example, where constant shape types were used to define the FShape class, there are now two options:

• Using geometry operations, we can associate types and/or subtypes of geometries.
• Using constant types and subtypes that are defined in the Geometry.TYPES and Geometry.SUBTYPES interfaces. This option has a big problem, in that these types and subtypes do not cover all possibilities, but only those defined initially as defaults. From now on libraries or extensions can be registered on their own, so if you use this option, instead of registering operations, our functionality won't function properly with these other geometry types.

In any case, if we choose the latter option, then we have a table showing the equivalents between the types of shapes and types of geometries of the new library:

(*) In the gvSIG 2.0 geometry library, any geometry may be 2D, 3D, 2DM, etc. This feature is managed through the subtype of a geometry (see Geometry.SUBTYPES for predefined subtypes), so there is no equivalent for this constant in Geometry.TYPES.

One of the main changes in the development of gvSIG 2.0 has been the replacement of all previous data access methods with a new API and implementation, namely the DAL (Data Access Library).

This API combines access to both tabular and geometric data, in addition to defining a common core API between vector and raster data.

For more information about using the API, as well as the development of data providers, consult the DAL development guide.

All code related to Mapcontext, symbology and labelling has been moved to a separate project: org.gvsig.fmap.mapcontext (libFMap_mapcontext). Those parts relating directly to mapcontext, the viewport, layers, etc. have not changed much since the previous version, except for changes required to conform to the rest of gvSIG 2.0.

The main change has been to extract the symbology and labelling API, as this API and the rest of mapcontext are a joint project between gvSIG desktop and gvSIG mobile.

The implementation of symbology and labelling now has its own project: org.gvsig.symbology. This is the implementation that is used in gvSIG desktop; gvSIG mobile has developed its own implementation.

Therefore, when a project is migrated to gvSIG 2.0 it will be affected mainly by:

• The extraction of the symbology and labelling API. These APIs have hardly been modified. The main change is that there are now managers for obtaining, creating and registering symbols, legends and labelling strategies. The entry point for accessing these managers will be the MapContextLocator.
• The introduction of new symbols, legends and labelling strategies. We use the previous managers to register them.
• A few changes to the rest of mapcontext, especially those related to data access, and issues such as InfoByPoint.
• Renamed all the starting packages with:
  • org.gvsig.fmap.mapcontext: main package of the org.gvsig.fmap.mapcontext project (libFMap_mapcontext).
  • org.gvsig.symbology: main package of the symboloy and labelling implementation project org.gvsig.symbology.

At the moment the development guide doesn't have any documentation available on this development.

A new project has been created where all the code related to MapControl is located: org.gvsig.fmap.control (libFMap_controls). This project also contains other graphical controls that depend on the other FMAP APIs, such as DAL.

For example, swing components, used from the gvSIG document table, have been created to display Feature tables. But now it is very easy to create applications outside of gvSIG, or to include other use cases that aren't from the document table, that show Feature data in tabular form.

Apart from the general changes to packages, and the adaptation to the other changes, this project has a few changes affecting the API. Some examples are:

• Rename the addCombinedTool method to addCombinedBehavior
• ...