While our earlier response dealt with the origin aspect of your recent question, one of our engineers offers this analysis on the conversion aspect.
Here's a simple test to confirm the most basic functionality of the API's geodetic coordination transform routines.
The environment's definition file includes the origin of ANVEL's local Cartesian world frame under the "location" tag. For Eastern Mountains, this looks like:
<location elevation="0" latitude="33.333300000000001" longitude="44.433329999999998" type="latlong" utcOffset="3"/>.
The same data are also shown, albeit with reduced precision, in the Properties pane of the Config panel under Environment. These can be used as well but result in more position error.
With Eastern Mountains loaded in the connected ANVEL instance, converting this geodetic position into the ANVEL local coordinates should produce the origin:
In: origGeo = LatLonAlt(lat=33.333300000000001 * pi / 180, lon=44.433329999999998 * pi / 180, alt=0)
Out: Point3(y=3.578986409256757e-12, x=6.585122997589916e-10, z=-5.441591367249506e-12)
which is the origin (to sub-nanometer accuracy).
The reverse transform should also work:
In: origGeo = anv.ConvertPointToWGS84(Point3(0, 0, 0))
In: origGeo.lat * 180 / pi
In: origGeo.lon * 180 / pi
which is the expected geodetic position.
Any conversions that are unable to round-trip the origin and produce the expected results are doing something other than a pure transformation between the two coordinate frames.
ANVEL Support Team