I'm having some difficulty with a new tool I'm working on that will hopefully be
released publicly as soon as I can nail this bit down.
Essentially, I'm working on a method to enable deformation of VPB heightfield terrain
during load/save operations (though not dynamically at scenegraph runtime). It would allow
for a variety of tools to hook into the deformation pipeline either while VPB is saving or
OSG is loading a VPB-built scenegraph.
Currently it can easily do "uniform" elevation alterations like clipping/clamping,
scaling, adding/subtracting and find/replacing. However, to be really useful it needs a
way to tell the deformation evaluator where on the Earth the elevation sample in question
is, to permit non-uniform deformations like roads and building sites.
I had originally planned to do this operation directly in VPB, where access to
geospatial coordinates is a bit simpler, but Robert convinced me to do it on the VPB-built
scenegraph via a pseudo-loader/saver that invokes a real/loader/saver while modifying the
scenegraph as it goes through the pipeline.
My coordinate system of choice for communicating the position of the vertex being
deformed is geographic WGS84 lat/lon, since it can be expressed with an X/Y pair of
doubles and works anywhere in the world without needing to know a zone or anything.
This is working fine, but it's difficult for me to reliably recover the WGS84 geographic
coordinates from the VPB-built tiles. Let's imagine we're loading a tile and modifying it
on the fly.
Once an osgTerrain::TerrainTile is loaded, we can find the osgTerrain::Locator within it
as well as an osgTerrain::HeightFieldLayer. The HeightFieldLayer refers to the Locator.
The Locator typically specifies a WKT CoordinateSystem. In this case, my tile IS WGS84
geographic, but I believe different kinds of tiles (built with different VPB options)
could well be different.
Here's my Locator as seen in the .osg file for this tile:
CoordinateSystem "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS
0.000349040550368496 0 0 0
0 0.000349073839882141 0 0
0 0 1 0
0.45727627733832 0.53232542185827 0 1
Notice "CoordinateSystemType GEOCENTRIC". In my GIS-mindset, geocentric means something
like ECEF coordinates http://en.wikipedia.org/wiki/ECEF
and anything using latitude and
longitude is GeoGRAPHIC coordinates.
The HeightFieldLayer contains an origin and interval which can be combined to determine
the coordinates of any vertex in the heightfield. For example, mine are
Origin 26.2000007629395 30.5 0
To me, those are GeoGRAPHIC, not GeoCENTRIC. But it may be a distinction of terminology.
Now, in my own personal case, this is exactly what I need -- they already appear to be
WGS84 lat/lon and I can go about my business without converting them. But I believe in
some cases, they will need conversion so I want to make sure I can handle that case before
I contribute this code.
I thought that perhaps Locator::convertLocalToModel and convertModelToLocal would be the
thing, but those seem to be for converting between Local coordinates, which range 0...1
across the heightfield (and its associated image layer).
So at the end of the day, I'm trying to come up with a standard set of steps to take
coordinates derived from the Origin and Interval members of the heightfield and get
something that I know will be geographic latitude and longitude, no matter how the dataset
was built by VPB. I know I can use EllipsoidModel's convertLatLongHeightToXYZ and
convertXYZToLatLongHeight to go back and forth between XYZ and Lat/Lon/Elev, no problem.
What I don't know is how to uniformly interpret the values in the heightfield with the
provided Locator in order to always come up with Lat/Lon/Elev (or XYZ to convert to LLA).
I figured it would have to be a method on the Locator, since the Locator is the object
that has and understands the CoordinateSystemType, but
convertLocalToModel/convertModelToLocal (and the combined convertLocalCoordBetween) don't
seem to be the answer.
Enlightenment welcomed. I think folks will really find this code useful once it's robust
enough to release. Attached is a small piece of typical data (very boring terrain in the
middle of a desert) built as .osg format by VPB.
Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
"There is no Truth. There is only Perception. To Perceive is to Exist." - Xen
Post generated by Mail2Forum