Hello all,

I have a world map using the Mercator projection, and would like to plot
some stuff on it using Latitude and Longitude.

The problem is that I can't seem to get the formule I found to spit out the correct value for Y.

-- The map :

https://upload.wikimedia.org/wikipedia/commons/thumb/7/73/Mercator_projection_Square.JPG/250px-Mercator_projection_Square.JPG

-- The formula :

Y = ln( tan(latitude) + sec(latitude) )

where "ln(...)" is log(...) / log(10)

... at least, that is what I could google about it.

where "sec(...)" is 1/cos(...)

-- The test data :

New York : Latitude = 39 (Longitude = -77)

-- Applying the formula and checking the partial results :

RadLat = DegToRad(39) -> 0.680952380952381

Temp = tan(RadLat) + 1/cos(RadLat) -> 2.09728292053088

log(Temp)/log(10) -> 0.321657020135087

Multiplying half the maps height by the above tells me that New York is
located somewhere in Canada. :-(

Can anyone tell me what goes wrong here ?

Regards,
Rudy Wieser




--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

After serious thinking R.Wieser wrote :

Can anyone tell me what goes wrong here ?

i pasted your post into chatgpt, it says:


You?re very close ? the issue is a combo of log base, formula form, and
how Mercator Y is mapped to pixels. Nothing fundamentally wrong with
your trig. Let?s untangle it cleanly.

then it explains a possible error in your formula and suggests the
workaround

--
/-\ /\/\ /\/\ /-\ /\/\ /\/\ /-\ T /-\
-=- -=- -=- -=- -=- -=- -=- -=- - -=-
........... [ al lavoro ] ...........
-.-. .... . ... .. ...- .. -. -.-. .- --- -.-. .... . ... .. .--. . .-.
-.. .- ..-. --- .-. --.. .- - --- .-. --- . .--- ..- ...- . -- . .-.
-.. .-

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Ammammata,

i pasted your post into chatgpt, it says:

You're very close - the issue is a combo of log base,

Yeah, I noticed that too. log() != log() : loge(), log10(), ln(), lg().

formula form,

You got me there I'm afraid. No idea what thats supposed to be about.

and how Mercator Y is mapped to pixels.

Really ? I can't imagine.

Nothing fundamentally wrong
with your trig. Let's untangle it cleanly.

then it explains a possible error in your formula and suggests
the workaround

Can you post what it said about that explanation and work-around please.

Regards,
Rudy Wieser



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 1/14/2026 8:28 AM, R.Wieser wrote:

Ammammata,

i pasted your post into chatgpt, it says:

You're very close - the issue is a combo of log base,

Yeah, I noticed that too. log() != log() : loge(), log10(), ln(), lg().

formula form,

You got me there I'm afraid. No idea what thats supposed to be about.

and how Mercator Y is mapped to pixels.

Really ? I can't imagine.

Nothing fundamentally wrong
with your trig. Let's untangle it cleanly.

then it explains a possible error in your formula and suggests
the workaround

Can you post what it said about that explanation and work-around please.

Regards,
Rudy Wieser

************ CoPilot Question *************

The mercator projection of the world globe can be displayed
on a computer screen. Assume the computer screen is a
unit square having a diagonal stretching from (0,0) to (1,1).
Write a C language program that accepts latitude and longitude in signed degrees,
and computes the location of a dot on the screen in the unit square.

The interface to the program would say on the command line

Enter Latitude in degrees:

Enter Longitude in degrees:

Your screen data point is at X= Y=

The program then waits for the next data input without terminating.

************ CoPilot Answer *************

#include <stdio.h>
#include <math.h>

/* gcc -lm -o merc.exe merc.c */

int main(void) {
double lat, lon;
const double PI = 3.14159265358979323846;

while (1) {
printf("\nEnter Latitude in degrees: ");
if (scanf("%lf", &lat) != 1) break;

printf("Enter Longitude in degrees: ");
if (scanf("%lf", &lon) != 1) break;

/* Clamp latitude to Mercator limits (~ñ85.05113ø) */
if (lat > 85.05113) lat = 85.05113;
if (lat < -85.05113) lat = -85.05113;

/* Convert longitude to X in [0,1] */
double x = (lon + 180.0) / 360.0;

/* Convert latitude to Y in [0,1] using Mercator projection */
/* Paul: Lang C log() is actually ln(). While Lang C log10() is log base10 */
double rad = lat * PI / 180.0;
double y = 0.5 - (log(tan(PI/4.0 + rad/2.0)) / (2.0 * PI));

printf("Your screen data point is at X=%f Y=%f\n", x, y);
}

return 0;
}
************ End CoPilot Answer *************

It took a bit to convince myself that the equation shown
in the CoPilot answer was successfully converted to C code.

*******

New York : Latitude = 39 (Longitude = -77)

-- Applying the formula and checking the partial results :

RadLat = DegToRad(39) -> 0.680952380952381

Temp = tan(RadLat) + 1/cos(RadLat) -> 2.09728292053088

log(Temp)/log(10) -> 0.321657020135087

*******
The CoPilot program gives

Enter Latitude in degrees: 39
Enter Longitude in degrees: -77
Your screen data point is at X=0.286111 Y=0.382179

Now, we have to work on our "where is our damn plot origin". Surprise.
It's not where you think when they wrote the equation. Lets find out.

Enter Latitude in degrees: -80
Enter Longitude in degrees: 0
Your screen data point is at X=0.500000 Y=0.887741

Enter Latitude in degrees: -50
Enter Longitude in degrees: 0
Your screen data point is at X=0.500000 Y=0.660855

Enter Latitude in degrees: -30
Enter Longitude in degrees: 0
Your screen data point is at X=0.500000 Y=0.587425

Enter Latitude in degrees: 0
Enter Longitude in degrees: 0
Your screen data point is at X=0.500000 Y=0.500000

Enter Latitude in degrees: 30
Enter Longitude in degrees: 0
Your screen data point is at X=0.500000 Y=0.412575

Enter Latitude in degrees: 50
Enter Longitude in degrees: 0
Your screen data point is at X=0.500000 Y=0.339145

Enter Latitude in degrees: 80
Enter Longitude in degrees: 0
Your screen data point is at X=0.500000 Y=0.112259

(0,0) is on the upper left of the unit square.

Paul

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Paul,

************ CoPilot Answer *************

...

double y = 0.5 - (log(tan(PI/4.0 + rad/2.0)) / (2.0 * PI));

...

Enter Latitude in degrees: 39
Enter Longitude in degrees: -77
Your screen data point is at X=0.286111 Y=0.382179

:-) That 0.382179 is 0.06+ larger than what I got from the formule I
posted - and that one was already *way* to big.

It looks like the result needs to be in the neighbourhood of 2.3

If I leave off the "0.5 -" part (likely a pre-inclusion of "half the images height") than I get 0.118, which is still about half of what it needs to be.

For a test I put 89 degrees latitude into that CoPilot formule I get a
result of *minus* 0.2662 - which should never happen.

When I again leave out the "0.5 -" part I get a result of 0.766 - which
feels way to small.

I have absolutily no idea what is happening with those formules (I've now
tried four of them).


By the way: odd that it has brackets around the "log(...) / (2.0 *PI)" part,
as if CoPilot isn't sure about if division comes before subtraction. Same
for the "/ (2.0 * PI)" part.

Here are the partial results from that CoPilot formule :

Lat: 39
Ang: .680952380952381
Tan: 2.09899066938588
Log: .741456595562241
Div: .117959003839447
Res: .382040996160553

Regards,
Rudy Wieser



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 1/14/2026 2:44 PM, R.Wieser wrote:

************ CoPilot Answer *************

...

double y = 0.5 - (log(tan(PI/4.0 + rad/2.0)) / (2.0 * PI));

...

Enter Latitude in degrees: 39
Enter Longitude in degrees: -77
Your screen data point is at X=0.286111 Y=0.382179

:-) That 0.382179 is 0.06+ larger than what I got from the formule I
posted - and that one was already *way* to big.

It looks like the result needs to be in the neighbourhood of 2.3

If I leave off the "0.5 -" part (likely a pre-inclusion of "half the images height") than I get 0.118, which is still about half of what it needs to be.

For a test I put 89 degrees latitude into that CoPilot formule I get a
result of *minus* 0.2662 - which should never happen.

When I again leave out the "0.5 -" part I get a result of 0.766 - which
feels way to small.

I have absolutily no idea what is happening with those formules (I've now tried four of them).

By the way: odd that it has brackets around the "log(...) / (2.0 *PI)" part, as if CoPilot isn't sure about if division comes before subtraction. Same for the "/ (2.0 * PI)" part.

Here are the partial results from that CoPilot formule :

Lat: 39
Ang: .680952380952381
Tan: 2.09899066938588
Log: .741456595562241
Div: .117959003839447
Res: .382040996160553

Regards,
Rudy Wieser

The CoPilot formula is capped to the valid range.

/* Clamp latitude to Mercator limits (approximately plus or minus 85.05113 degrees) */
if (lat > 85.05113) lat = 85.05113;
if (lat < -85.05113) lat = -85.05113;

In scientific endeavor, equations frequently have ranges of validity.
When doing Spice simulations of transmission lines, some equations are
only good to a certain cross sectional aspect ratio. Then, a second
equation covers the next chunk of domain. And so on. Your 89 degree
attempt, should be a result from 85 degrees, as set by the capping logic.

The Mercator is clamped, at a point where the exaggeration of size
has become too absurd. Maybe it is arbitrarily set at 10:1, or it
could be set at some other value. Greenland should fit into Africa,
something like 14 times.

I would have liked to pump data points for an outline map into
this little project, to see if the projection makes sense, but I could
not find any hint of available data decks online. I have a box of *punch cards* in the house, with this data on it. Now, where did I leave those ? Hmmm.

I was doing maps of the earth on a mainframe, and dumping to a line printer (132 columns),
and that was a long time ago. And that was with the QDGS library. As a 3D model, you could
set the "eye" in space, and see an ASCII-art diagram of what the map looks like at
that position. You could model what a space-landing would look like.

*******

There are likely to be more than one Mercator projection. I'm not an expert
in this topic, and just about anything is possible. Trace down the origins
of the equation you got, and see if the article makes any mention of other
math formula for it.

That's why I wanted to plot off a unit square with the world in it,
just to check that the presentation looks like the map in Wiki.
This is what CoPilot offered as cites.

https://hub.arcgis.com/datasets/esri::world-continents/explore <=== 1KB, then froze

https://www.giss.nasa.gov/tools/panoply/overlays/ <=== Mystery format (binary)
https://www.giss.nasa.gov/tools/panoply/ (need Java runtime)

https://ourworldindata.org/grapher/continents-according-to-our-world-in-data ?

https://geo.malagis.com/global-continent-boundary-datasets-a-comparative-analysis.html <=== poly and shapes

Looks about as pleasant as yard work.

Paul

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Paul,

The CoPilot formula is capped to the valid range.

/* Clamp latitude to Mercator limits (approximately plus or minus 85.05113 degrees) */
if (lat > 85.05113) lat = 85.05113;
if (lat < -85.05113) lat = -85.05113;

I tested 85 degrees latitude too, which gave a 0.500 result - cutting Russia vertically in two. Hey, when 89 degrees latitude returns something as low
as 0.766 , what did you expect ?

I would have liked to pump data points for an outline map into
this little project, to see if the projection makes sense, but I
could not find any hint of available data decks online.

I found a number of Mercator maps (one of them I provided in my initial message), and even a few in .SVG form. Like this one :

https://mathworld.wolfram.com/MercatorProjection.html

(Its also the one where I got my initial formule from)

I also got a few reference lat/lon coordinates :

https://time-ok.com/coordinates/north-america https://time-ok.com/coordinates/europe

There are likely to be more than one Mercator projection.

Not too many, if I may believe Wikipedia :

https://en.wikipedia.org/wiki/List_of_map_projections

By the way, I do not see any difference beween the "Mercator = Wright" and "Web Mercator" images.

That's why I wanted to plot off a unit square with the world in it,
just to check that the presentation looks like the map in Wiki.

Thats what I started with (the above links are the result of it). :-)

This is what CoPilot offered as cites.

My browser "doesn't do" JS, so no joy on the first two links

https://ourworldindata.org/grapher/continents-according-to-our-world-in-data

That one looks to be an Equirectangular projection, and is easy to plot on - lineair in both directions.

Alas. Although I can access the last webpage, I get 403 status when I try
to access the webp images.

Looks about as pleasant as yard work.

:-) Some people happen to like yard work. But yes, it is tedious. Extra
fun was gotten when reading that log() != log() .

Regards,
Rudy Wieser



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Further stuff :

I just thought of drawing latitude lines spaced 10 degrees apart on the
image I provided, and ran into other problems :

I had to multiply the formules result by two to get anywhere near a usable value.

The 10 degree line was drawn below the first line in the image above the equator. Same for the 20 degree line. Only the 30 and 60 degree lines
landed on a line on the image itself (the second and fourth above the equator).

Though the 40 degree line now comes rather close to where I expected New
York to be (which is at 39 degrees latitude), there is no line in the image near it. Huh?

I don't get it, what are those lines on the image for if not latitudes ? But than again, why are there only 5 lines above the equator in the image, and
not 7 ?

Regards,
Rudy Wieser



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

"R.Wieser" <address@is.invalid> writes:

By the way: odd that it has brackets around the "log(...) / (2.0 *PI)" part, >as if CoPilot isn't sure about if division comes before subtraction. Same >for the "/ (2.0 * PI)" part.

<pedantic mode>
It is not sure about anything - it generates text based on statistics. </pedantic mode>

Sorry for this non-related interruption ;)

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Bob,

By the way: odd that it has brackets around the "log(...) / (2.0 *PI)"
part, as if CoPilot isn't sure about if division comes before
subtraction.
Same for the "/ (2.0 * PI)" part.

<pedantic mode>
It is not sure about anything - it generates text based on statistics. </pedantic mode>

You know that, I know that. There is no intelligence to be had from AI's.
:-) :-(

But that makes it even worse : (all) the people who that that formule was stolen^wtaken^wcopied from where not sure about the order of operations ?

I can imagine plenty such brackets when trying to teach beginners some math, but not really in source-code like that. Also, too many of a good thing
can be bad (obsfucating where its actually important).

Regards,
Rudy Wieser



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026/1/14 8:24:17, R.Wieser wrote:

Hello all,

I have a world map using the Mercator projection, and would like to plo

t

some stuff on it using Latitude and Longitude.

The problem is that I can't seem to get the formule I found to spit out

the

correct value for Y.

-- The map :

https://upload.wikimedia.org/wikipedia/commons/thumb/7/73/Mercator_proj

ection_Square.JPG/250px-Mercator_projection_Square.JPG

-- The formula :

Y = ln( tan(latitude) + sec(latitude) )

where "ln(...)" is log(...) / log(10)

... at least, that is what I could google about it.

Rather than Googling the formula, my first thought was to go back to
first principles: as the name implies, a map projection can be thought
of as being created by shining a light through the earth (globe) onto a
sheet of paper - either flat and fixed to the globe at one point, or -
more commonly - a cylinder wrapped round the globe, touching at one
circle (often the equator), and then unrolled. Once this is realised,
basic geometry should make calculation of the co-ordinates fairly simple.


Unfortunately, to do this, one needs to know where the nominal light
source is. And - despite it being a _long_ article - I can't find a
statement of this in the Wikipedia article about the Mercator projection
- other that that - I _think_ - it _isn't_ the centre of the earth
(so-called "radial"), though is often thought to be (certainly Google's
AI thinks it is).

If anyone _can_ find out where the light source point is for the
Mercator projection, I'd love to know! (And it would answer Rudy's
question.)

(One other position for the light source I remember from last time I
looked into this - which was probably over 40 years ago! - is on the
opposite surface of the globe to the projection point (i. e. sort of
tracking round opposite the map "printing"); I don't think it's that,
though, as that would show the poles, though still distorted.

If it _is_ light-source-at-centre, then the Y co-ordinate would just be
the tangent of the latitude (scaled appropriately for the map size).
Even if it isn't, this _may_ be close enough - try a few places.

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

It has been my experience that folks who have no vices have very few
virtues
-- Abraham Lincoln, quoted by Mark Lloyd in alt.windows7.general 2018-12-
27

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

J.P. ,

First off, FYI, Paul has minimized his posting about the subject to the
Win10 group only. If you're not there already it might be a good idea to
take a peek.

If it _is_ light-source-at-centre, then the Y co-ordinate would just be
the tangent of the latitude

Somewhere along the road I had a similar thought. But why than do all the formules I now have (four at the moment) all do a tan() and than wrap that
up in a log() ? There must be something to it.

Regards,
Rudy Wieser



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026/1/15 20:0:31, R.Wieser wrote:

J.P. ,

[John by the way :-) ]

First off, FYI, Paul has minimized his posting about the subject to the Win10 group only. If you're not there already it might be a good idea to take a peek.

I replied to the posting I did, thinking I was the only respondent -
probably in the W7 'group; I saw the other responses when I moved to one
of the other 'groups, but too late then to amend my post.

If it _is_ light-source-at-centre, then the Y co-ordinate would just be
the tangent of the latitude

Somewhere along the road I had a similar thought. But why than do all the formules I now have (four at the moment) all do a tan() and than wrap that up in a log() ? There must be something to it.

[]

Indeed! But I can't think what.

Did you _try_ using just the tangent on a couple of places? Or perhaps
just a couple of latitudes, to see if the lines come out where they are
on the plot? You'd probably have to do that in the first place anyway,
to see what the vertical scale _is_; if doing that for say the ten and
forty degree lines (assuming that's what the ones on the plot are) gives different scales, then you'd know it isn't just that.


--
J. P. Gilliver

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Thu, 1/15/2026 8:52 AM, R.Wieser wrote:

Bob,

By the way: odd that it has brackets around the "log(...) / (2.0 *PI)"
part, as if CoPilot isn't sure about if division comes before
subtraction.
Same for the "/ (2.0 * PI)" part.

<pedantic mode>
It is not sure about anything - it generates text based on statistics.
</pedantic mode>

You know that, I know that. There is no intelligence to be had from AI's. :-) :-(

But that makes it even worse : (all) the people who that that formule was stolen^wtaken^wcopied from where not sure about the order of operations ?

I can imagine plenty such brackets when trying to teach beginners some math, but not really in source-code like that. Also, too many of a good thing can be bad (obsfucating where its actually important).

Regards,
Rudy Wieser

There IS an AI trained in symbolic math manipulation,
and this isn't it :-)

Paul

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

J.P. ,

[John by the way :-) ]

John,

I replied to the posting I did, thinking I was the only respondent -
probably in the W7 'group; I saw the other responses when I moved
to one of the other 'groups, but too late then to amend my post.

There was nothing wrong with your post or suggestion, I just thought that
you being able to see what others wrote would be beneficial to us both.

If it _is_ light-source-at-centre, then the Y co-ordinate would just be
the tangent of the latitude

But why than do all the formules I now have (four at the moment)
all do a tan() and than wrap that up in a log() ? There must be
something to it.

...

Indeed! But I can't think what.

Same here. But I'm no math wizz.

Did you _try_ using just the tangent on a couple of places? Or perhaps
just a couple of latitudes, to see if the lines come out where they are
on the plot?

:-) I did so before posting to you and got a rather promising result - on
the image I provided a link to. But I have no idea if it will also work
well on an image multiple times as big (where differences will be more prominent).

iow, I'm only eyeballing the results, and have nothing to numerically
compare them with. :-|

You'd probably have to do that in the first place anyway,
to see what the vertical scale _is_; if doing that for say the ten and
forty degree lines (assuming that's what the ones on the plot are) gives different scales, then you'd know it isn't just that.

Yep, thats what I've been doing.

By the way, the lines on the image are 15 degrees apart horizontally, and
from it I assume vertically as well. This means that the highest visible
line is at 75 degrees latitude.

Ah, I just went back to the wikipedia page* and noticed that the "web Mercator" projection mentions "and clips latitudes to ~85.05? for square presentation". I'm now assuming thats about the image itself. Another assumption is that its also true for the "Mercator = Wright" projection.

* https://en.wikipedia.org/wiki/List_of_map_projections

I have to do some more experiments. Though I'm a bit afraid that a tan()-only solution will only be good enough for smaller images, where the differences (compared to the actual formule) are barely noticable. Not
really what I'm after, but will probably use it as long as I can't get the official formule(s) to work.

.... But it *does* bother me that I can't get those official ones to work.
:-(

Regards,
Rudy Wieser



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Paul,

There IS an AI trained in symbolic math manipulation,
and this isn't it :-)

And you asked that AI, which knows nothing about symbolic math manipulation, to help you/me with a formule ? No wonder it doesn't want to work. :-p

Regards,
Rudy Wieser



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Thu, 1/15/2026 12:25 PM, J. P. Gilliver wrote:

On 2026/1/14 8:24:17, R.Wieser wrote:

Hello all,

I have a world map using the Mercator projection, and would like to plot
some stuff on it using Latitude and Longitude.

The problem is that I can't seem to get the formule I found to spit out the >> correct value for Y.

-- The map :

https://upload.wikimedia.org/wikipedia/commons/thumb/7/73/Mercator_projection_Square.JPG/250px-Mercator_projection_Square.JPG

-- The formula :

Y = ln( tan(latitude) + sec(latitude) )

where "ln(...)" is log(...) / log(10)

... at least, that is what I could google about it.

Rather than Googling the formula, my first thought was to go back to
first principles: as the name implies, a map projection can be thought
of as being created by shining a light through the earth (globe) onto a
sheet of paper - either flat and fixed to the globe at one point, or -
more commonly - a cylinder wrapped round the globe, touching at one
circle (often the equator), and then unrolled. Once this is realised,
basic geometry should make calculation of the co-ordinates fairly simple.

Unfortunately, to do this, one needs to know where the nominal light
source is. And - despite it being a _long_ article - I can't find a
statement of this in the Wikipedia article about the Mercator projection
- other that that - I _think_ - it _isn't_ the centre of the earth
(so-called "radial"), though is often thought to be (certainly Google's
AI thinks it is).

If anyone _can_ find out where the light source point is for the
Mercator projection, I'd love to know! (And it would answer Rudy's
question.)

(One other position for the light source I remember from last time I
looked into this - which was probably over 40 years ago! - is on the
opposite surface of the globe to the projection point (i. e. sort of
tracking round opposite the map "printing"); I don't think it's that,
though, as that would show the poles, though still distorted.

If it _is_ light-source-at-centre, then the Y co-ordinate would just be
the tangent of the latitude (scaled appropriately for the map size).
Even if it isn't, this _may_ be close enough - try a few places.

https://en.wikipedia.org/wiki/Mercator_projection

[Picture] Use Download Original for best result (CoPilot output)

https://i.postimg.cc/SQLZbfvY/mercator-equation.gif

The NASA Panoply program (written in Java and requiring a Java11 JRE),
offers a menu with at least 100 different projections, and Mercator
has two (not that it matters).

I don't think there is anything mysterious about this.

And actually harnessing Panoply to do something useful,
that's almost impossible. An alternative is something called
GGPlot.

I did a PostScript print of the NASA overlap map.

No matter what you set the paper to, the coordinates of the unit
square were only 406x406 pixels (which means the picture itself sucks).

406x406 square subtract 1482 on X, 989.5 on Y

But the beauty of the PostScript, is you find this inside.
This would be drawing a piece of coastline with line segments.
PostScript supports transform matricies, so they can do anything
they want with the item once selecting a coordinate system.

1553.23376 1231.24414 moveto
1553.21582 1231.28955 lineto
1553.17749 1231.35498 lineto
1553.15955 1231.4231 lineto
1553.12134 1231.44446 lineto
1553.14038 1231.46716 lineto

I scaled that, extracted the points, didn't plot lines, just dots,
and made a pbm file (netpbm black and white). The purpose of not plotting lines, was to get less visual clutter. My picture sucks when viewing
the whole thing (it isn't dark enough). But when you zoom into pieces
of the picture, it looks dark enough then to use.

Your coordinates for NYC, where did you get those coords ???
There is an article in Wikipedia I used, complete with a tiny
map widget when you click an icon near the coord info.

40 42 46 -74 0 22 New York City value (Wikipedia)

40.71277778 -74.00611111 DMS to D via https://www.latlong.net/degrees-minutes-seconds-to-decimal-degrees

X=0.294427 Y=0.375981 merc.exe (the CoPilot program)

That means, on my 10000x10000 pixel map, I plot a dot at (2944,3760).

Now, some weirdness to throw in. GIMP measures from lower left corner.
I think the equation measures from upper left corner. Yet, when I
plotted my PBM, it was upside-down as viewed on the screen, and I
had to do a Flip-Vertical so the map read correctly. So when GIMP reads (2944,3760) off the mouse cursor as I move around, that's kinda measuring
from the upper left corner. Otherwise, I would have needed to do 10000-3760
or so. Which turned out not to be necessary.

The PBM file looks nicer when zoomed in, and that's what you're looking
at here, is just a portion of my Mercator.

[Picture] Use Download Original when buried in adverts

https://i.postimg.cc/P5vhvS3w/NYC-coord3.gif

There is still some error there. Even if I made an allowance for
a one pixel error in plotting the picture, I don't think that covers
it and I might be off two or three pixels left-right.

I think the equation is pretty close. But I'm not happy that
there is an error still there.

Paul

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026/1/16 10:8:22, Paul wrote:

[]

Your coordinates for NYC, where did you get those coords ???
There is an article in Wikipedia I used, complete with a tiny
map widget when you click an icon near the coord info.

40 42 46 -74 0 22 New York City value (Wikipedia)

40.71277778 -74.00611111 DMS to D via https://www.latlong.net/degree

s-minutes-seconds-to-decimal-degrees

You used a website to work out 40 + 42/60 + 46/3600? :-)
[]

I think the equation is pretty close. But I'm not happy that
there is an error still there.

Paul

Yes, this has been a puzzle, for what seems like a simple question!

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

aibohphobia, n., The fear of palindromes.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Fri, 1/16/2026 4:59 PM, J. P. Gilliver wrote:

On 2026/1/16 10:8:22, Paul wrote:

[]

Your coordinates for NYC, where did you get those coords ???
There is an article in Wikipedia I used, complete with a tiny
map widget when you click an icon near the coord info.

40 42 46 -74 0 22 New York City value (Wikipedia)

40.71277778 -74.00611111 DMS to D via https://www.latlong.net/degrees-minutes-seconds-to-decimal-degrees

You used a website to work out 40 + 42/60 + 46/3600? :-)
[]

I am a complex person with special needs :-)

Paul


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

John,

Did you _try_ using just the tangent on a couple of places?

...

I have to do some more experiments.

After having done so, it looks like that

tan(DegToRad(Latitude)*0.78)\2.53627

gives a nice result.

Though I used 75 degree latitude as the reference for the "will the
calculated lines overlap the ones on the image?" test, causing all lower calculations to be /just/ under the lines on the image.

Re-doing it using 65 degree latitude as a reference should give a better result (75 degree just above its target, the others just below their target)

As I mentioned before, good enough to get an indication of the location
you're looking for, but it can be hundreds of miles to low (or high) ...

By the way, 0.78 is rather close to Pi/4 . Somehow that raises my suspicion that that is the actual value to be used, and my 0.78 is caused by my "that looks good" eyeballing ...

Regards,
Rudy Wieser



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Paul

Your coordinates for NYC, where did you get those coords ???

If you mean 39, -77 its probably from me.

Looking back in my docs I see I have an image of a globus wit the lat/long lines on it, mentioning 39, -77. The only problem is that it mentions Washington DC, and not New York. I've got no idea how I mixed those two up. My apologies.

40 42 46 -74 0 22 New York City value (Wikipedia)

40.71277778 -74.00611111 DMS to D via https://www.latlong.net/degrees-minutes-seconds-to-decimal-degrees

X=0.294427 Y=0.375981 merc.exe (the CoPilot program)

Is there any chance you can (re)post the used formule (just to be sure I'm using the correct one) and some intermediate results (especially the ones
fed into the tan() an log() functions) so I can verify what the formule is doing here (and spot my mistake(s)) ?

Regards,
Rudy Wieser




--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026/1/17 7:19:55, R.Wieser wrote:

John,

Did you _try_ using just the tangent on a couple of places?

...

I have to do some more experiments.

After having done so, it looks like that

tan(DegToRad(Latitude)*0.78)\2.53627

gives a nice result.

Asssuming DegToRad() just means multiply by pi / 180 ...

[]

By the way, 0.78 is rather close to Pi/4 . Somehow that raises my suspicion that that is the actual value to be used, and my 0.78 is caused by my "that looks good" eyeballing ...

Regards,
Rudy Wieser

... then the above simplifies to tan(Latitude*pi*pi/720)\2.53627, and of
course pi*pi/720 can be given as a constant.

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

"Tolerating intolerance is not a virtue." - Barry Shein

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, 1/17/2026 3:11 AM, R.Wieser wrote:

Paul

Your coordinates for NYC, where did you get those coords ???

If you mean 39, -77 its probably from me.

Looking back in my docs I see I have an image of a globus wit the lat/long lines on it, mentioning 39, -77. The only problem is that it mentions Washington DC, and not New York. I've got no idea how I mixed those two up. My apologies.

40 42 46 -74 0 22 New York City value (Wikipedia)

40.71277778 -74.00611111 DMS to D via
https://www.latlong.net/degrees-minutes-seconds-to-decimal-degrees

X=0.294427 Y=0.375981 merc.exe (the CoPilot program)

Is there any chance you can (re)post the used formule (just to be sure I'm using the correct one) and some intermediate results (especially the ones
fed into the tan() an log() functions) so I can verify what the formule is doing here (and spot my mistake(s)) ?

Regards,
Rudy Wieser

The CoPilot response shows its equation here. And this is what
it used to write the C code for me.

[Picture] Use Download Original for best result (CoPilot output)

https://i.postimg.cc/SQLZbfvY/mercator-equation.gif

Whereas the Wikipedia reference for the same thing is here.
The USGS equation hides the 2PI part inside its R and it neglects
to include coordinate correction for plotting purposes. The USGS
form of the equation shows the "shape of the transform" and is
not the equation a practitioner needs to implement. The Copilot
equation delivers a unit square, with the center of the
map presumably being 0,0 for lat,long. The unit square itself
has a different origin, like the upper left corner. In any case,
using your calibrated eyeball, you will be able to figure out
what additional math is require to fit your plotting scheme.

https://en.wikipedia.org/wiki/Mercator_projection

Mathematics [half way down the page or so...]

A simple expression for the spherical form of the Mercator projection is:[26]

[26] https://pubs.usgs.gov/pp/1453/report.pdf (PDF page 228, stamped as "page 218")

The USGS document on its page, does not note the
agreed 85.05113 degree cutoff for latitudes (so the "globe"
is not too messy). The cutoff is encoded in the C code that CoPilot gave me.

*************************************************************************** #include <stdio.h>
#include <math.h>

/* gcc -lm -o merc.exe merc.c */

int main(void) {
double lat, lon;
const double PI = 3.14159265358979323846;

while (1) {
printf("\nEnter Latitude in degrees: ");
if (scanf("%lf", &lat) != 1) break;

printf("Enter Longitude in degrees: ");
if (scanf("%lf", &lon) != 1) break;

/* Clamp latitude to Mercator limits (plus/minus 85.05113 degrees) */
if (lat > 85.05113) lat = 85.05113;
if (lat < -85.05113) lat = -85.05113;

/* Convert longitude to X in [0,1] */
double x = (lon + 180.0) / 360.0;

/* Convert latitude to Y in [0,1] using Mercator projection */
/* The C log function is an ln(), the C log10 function is an log() */

double rad = lat * PI / 180.0;
double y = 0.5 - (log(tan(PI/4.0 + rad/2.0)) / (2.0 * PI));

printf("Your screen data point is at X=%f Y=%f\n", x, y);
}

return 0;
}
***************************************************************************

.\merc

Enter Latitude in degrees: 40.71277778
Enter Longitude in degrees: -74.00611111
Your screen data point is at X=0.294427 Y=0.375981

And then I scaled up my graphic to 10000 x 10000
and plotted (2944, 3760). I wrote a piece of code
I call pbmplot.exe and it starts with an empty
square and adds the datapoints I extracted from the
Panoply output. The pbm graphics file format is
dead simple, and the graphics data (one hundred million
ASCII characters) is output with one printf("%s")
type statement :-) The format doesn't even need
<cr><lf> during the data phase, which I find both
amusing and practical. I bet Notepad would not
like that file :-) But GIMP opened that file just fine.

Paul

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

John,

Asssuming DegToRad() just means multiply by pi / 180 ...

Well, you may use any calculation in there that you want, as long as it does the job. :-) But yes, thats what the/my DegToRad function does.

... then the above simplifies to tan(Latitude*pi*pi/720)\2.53627, and
of course pi*pi/720 can be given as a constant.

I didn't even think that far. As I said, I'm no math wizz. :-|

Regards,
Rudy Wieser




--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

As I cannot get any formule to work I'm going to try this one last time.

Below are two formules for converting a lattitude on a Mercator-projection
map into a -1 ... +1 result that needs to be multiplied by half the maps-images height and subtracted from the equator (the map-images top-left
is 0,0).

I've split the calculations up into multiple parts, hoping that someone can tell me where one, or perhaps both, go awry.

-- Formule: ln( tan(latitude) + sec(latitude) )

Lat: 39
DegToRad(39) -> 0.680952
tan(0.680952) -> 0.810238
sec(0.680952) -> 1/cos(0.680952) -> 1.287045
ln(0.810238+1.287045) -> log(0.810238+1.287045)/log(10) -> 0.321657

0.321657 is *way* too high.


-- Formule: log( tan(PI/4.0 + rad/2.0) ) / (2.0 * PI)

Lat: 39
DegToRad(39) -> 0.680952
tan(PI/4+0.680952/2) -> 2.098991
log(2.098991) -> 0.741457
0.741457/(2*PI) -> 0.117959

0.117959 is *way* to low

Regards,
Rudy Wieser



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

On Mon, 1/19/2026 3:11 PM, R.Wieser wrote:

As I cannot get any formule to work I'm going to try this one last time.

Below are two formules for converting a lattitude on a Mercator-projection map into a -1 ... +1 result that needs to be multiplied by half the maps-images height and subtracted from the equator (the map-images top-left is 0,0).

I've split the calculations up into multiple parts, hoping that someone can tell me where one, or perhaps both, go awry.

-- Formule: ln( tan(latitude) + sec(latitude) )

Lat: 39
DegToRad(39) -> 0.680952
tan(0.680952) -> 0.810238
sec(0.680952) -> 1/cos(0.680952) -> 1.287045
ln(0.810238+1.287045) -> log(0.810238+1.287045)/log(10) -> 0.321657

ln(2.097283) = 0.740643 # Via the ln() button on my calculator
# Calc is a cheap Canon F502
# http://www.datamath.org/Related/Canon/Images/F-502.jpg

0.321657 is *way* too high.

https://luckytoilet.wordpress.com/2010/11/07/notes-on-mercators-projection/

x = lambda # longitude in radians ?
# Means our plot is not a unit square, as given

y = ln( sec(theta) + tan(theta) ) # I cannot copy the equation as it is mathml
# and will only confuse matters. 1/3rd down the page,

The plot origin must not be where we think it is. Notice how in a lot
of these mathematics discussions, nobody labels a damn thing. The
range on y is 0 to some positive number. X must be in the center of
the plot, so plus and minus lambdas move to either side for us.

-- Formule: log( tan(PI/4.0 + rad/2.0) ) / (2.0 * PI)

Lat: 39
DegToRad(39) -> 0.680952
tan(PI/4+0.680952/2) -> 2.098991
log(2.098991) -> 0.741457
0.741457/(2*PI) -> 0.117959

0.117959 is *way* to low

But it is 0.5 minus that number, so 0.382 .

double rad = lat * PI / 180.0;
double y = 0.5 - (log(tan(PI/4.0 + rad/2.0)) / (2.0 * PI));

And again, we have to evaluate the range of the equation and see how
we can fit it to the plot and make sense of it. In a previous post,
I ran merc.exe and entered some numbers to generate a range. So we
can see which direction it is moving. The Y axis seems to be down
the page on this one. I put this text into a previous post and I removed
all the distracting latitude text when making this table.

Enter Latitude in degrees: -80 Y=0.887741
Enter Latitude in degrees: -50 Y=0.660855
Enter Latitude in degrees: -30 Y=0.587425
Enter Latitude in degrees: 0 Y=0.500000
Enter Latitude in degrees: 30 Y=0.412575 \___ 39 degrees is between these two
Enter Latitude in degrees: 50 Y=0.339145 /
Enter Latitude in degrees: 80 Y=0.112259

Paul


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

Paul,

ln(2.097283) = 0.740643 # Via the ln() button on my calculator

And that 0.740643 points to somewhere between the northpole and canada on an ice plate. Where I'm quite sure Washington DC isn't located.

Which was why I started to doubt that "ln()" equals "log()". But if not,
what is it ?

The plot origin must not be where we think it is.

Well, thats easy to check : Just calculate the result for a Latitude of Zero degrees. It should point at the equator.

Notice how in a lot of these mathematics discussions, nobody labels a damn thing.

Just mathematics ? A couple of weeks ago I tried to find example code for OpenSLL. I could find some, but with zero indication which version of the
DLL it was for - and it matters a *lot*. It frustrates me to no end.

0.117959 is *way* to low

But it is 0.5 minus that number, so 0.382 .

In my previous message I mentioned that I multiply the result by half the height of the map, and subtract it from the equator (again, half the height
of the map). That is the same, right ?

Actually, it isn't. :-)

Now you have shown that the log() in the formule you presented is exactly
that (and not a elog() (natural log?) ) I had some solid ground from which I could look further.

The whole problem is that your formule multiplies by the full height of the map, and my "simplified" one multiplied by *half* the maps height (and than subtracts from the equator).

When I multiplied my result by two the result was the same as what came
outof your formule.

Thank you for that. :-)

mea culpa : after noticing that my implementation of the formule didn't work
I *should* have first tried to implement it as provided. :-|


Than only one thing remains : Any idea why the first formule doesn't give
the expected result ?<whistle>

Regards,
Rudy Wieser





--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

On 21/01/2026 19:01, R.Wieser wrote:

Paul,

ln(2.097283) = 0.740643 # Via the ln() button on my calculator

And that 0.740643 points to somewhere between the northpole and canada on an ice plate. Where I'm quite sure Washington DC isn't located.

Which was why I started to doubt that "ln()" equals "log()". But if not, what is it ?

The plot origin must not be where we think it is.

Well, thats easy to check : Just calculate the result for a Latitude of Zero degrees. It should point at the equator.

Notice how in a lot of these mathematics discussions, nobody labels a damn >> thing.

Just mathematics ? A couple of weeks ago I tried to find example code for OpenSLL. I could find some, but with zero indication which version of the DLL it was for - and it matters a *lot*. It frustrates me to no end.

0.117959 is *way* to low

But it is 0.5 minus that number, so 0.382 .

In my previous message I mentioned that I multiply the result by half the height of the map, and subtract it from the equator (again, half the height of the map). That is the same, right ?

Actually, it isn't. :-)

Now you have shown that the log() in the formule you presented is exactly that (and not a elog() (natural log?) ) I had some solid ground from which I could look further.

The whole problem is that your formule multiplies by the full height of the map, and my "simplified" one multiplied by *half* the maps height (and than subtracts from the equator).

When I multiplied my result by two the result was the same as what came
outof your formule.

Thank you for that. :-)

mea culpa : after noticing that my implementation of the formule didn't work I *should* have first tried to implement it as provided. :-|

Than only one thing remains : Any idea why the first formule doesn't give
the expected result ?<whistle>

Regards,
Rudy Wieser

I would expect most people would think that log(A) means log to base 10
of A while ln(B) is natural log of B if they were just shown without any explanation.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

EllisMorgan,

I would expect most people would think that log(A) means log to base 10 of
A while ln(B) is natural log of B if they were just shown without any explanation.

As I mentioned, I googled for what "ln()" could mean. I got information
back that different professions use "log()" to mean whatever they want it to mean. :-(

I did however find how to use "log()" to emulate "ln()" (as I showed in my first message). Alas, the result was still not near the expected one.

If you can point out what mistake(s) I made with that (first) fomule or my conversion of it I would be much obliged.

Regards,
Rudy Wieser



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

On Fri, 1/23/2026 1:56 PM, R.Wieser wrote:

EllisMorgan,

I would expect most people would think that log(A) means log to base 10 of >> A while ln(B) is natural log of B if they were just shown without any
explanation.

As I mentioned, I googled for what "ln()" could mean. I got information back that different professions use "log()" to mean whatever they want it to mean. :-(

I did however find how to use "log()" to emulate "ln()" (as I showed in my first message). Alas, the result was still not near the expected one.

If you can point out what mistake(s) I made with that (first) fomule or my conversion of it I would be much obliged.

Regards,
Rudy Wieser

If you take a math course, you're taught it is as Ellis explains.

That the notation ln() is a logarithm based on the constant e = 2.71828 .

And that log() is log base 10.

*******

And just scraping a calculator web page gives a definition
with a superscript power y and a subscript base b as
a way of declaring other bases for a logarithm. For example,
in computer design, you might want a log base 2, as the
computer is binary for some things it does. You could
change the subscript to "e" or even the PI symbol if you wanted.

y
x = b ; then y = log (x); where b is the base
b

We could write

ln(x) = log (x)
e

and I'm writing it this way so plain ASCII will do the job.

But when it comes to computers and math, some languages
allow entry of natural expressions, to at least make it
kinda look like math. Fortran and C butcher math,
and C++ is a little better.

Paul

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

Paul,

If you take a math course, you're taught it is as Ellis explains.

Good for Ellis I suppose. How does that help me, having googled and found that different professions use those different names as they bloody wel
please ?

Also, in my very first posy I included "where ln(...) is log(...) /
log(10)", indicating that I already had the idea that "ln()" *PROBABLY* was the natural logarithm, and how to get it using the standard base-10 log().

I ALREADY TRIED THAT, and still didn't get the expected result.

A few posts back I've provided the origional formule, the replacements I had to make ( "ln()" and "sec()" ) and gave several intermediate results.

*Please* put that formule into whatever you want to use and see where the intermediate results differ from mine - so I know were the problem is and
can try to fix it.

Regards,
Rudy Wieser



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

On 2026/1/19 20:11:34, R.Wieser wrote:

As I cannot get any formule to work I'm going to try this one last time.

[]
There are three stages to this - I would say best sorted individually
before trying to combine them. (Stages 2 and 3 are related and might
need reversing in order.)

1. The mathematical conversion from latitude (and longitude) to the
position on the plane map *relative to its centre*, assuming that's
where the Greenwich meridian crosses the equator. This is the one that
might or might not be just a tangent function (for latitude; for
longitude, it's just scaling and offset, see below).

2. The _scaling_ required, depending on the size of the map image. Which
again will depend on the size of the image (and may be different for X
and Y).

3. The _offsetting_ required to account for the fact that the above
point is not at 0, 0 on the image (probably offset by half the size of
the map being used, in pixels, in each direction).

I think _most_ of those contributing to this discussion know that, but
have not been making it very clear which bits of their formula(e) do what.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

The fact that there is a highway to hell and only a stairway to heaven
says a lot about anticipated traffic numbers.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

On Fri, 1/23/2026 4:31 PM, R.Wieser wrote:

Paul,

If you take a math course, you're taught it is as Ellis explains.

Good for Ellis I suppose. How does that help me, having googled and found that different professions use those different names as they bloody wel please ?

Also, in my very first posy I included "where ln(...) is log(...) / log(10)", indicating that I already had the idea that "ln()" *PROBABLY* was the natural logarithm, and how to get it using the standard base-10 log().

I ALREADY TRIED THAT, and still didn't get the expected result.

A few posts back I've provided the origional formule, the replacements I had to make ( "ln()" and "sec()" ) and gave several intermediate results.

*Please* put that formule into whatever you want to use and see where the intermediate results differ from mine - so I know were the problem is and can try to fix it.

Regards,
Rudy Wieser

I wrote a program, worked an example and put a dot on a map
in a posted picture. That's enough.

Paul



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

John,

There are three stages to this

...

1. The mathematical conversion from latitude (and longitude) to the
position on the plane map *relative to its centre*

Nope. There is no rule that that center must be taken as the origin. Take the formule Paul provided for instance. It returns a result in the range of
0 to 1 .

2. The _scaling_ required, depending on the size of the map image.
Which again will depend on the size of the image (and may be different
for X and Y).

Worse : Mercator maps go from +85 to -85 latitude. That must be part of the formule (I've found several maps where the south-pole is cut off, and a bit
of the north too. iow, useless without further information).

But again no. The result of the formule *is* the scaling (in your and my usage ranging from +1 to -1, in Pauls formule case, from 0 to +1). You just apply it on whatever size Mercator-style map you have handy.

I think _most_ of those contributing to this discussion know that,
but have not been making it very clear which bits of their formula(e)
do what.

I do not need to know what all the parts of a car do, as long as I can drive it. The same goes for these two formules. Latitude goes in, something I
can apply comes out.


Though the whole problem isn't that nobody understood what you said there,
but that nobody was willing to compare the (intermediate) results I posted with what they got themselves, allowing me to locate where I made my mistake(s?).

Not when I asked for it in my first post, and not when I rather explicitily asked for it a few days back. :-(

Regards,
Rudy Wieser



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

Paul,

I wrote a program, worked an example and put a dot on a map
in a posted picture. That's enough.

I already knew that both of those formules where expected to work, so you wasted your time in proving that your CoPilot provided one does.

*What I was asking for* was a bit of help to why my implementation of first one, than both formules refused to return a usable result. I gave you *everything* to be able to do so.

You think that what you did was enough ? How ? You did not even *try* to answer my question. :-(

Regards,
Rudy Wieser



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Hello Rudy,

By the way: odd that it has brackets around the "log(...) / (2.0 *PI)"
part, as if CoPilot isn't sure about if division comes before
subtraction.
Same for the "/ (2.0 * PI)" part.

<pedantic mode>
It is not sure about anything - it generates text based on statistics.
</pedantic mode>

You know that, I know that. There is no intelligence to be had from AI's. >:-) :-(

I cannot suppress the urge to point that out to people, so do not take it personally :)

But that makes it even worse : (all) the people who that that formule was >stolen^wtaken^wcopied from where not sure about the order of operations ?

I can imagine plenty such brackets when trying to teach beginners some math, >but not really in source-code like that. Also, too many of a good thing >can be bad (obsfucating where its actually important).

That is indeed an interesting find, but I'm fine with it myself. I assume many (most?) programmers do not rely on the order being implicitly present.

In this code, maybe it is a bit superfluous, but when the variable names are more
verbose, I certainly am happy with brackets :)

Cheers,

Bob

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Bob,

<pedantic mode>
It is not sure about anything - it generates text based on statistics.
</pedantic mode>

You know that, I know that. There is no intelligence to be had from
AI's. :-) :-(

I cannot suppress the urge to point that out to people, so do not take
it personally :)

Don't worry, I didn't.

I can imagine plenty such brackets when trying to teach beginners some
math, but not really in source-code like that. Also, too many of a
good thing can be bad (obsfucating where its actually important).

That is indeed an interesting find, but I'm fine with it myself.
I assume many (most?) programmers do not rely on the order being
implicitly present.

I'm a (hobby) programmer myself, and I do. Basic calculus and all that.

In this code, maybe it is a bit superfluous, but when the variable names
are more verbose, I certainly am happy with brackets :)

verbose variable names ? How so ? You can only use two letters, right ?
:-) (yep, old BASIC variants)

