Re: Early vs Late binding

Martin Desruisseaux <[email protected]> writes:

> The hub transformation technique (early binding) seems appealing because
> it is simpler. But it assumes that transformation from CRS A to CRS B
> can always be represented by transformation from CRS A to the hub
> (WGS84), followed by transformation from the hub to CRS B. Intuitively
> is seems an approach that should work. But actually this reasoning
> assumes that transformations from/to the hub are exact. As soon as we
> take in account that transformations from/to the hub are approximate,
> the assumption that "A to B" is equivalent to "A to hub to B" stop being
> true.

It strikes me that there are two separate problems wrapped up in the
conventional hub approach:

  one is the unavoidable accuracy issues you talk about, that would
  exist even if we used a recent ITRF as the hub

  the other is the confusion about WGS84 and the multiple versions of
  it.  While I can see that a user's label of WGS84 should be viewed as
  meaning "I have data in some WGS84 realization and I don't know
  which", that view doesn't make sense for WGS84-as-hub, where we should
  have able to label those transformation paramaters to a particular
  realization of WGS84.

My impression is that a lot (most?) of the hub trouble avoidable by late
binding is about WGS84-as-set, and probably some of it is about
transforming between e.g. different NAD83 realizations, where the
relationship between them might be known more precisely than the
NAD83/ITRF releationship.

(I get it that the late-binding appraoch avoids these problems by
searching for low-error transformations, and I am not meaning to
question the wisdom of that approach.)




Related to the larger discussion, I can see the point of defining the
longstanding WGS84 codepoint as referring to the set of WGS84
realizations (and thus not very accurate), as I hear has been decided in
the larger world.  Once that decision has been made, however, it seems
that

  each WGS84 realization should have a separate codepoint

  all use of the codepoint referring to the set should be strongly
  discouraged, in favor of figuring out what people really mean and
  saying that instead

  any protocol which has the set-style WGS84 codepoint hardcoded in it
  needs to be fixed to carry a datum codepoint along with the protocol.
  Or if that's not possible, to specify that it means the latest ITRF or
  the latest available WGS84 realization.

In the protocol case, people with fuzzy data will still get fuzzy
results, but with protocols defined with non-fuzzy datums, then
non-fuzzy data should be handeld accurately.

Is that how others see this?
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj