Problems with mapping around the poles
January 31, 2008 21 Comments
OK, so I’m going to use my own IMS server to handle the pole projection issue but that brings up a couple issues that I’ve got to figure out.
- How to handle data that was not created in polar projections. Martin linked to a paper by Waldo Tobler that hits on some of the issues. Right now I’m only thinking points, but you know that the client will want polygons eventually.
- What do I do with global datasets? Sure the Bipolar Oblique Conic Conformal works well for the poles, but what about the equator? Folks are used to Mercator so there has to be some sort of change between the two which adds complexity. I guess one could use a 3D globe such as VE3D, but I’d rather focus on the simplicity of a 2D map.
I’m paying my penance for making fun of polar projections all these years.
Freaking polar projections are making me bald
About James Fee
Ugly hacks? Three title sets, one mercator, one polar stereographic N, one polar stereographic S, and swap between them as the center of your map panel crosses the arctic circle…
Or, no tile sets at all, do dynamic rendering for the whole earth, but instead of altering your x/y when you move the map around, alter the origin points of an orthographic projection. That could be fun.
I think that dynamic rendering really pays off in these cases. Tiles are great and all, but falls down when the area of interest can’t easily be cut-into square pieces.
I think that a Mapscript (Mapserver!) approach to dynamically adjusting the projection (like Paul mentions above) based on latitude might do the trick nicely.
Great idea Paul!
what about these projections used for satelite tracks (i forgot the name,) or you can use cylindric projection with oblique (touching) axes (e.g. u=-90deg,v=45deg) – if focusing on one pole
Two poles is a requirement.
Can you use the Universal Polar Stereographic coordinate system? You would get the advantages of low-distortion stereographic projections and planar coordinates.
mhm .. maybe you buy yourself an orange and try to cut it in a way which may fit to your problem
(then you find out what type of projection/transformation it may be?) . Otherwise 3D is the only choice (give those people a short course in projections using the orange and they may understand the problem)
Oops, forgot about these guys…
http://freeearth.poly9.com/
@Justin, that is a good idea. I can just change to that projection near the poles and stay in Mercator the rest of the way.
@mentaer, most globes still have distortion at the poles. Is there one you think might work well.
Turn the Mercator projection 90 degrees.
Ever heard of the Fuller projection?
http://www.grunch.net/synergetics/map/dymax.html
It’s rarely used, but might be just what you’re looking for. ArcCatalog supports it.
I haven’t tried it, but switching projections would be bad if you are using cached map services, because your labels could end up upside down.
I did a test digitizing a polygon over the south pole in Antarctica using the South Pole Orthographic projection. When I changed ArcMap to a UTM projection it clipped the polygon. ESRI uses a “projection horizon” to check if features are in the valid area of a projection to decide whether to render them and clip them if necessary.
It appears ESRI handles the display problems, but what about spatial analysis? Think about the shortest distance between two points; the ESRI answer depends on your map projection, because computation is performed using Euclidean geometry.
Waldo Tobler mentions one system that supports global analysis:
“The one exception, explicitly designed to consider the spheroidal earth, is the Hipparchus system”
http://www.geodyssey.com/papers/hlauto8.html
Why not use one of the 3D viewers (ArcGIS Explorer / Virtuel Earth 3D/ Google Earth) ? You can use the existing tiles and still map the poles.
Morten, take a look at how VE3D handles the poles. It doesn’t work any better because they are just wrapping Mercator around a globe and filling in the ends with a color. You can’t place a point on the pole AFAIK.
The only thing I can think off is what you said to Justin: switch projections at some point. At the poles use azimutal projections (depending if you need equal-distance, equal-area, conform… i.e. chosing among gnomonic, orthographic, stereographic projections…) and inbetween cylindric projections (i.e. mercator/ UTM projections). In essence you need to switch projections quite often.
(btw. a german page, but with many nice images: http://www.boehmwanderkarten.de/kartographie/is_netze.html)
It looks like James has already moved on to a new blog posting, but I think you guys are missing a point here. Projections have limitations beyond distortions in shape, area, distance, and direction. They cannot represent large features easily like great circles or techtonic plates. I like Tobler’s comment about analysis that “neglects the danger from intercontinental missiles”. All our GIS software is suitable only for small areas.
Here is a quote from the Hipparchus paper:
“A failure to understand the precise nature of spatial data (especially, by ignoring the profound conceptual difference between an analog map and the true data domain) often leads to a blind transplant of conventional cartographic techniques into a computerized system. This seldom results in a satisfactory geopositioning model: cartographic projections are notorious for their computational inefficiency; global coverage usually requires the use of location-specific transformations. Programming becomes progressively more complex as the precision requirements increase. Boundary problems are difficult to solve; this imposes discontinuities or size restrictions for the models of spatial data objects. Finally, classical cartography offers little or no help in modelling of the near-space geometry. The same system can therefore be forced to employ two disparate numerical methodologies: one for the positions on the Earth surface and quite another for orbital data. This presents an increasingly serious problem in many emerging high data-volume applications.”
@Martin: The problem is that users don’t see GIS application as suitable for small areas. The requirements are that it handle both poles and all the space in between. Now reality says that is impossible, but the expectation is that there is a solution out there. Compromise is at the core of creating web applications and has been since the beginning. The problem with polar web mapping is there is nothing to compromise on. Its all as Paul put it “ugly hacks”. I don’t disagree with with the papers we’ve been reading here at all. In practicality I’ve got to make recommendations that aren’t going to agree with the conclusions.
Thank you. I just wanted someone to acknowledge the earth is not flat.
Now bring on the Manifold comments.
My guess is that Pyxis’ digital earth reference could handle it, but it is a propretary system. Its a projection/reference system initially developed for defence activities. I’m not sure if you are looking for that type of a solution.
Based on the demos that Perry Peterson gave to one of my clients, the performance is amazing.
http://www.pyxisinnovation.com/pyxwiki/index.php?title=How_PYXIS_Works
use the Fuller projection
Greetings – A note on how we handle projections for the suite of Arctic Research Mapping Applications (http://armap.org) in ArcIMS, GE and AGX.
In ArcIMS, we’re serving 6 ArcMap services (all hitting an SDE database and ArcOnline) each with a different central meridian for Lambert Azimuthal Equal-Area (to ensure that the polar orientation is correct for each of the major Arctic nations.) The different polar views are then accessible to the user through a pulldown “Zoom to” menu (Zoom to Russia, Zoom to Greenland, etc.) You could do the same with any combination of projections and simply reproject your ArcMap data frame to whichever polar projections you opt to use and one that works for your project at the equator.
We’re also serving up the data as KML for use in GE and in AGX. We often see weird artifacts of missing data in GE at the pole and AGX does not handle the symbology for WMS or Globe services well at the poles in build 410 (so here we use the kml to display points without distortion and we run custom query tasks against an SQL web service. Awkward, but it works for a prototype. We haven’t tested if the polar symbology issues have improved with build 440 for AGX.)