But if your variable names become /that/ verbose than they cease to be helpfull, and need to be re-written.

And yes, I've seen function/variable names which spanned a full 80 (or was
it 132) column screen. :-( You *can* have to much of a good thing. Just imagine multiple of such "verbose" names that have a difference of just a single letter. :-((

But yes, sometimes a few extra brackets help to understand what is being
done.

Same for the "/ (2.0 * PI)" part.

I think I made a humongous mistake there : "/ (2 * PI)" is something quite different from "/ 2 * PI". :-|

Regards,
Rudy Wieser



--- PyGate Linux v1.5.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

On 2026/1/24 8:28:44, R.Wieser wrote:

John,

There are three stages to this

...

1. The mathematical conversion from latitude (and longitude) to the
position on the plane map *relative to its centre*

Nope. There is no rule that that center must be taken as the origin. Take the formule Paul provided for instance. It returns a result in the range of 0 to 1 .

It makes it easier to understand what's going on if done in these three
stages. And assuming we're talking of the Web Mercator image as shown at https://upload.wikimedia.org/wikipedia/commons/e/ec/Web_maps_Mercator_projection_SW.jpg,
0 degrees latitude and longitude _is_ at its centre.

2. The _scaling_ required, depending on the size of the map image.
Which again will depend on the size of the image (and may be different
for X and Y).

Worse : Mercator maps go from +85 to -85 latitude. That must be part of the

(Or 85.051129.)

formule (I've found several maps where the south-pole is cut off, and a bit of the north too. iow, useless without further information).

No, just because the map is cut off at those latitudes, that figure does
NOT have to appear in the formula. The poles _have_ to be cut off,
otherwise the map would be infinitely tall, and very distorted at the poles.

But again no. The result of the formule *is* the scaling (in your and my usage ranging from +1 to -1, in Pauls formule case, from 0 to +1). You just apply it on whatever size Mercator-style map you have handy.

The above image, according to my browser, is 2068 by 2060 pixels.

I think _most_ of those contributing to this discussion know that,
but have not been making it very clear which bits of their formula(e)
do what.

I do not need to know what all the parts of a car do, as long as I can drive it. The same goes for these two formules. Latitude goes in, something I can apply comes out.

True, if that really is all you want. As a scientist/engineer/just
enquiring mind, I don't like to blindly use a formula without knowing
what it does - or perhaps _why_.

Yes, you can drive a car without knowing what each bit does. But knowing
at least some of them will improve your longevity (wear and tear on the mechanisms), fuel economy, performance ... as you drive.

Though the whole problem isn't that nobody understood what you said there, but that nobody was willing to compare the (intermediate) results I posted with what they got themselves, allowing me to locate where I made my mistake(s?).

That is indeed one of many problems.

It would be good to see where the following points come out on e. g. the
above image, using any formula (longitude given first):
0, 0
+/- 180, 85
+/-180, -85
and some known place, such as London or New York.

Not when I asked for it in my first post, and not when I rather explicitily asked for it a few days back. :-(

Regards,
Rudy Wieser

I guess if you just want a formula that works, and _aren't_ bothered
about the three steps - the mathematical conversion from angle to linear dimension, the scaling, and the offset - then we're very different
minds. Which is of course fine; if we were all the same, it'd be a
boring world.

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

We no longer make things, but sell each other consultancy on how to run consulatancies better. (Michael Cross, Computing 1999-3-4 [p. 28].)

--- PyGate Linux v1.5.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

On Sat, 1/24/2026 3:42 AM, R.Wieser wrote:

Paul,

I wrote a program, worked an example and put a dot on a map
in a posted picture. That's enough.

I already knew that both of those formules where expected to work, so you wasted your time in proving that your CoPilot provided one does.

*What I was asking for* was a bit of help to why my implementation of first one, than both formules refused to return a usable result. I gave you *everything* to be able to do so.

You think that what you did was enough ? How ? You did not even *try* to answer my question. :-(

Regards,
Rudy Wieser

Show me current code.

Have the program print out something like this.

Enter Latitude in degrees: -80 Y=0.887741
Enter Latitude in degrees: -50 Y=0.660855
Enter Latitude in degrees: -30 Y=0.587425
Enter Latitude in degrees: 0 Y=0.500000
Enter Latitude in degrees: 30 Y=0.412575 \___ 39 degrees is between these two
Enter Latitude in degrees: 50 Y=0.339145 /
Enter Latitude in degrees: 80 Y=0.112259

You can see from the output, I'm covering most of a unit square
and my output graph origin must be in one of the
corners of the unit square.

We know the equation is not valid past 85 degrees
at either end, so that range of values will
tell us whether we are covering a unit square or not.

Most of the trouble with this stuff, seems to be
with origin-of-map and origin-of-unit-square.

If we enter (0,0) for lat-long we expect to be in the middle
of the unit square. You can see my Y above is 0.5 in that case.

You can check in Wikipedia for the icon next to the
lat-long for a city, and that icon (with a good browser)
will yield a pop-up map with enough detail you can
fit it to your map data.

Paul


--- PyGate Linux v1.5.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

John,

It makes it easier to understand what's going on if done in these
three stages.

It is, and its why I tried to convert Pauls CoPilot formule into one which would returne a +1 ... -1 result (and made a mistake I only much later recognised).

And assuming we're talking of the Web Mercator image as shown at https://upload.wikimedia.org/wikipedia/commons/e/ec/Web_maps_Mercator_projection_SW.jpg,

I started with the image just above it (as mentioned in my initial post).

And thats another problem (which I ignored for the time being) : which of those two where either formule for ? Can you tell ? I definitily can't.

0 degrees latitude and longitude _is_ at its centre.

For /that/ image, yes.

I don't think you noticed, but it and the one above it have a border around the map-image itself, throwing the precision off a bit. And imagine a map with un-equally sized borders. And yes, I encountered those too. Then there are the maps I mentioned earlier, which could be in a Mercator projection,
but not in a +85 to -85 latitude range.

No, just because the map is cut off at those latitudes, that figure
does NOT have to appear in the formula. The poles _have_ to be
cut off, otherwise the map would be infinitely tall, and very distorted
at the poles.

You mis-understood : I've seen maps where the top of the image is at about
+75 latitude (just above Russia), and the bottom at about -60 latitude (just below south america). Meaning that *none* of the south-pole ice is visible
on the map, and the ice-plate at +45 longitude is pretty-much cut in half.

iow, the equator of such an image is /definitily not/ at half the height of the image.

I've also found a few maps in which 0 degrees longitude was *not* in the horizontal center of the image (its left started at about -170 degrees longitude, just between the russian peninsula and canada).

I do not need to know what all the parts of a car do, as long as I can
drive
it. The same goes for these two formules. Latitude goes in, something
I
can apply comes out.

True, if that really is all you want. As a scientist/engineer/just
enquiring mind, I don't like to blindly use a formula without knowing
what it does - or perhaps _why_.

Bothering about /how/ something works is only a good use of time and energy *after* you make sure /that/ it works.

It would be good to see where the following points come out on e. g. the above image, using any formula (longitude given first):
0, 0
+/- 180, 85
+/-180, -85
and some known place, such as London or New York.

Sigh. I already gave the latitude of Washington DC. Multiple times even.
In my initial post I already provided the result and mentioned that it
pointed somewhere into canada.

But it doesn't really matter which value is plugged into the formula (as
long as its a valid one ofcourse). The only thing that I needed was someone who would repeat the calculations I provided and compare the result with the one I also gave.

I can give you the results for +85 and -85 latitude - which will ofcourse mirror each other - but those values will be of zero use to anyone - other than to be able to tell me that those results are wrong. And thats
something I already know.

Do you still want them, now you know that they would be of no real use to
you ?

One thing bothers me though : why would I need to provide results for +180
and -180 longitudes too ? The longitude isn't any part of the formule.

Regards,
Rudy Wieser



--- PyGate Linux v1.5.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

On Sat, 1/24/2026 9:16 AM, J. P. Gilliver wrote:

On 2026/1/24 8:28:44, R.Wieser wrote:

John,

There are three stages to this

...

1. The mathematical conversion from latitude (and longitude) to the
position on the plane map *relative to its centre*

Nope. There is no rule that that center must be taken as the origin. Take
the formule Paul provided for instance. It returns a result in the range of
0 to 1 .

It makes it easier to understand what's going on if done in these three stages. And assuming we're talking of the Web Mercator image as shown at https://upload.wikimedia.org/wikipedia/commons/e/ec/Web_maps_Mercator_projection_SW.jpg,
0 degrees latitude and longitude _is_ at its centre.

2. The _scaling_ required, depending on the size of the map image.
Which again will depend on the size of the image (and may be different
for X and Y).

Worse : Mercator maps go from +85 to -85 latitude. That must be part of the

(Or 85.051129.)

formule (I've found several maps where the south-pole is cut off, and a bit >> of the north too. iow, useless without further information).

No, just because the map is cut off at those latitudes, that figure does
NOT have to appear in the formula. The poles _have_ to be cut off,
otherwise the map would be infinitely tall, and very distorted at the poles.

But again no. The result of the formule *is* the scaling (in your and my >> usage ranging from +1 to -1, in Pauls formule case, from 0 to +1). You just
apply it on whatever size Mercator-style map you have handy.

The above image, according to my browser, is 2068 by 2060 pixels.

I think _most_ of those contributing to this discussion know that,
but have not been making it very clear which bits of their formula(e)
do what.

I do not need to know what all the parts of a car do, as long as I can drive
it. The same goes for these two formules. Latitude goes in, something I >> can apply comes out.

True, if that really is all you want. As a scientist/engineer/just
enquiring mind, I don't like to blindly use a formula without knowing
what it does - or perhaps _why_.

Yes, you can drive a car without knowing what each bit does. But knowing
at least some of them will improve your longevity (wear and tear on the mechanisms), fuel economy, performance ... as you drive.

Though the whole problem isn't that nobody understood what you said there, >> but that nobody was willing to compare the (intermediate) results I posted >> with what they got themselves, allowing me to locate where I made my
mistake(s?).

That is indeed one of many problems.

It would be good to see where the following points come out on e. g. the above image, using any formula (longitude given first):
0, 0
+/- 180, 85
+/-180, -85
and some known place, such as London or New York.

Not when I asked for it in my first post, and not when I rather explicitily >> asked for it a few days back. :-(

Regards,
Rudy Wieser

I guess if you just want a formula that works, and _aren't_ bothered
about the three steps - the mathematical conversion from angle to linear dimension, the scaling, and the offset - then we're very different
minds. Which is of course fine; if we were all the same, it'd be a
boring world.

As an engineer, I run a range of values through the equation, to get
a feel for both the rate-of-change of my (broken-or-working) function
as well as the absolute displacement. When we design logic blocks that
cannot be changed, in silicon, we waste a whole month on a test bench to
test all boundaries for mis-behavior. If trig functions were involved,
that just magnifies the amount of work, because then there are lots
of ways to break a thing.

The code I got, has a "clamp" function that sets any value outside 85.051129 back to exactly 85.051129 so that the function cannot produce any
infinities by accident.

#include <stdio.h>
#include <math.h>

/* gcc -lm -o merc.exe merc.c */

int main(void) {
double lat, lon;
const double PI = 3.14159265358979323846;

while (1) {
printf("\nEnter Latitude in degrees: ");
if (scanf("%lf", &lat) != 1) break;

printf("Enter Longitude in degrees: ");
if (scanf("%lf", &lon) != 1) break;

/* Clamp latitude to Mercator limits (approximately 85.05113 degrees) */
if (lat > 85.05113) lat = 85.05113;
if (lat < -85.05113) lat = -85.05113;

/* Convert longitude to X in [0,1] */
double x = (lon + 180.0) / 360.0;

/* Convert latitude to Y in [0,1] using Mercator projection */
/* the C log function is an ln() below, the C log10 function would be a log() */
double rad = lat * PI / 180.0;
double y = 0.5 - (log(tan(PI/4.0 + rad/2.0)) / (2.0 * PI));

printf("Your screen data point is at X=%f Y=%f\n", x, y);
}

return 0;
}

My conclusion from examining the pattern, is

(0,0) is on the upper left of the unit square
and Y is going down the page. That makes -80 near the
bottom.

Enter Latitude in degrees: -80
Enter Longitude in degrees: 0
Your screen data point is at X=0.500000 Y=0.887741

Enter Latitude in degrees: -50
Enter Longitude in degrees: 0
Your screen data point is at X=0.500000 Y=0.660855

Enter Latitude in degrees: -30
Enter Longitude in degrees: 0
Your screen data point is at X=0.500000 Y=0.587425

Enter Latitude in degrees: 0
Enter Longitude in degrees: 0
Your screen data point is at X=0.500000 Y=0.500000 <=== (0,0) is at (0.5,0.5)

Enter Latitude in degrees: 30
Enter Longitude in degrees: 0
Your screen data point is at X=0.500000 Y=0.412575

Enter Latitude in degrees: 50
Enter Longitude in degrees: 0
Your screen data point is at X=0.500000 Y=0.339145

Enter Latitude in degrees: 80
Enter Longitude in degrees: 0
Your screen data point is at X=0.500000 Y=0.112259

Paul


--- PyGate Linux v1.5.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

Paul,

Show me current code.

Explain to me how my code would help you any better than the worked-out formule with its input, partial and full results I already gave.

Besides, the language I'm using might not be the one you know/are
comfortable with, thereby adding yet another layer to the problem.

First rule of bug-hunting : remove everything that has got zero to do with
the problem.

Have the program print out something like this.

[snip list of values]

Alright, here it is :

lat: -80 Y= -1.059456
lat: -50 Y= -0.439171
lat: -30 Y= -0.238666
lat: 0 Y= 0.000000
lat: +30 Y= +0.238666
lat: +50 Y= +0.439171
lat: +80 Y= +1.059456

Regards,
Rudy Wieser



--- PyGate Linux v1.5.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

On 2026/1/25 9:30:57, R.Wieser wrote:

Paul,

Show me current code.

Explain to me how my code would help you any better than the worked-out formule with its input, partial and full results I already gave.

Besides, the language I'm using might not be the one you know/are comfortable with, thereby adding yet another layer to the problem.

[]
English?
One of them is a formula; two or more, though pronounced form-you-lee,
are formulae - or formulas for those who object to classical plurals.

:-)

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

There are a lot of things that children should be shielded from, but
"bad language" isn't one of them.

"Honey, we shouldn't say that when other people are around because some grownups get upset about it. No, I don't know why, they just do."
- "The Real Bev", in mozilla.general 2015-6-7

--- PyGate Linux v1.5.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

John,

English?
One of them is a formula; two or more, though pronounced
form-you-lee, are formulae

Are you sure about that ?

https://www.merriam-webster.com/dictionary/formule

Regards,
Rudy Wieser



--- PyGate Linux v1.5.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

On 2026/1/25 11:2:38, R.Wieser wrote:

John,

English?
One of them is a formula; two or more, though pronounced
form-you-lee, are formulae

Are you sure about that ?

https://www.merriam-webster.com/dictionary/formule

Regards,
Rudy Wieser

Ah, UK/US difference again. In UK, the form formule is 1677-1829 (https://www.oed.com/search/dictionary/?scope=Entries&q=formule),
whereas the form formula is current (https://www.oed.com/dictionary/formula_n?tab=factsheet#3817037 - which
also shows that it exists in US English).

Formula comes from the Latin formula; formule comes from the French
formule, which comes from the Latin formula.

Isn't language fun!

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

Imagine a world with no hypothetical situations...

--- PyGate Linux v1.5.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

John,

Ah, UK/US difference again. In UK, the form formule is 1677-1829 (https://www.oed.com/search/dictionary/?scope=Entries&q=formule),
whereas the form formula is current

merriam-webster doesn't make any such distinction. Who am I going to believe
?

formule comes from the French formule,

Yes, thats what the link I posted says. And for funzels it mentions your singular "formula" as being the plural of of "formule".

Isn't language fun!

Almost as funny as math. :-(

Regards,
Rudy Wieser



--- PyGate Linux v1.5.5
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

On 2026/1/26 11:13:59, Daniel70 wrote:

On 26/01/2026 2:01 am, R.Wieser wrote:

John,

Ah, UK/US difference again. In UK, the form formule is 1677-1829
(https://www.oed.com/search/dictionary/?scope=Entries&q=formule),
whereas the form formula is current

merriam-webster doesn't make any such distinction. Who am I going to believe >> ?

merriam-webster is Yank, isn't it??

Yes.

Nuff said.

Well, despite what many people think (and what many people _wish_!), the majority of dictionaries do _not_ record how language _should_ be used,
but how it _is_. As such, M-W is probably reflecting US usage; the OED
probably primarily reflects UK usage, though usually tries to record US
usage too, but would appear to be somewhat behind on this entry (or, I
haven't got beyond the paywall aspects to delve further).

(There _are_ "prescriptive" dictionaries, mainly for people learning the language as a foreigner, who have need of such.)

formule comes from the French formule,

Yes, thats what the link I posted says. And for funzels it mentions your >> singular "formula" as being the plural of of "formule".

Yes, I noticed that. I've never come across that as a plural (it's very
odd: would only make sense etymologically if the singular was formulum,
which is isn't; that isn't to say that it isn't used though!)

Isn't language fun!

Almost as funny as math. :-(

Well, I enjoy it. (Can't really help it in my family - both parents were language teachers and brother works for the dictionary.) And I do enjoy
_some_ maths (UK spelling!) too.

Regards,
Rudy Wieser

Regards, John

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

G B Shaw said: "Few people think more than two or three times a year; I
have made an international reputation for myself by thinking once or
twice a week." (quoted by "Dont Bother" [sic], 2015-8-24.)

--- PyGate Linux v1.5.6
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

On 2026/1/26 11:11:11, Daniel70 wrote:

On 25/01/2026 10:02 pm, R.Wieser wrote:

John,

English?
One of them is a formula; two or more, though pronounced
form-you-lee, are formulae

Are you sure about that ?

https://www.merriam-webster.com/dictionary/formule

Regards,
Rudy Wieser

Dictionarys .... What would THEY know??

More than you could possibly imagine [(C) Marvin]

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

We'd agreed to overlook each others' families and everything, and
get married" (The Trouble with Harry)

--- PyGate Linux v1.5.6
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

On Tue, 1/27/2026 3:59 AM, Daniel70 wrote:

On 26/01/2026 11:43 pm, J. P. Gilliver wrote:

On 2026/1/26 11:13:59, Daniel70 wrote:

On 26/01/2026 2:01 am, R.Wieser wrote:

<Snip>

Isn't language fun!

Almost as funny as math.ÿ :-(

Well, I enjoy it. (Can't really help it in my family - both parents were
language teachers and brother works for the dictionary.) And I do enjoy
_some_ maths (UK spelling!) too.

As much as it grates on me, I can, sort of, accept the Yank 'Math' ... I mean the full word IS 'MathematicS' and, if you were going to truncate it by dropping the tail-end, then ALSO dropping the 's' makes sense ..... but it sounds so awkward!!

If you were on campus, you would soon get used to acronyms
and abbreviations and shorthands.

Such shorthands are more popular with STEM students. Hahaha.

https://en.wikipedia.org/wiki/Science,_technology,_engineering,_and_mathematics

You can learn many things at university, but a common joke when discussing
what courses to take, would be "Have you considered Basket Weaving...".
See, there really is such a thing. But that would not be shortened
to Bask101. I think you can imagine how such a persons office at
work would be decorated when they graduated.

https://carleton.ca/indigenous/avpii/wp-content/uploads/doublewoven-baskets-1200x900-1.png

I had an applied math professor, where the office he had, had farm tools
in it. A piece of a plow. Various odds and ends you might find in a barn.
We never asked the guy what that was all about, because the
conversation "might become uncomfortable". And you wouldn't
want to be chased down a hall, with a pitchfork. He was one of
my favorite characters because he could derive *everything*
from first principles. He would start at 10AM with a yellow
pad of quad-rule paper, and derive Greens Theory, and for the
1PM class, he would put a solid ten pages of notes on the
blackboard (in one hour). In other words, he did not work from "canned notes". The ink was still wet at 1 PM.

I had to buy a special "high speed pen", just to keep up with him
on note-taking. That's one class you could not arrive with your
Rapidograph (that's a favoured tool of Physics students).
That kind of pen is just too slow.

https://bijansartstudio.ca/product/koh-i-noor-rapidograph-artist-and-technical-pen-1-0-50/

Paul

--- PyGate Linux v1.5.6
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

On 2026/1/27 9:19:47, Daniel70 wrote:

On 26/01/2026 11:44 pm, J. P. Gilliver wrote:

On 2026/1/26 11:11:11, Daniel70 wrote:

On 25/01/2026 10:02 pm, R.Wieser wrote:

John,

English?
One of them is a formula; two or more, though pronounced
form-you-lee, are formulae

Are you sure about that ?

https://www.merriam-webster.com/dictionary/formule

Regards,
Rudy Wieser

Dictionarys .... What would THEY know??

More than you could possibly imagine [(C) Marvin]

Hmm!! "Marvin" .... is that Marvin as in THHGTTG??

It would indeed; the true inheritor of Eeyore (or, Eeyore was the
ur-Marvin).

Yes, at some point in THHGTTG some vapid character (probably Zaphod)
said "Hey, d'you know what?", or something similar, and Marvin, in his
default doleful voice, replied "More than you can possibly imagine".

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

Intelligence isn't complete without the full picture and the full
picture is all about doubt. Otherwise, you go the way of George Bush.
- baroness Eliza Manningham-Buller (former head of MI5),
Radio Times 3-9 September 2011.

--- PyGate Linux v1.5.6
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

On 2026/1/27 9:58:3, Paul wrote:

[]

want to be chased down a hall, with a pitchfork. He was one of
my favorite characters because he could derive *everything*
from first principles. He would start at 10AM with a yellow
pad of quad-rule paper, and derive Greens Theory, and for the
1PM class, he would put a solid ten pages of notes on the
blackboard (in one hour). In other words, he did not work from "canned notes".
The ink was still wet at 1 PM.

[]

If we're swapping lecture anecdotes:

At school (not uni), we had the very opposite of the above: Mr. King in geography used _his_ notes from when he was at school (the same school).
He _had_ added a footnote about North Sea Oil (this was the 1970s).

At uni, I once dozed off while actually in the act of taking notes; on examination afterwards, the letters just got smaller over about three
words, then stopped.

"This is a one-line proof - of we start sufficiently far to the left."

Old professors never die - they just lose their faculties.

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

Intelligence isn't complete without the full picture and the full
picture is all about doubt. Otherwise, you go the way of George Bush.
- baroness Eliza Manningham-Buller (former head of MI5),
Radio Times 3-9 September 2011.

--- PyGate Linux v1.5.6
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Subject: Re: Worldmap mercator projection - Latitude to Y calculation. - last try

On Tue, 27 Jan 2026 19:59:05 +1100, Daniel70
<daniel47@nomail.afraid.org> wrote:

As much as it grates on me, I can, sort of, accept the Yank 'Math' ... I >mean the full word IS 'MathematicS' and, if you were going to truncate
it by dropping the tail-end, then ALSO dropping the 's' makes sense
..... but it sounds so awkward!!

You want awkward? Try telling everyone "I won a maths debate! I won a
maths debate!" See if they look at you funny.


--- PyGate Linux v1.5.6
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)