|
http://www.coin3d.org/ http://www.kongsberg.com/kogt/ |
The SoGeoOrigin class is used to specify an absolute geographic location against which geometry is referenced.FILE FORMAT/DEFAULTS: More...
#include <Inventor/nodes/SoGeoOrigin.h>
Public Member Functions | |
| SoGeoOrigin (void) | |
| virtual void | doAction (SoAction *action) |
| virtual void | callback (SoCallbackAction *action) |
| virtual void | GLRender (SoGLRenderAction *action) |
| virtual void | getBoundingBox (SoGetBoundingBoxAction *action) |
| virtual void | getMatrix (SoGetMatrixAction *action) |
| virtual void | pick (SoPickAction *action) |
| virtual void | getPrimitiveCount (SoGetPrimitiveCountAction *action) |
Static Public Member Functions | |
| static void | initClass (void) |
| Sets up initialization for data common to all instances of this class, like submitting necessary information to the Coin type system. | |
Public Attributes | |
| SoSFVec3d | geoCoords |
| SoMFString | geoSystem |
Protected Member Functions | |
| virtual | ~SoGeoOrigin () |
The SoGeoOrigin class is used to specify an absolute geographic location against which geometry is referenced.
FILE FORMAT/DEFAULTS:
A common problem when dealing with geographic data is the reduced floating point precision you often get. UTM coordinates are often in the 10^5 a 10^6 magnitude, and this leaves very little precision for details at that position.
The SoGeo nodes are therefore useful when you want to keep your data in its original system, but still get good floating point precision when rendering.
Coin needs a local Cartesian coordinate system when rendering. When a SoGeoOrigin node is used, Coin will create a coordinate system at the SoGeoOrigin position, and all geometry (and the camera) in the scene graph will be projected into that coordinate system.
The coordinate system will always have the Z axis point up from the ground. The Y axis will point towards the north pole, and the X-axis is found using the right hand rule.
A scene graph should only contain one GeoOrigin node, and all geometry in the scene graph will, as stated earlier, be rendered relative to this position. This means that the precision will be best if the GeoOrigin position is as close to actual camera position as possible. If you move around on a large area, it might therefore be a good idea too actually move the GeoOrigin postition instead of the camera.
To place geometry in the scene graph, you can either use an SoGeoSeparator node or an SoGeoCoordinate node. When using a GeoSeparator node, all geometry inside that separator will be rendered relative to its geo-system position and orientation, and you then use regular shapes and regular SoCoordinate3 nodes to specify data (the points in an SoCoordinate3 must be adjusted to be relative to the GeoSeparator position).
The SoGeoCoordinate node on the other hand can contain double precision geo-coordinates, and that node will internally recalculate the double precison array to a single precision array which is relative to the SoGeoOrgin node.
One note regarding UTM projections: Since it's quite common to assume a flat earth when working with UTM data, it's possible to supply a "FLAT" keyword for UTM coordinate systems:
Example scene graph:
GeoOrigin { geoSystem "GD" geoCoords 40.77 -73.97 0 }
GeoSeparator {
# New York, NY
geoSystem "GD"
geoCoords 40.67 -73.94 0
BaseColor { rgb 0 1 0 }
Cube { width 25000 height 25000 depth 25000 }
Translation { translation 0 0 30000 }
Text2 { string "New York" }
}
GeoSeparator {
# Los Angeles, CA
geoSystem "GD"
geoCoords 34.11 -118.4 0
BaseColor { rgb 1 0 0 }
Cube { width 25000 height 25000 depth 25000 }
Translation { translation 0 0 30000 }
Text2 { string "Los Angeles" }
}
GeoSeparator {
# Washington, DC
geoSystem [ "UTM", "Z17" ]
geoCoords 846889 4313850 0
BaseColor { rgb 0 1 1 }
Cube { width 25000 height 25000 depth 25000 }
Translation { translation 0 0 30000 }
Text2 { string "Washington" }
}
# add a small geogrid
GeoCoordinate {
geoSystem "GD"
point [
32 -120 0,
32 -110 0,
32 -100 0,
32 -90 0,
32 -80 0,
32 -70 0,
34 -120 0,
34 -110 0,
34 -100 0,
34 -90 0,
34 -80 0,
34 -70 0,
36 -120 0,
36 -110 0,
36 -100 0,
36 -90 0,
36 -80 0,
36 -70 0,
38 -120 0,
38 -110 0,
38 -100 0,
38 -90 0,
38 -80 0,
38 -70 0,
40 -120 0,
40 -110 0,
40 -100 0,
40 -90 0,
40 -80 0,
40 -70 0
42 -120 0,
42 -110 0,
42 -100 0,
42 -90 0,
42 -80 0,
42 -70 0
]
}
DrawStyle { style LINES }
BaseColor {}
ShapeHints { vertexOrdering COUNTERCLOCKWISE }
QuadMesh { verticesPerRow 6 verticesPerColumn 6 }
| SoGeoOrigin::SoGeoOrigin | ( | void | ) |
Constructor.
| SoGeoOrigin::~SoGeoOrigin | ( | ) | [protected, virtual] |
Destructor.
Used for specifying the geographic coordinates. For the GD system this should be <latitude> <longitude> <elevation>. For UTM it is <easting> <northing> <elevation>, and for GC it is simply <x> <y> <z>.
Used to specify a spatial reference frame. Coin currently supports three different systems. Support for more systems might be added in the future.
The "GD" and "UTM" systems can, for future support, have an ellipsoid specification. The default is "WE" which is the WGS84 ellipsoid, the only ellipsoid currently supported in Coin.
Copyright © by Kongsberg Oil & Gas Technologies. All rights reserved.
Generated on Mon Sep 6 20:01:48 2010 for Coin by Doxygen 1.6.3.