We are using various capturing techniques for 2D and 3D photogrammetry feature extraction from the time of analytical systems. In addition to tablet digitizing systems, softcopy photogrammetry feature extraction approaches to vector data have also been available for many years.
The photogrammetric approach, also known as photogrammetry 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. Photogrammetry 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.
The photogrammetry 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 photogrammetry 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.
Data used for GIS analysis needs to come from somewhere. While there are a number of methods used for generating photogrammetry vector data, the demand for photogrammetry 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.
Posts
