ISRIC:152160 - The Homolosine Projection in a Big Spatial Data framework
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 |
| |
| 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/43446 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
FOSS4G Bucharest 2019138 / 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
SoftwareReal numberPresentation of a groupPerspective (visual)MappingCategory of beingComputer fontBitGoodness of fitTexture mappingMoment (mathematics)Lecture/Conference
01:28
Organic computingAreaEquals signAxonometric projectionRaster graphicsAngular resolutionCellular automatonLogical constantCase moddingLevel (video gaming)Similarity (geometry)Statement (computer science)Mathematical analysisMaß <Mathematik>Electronic visual displaySource codeError messageIcosahedronInjektivitätPairwise comparison1 (number)Cellular automatonFigurate numberEqualiser (mathematics)Stack (abstract data type)NumberSelectivity (electronic)Arithmetic meanCASE <Informatik>Line (geometry)WhiteboardConstructor (object-oriented programming)Discrete groupDevice driverInverse elementExpected valueCirclePoint (geometry)Raster graphicsLibrary catalogPlatonic solidPairwise comparisonComputer programmingMultiplication signSurfaceDistortion (mathematics)Graph (mathematics)Digital photographyAreaBitShape (magazine)MappingRing (mathematics)Texture mappingInformationGraph coloringGoodness of fitBeat (acoustics)Forcing (mathematics)Lipschitz-StetigkeitCausalityState of matterCryptographyFile archiverNichtlineares GleichungssystemSurgeryGreen's functionLatin squareAngleRegular graphDegree (graph theory)Inheritance (object-oriented programming)InternetworkingWeb pageDemoscene19 (number)GoogolDirection (geometry)Universe (mathematics)Computer animation
08:52
AreaEquals signInfinityProgrammable read-only memoryBoss CorporationDistortion (mathematics)SummierbarkeitAxonometric projectionSicMultiplicationCellular automatonPoint (geometry)Vector spaceDatabaseRaster graphicsVector graphicsOpen setElectronic visual displayGoogle EarthImplementationSoftwareService (economics)CodeLocal GroupArchaeological field surveyFunction (mathematics)Codierung <Programmierung>Programmer (hardware)Inverse elementProcess (computing)MappingException handlingAngleAreaSoftware bugSign (mathematics)CodomainTerm (mathematics)EllipsoidPresentation of a groupDistanceVector spaceNeuroinformatikCASE <Informatik>SurfaceRandom matrixSoftwareGrass (card game)GoogolPoint (geometry)ImplementationRepository (publishing)Distortion (mathematics)Equaliser (mathematics)CodeMathematicsMiniDiscResultantSpacetimeWeb 2.0Texture mappingComputer programmingBitMereologyGoodness of fitTesselationServer (computing)Cellular automatonNumberGeometryRow (database)Revision controlArrow of timeOnline helpForcing (mathematics)Right angleForm (programming)InfinityNormal (geometry)System callCycle (graph theory)Pairwise comparisonDivisorProcess (computing)Shift operatorReal numberInstance (computer science)Image warping
16:15
Computer animation
16:38
InformationPresentation of a groupEvent horizonComputer animation
17:04
Dependent and independent variablesMultiplication signExecution unitLecture/Conference
17:26
InformationMultiplication signPhysical systemCodeCodeCoordinate systemTerm (mathematics)Latent heatSystem callPersonal digital assistantComputer animation
18:21
Revision controlHookingInstance (computer science)Coordinate systemTexture mappingComputer programmingTerm (mathematics)Server (computing)Right anglePredictabilityDatabaseSlide ruleInverse elementMultiplication signCodeSoftwareMappingState observerSign (mathematics)Different (Kate Ryan album)Program slicingEndliche ModelltheorieProduct (business)Group actionLecture/Conference
Transcript: English(auto-generated)
00:07
OK, good morning. Thank you all for coming to this session. We'll be speaking mostly about map projections. I will be the first speaker introducing what is much more a user perspective on this topic. And then we'll have two other presentations that are a
00:23
bit more technical and go more into the software. OK, so my name is Luis, and I work at a place called Izrik. Oh, just a moment. They replaced this, but didn't put the.
01:01
Sorry for that. Let's see. All right. OK, this is the outline of the presentation. Well, let's go forward. So the problem, why am I here today? As I said, I work at Izrik. And Izrik does, among other things, maps of soil properties for the whole world.
01:21
And this is one of our maps for 2017. Quite a beautiful map, but there is something wrong with it. I don't know if that's obvious. If I tell you that this map takes up five gigabytes and took several days to compute, does that ring any bells?
01:45
There is an obvious problem with this, is that it's not an equal area projection. So this is a raster where the cells are defined by intervals of latitude and longitude. The problem with this is that these cells, they start to become really, really small as you move away from the equator.
02:01
And here in this example, we have in green cells that are defined at regular intervals in an equal area projection, and in blue, cells that are defined in the previous map, in what is called the Marinos of Tyria projection, a very, very old projection. And as you can see, the cells get smaller and smaller.
02:22
In the end, you have 60% more cells in your raster in this kind of projection than if you would use an equal area projection. Why is this happening? Well, before that, just to say that this is not only ISRIQ doing this, but there are many, many data sets out
02:40
there that are published in this kind of projection with rasters defined on cells with equal intervals of longitude and latitude. And these are just a few examples. Why is this happening? I'm not really sure. I can speculate a little bit. But one of the things that I know is that it's not so
03:03
easy to work with equal area projections in a phospho-G stack. So yeah, let me just show you why this is the case. This is New Zealand in the stereographic projection, meaning that if you were on board the International Space
03:23
Station and you would go over New Zealand looking down, you would see something very similar to this. If you plot this with an equal area projection, in this case, Eckert 4, which is a somewhat popular projection, you see that things start going a little bit wrong.
03:41
And if we go to an even older projection, like the worldwide, well, it doesn't really get better, does it? And if you go to the sinusoidal, probably the oldest equal area projection of them all, you start to seeing things like this. And your poor kiwis transformed into bananas, the silver lining being that now Australia is much closer.
04:01
So they don't need to fly six hours or so to get to Australia anymore. So yeah, those are the kind of questions that I was confronted with. So what I did, I went to the Proj manual to look exactly what kind of projections are there, what kind of projections are available that I could work with.
04:22
And in fact, Proj supports a lot of projections, far more than I was expecting. But in a phosphor g stack, it's not only Proj that needs to support these projections. You need Goodall, first and foremost, because Goodall is the driver that all the other user programs use to get data
04:41
in and out. So at least Goodall and Proj need to support the projections so that you can use it. So I went through the catalog and Proj and see what I could find. One interesting projection is the hammer projection, which is contemporary to Eckerd-4 and all the other projections that Max Eckerd defined.
05:02
And actually, you can use the hammer projection with phosphor g. There are some tricks. There is this little bit, wktex. You have to be aware of these little tricks. I don't have the time to explain you the details. But yeah, you can use it. And now for a little intermission here. I grew up in the 1980s, so there was no internet.
05:24
First time there was a phone in my home, I was seven. And back then, to get information and know about stuff, we would read books. Some of you may know what a book is, you know, with pages, you turn it back and forth. And luckily for me, my parents, they were subscribed to the Reader's Digest.
05:41
So every so often, we would get a new encyclopedia, so a host of heavy and large books that had a lot of photos and graphs and maps. And many maps like this, in this kind of shape. For some reason, as we got into the digital age, this disappeared. So it was with great surprise that I found out that actually
06:04
this particular projection, the homologous sign, which was defined in the 1920s by a gentleman called Goode, is actually supported in Phosphor G. It actually works. Awesome. So let's move a bit forward in time. Another similar projection from the 1920s, theomorphic
06:23
developed by Mr. Borg. And well, things start to go wrong. So what is happening here? CS to CS. So approach two can pretty much deal with it, but Goode complains. Why is Goode complaining? Because Goode requires any projection to be implemented
06:41
both in the direct way and the inverse way. There are reasons for that. But what happens is that in the case of theomorphic, the inverse is not implemented, and so Goode cannot use it. So bad. And we move on throughout the 20th century to even more sophisticated projections, like the ones defined by Mr.
07:03
Snyder, who anyone that studied cartography probably knows, a scholar of the 20th century who published many books about cartography, and developed his own projections based on the platonic solids. Interestingly, the most popular of these projections, which is based on De Cosahedron, this little figure here, is also supported in Proch.
07:24
I was quite surprised. But again, we have the problem that it cannot be used by Goode because the inverse is not there. And there are many other projections, and Snyder especially defined very interesting projections throughout the 20th century. Most of them are not supported.
07:41
You cannot really use them in phosphor gene. So here I was. I found out, OK, there are a number of projects, not many, but there are a few that are supported. But in the end, OK, so which one should I use? Which one really is the best for my use case? So I did a little comparison to understand,
08:01
to have an answer to this question. And I did a selection of five projections that more or less go through the history of equal area until the beginning of the 20th century. And to do this assessment, I used a construction that I call the Discrete Distortion in Dikatrix that is inspired on Thistos in Dikatrix,
08:22
but it's something much simpler and that allows me to compute the distortions that are created by an equal area projection using phosphor gene itself. So what is this? It's something really simple. You define a center point somewhere in the surface of your ellipsoid, and then you measure one kilometer
08:42
according to each of the four cardinal directions, north, east, east, south, and west. If you project something like this with a stereographic projection, you get this beautiful kind of circle with the 90 degrees, what you see in gray. But if you project it with an equal area projection, you have the penalty of distortion.
09:02
You start having angles rotated, what you can see here with the red arrows, and the distances between the points in the outskirts and the point in the center start changing. So what I did was basically to position 20,000 of these things all over the globe
09:21
and then measure the things that you see here in red. These are the results for angular distortion. In this case, we have two that perform really bad, the sinusoidal and hammer, mole vial and so and so, and two that perform really good, the homologous sign and Eckerd four.
09:42
Okay, now mapping this, so darker colors, more distortion. Sinusoidal doesn't look good at all. The mole vial there looks a little bit better. Hammer, sorry. Hammer, well, there is, it's really bad.
10:03
And sorry, this is changing two at this time, Eckerd four, and you start seeing, so this is a bit more sophisticated, and you see that the distortion is being compressed to the higher latitudes, okay? And finally, the homologous sign, again, a relatively clean map with just this region in east Russia
10:21
and the Sea of Japan that gets a bit of distortion. And now to the distances distortion, what we see is more or less an inversion, so those that were performing bad in terms of angles now perform good, and those that were performing good in terms of angles perform bad in distortion.
10:40
The exception being the homologous sign from Gude. So the homologous sign was the best for angles and it's still the best for distances. So, well, look at this in the maps. This is really sensible, I'm sorry. The sinusoidal, so as you can see, the sinusoidal now, it's a much cleaner map, so the distortion in terms of distances
11:03
is now shifted to, consigned to certain areas. The mole vial, still decent, but heavy distortions in certain places. And the hammer, the hammer is very particular because it performed bad for angles and it also performs bad for distances.
11:21
But it's a beautiful map, anyway. And Eckert, and again, you see, it's not as good as it was for the angles, but it compresses the high distortions against to the high latitudes. And then the homologous sign, really very clean map, distortions very well consigned.
11:40
So okay, after this comparison, it was obvious that at ISRIK, we should use the homologous sign projection. And this is one of our most recent results, so the next edition of our maps will be made available to the public in this projection. Okay, so, well, start updating your approach databases to work with our data.
12:02
Yeah, just, so this projection helped us save disk space. About one less million cells per us, so a really large number in savings. And of course, we were talking of terabytes and terabytes do not scare anyone these days, but we spare days of computation, and days of computation are expensive, all right?
12:23
Okay, it's not all good. Let's go now to the bad part where I complain about software and stuff. The first problem you have when you start using the homologous sign is this. You load up a vector, so it always works very well with RASAs, but you load up a vector in a program like Tuj's and you start having these things.
12:41
The problem here is that for these programs, the codomain of any projection is infinite, which in most cases is false. So in most cases, the codomain of a projection is finite, just as the surface of the ellipsoid is finite. So to tackle this, I developed a couple of vector layers
13:03
that you can use to clip these weird areas, sorry, these weird areas that you get in places like Greenland, and then you get very nice vectors that exist only within the codomain of the projection. Another problem is that you have to be careful
13:21
the way you project to and from the homologous sign. You have to use Google Warp and know the tricks, and the tricks are in this particular issue opened in the Google repository. And it works, but you cannot do a projection, for instance, with QGs or with GRASS.
13:41
It will go wrong. So you have to use Google Warp. Not a big problem, but you have to be aware of it. Well, Google and Proj, it works, but we have tools like GeoTools that do not support the homologous sign yet. One of the disadvantages of this is that things
14:01
like Google Earth Engine then do not support the homologous sign, and the software that Andrea develops also does not support the homologous sign, and this is right now a major priority for us, and hopefully we'll have an implementation still this year. We'll see how that goes. Another important tool that doesn't support
14:21
the homologous sign is Proj4js. This complicates matters in web mapping. I haven't been able to get it to work with open layers five yet. Still some research to do on that. I still have to go and see what happens with leaflet, so all in all, still an open question how you use this projection in web mapping. And finally, EPSG, so there's no EPSG code
14:44
for the homologous sign. It looks like there won't be one any time soon, and some programs, they really want you to use EPSG codes, so you can use tricks, et cetera, but in the end, it kind of works. I can get this, for instance, working on map server
15:00
and serve tiles in the homologous sign. It's not a problem, but one thing that bugs me is why do we depend so much on the EPSG? And I think we should reflect a little bit on this. Proj6 is coming there. Maybe it can force a change, we'll see. Okay, summary. Well, it's not evident how you work
15:23
with equal area projections in a phosphor g-stack. Projections newer than 100 years old mostly are not supported, but we have the homologous sign, and the homologous sign has this advantage that minimizes both angular and distance distortions. Some of the projections that are supported
15:42
are clearly outdated that you wouldn't use for anything because the penalty is just too big, like the sinusoidal and the hammer, but there are other projections that are still relevant, especially the Eckerd form, but also the mall violin, which is quite nice, but it's quite nice maps. And the main conclusion is that we have to code more projections.
16:01
We have to code more, we have to invest on this, and I hope that this presentation somehow instigates that drive to continue developing this. So, yeah, there are some recommendations, but I can skip this. And yeah, let's go into the questions, thank you.
16:24
Any questions? Ah, yes. Hi, for the EPSG, have you reached out to them for seeing if they want to include it? And another question for the POG4, do they have also a committee to decide
16:43
on which projections are going in? Because this is what the EPSG does. So I contacted the EPSG some months ago, and I'm still waiting for an answer, regarding Proj. So there was a presentation about this yesterday with Evan,
17:02
and Evan clearly said that he doesn't want to do that. And it's understandable, it's understandable. But the team wants to develop software, they don't want to be bugged with these kind of issues. But maybe this is not something so much to be picked up by the Proj team, but maybe by some unit at the OSG, et cetera.
17:22
Maybe reach out to the EPSG people again, because I have been in contact, because we had to extend some specific codes there, and so they are responsive. Try to contact them one more time.
17:40
All right, thank you. Them and also ESRI, and ESRI I haven't contacted yet, and from what I know, ESRI is more approachable on that. We still have time, any other comments? Yeah, so in the Proj project, we don't really want to govern your various coordinate systems that you just come up with
18:04
but you can define your coordinate system in terms of WKT, or WKT2, if you want to, and Proj should be able to just digest that and turn it into whatever you want. So I don't think you actually need
18:20
a specific EPSD code for this. You can just define your coordinate system in terms of the standardized way of doing it. So yeah, that should be possible for you. And then just another, maybe a question. Have you tried doing, like you had some examples in the beginning of using Proj and D-LOL,
18:43
and your comment was that it doesn't work for a certain prediction because there's no inverse. Have you tried doing it with newer versions of Proj and D-LOL? Because I think it might work in those. All right, thank you. So regarding the first comment, can you please pass that on to your map server colleagues?
19:03
Because it's to them that you have to tell that. Because I already do that. I already use the Proj database and I can hook up the other software to use the projection the way I want. The problem is that programs like map server, they demand an EPSD code. I cannot just pass a WKT to map server, for instance.
19:25
Exactly, that's what I do. That's what there was in one of the slides. Regarding the new versions of Proj, the answer is no, but I really want to. However, we have this policy of using, you know, pre-compiled packages, et cetera.
19:42
We mostly depend on Ubuntu Gs, and so we will only do that upgrade when either Ubuntu Gs or Debian Gs have the packages there. But I'm really looking forward to that, I can tell. Still time for one question or one comment, if you want.
20:01
One of the first slides had geoserver depend on GDAL depending on Proj, but it's not true. Geoserver has its own referencing subsystem, which is the geotools one. Perfectly right, sorry. And that's why we cannot use the Omo assign in geoserver. That's right.