[Proj] Re: Global Gauss-Kruger and libproj4---the final story

[strebe]

On Aug 28, 2008, at 5:04:53 PM, "Gerald I. Evenden" <geraldi.evenden at gmail.com> wrote:
Let's see. tan(x) has two values at x=90 degrees: +inf and -inf. So it is no 
longer a function, eh?
Infinity is not a value. Your conception and definitions are not mathematical.

Tangent is undefined at an abscissa of 90°±180°, with the ordinate increasing asymptotically as the abscissa approaches 90°±180° from lesser values, and with the ordinate decreasing asymptotically as the abscissa approaches 90°±180° from greater values. I will not respond to any argument over this, since it is basic mathematics, available anywhere. Any mathematician would disagree with your characterization. Infinity as a value is a convenient fiction, but it does not always work, and it does not bear on the question of whether tangent is a function or not.
I can't find any such distinction for the definition of a "function." Please 
give reference.
See, for example, 

http://mathworld.wolfram.com/MultivaluedFunction.html

A bazillion other Web pages will do, easily searched for.
Even if your questionable definition were true, it merely verifies that 
proj_fwd() is a function because it only returns one value. It is defined 
that way in the documentation.
You have, yet again, confused yourself about the who is arguing what. Yes. You treat projections as functions. That's clear. That's always been clear. That's THE problem. You have decided it's not YOUR problem, so now it's your clients' problem. That doesn't make the problem go away. It just changes who it's a problem for.  I have specifically acknowledged multiple times that you have chosen, for your convenience, to ignore the multivalued results of projection formulæ in order to treat projections as functions. Why are you crowing about this evidence of proj_fwd() being a function when its functional nature is exactly why we're even having this conversation?
In terms of interruptions applying to all projections I presume you are 
referring to the del-lon=180 condition. In many projection software this is 
not a break and the map merely repeats on in the x direction.
That is impossible for almost all projections that are not cylindric or pseudocylindric. It's merely a convenient evasion of responsibility that works for two common classes of projections. Meanwhile it can't work for most projections because most projections depend on trigonometric (and therefore periodic) manipulations of longitude, resulting in extended longitudinal ranges wrapping back onto themselves — resulting, even, on 180°E mapping onto 180°W.
As far as I am 
aware it is always the graphic programmers job to handle this condition and 
not the projection routine: when at the map edge recall the function with the 
sign of the lon term reversed.
As far as "recall the function with the sign of the lon term reversed" goes, see the prior comment.

This was never about whose job it is. You're free to decide what's your job and what isn't. Rather, it's a matter of what has to happen regardless of who does what in order to get the job done. 

You have declared with much sophistry that somehow the ellipsoidal transverse Mercator can't be accommodated in libproj4 because of the cusps. That's nonsense. There is nothing unique to that projection from libproj4's perspective. Since you have put the onus of interruptions and odd boundaries on the client, then the same would be true in the case of the ellipsoidal transverse Mercator. Meanwhile libproj4 could happily provide one result of the multivalued formulæ along the cusp, just as it does for every projection.
BTW: you are the first person I have ever heard that refers to the wrap-around 
condition of longitude as an interruption if, indeed, that is what you are 
referring to.
That is what I am referring to. It is an interruption by any rational analysis. I don't care if you call it a phlabbergompkin to distinguish it from what you call an interruption (which you would never be able to provide a definition for that's not arbitrary). It's exactly the same thing, and what you seem to think of as an "uninterrupted" map is undeniably interrupted. It's not important what it's called. It's important what it does. What it does is separate points on the map that are adjacent on the globe.
If there are other examples, other than projections commonly recognized as 
interrupted (for example Goode) *please* name them.
*Berghaus star
*Peirce quincuncial
*Waterman
*Fuller dymaxion
*Cahill butterfly
*Guyou
*Raizs armadillo
*two-point equidistant
*vertical perspective
*general perspective
*all of the dozens of polyhedral projections described in the literature
*any projection in oblique aspect (which you handle with something of a hack, it appears)

Since whatever definition you use for "interruption" appears to be arbitrary, and I have no access to your arbitrary definition, I cannot guarantee that you'll agree that all the projections in that list are "interrupted" by your definition but are not "commonly recognized" as interrupted. That's not my problem, and I will not argue over the list or its meaning. I chose projections whose natural boundaries do not follow the common cylindric or azimuthal bounding parallels and meridians. The list is hardly exhaustive.

Perhaps you'll claim those are all cartoon projections, or nobody uses them, or whatever else. I don't care. Not my problem. It's a reasonable policy for you to limit your software to handle 95% of the needs and blow off the rest. It's not reasonable for you to claim your reasons are founded on some natural property of map projections. They're not. My point has only ever been that you're rationalizing your decision not to support the ellipsoidal transverse Mercator with fallacious arguments, and I do not wish for the (doubtless rapidly fading) audience to be confused by such remarks.

Regards,
-- daan Strebe


On Aug 28, 2008, at 5:04:53 PM, "Gerald I. Evenden" <geraldi.evenden at gmail.com> wrote:
From:   "Gerald I. Evenden" <geraldi.evenden at gmail.com>
Subject:    Re: Global Gauss-Kruger and libproj4---the final story
Date:   August 28, 2008 5:04:53 PM PDT
To: strebe at aol.com
Cc: proj at lists.maptools.org
On Thursday 28 August 2008 5:30:30 pm strebe at aol.com wrote:
> >The only context that I use the term "interruption" in discussing
> >cartographic projections are in cases like Goode's world maps or
> >"orange peal" charts often using the sinusoidal projection. Please
> >define what *you* mean by interruptions.
>
> An interruption is any location where two points of infinitesimal
> separation on the globe are mapped to two points having finite separation
> on the plane. This happens somewhere on all projections. All along an
> interruption, the projection formulæ are no longer a function; they are
> multivalue.

Let's see. tan(x) has two values at x=90 degrees: +inf and -inf. So it is no 
longer a function, eh?

I can't find any such distinction for the definition of a "function." Please 
give reference.

Even if your questionable definition were true, it merely verifies that 
proj_fwd() is a function because it only returns one value. It is defined 
that way in the documentation.

In terms of interruptions applying to all projections I presume you are 
referring to the del-lon=180 condition. In many projection software this is 
not a break and the map merely repeats on in the x direction. As far as I am 
aware it is always the graphic programmers job to handle this condition and 
not the projection routine: when at the map edge recall the function with the 
sign of the lon term reversed.

BTW: you are the first person I have ever heard that refers to the wrap-around 
condition of longitude as an interruption if, indeed, that is what you are 
referring to.

If there are other examples, other than projections commonly recognized as 
interrupted (for example Goode) *please* name them.

> Regards,
> -- daan Strebe

-- 
The whole religious complexion of the modern world is due
to the absence from Jerusalem of a lunatic asylum.
-- Havelock Ellis (1859-1939) British psychologist

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20080828/e67bcb8f/attachment.html>