GvSIG CE community
From gvSIG CE Wiki
2012: gvSIG CE Code Sprint in Munich, Germany. Planned for Autumn 2012.
2013: gvSIG CE Code Sprint in Berlin, Germany. Planned for Autumn 2013.
This space is for documenting plans for new features and improvements to existing ones. Please use with consideration. The Users List are a better place for long discussions of initial ideas, wishes and feature requests. This Wiki is for documenting things that have been reasonably well thought through and are realistic to implement. Of course, you can always post to the Mailing Lists to initiate a brain storming. If there are things that you would like to see changed or added to gvSIG CE, the Users List is the place to talk about it. The best way to REALLY add them to gvSIG CE is to supply a patch ;-)
You can use the "History" button on each page to track changes to its content.
In this category, we list features related to layer styling, map symbols, labeling and layout (including export formats).
Classification of current (04/04/2013) Bugs
We are trying in this page to identify which bugs related to the category Map layout and publication are more important and should be worked first. If you apply a Filter by this Category on the bug tracker you will find more tickets as the ones listed below. Those tickets related to labeling, annotations or symbology are not listed here as we want to list on this page only the tickets that we should work to improve the layout in gvSIG CE. If you like to contribute with us, edit this page or those tickets that you consider more important. We made a first classification ordered by Priority (high-normal-low):
- 0000368: gvSIG CE crashes when moving objects of the Layout
- 0000288: Scale in view and map document
- 0000238: Legend items cannot be defined correctly
- 0000151: Problems with legend generated from layers that have hidden features
- 0000142: Map layout window grays out when inserting a View (Windows only)
- 0000390: Reference (coordinate) grid
- 0000388: Loading gvt fails
- 0000377: Add cartographic decorations
- 0000328: Quick print-out triggers bogus "Formato no soportado"
- 0000313: Different colour representaion in pdf-output
- 0000312: Legend information changes after cancelling the legend menu
- 0000289: No arrow decoration in print layout
- 0000263: Map Layout: Page setup is not saved
- 0000257: *gvt cannot be loaded
- 0000249: Update iText PDF library
- 0000242: Labels not correctly rendered in PDF output
- 0000241: Zooming does not work correctly
- 0000240: Extent changes in layout
- 0000239: Default values will be displayed
- 0000237: Error when opening template (*gvt)
- 0000213: suggestion for improvement: legendsize
- 0000191: Allow user to add SEXTANTE diagrams to a map layout
- 0000168: Cancelling legend "Format" window -> Null pointer error on move or resize
- 0000157: Raster layers displaced on PDF export
- 0000367: Undo Button in Layout isn't a good one
- 0000318: Show yes-no dialogue before exporting to pdf
- 0000317: Show save dialogue before closing template
Tickets that need more testing:
Add SVG export to layout tool
- Adding the possibility for exporting map layouts into svg-format(scalable vector graphics) could be useful for layouting maps in other applications such as Inkscape.
- Which classes are currently used by gvSIG to export PS/PDF? Do they support SVG or would the latter at least be easy to add?
- SVG output should render View content as vectorial objects, not rasterized, as the current PDF export does.
- Take a look at Kosmo GIS. It does export to OpenOffice Drawings. Could this be used as a starting point?
Although analytical modules should be implemented in SEXTANTE, we can still discuss them here first. Heavily interactive modules may be better placed in a gvSIG toolbox than in SEXTANTE.
Interactive variogram analysis (geostatistics)
Support for Kriging is currently implemented in SEXTANTE, as well as SAGA (more flexible, available via SEXTANTE).
However, it is impossible to find optimal Kriging parameters (nugget, sill and range), unless there are some interactive, exploratory tools that allow the user to produce variograms and analyse them to understand the structure of the input data.
The proposition is to build an interactive tool in gvSIG that allows the user to produce (semi-)variograms from raster datasets, and explore them interactively to find the best Kriging parameters. The actual Kriging would then be done by the corresponding SEXTANTE/SAGA module. Some R modules could be used to produce further exploratory tools (QPlots, etc.).
- An older article published in Computers & Geosciences contains descriptions and source code for Java variogram widgets. It may be possible to build on this. However, the copyright situation needs clarification: B.R. Faulkner, Java classes for nonprocedural variogram modeling, Computers & Geosciences 28 (2002) 387–397.
- It is also possible to find (good) Kriging parameters by a computational procedure, which is also included in the software above.
- Take a look at VarioWin and its "Model" software. This gives a good impression of important non-interactive and interactive procedures.
- R implements all the non-interactive things.
- Also take a look at SGeMS
Data analysis interface
Having an homogeneous interface for all spatial data analysis extensions is a must to improve the gvSIG CE interface. Eventually, all data processing features should be accessed from SEXTANTE. This is a list of steps to take to accomplish this:
- Modify the SEXTANTE toolbox so it can include external commands (to be able to call any gvSIG element from it)
- Incorporate in the toolbox those functions that are hard or impossible to implement as SEXTANTE algorithms.The following is a list of such features:
- TODO: write list
- Implement those features currently not available in SEXTANTE but that can be implemented as SEXTANTE algorithms. The following is a list of such features:
- TODO: write list
Rearranging raster functions
- Select Raster Layer
- Regions of interest
- Image profile
- Colour table: move into Properties windows (gvSIG Raster layer > Raster properties)
- Create overviews
- Analysis view
- Raster properties
- Classification: move into SEXTANTE toolbox
- Mosaic: move into SEXTANTE toolbox
- Transformations: move into SEXTANTE toolbox
- Vectorization: move into SEXTANTE toolbox
- Filters: move into Properties windows (gvSIG Raster layer > Raster properties)
- Radiometric enhancement: move into Properties windows (gvSIG Raster layer > Raster properties)
- Image fusion: move into SEXTANTE toolbox
- Georeferencing: new menu entry in "Tools" (done in OADE 2010)
- Free Transformations
- Reprojection: remove in gvSIG
- Grab from view: move into Properties windows (gvSIG Raster layer > Raster properties) ?
- Save as: move into Properties windows (gvSIG Raster layer > Raster properties) ?
- Clipping: move into Properties windows (gvSIG Raster layer > Raster properties) ?
More processing functions which are not in the Sextante Toolbox
- Derivative Geometries
- Add Geometry Info
Redesigning the project manager
Here we'll make a summary of this topic (http://gvsigce.sourceforge.net/forums/viewtopic.php?f=10&t=13) Some suggestions to redesigning the project manager:
- Project manager with a tree of elements (views, layouts, data), where you can browse and also execute actions on elements (for instance, opening with a double click). In the case of views, an element representing a view could be expanded to see the layers it contains, and actions such as copying layer from one view to another could be performed from the manager.
- Add main menu entries like "Add View", "Add Map", "Add Table", to directly create these items.
- Add a view to a new project by default.
- Add a separate window for managing existing items (create, rename, remove, properties).
- Put the session settings somewhere entirely else.
- Provide a drop-down list of open Views, Maps, etc., so the user can navigate through them with a single click. Maybe the status bar could be used for this. Most of the space on it is currently unused.
- A way to create new views and layouts and to switch between them that's faster than going through a project manager.
- Data manager in Project Manager: http://osgeo-org.1803224.n2.nabble.com/PROPOSED-FUNCTIONALITY-Data-Manager-in-Project-Manager-td6654938.html
There is an ongoing effort to analyse the possibilities to Integration of Geotools.
gvSIG CE Enterprise
An "enterprise level" GIS should include some outstanding capabilities that make it fit for use in large workgroups and critical production environments. This section lists some capabilities (already present or required) that make gvSIG CE an "enterprise solution". Please add your thoughts on what features should be advertised, extended or created for use in large institutions and critical environments.
The Java technology that gvSIG uses gives it very strong fundamentals.We already have full 64 bit support. Resources (RAM, CPU cores can be monitored in the status bar), a "free RAM" action can be triggered via a double-click into the status bar.
Ease of use
Contrary to common belief, a steep learning curve is a good thing, as long as it is also smooth. End user documentation and consistency within the GUI are two important things that need to be addressed; as are general GUI usability improvements. A review of all GUI windows/dialogs for consistency is a long outstanding task. The bug tracker contains all necessary tickets.
We urgently need better support for locating and reloading project files that were opened in previous sessions. Also required would be a versioning system for .gvp files (at least more than just one level of backup).
We are (almost) "ready to go enterprise" when it comes to extreme processing, i.e. processing of very large input datasets. We have PostGIS, GRASS and SAGA, and gvSIG itself is not bad at all when it comes to handling very large layers. One important task here would be 64 bit binaries and GRASS 7 support (once GRASS 7 becomes available).
Automated data processing
We are very well set up here: SEXTANTE offers batch processing, iterative processing, scripting, a CLI and a graphical modeller. In addition, there is Jython and GRASS scripting (Bourne Shell). All it takes is some better documentation of these programming interfaces and some sample code/tutorials.
Quality assurance and team work
Enterprise level functionality includes things for data quality assurance, validation and collaborative editing. There is very little in this area that does not at least exist in rudimentary form in gvSIG CE.
Topology checking and cleaning
We have the Topology Extension which is 99% working and v.clean (via GRASS). All it takes is a little bit of clean-up work for the Topology Extension!
High quality data publication
Among all open source GIS, gvSIG CE offers the most flexible map layout capabilities. However, there is still a lot of room for improvement. Fix all the bugs in the Map layout extension; add SVG output; improve/fix advanced labelling capabilities; improve KML support.
Collaborative vector editing
Obviously, this is not possible for file-based GIS projects. But PostGIS layers should allow true collaborative editing. This functionality could be modelled on the "pgVersion" plug-in for QGIS (http://www.kappasys.ch/cms/index.php?id=23&L=5).
With its highly modular architecture, gvSIG CE is very strong in the area of customization and can be tailored to fit almost any work environment's needs.
It is very important that we translate all Spanish comments in the Java sources to English and make available full online documentation of the API. Another important task is to remove all redundant code and make the GeoTools integration happen!
In a complex working environment (spatial data infrastructure), gvSIG CE must play nicely with other components. We have already come a very long way in this area (cross-platform support is awesome!), but there is room for improvement.
OGC compliance(!): We need to update WMS and WFS support! A lot of servers nowadays use WMS-T (for whatever reason).
Geodata file formats
We have added further OGR format providers to gvSIG CE (the same way we did for SQLite): MapInfo, IDRISI, ... (others?). One of the most useful is the new (read-only) support for ESRI File Geodatabases.
We should check whether the current GUI is good/clear enough for heavy use of database connections. Some suggestions: Better handling of large tables and better table editing behaviour; save/restore settings for database connections; etc.
Relational data models
There is already some rudimentary functionality for linking tables, and gvSIG can include non-spatial tables in a project. These are good fundamentals, but we need to add persistent storage of 1:n and m:n table relations to gvSIG projects. We also need to provide the GUI tools (forms) necessary to handle data input into complex relations (look-up lists, subforms, polymorphic tables, ...).
Long-term maintenance is a critical aspect wo which we haven't paid too much attention. However, corporate users often stress that they do not trust open source projects, because they might disappear any day. So we should think how to improve our base in this area. Maybe that could even include things like subscription models for bug fixing, so that we can have a more steady funding stream.
Expose all XML program settings as environment variables, so that default settings can easily be deployed:
We don't have an updated mechanism that works from within gvSIG CE.
Helpdesk & Support
Professional support is key. We have the usual Wiki, mailing lists, etc. but lack a directory of paid-for providers of technical support and training. We should also have a list of reference customers.
Legal certainty and trust
Issues of legal certainty and trust are far more central in a corporate environment with many users. As open source software, gvSIG CE has perfect fundamentals here, but only if we do not repeat the mistakes of the original gvSIG and make sure to get rid of anything that could raise doubt about issues such as licenses or patents, or free commercial use.
We must scrutinize the current distribution of gvSIG CE for any 3rd party components that may be more limiting than the base GPL license -- and remove them. In particular, we need to deal with proprietary drivers and file formats. All licensing must be 100% clear and transparent for the user.
Since the takeover of SUN's Java technology, there has been a lot of uncertainty about the future of (free) Java and the different proprietary JDKs. Apples move to drop Java support has done nothing to make the situation better. We need to switch to a unified OpenJDK as soon as stable builds become available.
OSGeo membership is a huge source of trust for corporate investment. We should apply for OSGeo incubation as soone as we have cleaned up our codebase. An important task would be GeoTools integration which would allow us to chuck out a lot of dubious code.
We must support encrypted protocols wherever possible (e.g. database connections, web services) and allow encryption and password protection of project files.
User authentication and encryption
It should be possible to use encrypted layer data and to provide safe, encrypted storage ("vault" or "keychain") for connection (DBMS and Web services) credentials. This must be handled on the application-level. Once logged into the application, users would have access to there personal keychain, e.g. for authentication agains different Web services. There are many aspects to this: master passwords, crypto keys vs. passwords, password quality constraints, encryption strength & in-memory encryption, granular access control... A lot of GUI tools would also have to be developed. Perhaps there are Java frameworks that could be used. For instance something like Apache Shiro or something from this list