UDig Roadmap

uDig 2 Series Roadmap

uDig 2 Series is devoted to finding the project a home (with LocationTech) and gradually factoring the project into component parts for use by Eclipse RCP developers.

For our desktop users there is a lot more functionality available within easy reach:

• The uDig SDK provides developers with additional features (graph analysis, geocoder search etc...) beyond that available in the desktop application.
• The other great source of functionality is the additional RnD work that is happening at the library level (geopackage, additional raster formats, a host rendering improvements).

Making this functionality available for our Desktop users, and our SDK developers, is a great technical direction.

We also look forward to collaboration with fellow LocationTech projects as they complete incubation. This is especially important as GeoCoding technologies are developed, as this is a roadblock for those seeking to bridge between their business data and a good mapping solution.

By the end of the uDig 2 Series we want to nail our reuse story for RCP developers, and earnestly collect tools and processes for our Desktop users.

uDig 2.0 Milestone 1

Incubation Progress:

- Transition to LocationTech github - Packages changed to org.locationtech.udig

Technology Progress:

- Upgrade to GeoTools 11 series - Installer download of prepackaged JRE

Stretch goal:

- Upgrade to Eclipse 3.8 (to avoid issues on OSX)

Note: This is a milestone target, pre-packaged download will be from refractions.net as we will not of completed parallel IP process yet.

uDig 2.0 Release

Incubation Progress:

- Submission of all dependencies for IP review

Technology progress:

- n/a

Stretch goal:

- Reduce code to minimum in active use - Upgrade to Eclipse 4.x for a new look and feel (given community interest)

uDig 3 Series

What does the future of uDig look like beyond 2.0? The uDig Platform has a strong integration story, and is fully capable of integration with other toolkits and rendering chains beyond our core use of GeoTools. We would like to take advantage of this independence and take a role similar to OpenLayers for web mapping, acting as a single "clearing house" framework allowing teams to leverage spatial data using their choice of spatial toolkit, scripting language, and even geometry representation.

Toolkit Independence

The uDig architecture makes heavy use of the Eclipse IAdaptable approach to problem solving. This allows the core framework to remain stable, while gradually being taught (through plugins) how to work with additional GeoSpatial toolkits.

GeoTools Example (available in uDig 2 series):

if( resolve.canResolve( FeatureSource.class ) ){
    FeatureSource source = resolve.resolve( FeatureSource.class, progressMonitor );
    FeatureCollection features = source.getFeatures();
    ...
}

Because we know we are working with external resources, the uDig IResolve class makes use of a progress monitor to track any work involved in establishing an initial connection.

This is the same example adapted for the light-weight Jeo project:

if( resolve.canResolve( VectorDataset.class ) ){
    VectorDataset dataset = resolve.resolve( VectorDataset.class, progressMonitor );
    Cursor<Feature> features = dataset.cursor( new Query() );
    ...
}

uDig offers similar independence with respect to its rendering engine, out of the box support for the GeoTools rendering engine is available. Our business customers already write custom renderers to directly draw their business objects smoothly and efficiently.

Road Map FAQ

Q: When will uDig upgrade from Eclipse 3.7

There is strong community demand to upgrade to Eclipse 4.

The development team is occupied with the transition to LocationTech, if you know any other developers interested in this work we would be pleased to work with them.

Q: When are you going to have a release?

We are in position to issue a milestone release at any time, based on community demand/interest.

Our next official release will depend on the Eclipse Foundation IP process which is currently underway.

Q: When are you going to support Curve (or GML3, or Geography)?

We are dependent on the JTS project getting funding, with a technical direction to take on these data structures (and more importantly the math behind them).

Recently the Spatial4J project has joined LocationTech offering us an implementation of Geography (i.e. geometry on the surface of a sphere). Technically the GeoTools library can be taught how to make use of Spatial4J (rather than JTS) but this integration effort remains unfunded.

If you are interested several projects have been able to produce the appropriate data structures, but as a GIS application we have not been interested until they are backed up by math (allowing their use for analysis).

• http://sourceforge.net/p/jts-topo-suite/code/HEAD/tree/trunk/
• https://github.com/spatial4j/spatial4j
• https://github.com/geotools/geotools/tree/master/modules/unsupported/geometry (port of JTS to ISO1907 data structures)
• https://github.com/geotools/geotools/tree/master/spike/geometry (mash up of deegree GML data structure only approach)

Technical details: JTS is an implementation of Simple Features for SQL data structures (Point, Line, Polygon). ISO19107 offers a richer set of data structures (Point, Curve, Surface, Volume) that is used by GML3. Implementing the data structures is reasonably straightforward, supplying the math to support operations requires dedication and funding.

Q: Are you going to have a 3D map?

A: Teams have added a 3D map to uDig before, and our ViewportModel can be used to drive a 3D canvas if you would like to implement one. If you check the email archives you can find that previous teams have been successful (but were unable to donate their work back to the project due to licensing restrictions).

Q: Can I read GML files?

We previously implemented this functionality, but it was withdrawn due to user-list frustration over how GML works. GML is really a choose-your-own-file-format adventure kit, where your choices are represented by a schema file making use of GML concepts and definitions.

The good news is that a "two pass" solution is now available (scanning the file once to build up a pretend schema) and then a second time to import the data.

Q: Do you support WCS?

No. The WCS specification is not complete from the perspective of a client. Based on the information available in the GetCapabilities and DescribeCoverage documents you are not able to safely construct a GetCoverage request.

How is this being used by other projects? I can only assume that the end-user is being asked, and thus is responsible for making some assumptions about the data being accessed.

This situation has improved for WCS 2.0, making it the first WCS standard that we could recommend for implementation.