Mapping beyond Web Mercator
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
Title |
| |
Alternative Title |
| |
Title of Series | ||
Number of Parts | 295 | |
Author | ||
Contributors | ||
License | CC Attribution 3.0 Germany: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
Identifiers | 10.5446/43390 (DOI) | |
Publisher | ||
Release Date | ||
Language |
Content Metadata
Subject Area | ||
Genre | ||
Abstract |
| |
Keywords |
FOSS4G Bucharest 2019193 / 295
15
20
28
32
37
38
39
40
41
42
43
44
46
48
52
54
57
69
72
75
83
85
87
88
101
103
105
106
108
111
114
119
122
123
126
129
130
131
132
137
139
140
141
142
143
144
147
148
149
155
157
159
163
166
170
171
179
189
191
192
193
194
195
196
197
202
207
212
213
214
215
216
231
235
251
252
263
287
00:00
Texture mappingCellular automatonAddress spaceMappingAreaWeb 2.0Goodness of fitComputer virusSoftwareLecture/ConferenceXMLUML
00:22
Web 2.0MappingPresentation of a groupDemosceneFrustrationSystem callLecture/Conference
00:42
Continuous functionAlgebraic varietyWeb 2.0TesselationPresentation of a groupOpen setFreewareTexture mappingFrustrationProduct (business)DialectElektronisches MarketingState of matterLine (geometry)Mechanism designComputer animation
02:13
AreaShape (magazine)DistanceDistortion (mathematics)Local ringMaxima and minimaAxonometric projectionNormed vector spaceEquals signAzimuthObservational studyChemical polaritySample (statistics)SpeciesFunction (mathematics)Codierung <Programmierung>Client (computing)InfinitySphereWeb 2.0SurfaceDistanceNumberCurvatureElectronic mailing listTexture mappingAreaAlgebraic varietyEqualiser (mathematics)Physical systemQuicksortWhiteboardGroup actionMultiplication signTime zoneArchaeological field surveyStatisticsInterpreter (computing)Distortion (mathematics)CASE <Informatik>Data storage deviceInsertion lossWorkstation <Musikinstrument>CodeLocal ringWeb-DesignerInstance (computer science)Focus (optics)Perspective (visual)Ring (mathematics)Point (geometry)Process (computing)ArmTorsion (mechanics)Type theoryOvalCircleNetwork topologyVideo gameReading (process)Maxima and minimaPhysical lawPower (physics)Pole (complex analysis)Line (geometry)Stereographic projectionSpeciesComputer reservations systemAzimuthNeuroinformatikCoordinate systemStandard deviationDoubling the cubeComputer animation
08:26
Computer multitaskingLine (geometry)Axonometric projectionSocial classTransverse waveConic sectionChemical polarityAreaEquals signAzimuthReading (process)Unified threat managementRaster graphicsEllipsoidMoving averageAlgebraic varietyPixelPoint (geometry)TheoryMathematicsValidity (statistics)Continuous functionTexture mappingLine (geometry)CASE <Informatik>NP-hardLimit (category theory)CurveFilm editingPolygonInheritance (object-oriented programming)ResultantSet (mathematics)Server (computing)MedianEllipsoidMereologyAreaGreatest elementCuboidMappingFunction (mathematics)HeuristicDegree (graph theory)Conformal mapSoftwareFile formatVideo gameExpressionInternational Date LinePhysical systemService (economics)Boom (sailing)WebsiteTerm (mathematics)Noise (electronics)Endliche ModelltheorieGoodness of fitProduct (business)QuicksortShift operatorComputer animation
14:25
Axonometric projectionMathematicsDegree (graph theory)Unified threat managementSatelliteComputer-generated imageryPhotographic mosaicUltraviolet photoelectron spectroscopySatelliteDigital photographyResultantOrder (biology)Source codeCASE <Informatik>PixelUnified threat managementAlgebraic varietySoftwareTexture mappingPhotographic mosaicMetreMultiplication signServer (computing)Computer animation
15:55
Social classKolmogorov complexityAxonometric projectionUnified threat managementTime zoneLarge eddy simulationVideo gameNatural numberTexture mappingEndliche ModelltheorieCASE <Informatik>Algebraic varietyMultiplicationAngleMultiplication signSoftware developerLevel (video gaming)WordWeb 2.0
17:37
Texture mappingForm (programming)Operator (mathematics)Cache (computing)Multiplication signClient (computing)File formatSet (mathematics)Overhead (computing)Disk read-and-write headQuicksortVideo gameObject (grammar)CodeProper mapEndliche ModelltheorieMedical imagingPiOpen sourceSystem callSource codeTesselationAlgebraic varietySocial classOptical disc driveDifferent (Kate Ryan album)Level (video gaming)TouchscreenPrice indexComputer clusterSound effectDefault (computer science)WeightFilm editingAreaFormal grammarPhysical systemData storage deviceScripting languageLatent heatTransformation (genetics)Row (database)ImplementationServer (computing)Functional (mathematics)Beer steinProcess (computing)Computer configurationType theoryInformationAlgebraPole (complex analysis)Traffic reportingKey (cryptography)Machine codeWeb 2.0Java appletClosed setMereologyVector spaceTessellationRouter (computing)NumberZoom lensMobile WebCodeSoftware bugAdaptive behaviorBitIntegrated development environmentFunction (mathematics)Response time (technology)Touch typingNetwork topologyHoaxElectric generatorMilitary baseCoordinate systemLecture/Conference
Transcript: English(auto-generated)
00:07
OK, so let's go to the second address in this session, Andrea Jaime, who doesn't need the introduction. And Andrea will explain this how to do web mapping without Mercator. That's awesome.
00:21
Hello. Good morning, everybody. My name's Andrea Jaime. I'm going to talk about mapping beyond Web Mercator. I work for GeoSolutions, an Italian-based company that supports and develops GeoServer, GeoTools, GeoNetwork, GeoNode, and a few others. The topic of today's presentation is, well,
00:43
let's say, my frustration with seeing Web Mercator everywhere. So why do people use Web Mercator? Well, because there's plenty of free and ready-to-use tiles out there, OSM, Google Maps, Bing Maps, whatever, Open Map tiles.
01:01
They are all in Web Mercator. So you just have to go cherry-pick ready. You have your own base map ready to go, and you just have to think about your overlays. So why bother about other productions when you can have this for free? Why? Because it's familiar.
01:21
I think it's a tragedy that people are used to look at the world like this, but that's how it is in these days. And why? Because it's easy. Learning about projection is not exactly the easiest thing of the world. And well, I think that from Luis's presentation and the next presentation and my presentation,
01:41
this will become very evident. So why make the effort to learn several of them when you can get away with just one? There's one merit to the Web Mercator. It's fair to the dateline. It turns the world into a continuous map.
02:00
So you can just put two of the maps side by side, and you get a continuous mapping across the Pacific, which is kind of nice, and I think that people living in New Zealand appreciate that. Some reasons to avoid the Web Mercator. Why you should stay away from it? One reason to rule them all, the reason
02:22
that Luis was talking about, distortion. Every map projection induces some distortion because we are going from a double curvature surface, which is the Earth, to a flat surface. So we want to minimize a certain type of distortion in a certain area, and that's the job of each map
02:41
projection. So what is the distortion of Web Mercator? Well, Web Mercator distorts areas in a very significant way. So let's say that we took Italy, where I live, and we moved it atop Greenland.
03:01
Italy would suddenly become so much bigger, we probably wouldn't like the climate there, but. So yeah, and just another example. We keep on looking at UK that way. Well, UK is actually three times smaller than we see it in the Web Mercator. And I mean, this problem becomes bigger and bigger
03:22
as you move far north. So equal area maps to the rescue. What is the problem? Well, Luis was providing us a perspective about computation times and storage, but there is also a problem of perception.
03:41
Yes, you can use tools to measure areas, to measure distances on a map. You cannot turn off your eyes, and your eyes perceive relative proportions naturally. So you cannot just stop your brain from doing that. So you can look at the map and say, oh, this is two times bigger than that.
04:02
If interpreting the map is based on such reasoning, people will do it whether you like it or not. So you need, in that case, an equal area projection. So all kinds of statistical maps need this kind of projection. This is an example from FAO.
04:25
And then there's another problem, which is the distance perception. Again, the Web Mercator distorts distances in a very significant way. Again, if your map and the reading of your map
04:42
is somehow related to comparing relative distances, you cannot stop your brain from saying, ah, that is two times longer than this. And then you have it very wrong if you are using Web Mercator. These are lines of equal distance
05:02
at 300 and 200 kilometers from Maribor, Slovenia. They are not circles, as you can see. They are more like eggs. So as you can see, the distances far nor are exaggerated a lot. So what do you do? You can use an equidistant map instead. An equidistant map, like the Azimuthal equidistant,
05:24
for example, makes all distances equal to a center point. So if you have a use case in which you have a focal point in your map, and you wanted to make it very easy to perceive the relative distances from that point, then you use an equidistant map.
05:40
And well, you've probably seen it around, like in the UN logo, for example. Another case here is weather radar maps. So we have weather stations, and we wanted to map the area around the weather station. Distances from the weather station are kind of important in this kind of interpretation,
06:00
so that's why the Canadian Weather Service uses this kind of projection. Another problem with Web Mercator is that it never includes the pole. Sometimes it includes Antarctica, sometimes it's so bad looking that people just strap it away.
06:22
Let's forget about it. And well, the poles are kind of important in this age and time. Anyone worried about climate changes and stuff like that? Well, the poles are where the action is. So for that, if you are particularly interested
06:40
in the poles, there are the polar stereographic projections. This is one example from the Northern Pole. And another, they are, well, at least the second is geo-server powered. Another one from FAO, the species distribution, and that's a south polar instead.
07:05
And then, well, why do you not use Web Mercator? Because the law tell you otherwise. And there are lots of laws telling you that you should be using something else. I don't think there is any law anywhere telling you to use Web Mercator.
07:21
It's just a sort of de facto standard for web developers. But if you are here in Romania, I asked Codrina to give me a list of common coordinate reference systems for map publishing in Romania, and she came up with this list. Web Mercator is one of them,
07:41
but you typically have to support others for inspired compatibility and to support the local way of viewing Romania, okay? So long story short, there are lots of reason to stay away from Web Mercator.
08:00
And then there are also the autocodes in WMS. Autocodes are a way to specify a generic CRS like a Mercator, for example, and provide the central access of it on the fly. And we have a number of customers doing that because they want to center the projection on the viewing area continuously
08:22
to get the minimum distortion possible. Okay, how do you handle all these projections? Okay, well, theoretically it should be simple. Luis already showed us that it isn't. In theory, one should just take each point or each pixel and reproject it to the target projection,
08:43
and while it's done, what could possibly go wrong? Luis already showed us an example. Much can actually go wrong, especially if you are a global data set and you want to reproject it to a local projection, which is something that we do a lot with our customers.
09:02
So this is one example of taking a world map with all the countries in latitude, longitude, and reprojecting it fully to UTM 32 North. This is the result that you get. That thing that I think over Europe is Russia,
09:20
which is a huge polygon that goes way beyond the limits of UTM 32 North valid area. And well, the math starts wrapping around and you get that mess. And the other problem that typically we are dealing with and we are going to talk about is the dateline. It's like the world ends there and most of the software cannot handle it.
09:43
So what's going on? We have a global data sets versus locally defined projections. We have data crossing the datelines. We have a very long lines and so on. Do we have to pre-process our data to, you know, handle these issues? Well, if you are just targeting one projection,
10:01
you can pre-process your data. But what if you are targeting a hundred or infinite if you are using auto codes? You cannot just do it. The software has to do it for you on the fly. So in G server, we have this advanced projection handling subsystem that does a bunch of these things. And as a set of heuristics projection by projection
10:23
to handle the common hiccups. So step one in APH is deciding which data to read, which sometimes is not obvious because if I'm displaying something across the dateline, I might be have to pick data from the two ends of the longitude grid.
10:43
So G server takes one bounding box that you provide and typically generates two to read from in your original data. Then you have to cut excess data. So you have to cut polygons, you have to cut lines so they don't go beyond the area of definition
11:01
of the projection. I'm not talking about the legal area of definition. I'm talking about where the math is still somewhat stable. So for a UTM, for example, it would be 45 degrees from the central median. After that, it starts going haywire. Then you might have to wrap data.
11:21
If I'm mapping across the dateline, I might have to replicate data that was on the other side of the dateline on this side so that I can get a continuous map. And then I might have to do dynamic densification. So if you're a project just point by point and you have very long lines in the input,
11:40
you will get very long straight lines in the output, but the desired output is a curve instead. So what your server does is to determine how much deformation there is, and then it starts adding points in the middle. It doesn't generate a generic curve. It's still all straight lines, but we have so many that you perceive a continuous curve.
12:05
And then we are project, and during the projection, some dateline crossing might occur. This is just a datum shift, but some points that were touching the dateline go right on the other side. So we have to deal with that.
12:21
So there is a heuristic that detects dateline crossing and unwraps it so that we get a nice map. So let's see some side-by-side examples of what happens with and without APH because you can enable and disable it in GeoServer. So PDC Mercator, it's a Mercator centered on the Pacific.
12:45
So it's centered more or less on the dateline actually the center is 150 degrees east. So if I don't do anything, Antarctica goes away, Greenland goes bizarre, and I don't have a continuous map.
13:02
With APH, everything looks like it should. If I try to a project in a Lambert conformal conic, which is an interrupted projection, I get Russia and part of that area that again goes bizarre in a similar way
13:22
to what Luis was showing us. GeoServer determines that we are going beyond the area of definition, cuts the data, and voila, we get the result that we want. Silly datum change. Let's say we go from 4326 to 4230.
13:42
Just a different ellipsoid. Stuff keeps going on the other side of the dateline, kaboom, we get long lines everywhere. Antarctica has that bizarre thing at the bottom. With APH, we detected the dateline crossing and fixed them. And this is the 32 North case. The super bizarre thing and then the data cut
14:03
in the area of validity and properly displayed. Let's say I just want to center on the Pacific. Well, if I don't do anything, I get only half of the map that I wanted. I have to replicate the rest of the data on the other side of the dateline, which APH does.
14:23
There are some other hard data cases to handle, like many meteorological data are not delivered between minus 180 and 180, but between zero and 360. And I'm like, what? So we have to teach the software that there are these cases and to do multiple reads
14:42
and stitch stuff together again in the map. And then there are satellites and satellites and more satellites. Sentinel-2, Sentinel-3, Sentinel-whatever, Sentinel-N. They keep on mapping the planet. They keep on taking photos. And for some reason, they decided to keep taking photos
15:03
even across the dateline. I mean, the world ends there. You shouldn't be taking a snapshot there in the middle of a discontinuity. But they do because the planet exactly continues there. So they then give you the data in UTM-60 or UTM-1 with the actual pixels going across the dateline.
15:23
So we need to handle that and in order to generate a continuous mosaic. In those cases, for the Sentinel case, for example, they give you data in all the UTMs plus the two UPS, you end up with more than 120 projections
15:41
as your global mosaic sources. And this is a GeoServer displaying the result of reproducting everything towards WGS-84 and generating a seamless map. Some final words. Is this the beginning of the end?
16:00
People started noticing that Web Mercator is bad. We have one actor in particular named Google that stopped using it, at least when you are zoomed out. And they decided, well, what about if we use the globe instead? I have the impression that some other will follow and eventually Web Mercator will fall out of favor.
16:21
That's at least my hope or dream. So in summary, more projections are coming in every day. There is life outside 3857. And the GeoServer with the APH helps you to support multiple projections and keep on publishing global data
16:41
in whatever local projection you want. You may think, okay, this is making my life more complicated. Yeah, okay. But it also making your life and your maps more interesting and more informative. If one projection that you care about is not supported, you can add it.
17:00
If you want advanced projection handling for it, you can also add it because everything is pluggable. So in the case of the homologine, we would have to add the projection first and then add a subsystem in the APH to deal with its interrupted nature, which is feasible. It's just a matter of developer time.
17:23
And that's all. Plenty of time for questions. Just wait for the microphone to get to you. So what is the performance overhead of this setting?
17:42
Can you say anything about it? Sorry. Okay, so yeah, it has an overhead, but it's normally enabled by default in GeoServer and most people do not notice that it's working.
18:01
The only part that is a bit expensive is doing the cutting at the area of definition of a projection. That goes through JTS and it's a topologic operation. That's slow. The rest of it is actually pretty fast.
18:23
Are you familiar with the adaptive composite map projections like from Bernard Yenny? When, depending on where you navigate on the globe, it will morph into a different projection. Basically most useful in a interactive map.
18:42
So for example, if you're zooming, it would morph into a web map in certain areas. On the poles, it would be more stereographic and so on. I think it's built into S3 ArcGIS also as an option. But there's also open source Java-based implementations for it.
19:03
No, never heard of it, sorry. Yeah, sounds interesting. Any other question? Yes? Not for us.
19:26
Okay, my question is the implementation of this transformation and reference systems, is it related or somehow to the project or is it a standalone thing?
19:43
It's a standalone thing, but there is a relation. So in the Java world, getting in touch with native code is like mating between porcupines. It's really, really hard.
20:02
Establishing the calls to native code is tiresome project activity. There is a very significant overhead calling native code. And so even if the native code is fast, calling it, especially if you call it very often,
20:21
like many, many calls, very chatty relationship, it's gonna kill the performance of your software. So pure Java instead. It's much faster, easier for us to maintain. However, there is a relationship. If you look at the code of the projection classes and just the projection classes, you will recognize approach because they are ports
20:41
from C to Java, adopting the syntax. So if you need to do a molesin, you literally look at the layout of one of our supported projections and replace the molesin coding from approach and then make it work with Java, which is normally not too far away.
21:17
I wonder about the ideas about making the information,
21:23
which is projected in many, many kind of projections perform very fast because the most common idea is just to keep the vector types, for example, in many projections pariahily, in the projections we are used most. And I wonder if there are some kind of improvements
21:40
to this kind of making a tree of few projections where we have to maintain every kind of tiles possible. Okay, so if you look at the Mapbox vector tile specification, they say that the default is Web Mercator, but actually the vector tile itself contains no indication
22:04
of what projection it was meant for. Also the vector tiles inside, they are already projected on the screen. So the values are not coordinate reference system anymore. They are already screen based. So you can actually generate vector ties
22:23
for whatever projection you want. The problem is that most of the clients assume the layout of the Web Mercator and they won't work with a different layout, different zoom levels, different number of router tiles, like if you have a projection, sorry, a grid set that has a two by one router tile instead of having just one, it won't work and so on.
22:44
Another thing is that pre-populating the tile caches is not the only way to go. I think that Mapbox has pushed it a lot because technologically they want to go to S3, stick the data in there and then work from the cheapest possible source in Amazon.
23:03
But vector tiles can actually be generated on the fly and most of the time they are actually faster to generate than a PNG because the PNG encoding literally kills you performance wise. It's like 50% of the whole response time if your data sources are fast enough. So I see no reason not to use Mapbox vector tiles
23:23
with another projection and generate them on the fly. So you can support whatever projection you want. If you look at the GeoServer code, it's actually a WMS output format. You can literally ask for a vector tile doing a get map
23:41
with whatever size, with whatever projection. There is only one thing that a vector tile has to be square. So if you ask for a 500 by 700 image, GeoServer will generate you a 700 by 700 vector tiles with a side which is empty.
24:11
I think we'll close. Hi, what is your preferred client when not working with Mercator?
24:24
Client. Okay, it's time for a confession. I don't use clients. I don't use GeoServer. I use a Java ID called IntelliJ. That's what I use 90% of my day. So I developed GeoServer,
24:41
but it's not like I actually use it. I'm most of the time stuck in an IDE trying to get new functionality or bug fixes for it. I have no idea about clients. I cannot develop in JavaScript, so no clue. I can tell you what my company went for. In MapStore, we decided not to choose,
25:02
and it supports both OpenLayers and Leaflet and Cesium. So OpenLayers we use for anything that is OGC protocol-heavy. Leaflet for mobile and anything that is very simple. And Cesium for whoever wants the thrill of 3D,
25:21
of fake 3D, because it's just 2D maps draped onto a globe. All right, we have to close it there. Thank you very much, Andrea. We'll resume this session at noon.