3D data support

From gvSIG CE Wiki

Jump to: navigation, search

We will try to avoid the problems that other GIS are facing with their 3D integration, specifically:

  • Identify actual 3D use cases.
  • Do not make OpenGL mandatory (problem: 32 bit coordinate format, trouble with drivers).
  • Do not try to emulate Google Earth; provide high-precision, accurate 3D at all scale levels.
  • Avoid using a disparate 3D View with limited functionality.
  • Avoid special 3D data formats.
  • Find ways to make majority of GIS tools available for 3D data.

Below are some ideas for seamless integration of functionality for 3D data, as well as an implementation plan that links development tasks (in the order in which they have to be completed) with tickets in the bug tracker.

Contents

Implementation Plan

This section tracks our implementation progress. It lists the URLs of tracker tickets that relate to 3D development work. Tickets are listed in the order in which they have to be completed. Once a task is done, it is marked "[DONE]" in the text (and the corresponding tracker ticket(s) will be closed, of course).

Basic Z Data Support for Vector Layers

These tasks need to be completed to allow users to add Z coordinates and create 3D vector layers.

Support 3D User Coordinate Systems (UCS) in Views

This would be a feature similar to common CAD approaches. Essentially, it tricks a regular 2D View into showing 3D coordinates.

This concept will allow to use regular 2D Views and GIS tools for 3D data that represents cross sections. Essentially, the idea is that current Views are aligned with the X-Y plane of the coordinate system, but in theory they could be aligned to any user-defined plane. In this way, we can treat 2D data as pseudo 3D.

The user would define a UCS, then load 2D data and the coordinate display of the View would switch to a 3D display and the UCS coordinates under the cursor would be displayed.

There are several ways in which a UCS could be defined:

  1. Define plane by three 3D points.
  2. Define by rotation around a 3D axis (the latter defined by two 3D points).
  3. Define by rotation around W(orld)CS ax(e/i)s.

The advantages are:

  1. We can keep using regular 2D Views.
  2. 2D topology and other 2D assumptions remain intact.
  3. Regular 2D GIS tools can be used to process pseudo 3D data.

The problems are:

  1. Handling real 3D data in a View with a UCS means reprojecting that data to the UCS.
  2. CAD editor needs to be able to place Z data on the the UCS of the layer.

Open questions:

  1. How to handle georeferencing of raster data against a UCS (maybe we could add UCS info to the RMF).
  2. Save UCS transformation info in datasets or project file?
  3. Should we allow to specify a UCS transformation when loading data?
  4. Multi-view feature supports: How can we make it possible to use one attribute table record attached to several geometries in several Views?

Raster layers with depth

We could interpret the bands of a raster layer as depth slices.

To make this really useful, we would need:

  1. A way to specify the Z range of the raster (from this we can infer the thickness of each "slice"). Options would be: save to RMF (will only work with file layers), save to project file (means that Z range might get lost easily), use last band as a "magic band" that does not contain actual geodata, but somehow (efficiently) encodes the Z range (this band could be queried on loading and discarded afterwards).
  2. GUI support:
    1. Slider to change the current depth
    2. TOC legend that shows depth information.
    3. Tool for producing 2D slices (cross-sections) through depths bands/slices.

(Look into ImageJ to see how this could translate to the concept of image stacks used there!)

Problem:

  1. How to harmonize this idea with a UCS?

VTK support

Add VTK export for raster and vector layers. Multi-band rasters or groups as rasters can be exported as VTK voxels.

There is an official Java wrapper for VTK: http://www.vtk.org/Wiki/VTK/Java_Wrapping

3D processing tools

Clearly, some specific tools would also be required:

  • Planarizing all polygons in a layer, so that their Z coordinates fall onto the same 3D plane: This is a prerequisite for upholding clean topology in 3D polygon sets.
  • Transforming from 2D+UCS to real 3D coordinates (and vice versa).
  • Adding and dropping Z data.
  • Using Z data in the (SEXTANTE) field calculator.

Some suggested processing tools have already been fleshed out: