# Using mathematical hack (EPSG 4326 to EPSG 3395)?

I am currently in the process of writing my own GIS. While doing so I thought of a hack for transforming points from EPSG 4236 (WGS84, geographic coordinates) to EPSG 3395 (World Mercator, projected coordinates) and wanted to ask if this hack has any mathematical drawbacks.

I am drawing the coordinates using the graphics card (using OpenGL). OpenGL works on the basis that the coordinates in a window go from -1.0 to 1.0 - see this picture for illustration. OpenGL has a thing called a vertex shader. You can use it to transform the given coordinates in a highly parallel way (instead of transforming one coordinate at a time, you can transform millions at a time, it is very fast). The coordinates that I get are always in the WGS84 coordinate system.

Now, what I did was the following: I know the height / width of the window (let's say 800 x 600 pixel) and the DPI of the monitor. I also know the center coordinate (where the user is currently looking at) in WGS84.So what I do get the accurate scale is that I first transform the center of the screen into EPSG 3395 using the regular conversion. I calculate the real-world scale of the window in meter using the DPI number, scale the result by the current scale (let's say 40.000) and calculate the "bounding box" of the window in EPSG 3395 (add / subtract to the center of the screen). Then I transform said bounding box back to EPSG 4326 using the reverse formula. I do this every time the user zooms / pans the map / resizes the window. So I have to do only 5 coordinate transformations, instead of possibly thousands.

Then I upload the bounding box and the coordinates in EPSG 4326 to the GPU / OpenGL. The shader for transforming the EPSG 4326 coordinates into OpenGL coordinates (from -1.0 to 1.0) looks like this:

``````in float x;
in float y;

uniform float north;
uniform float east;
uniform float south;
uniform float west;

void main() {

// x, y is "each coordinate"
// this function will run for each coordinate pair in parallel

float delta_east_west = (east - west) / 2.0;
float delta_north_south = (north - south) / 2.0;

float final_x = -1.0 + ((x - west) / delta_east_west);
float final_y = -1.0 + ((y - south) / delta_north_south);

gl_Position = vec4(final_x, final_y, 0.0, 1.0);
}
``````

So I am basically setting the coordinate as a percentage of the window width, which gives me a value between -1.0 and 1.0 - if the coordinate is in the currently visible area. The result looks like this:

To me, this looks like a mercator projection, however I am not sure if it actually is. The intended use does not have to be highly accurate or measurable, discrepancies of up to a meter are OK, this is intended for cartography (only the scale is important). Does the mercator projection require me to run each point through the (quite complicated) conversion function? For highly accurate mapping, I would of course not do this and use a CPU-bound approach for increased accuracy, but I am wondering if I have a mercator projection now or something else. However, for cartography, it was very important that I can smoothly zoom in / out very fast, at the cost of accuracy. What I think is that my map may be accurate at the edges, but not in the middle.

I should not that the chosen UTM zone is always the zone that the middle of the screen lies in. For example, if the middle of the screen lies in UTM zone 30, the reverse transformation (from meters to degrees) of the screen bounding box will be done using this zone, although the coordinates may be in a different zone.

You are essentially performing a linear approximation of the Mercator projection formulas in the display window. This will be fine in large scales (small areas) where the distortion can be assumed constant throughout the window. However, you need to account for it because the actual displayed scale will differ by a factor of `sec(phi)` (secant function of latitude) - this is the distortion.