[Proj] The problem with proj.4

[support.mn at elisanet.fi]

Hello people,

Frank,

my main concern is that if there is any possible path that some
particular map reference can take, there should be a method
to fully describe it in proj.n (or whatever), if that is to be
"the system" to be used. We already heavily use the end
product adjustment possibility where we shift, scale and
rotate the resulting map. And we don't like, that we have to use
i so much. The definition should be so strong that when it is once
fully accurate it should take car of most adjustments. And it
also sometimes does it, thanks!

Why?

One have to remember that this end adjustment is only locally
defined for any single particular map. So we keep always telling
to the end users to define their maps correctly in the first place
and in the second place adjust them locally. But if one cannot
define that accurately since the definition language is missing
some parameters!?? What then... caos?

So fuzzy calculations are not acceptable. There have
to be a way to define the calculations clearly in a standardised
way. Nobody wants to enter all the formulas, so a description
languge like proj.4 (or similar) is needed. There is enough
fuzzyness in the end user local adjustments. We have to keep
it clean and precise at the definition level.

> "ellps", "R",
> a, b, rf and f.  Will we have to introduce "p" and "d" versions of all
> these?

Yes, I see no other way around? Do you see? And not only that.
The program should not do too many assumptions. It is better
to give an error message than take some fuzzy action that maybe
yields more problems later.

> Also, how often will we actually use them?

I am sure that people will use them more when they can use them.
Now it is just more or less hoping that everything would fit, but
nobody is not sure, since the calculation path is not in full control of
the definition language. And that really should!

We are not using proj.n because we cannot write such a library our
self (given enough time). The reason is that we need a precise and
standardised definition language. What is the library that executes
those descriptions is a different story. It is the same story as with
any computer programming languages. Nobody cares what target
computer or program compiles the standard language. People are
only concerned that the language it self is precise and yields accurate
and same results in all environments when executed.

It is the abstraction (and standardization) not the implementation
we are interested of.

best regards: Janne.