Core Development
What is Core Development?
Core development adds new features to the open source projects we participate in: GeoServer, OpenLayers, GeoExt and PostGIS.
We have prepared “road maps” of features and activities we consider important to the continued growth and maturity of the projects.
OpenGeo offers reduced rates for programming of items in the core development road maps.
A common question we get is “will this feature be in the next release?”
The only way to ensure a feature is added on a particular schedule or before a particular release is to fund the development of that feature.
Tell us what road map feature you are interested in, and how much funding you can put behind it.
We will combine your support with others until there is enough backing to complete the feature. For more information see the FAQ.
GeoServer
GeoServer always tries to stay up on the latest standards, but no one has yet funded WMS 1.3. Most of the needed infrastructure is already in place, as it was required for WFS 1.1. But the bindings need to be built and it must pass the CITE compliance tests.
Currently features are only accessible via the Web Feature Service (WFS) API. REST feature access will provide a ”resource oriented“ approach to accessing geographic collections. It will also use the existing AtomPub specification to provide for feature viewing and editing.
GeoExt
Many applications will need to allow users to logon to a remote server, be it for remote administration, editing of data, or controlled view access. GeoExt should have a default manager for logging on, with different options for the backend login mechanism and desired front-end gui dialog.
Versioned Editing Toolbar and Components
There have been several applications making use of the WFS-V 'versioning' protocol of GeoServer, to do operations like History, Diff and Rollback in addition to the standard editing. These should have default components in GeoExt so people can easily add rich versioning capabilities to their applications
GeoWebCache
Several improvements to GeoWebCache could be done to better support clustering for reliability and scalability. While traditional clustering techniques work there are several unique aspects of geospatial cache clustering which can be optimized for directly in the GeoWebCache codebase.
Respond to arbitrary zoom levels (WMS through tile recombination)
The main limitation of a cache like GeoWebCache is that it can only respond to requests at set zoom levels. A more intelligent cache, however, could properly recombine the raster tiles it knows about and sub-sample it up or down to the requested zoom level. In this way it could serve most any WMS request, instead of being limited by the pre-set cache.
OpenLayers
CQL is a terse language for writing data filters. This item will allow users to flip between a GUI view of the filter and a text view of the filter in CQL, and edit either one.
Shared Polygon Boundary Edit Tool
Polygon collections that form a “coverage” are a common form of GIS data. This tool will allow users to edit the locations of boundaries that are shared by two or more polygons.
PostGIS
Tracking collections of moving objects, querying the historical data for relationships, and maintaining alarms when objects enter/leave areas is now a very common use case. The objects might be trucks, planes, boats, people, and so on. A standard data model, support functions, and API for efficient handling of this case would be helpful.
A POINTPATCH type, and associated index and functions, for handling the management of multi-terrabyte collections of LIDAR point data.