Wednesday, May 20, 2009

Exploring Stereo 3D Feature Extraction (Part 1)

Manual operator-driven 2D and 3D feature extraction techniques have in use for many years. One of the early methods of getting data into a GIS was from 2D digitization. In addition to tablet digitizing systems, softcopy photogrammetry approaches to vector data have also been available for many years.

Remember this? Click the image for details

The photogrammetric approach, also known as stereoscopic feature extraction, is one step closer to the source of the data than GIS-based digitizing. Instead of compiling feature data from an orthophoto or another source of information, stereo extraction uses the original images along with the triangulation metadata. The triangulation metadata consists of exterior orientation parameters that are required for stereo pair generation. Exterior orientation data could also come from airborne GPS/IMU data – which may be necessary for mapping remote areas where collecting ground control points is not an option.

Stereo feature extraction is inherently 3D. The vector data are measured in X, Y, and Z by manipulating a floating cursor while viewing a stereo pair of left and right images. As a result, the point, line, and polygon feature data all have Z values associated with each vertex. Because GIS developed in a 2D paradigm, many early stereo feature extraction packages were coupled with CAD environments as a platform. Basically a stereo viewer would be added for stereo image viewing and 3D measurement, and the feature data would render in the application's native “viewer”. In more recent times applications have been developed for GIS packages in addition to CAD environments, as well as a number of native applications that do not require platform technology.

Stereo Feature Extraction in PRO600

So why is this important? Data used for GIS analysis needs to come from somewhere. While there are a number of methods used for generating vector data, the demand for 3D vector data appears to be on the rise. One area of current discussion is the format and environment for generating and persisting 3D vectors. Currently the end application tends to determine the format, but this can be challenging for people trying to create one-size-fits-all data products (e.g. if I want to create a textured 3D city model, what format should I use without being locked into one system?). In this respect the development of CityGML is intriguing, as the geometric properties are but one aspect of urban information modeling and are viewed as an inter-related component of a much broader system. But persistence models aside, tools are still required for the original content generation.

More on specific 3D feature extraction tools tomorrow...

No comments: