Integrating Geotools into gvSIG CE

After some work, we have managed to replace the gvSIG CRS module for Geotools. Here we are going to discuss what we have done, the cost of the task in hours, what we have achieved and some issues that have arisen.

First of all, we have to say that the result is quite satisfactory. Except for a couple of cases that we will discuss later, all the functionality has been migrated successfully. Basically, we have done a two-step task: first, replace the existing references to previous versions of Geotools with the current version (Geotools 8.0) and then replace the gvSIG projection library with Geotools.

The first step involves the replacement of existing code that uses previous versions of Geotools with new code that uses the 8.0 version. Thus, we have replaced not only old jars but also classes in the repository that were copies of the Geotools code. An example of the latter is the org.geotools.referencefork package on libTopology. These changes can be reviewed in the SVN repository [1][2]

Then, the tricky part is to replace the gvSIG projection API with the Geotools one. This can be better viewed in the following diagrams that show the before and after status. Note that the red gvSIG element stands for every place in the gvSIG code that uses projections:

Basically, we replace the following interfaces:

• IProjection (gvSIG) -> CoordinateReferenceSystem (Geotools)
• ICoordTrans (gvSIG) -> MathTransform (Geotools)

and we get rid of all the custom CRS, CRS factories and everything related with implementations since Geotools already provides us that. Also, in order
to make the change as smooth as possible, a ProjectionUtils class has been created to delegate some tasks on Geotools and perform some other tasks that were responsibility of gvSIG CRS related interfaces but don’t exist in Geotools replacements. It’s a kind of adapter from the previous gvSIG API to the new Geotools one. In some cases
this adaptation is direct and ProjectionUtils simply manages an exception (for example, the getCRS method), but in other cases it performs a bit more complicated task (for example, the transform method). In any case, it is desirable that this class will eventually disappear for a full adaptation of the gvSIG code to the Geotools API. Finally, the libJCRS and extJCRS projects are excluded from build since we don’t need them anymore. These changes can be reviewed in the SVN repository [3][4].

After all this work, we have obtained a gvSIG version that performs projections using Geotools and we have removed almost three projects (extJCRS and libJCRS completely and most of libProjection classes), so the gvSIG team has less code to mantain. However, while replacing the projection support, some functionaly has been lost. As a result, some topology processes related with referencing and the Voronoi diagram may not work properly. Also, specifying the map scale manually may not work as expected. Lastly, by excluding the extJCRS extension, the panel for projection selection has been replaced with a previous version, less intuitive. These are the main issues that have arisen, but there are more little technical details that can be reviewed in the gvSIG CE code sprint wiki [5].

Regarding the cost of the task, it is important to notice that some tasks are still to be done, as explained previously. Also, by performing these changes, it is expected that some bugs would have been introduced, so the cost we present here does not take the technical debt into account and it will not be surprising that it doubles the cost of the already done work. Having considered all that aspects, the cost of the task performed so far is around 30 hours.

Finally, it is important to consider what the future tasks should be: what remains to be done and how to do it. In our case, the first task is to identify introduced bugs with unit tests, solve them and, if possible, remove the ProjectionUtils class to have a full adaptation to the Geotools API. Then, we should introduce Geotools in the data access layer of gvSIG and get rid of the drivers/adapters system, one of the most obscure parts in gvSIG. In order to do so, we should use directly the Geotools data stores from the layer classes (FLayer, FLyrVect, …). Thus, we can transform the current gvSIG data access layer:

into a much more simple layer:

A rough test has been made in this direction and the result can be seen in the following video. We use a toolbar button to add a new layer that uses Geotools in order to read a shapefile (specified by code, just for test purposes):

gvSIG vector layer with Geotools

However, this new FlyrVect with Geotools does not have a ReadableVectorial implementation since it uses a Geotools data store directly. A solution is to remove the getSource method from FLyrVect, but then all the extensions that implement custom drivers or use the ReadableVectorial directly will be broken. Thus, the backward compatible option consists in implementing an adapter for ReadableVectorial (and every other interface that gets obsolete in the layer classes API) that delegates in Geotools directly.

Moreover, there are a few tasks that, despite not being strictly necessary, are very interesting and should be considered. First, it is also possible to replace the gvSIG implementation for rendering and symbology. The advantages of this change is that all symbology code will be replaced with Geotools. Another feasible option for Geotools integration is the query syntax. gvSIG provides several different syntaxes to query data so it could be possible to replace all these syntaxes with the Geotools implementation. Regarding the processing framework, it could be also interesting to analyze the current status of gvSIG and determine the benefits of using the Geotools framework. Finally, there are OGR data stores available in Geotools that can be used in order to get access to a great amount of formats [6].

In conclusion, we hope that the work we have done gives a better perspective of the Geotools integration in gvSIG, how it can be performed, what we can and cannot do in the next gvSIG CE code sprint in Munich [7] as well as some hints on what will be the cost of the full integration.

[1] SVN revision 701
[2] SVN revision 702
[3] SVN revision 703
[4] SVN revision 704
[5] Geotools in gvSIG CE
[6] OGR Vector Formats
[7] gvSIG CE Code Sprint in Munich

After some work, we have managed to replace the gvSIG CRS module for Geotools. Here we are going to discuss what we have done, the cost of the task in hours, what we have achieved and some issues that have arisen.

First of all, we have to say that the result is quite satisfactory. Except for a couple of cases that we will discuss later, all the functionality has been migrated successfully. Basically, we have done a two-step task: first, replace the existing references to previous versions of Geotools with the current version (Geotools 8.0) and then replace the gvSIG projection library with Geotools.

The first step involves the replacement of existing code that uses previous versions of Geotools with new code that uses the 8.0 version. Thus, we have replaced not only old jars but also classes in the repository that were copies of the Geotools code. An example of the latter is the org.geotools.referencefork package on libTopology. These changes can be reviewed in the SVN repository [1][2]

Then, the tricky part is to replace the gvSIG projection API with the Geotools one. This can be better viewed in the following diagrams that show the before and after status. Note that the red gvSIG element stands for every place in the gvSIG code that uses projections:

Basically, we replace the following interfaces:

• IProjection (gvSIG) -> CoordinateReferenceSystem (Geotools)
• ICoordTrans (gvSIG) -> MathTransform (Geotools)

and we get rid of all the custom CRS, CRS factories and everything related with implementations since Geotools already provides us that. Also, in order
to make the change as smooth as possible, a ProjectionUtils class has been created to delegate some tasks on Geotools and perform some other tasks that were responsibility of gvSIG CRS related interfaces but don’t exist in Geotools replacements. It’s a kind of adapter from the previous gvSIG API to the new Geotools one. In some cases
this adaptation is direct and ProjectionUtils simply manages an exception (for example, the getCRS method), but in other cases it performs a bit more complicated task (for example, the transform method). In any case, it is desirable that this class will eventually disappear for a full adaptation of the gvSIG code to the Geotools API. Finally, the libJCRS and extJCRS projects are excluded from build since we don’t need them anymore. These changes can be reviewed in the SVN repository [3][4].

After all this work, we have obtained a gvSIG version that performs projections using Geotools and we have removed almost three projects (extJCRS and libJCRS completely and most of libProjection classes), so the gvSIG team has less code to mantain. However, while replacing the projection support, some functionaly has been lost. As a result, some topology processes related with referencing and the Voronoi diagram may not work properly. Also, specifying the map scale manually may not work as expected. Lastly, by excluding the extJCRS extension, the panel for projection selection has been replaced with a previous version, less intuitive. These are the main issues that have arisen, but there are more little technical details that can be reviewed in the gvSIG CE code sprint wiki [5].

Regarding the cost of the task, it is important to notice that some tasks are still to be done, as explained previously. Also, by performing these changes, it is expected that some bugs would have been introduced, so the cost we present here does not take the technical debt into account and it will not be surprising that it doubles the cost of the already done work. Having considered all that aspects, the cost of the task performed so far is around 30 hours.

Finally, it is important to consider what the future tasks should be: what remains to be done and how to do it. In our case, the first task is to identify introduced bugs with unit tests, solve them and, if possible, remove the ProjectionUtils class to have a full adaptation to the Geotools API. Then, we should introduce Geotools in the data access layer of gvSIG and get rid of the drivers/adapters system, one of the most obscure parts in gvSIG. In order to do so, we should use directly the Geotools data stores from the layer classes (FLayer, FLyrVect, …). Thus, we can transform the current gvSIG data access layer:

into a much more simple layer:

A rough test has been made in this direction and the result can be seen in the following video. We use a toolbar button to add a new layer that uses Geotools in order to read a shapefile (specified by code, just for test purposes):

gvSIG vector layer with Geotools

However, this new FlyrVect with Geotools does not have a ReadableVectorial implementation since it uses a Geotools data store directly. A solution is to remove the getSource method from FLyrVect, but then all the extensions that implement custom drivers or use the ReadableVectorial directly will be broken. Thus, the backward compatible option consists in implementing an adapter for ReadableVectorial (and every other interface that gets obsolete in the layer classes API) that delegates in Geotools directly.

Moreover, there are a few tasks that, despite not being strictly necessary, are very interesting and should be considered. First, it is also possible to replace the gvSIG implementation for rendering and symbology. The advantages of this change is that all symbology code will be replaced with Geotools. Another feasible option for Geotools integration is the query syntax. gvSIG provides several different syntaxes to query data so it could be possible to replace all these syntaxes with the Geotools implementation. Regarding the processing framework, it could be also interesting to analyze the current status of gvSIG and determine the benefits of using the Geotools framework. Finally, there are OGR data stores available in Geotools that can be used in order to get access to a great amount of formats [6].

In conclusion, we hope that the work we have done gives a better perspective of the Geotools integration in gvSIG, how it can be performed, what we can and cannot do in the next gvSIG CE code sprint in Munich [7] as well as some hints on what will be the cost of the full integration.

[1] SVN revision 701
[2] SVN revision 702
[3] SVN revision 703
[4] SVN revision 704
[5] Geotools in gvSIG CE
[6] OGR Vector Formats
[7] gvSIG CE Code Sprint in Munich