Cartographic2 is really just a special case of Cartographic3 where height=0. I can’t think of a good reason for us needing to maintain both. For Cartesians, there’s some differences in functionality that necessitate different versions; but I can’t think of any for Cartographic.
Thoughts?
Matt
Is there need to distinguish between positions that have a height
above the ellipsoid and positions that are implicitly on the surface?
For example, it can be convenient to give a ground-based object a
lat/long but no height, and let the engine work out how best to place
it on the surface. Its actual height above the ellipsoid will vary
with position and with the level of detail of the terrain tile that it
is on. In this case, In this case, neither setting height to zero nor
continually recalculating height as the object moves or more terrain
detail is loaded feels quite right.
I'm not sure if separate Cartographic2 / Cartographic3 classes are the
best way to handle such a case. Another possibility is to use
Cartographic3s for such cases and store a "relative to surface /
relative to ellipsoid" flag somewhere, in which case Cartographic2 can
be removed.
These are just thoughts...
Regards,
Tom
Thanks Tom, I agree with you 100%. At some point I think we'll make a
HeightReference enum and make it a property on Cartographic3 (probably
once terrain comes in). I'm going to remove Cartographic2.
Perhaps I’m late to the party, but I’m on board. I’m not sure that we need a Cartographic2 type, but we should have sensible height = 0 (or “ground”) defaults for ground-focused users. The advantage of Cartographic2 is that height is never stored, which is a significant memory savings relative to the side of the entire object, and some functions can be optimized for this case; however, a height check also allows the optimization. I’m also not concerned about the memory savings since we rarely keep Cartographic2 in memory, we usually keep Cartesian3.
Patrick
Patrick, it's all done and just waiting for you to merge it.