How Simplicity Will Save GIS
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 | 188 | |
| Author | ||
| 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/31620 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Producer | ||
| Production Year | 2014 | |
| Production Place | Portland, Oregon, United States of America |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
FOSS4G 2014 Portland149 / 188
7
10
14
15
16
23
24
25
28
29
33
37
39
40
43
45
46
48
50
56
64
65
69
72
74
82
89
91
98
102
107
111
114
118
128
131
132
135
138
141
143
147
149
150
157
158
161
164
165
166
173
174
175
179
185
00:00
MappingLibrary (computing)Presentation of a groupStatement (computer science)Program slicingTexture mappingMobile appRevision controlOpen sourceWordSoftware developerPower (physics)Slide ruleCartesian coordinate systemLecture/ConferenceComputer animation
02:12
Volume (thermodynamics)Price indexComputational complexity theoryTexture mappingCuboidComputer animationPanel paintingSource codeLecture/Conference
02:49
CuboidPoint (geometry)Computer-assisted translationMappingPosition operatorMultiplication signBuildingComputer animation
04:18
MappingMedical imagingTesselationMusical ensembleDampingTexture mappingBoss CorporationService (economics)Inheritance (object-oriented programming)Data managementComputer animationMeeting/Interview
05:19
MappingModal logicCodeDampingWrapper (data mining)Web pageData managementLine (geometry)Open sourceVideo gameComplete metric spaceStability theoryMeeting/InterviewComputer animation
06:35
Archaeological field surveyTexture mappingWrapper (data mining)SoftwareExterior algebraMeeting/InterviewComputer animation
07:23
Copyright infringementDampingLibrary (computing)WordMultiplication signOpen sourceProjective planeComputer animationMeeting/Interview
08:08
Boss CorporationMultiplication signDampingComputer animation
08:41
DampingRevision controlBuildingMarginal distributionLibrary (computing)Wrapper (data mining)Multiplication signMappingWeb 2.0Data managementTexture mappingComputer animationMeeting/Interview
09:32
Texture mappingDampingWordData managementPoint (geometry)Library (computing)Meeting/Interview
10:14
Library (computing)Open sourceMetropolitan area networkMappingWater vaporWeb browserComplex systemTexture mappingComputer animation
11:12
WebsiteElement (mathematics)Right angleMilitary baseCommunications protocolLine (geometry)MappingTexture mappingCartesian coordinate systemComputer fileCodeDifferent (Kate Ryan album)ImplementationRange (statistics)CASE <Informatik>Task (computing)Standard deviationSurfaceProcess (computing)Client (computing)Decision theoryProjective planeMathematical analysisMultilaterationMobile appComputer animation
13:02
Process (computing)Cartesian coordinate systemResultantSoftware developerVapor barrierComputer animation
13:48
Exception handlingBitType theoryElectronic program guideExpert systemDivisorMeeting/Interview
14:58
Process (computing)Default (computer science)Configuration spaceLine (geometry)CuboidSoftwareSign (mathematics)Texture mappingCodePairwise comparisonInheritance (object-oriented programming)Projective planeForcing (mathematics)Complex systemQuicksortBuildingComputer animation
17:36
MereologyComplex systemConcentricState of matterComputer animation
18:10
DebuggerService (economics)Level (video gaming)WordDecision theoryEnterprise architectureProcess (computing)PlanningTexture mappingInsertion lossStack (abstract data type)Information technology consultingFront and back endsComputer animation
19:37
PrototypeMappingAlgorithmComputational complexity theoryFocus (optics)CASE <Informatik>Cartesian coordinate systemStandard deviationCodeMonster groupDigital Equipment CorporationPotenz <Mathematik>Right angleVisualization (computer graphics)CuboidEvent horizonCodeComputer animation
22:27
CASE <Informatik>HypothesisWeb 2.0Complex systemMultiplication signAlgorithmOpen sourceBuildingMappingInsertion lossLibrary (computing)Vector spaceFood energyNumberScalabilityImplementationTriangulation (psychology)Product (business)Different (Kate Ryan album)CodeComputational complexity theoryProcess (computing)FrictionScaling (geometry)Point (geometry)Network topologyOverhead (computing)Projective planeCombinational logicMathematicsWritingChemical equationPurchasingLine (geometry)Maxima and minimaBitSoftwareProfil (magazine)Computer animation
30:26
Twin primeArithmetic progressionPublic domainComputer animationDiagram
31:28
Multiplication signLibrary (computing)Condition numberDifferent (Kate Ryan album)Query languageCodeComplex systemWeb-DesignerNetwork topologyParameter (computer programming)Revision controlFormal languageCartesian coordinate systemRight angleForcing (mathematics)Event horizonPoint (geometry)Web browserComputer programCuboidDensity of statesConfiguration spaceRuby on RailsInternetworkingView (database)Software developerSimilarity (geometry)BitWeb pageSoftware frameworkMetropolitan area networkWritingComputational complexity theoryError messageElectric generatorLimit (category theory)WebsitePhysical systemInsertion lossSoftware bugStability theoryComputer hardwareWeb 2.0Concurrency (computer science)Computing platformBefehlsprozessorAssembly language
38:13
Euler anglesComplex systemNatural numberBit rateRegular graphBitShape (magazine)Sound effectWave packetComputer programAnalogyFitness functionVideo gameConsistencyComputer animation
40:34
Vector potentialBitMultiplication signComputer animationPanel painting
41:05
Arithmetic meanBitCASE <Informatik>Multiplication signLecture/Conference
Transcript: English(auto-generated)
00:00
Hello, everyone. My name is Vlad. I want to talk to you about simplicity in GIS. I work at Mapbox, and I also created a thing called Leaflet. Talking about simplicity in GIS, this is the biggest room I ever talked in. When I prepared for the talk, I was
00:29
prepared to talk about abstract philosophical questions and not bore the audience to death. So, but I had a miraculous revelation a couple of days ago. I discovered that the Apple
00:47
keynote presentation tool in the latest version just got GIF animation support, so I made sure to put a lot of this so that, even if you're not listening at all, you can at least enjoy the slides.
01:03
So, simplicity. First, I feel that I need to make a statement. GIS is hard. It's really, really hard. Well, I'm not even sure what GIS means, but it's really hard, and it's super confusing. Especially for people that never studied GIS and just happen to work
01:27
with maps. I know what I'm talking about, because I spent almost seven years creating map applications and mapping libraries, and I also created a library called Leaflet,
01:44
a JavaScript library for interactive maps that is used by thousands of developers worldwide to create map apps, and it's by far the most used open-source map library ever created, and it's used by the world's most powerful online brands, and, given all that huge experience
02:06
I have, I'm still completely clueless about GIS. So, whenever I hear about all these abbreviations and complex terms, and see the sheer volume of technology that's associated
02:22
with GIS, like, I freak out, because I have to show you how I feel on a typical Phosphagy talk. It's like this. And another fun indication is that my company,
02:41
Mapbox, it intentionally advertises itself as not a GIS company, so as not to scare people away. So, well, it's kind of insulting, but that's not Mapbox's problem, right? So, I'm clueless about GIS, but it's exactly the reason why Leaflet succeeded, why it became such
03:08
a popular tool, and there's, I feel that there's absolutely no way I could create such a successful tool if I studied GIS beforehand, and to explain that, and to generally explain
03:25
you the motivation behind this topic I want to talk about, simplicity, I want to talk about technology, but now I have a bigger audience, and I also feel the need to run a quick
03:43
recap, so, but this time it's with animated GIFs, so it's more interesting. So, it was April 2008. I started working for a company called Cloud Mate that positioned itself as a start-up based on OpenStreetMap data, building business around OpenStreetMap. I
04:03
was really young, and careless, and I thought that, wow, maps, it's so easy, and so fun, it's going to be great. How hard could this be? I was really, really optimistic,
04:22
and I thought, like, maps, so, what are maps about? It's probably some image tiles involved, like, after some research that I did into maps, I understand that some image tiles involved, there's some pan and zoom happening with the mouse, and that's pretty easy to do,
04:42
and I was pretty good at JavaScript back then, and I only started getting into maps, and maybe you want to put some stuff on it, on top, like marker, a pop-up, so, like, how hard could this be? It's, like, super easy. So, if it's easy, and my company tells me to
05:04
make a JavaScript API for their mapping services, I say, like, let's build an API from scratch. Well, it's easy, it will be awesome, it will be smooth and fast, and lightweight, and my boss said no. So, I was told by the management that we don't have to reinvent
05:28
the wheel, that it's super risky, and, like, we can get into a bad situation later if we start from scratch, and there's no reason to do this, because there's a major
05:44
stable open-source solution already existing, and back then, the only open-source solution for maps was OpenLayers, and they said let's build a wrapper against the existing solution.
06:02
So, I decided to look into this solution, because I was clueless about maps, and I started looking into OpenLayers, and I discovered that it has more than 100,000 lines of code, hundreds of features and megabytes of JavaScript, and we were talking about 2008,
06:23
there, like, Ajax was just becoming the buzzword, and megabytes of JavaScript on a page would kill performance completely. So, I freaked out. It was such a great mismatch between what
06:42
I assumed to be mapping business, and what it really was in the GIS community. So, I started looking into building a wrapper against OpenLayers, but it kind of looked like this. So, it didn't really fit. Like, it was an already really, really huge and really,
07:06
really complicated and confusing piece of software, and making a wrapper against it just didn't make sense to me at all. So, I started thinking, well, maybe if there's only one solution, and it's really huge and bloated, maybe we should make an alternative.
07:25
So, like, I went to some awesome chat, I think, maybe IRC, and I said, hey, guys, what do you think about making a simple lightweight OpenLayers alternative?
07:41
And I was said, unexpectedly, there's no way I could do that. From scratch, myself, and, like, that's a worthless idea, and I got a share of disapproval, like they said. Why do you spend time on this, wasting time instead of contributing to existing
08:03
open source awesome projects like OpenLayers? So, the community said to me that it's a
08:33
waste of time. So, I started building from scratch, but I didn't tell anyone. So, it was,
08:46
like, yes, really great plan. And there was a deadline in a couple of weeks when I had to present my first version of the API for my company, and I think I built an OpenLayers wrapper in a couple of days, but I still had a huge margin to work on stuff that I wanted.
09:06
And I built libraries from scratch. And a couple of days, or a couple of weeks later, I, when the time comes in, I presented the first version of what would be later known as web map
09:21
slide. It's a cloud-made API for maps. And when my management saw the API, like, not knowing that it was written from scratch, they were really, really surprised because they never ever saw a map that was working so fast and smooth.
09:42
And then I had to admit that it's not an OpenLayers wrapper. I still wrote a thing from scratch, even when you told me not to, and I was not even sorry about that, because I proved my point. And eventually, management agreed that we should go with our custom solution because
10:07
it will be a competitive advantage, a mapping library that's fast and lightweight. So, in a way, the thing that would later become Leaflet was born as a protest
10:22
against bloat, clutter, and complexity. And three years later, it was open-sourced. I managed to convince my company that we needed to open-source this because it was really hard to keep up with browser advancements, and it was really hard to maintain a library myself,
10:43
and there was a need for such a library, and so a lot of people wanted to contribute, but they couldn't because it was proprietary back then. So, now, Leaflet is the most popular mapping library ever. It's used just everywhere. Everywhere where you see a map that's not
11:04
Google Maps, like 99 per cent is Leaflet. So there are lots of amazing maps on lots of amazing websites. And, yes, but I want to talk about why did it actually succeed, and
11:25
why it went this far. How it grew so fast, and why everyone switched to it. It all comes down to simplicity, and to explain how it actually happened, I want you to imagine
11:48
the thought process of an aspiring map app creator. You may close your eyes and try to remember how you were thinking when you first got tasked to create a map. So, maybe,
12:03
like for most of you, it was pretty much like this. I want to learn GIS reading books and academic papers and articles about geospatial data, map projections, geospatial standards and protocols, and perform analysis of my data and use cases,
12:25
probably involving other GIS specialists and do a lot of other research so that I can make sensible decisions about the required technology stack and adjust it to the needs of my application and finally make a fucking map. Maybe a couple of years. Of course, it's not
12:41
how it works at all, so it's bullshit. How it actually works is I want a map right now. I want to create a map right now with one line of code, and deal with it later, and modify it later, and learn later. I want a map right now. So, get the technology out of
13:06
my way. I must say that application development is a creative process, so it's not purely
13:21
analytical. If someone tells you that, it's not true. You actually have to be creative to create amazing software. Technology, the main purpose of technology is to bridge the gap between creative thinking and the end result not be a barrier between the two.
13:45
I'm sure a lot of you watched the most popular TED Talk ever given. It's called How Schools Kill Creativity by Dr Ken Robinson. He said, I believe this passionately, that we
14:01
don't grow into creativity. We grow out of it. In fact, we get educated out of it. There's a lot of modern research into modern psychology and human behaviour that
14:20
concludes that actually there's no divide between two types of people, the creative types and the purely analytical types. Actually, all people without exceptions are born creative, but our
14:42
education, as we grow, we lose quite a bit of this creativity. There's also another guy that's a big expert in education that said, you must unlearn what you have learned. People actually want to create, to explore,
15:10
to experiment and learn along the way, not before. The problem with traditional education is we spend so many years learning things before we even get the chance to understand how to
15:24
apply our knowledge. On the contrary, creative learning works like this. You build something, something really simple, like the first step. You build something and you learn from the experience. After you learn from the experience, you can build something more and learn from
15:44
this and build more, and it's a never-ending process of creation and learning. That's how people really are designed to learn. Even Albert Einstein said that the true sign of
16:01
intelligence is not knowledge, it's imagination. To enable this kind of creative search and to this kind of super fast-paced learning with any tool, it has to be that simple to get started.
16:22
It has to be that simple to understand and that simple to use. There's also a principle called convention over configuration that illustrates this well. It's a principle that says don't force me to think about unimportant things until I'm ready to address them. Make
16:43
sensible defaults. Don't make me think about stuff until I really need it so that I can create a map with one line of code and not care about some projections or other stuff until I want to. So that's how you make software really easy to get started with. So complexity,
17:11
it fills your mind. It's kind of a good comparison to think about it. It fills your RAM and you get slow and it really dumbs you down. While your brain is filled with complexity,
17:31
you can't think outside the box. Often when you get met with complexity, you get desperate
17:44
and you can't solve hard problems. It may look like this too. Simplicity on the other hand, it frees your mind. It unleashes your creativity and learning potential. It makes you in a state of a relaxed concentration where you can create and experiment
18:09
and explore. So simplicity enables you to do more with less. And now
18:21
this all is concerning individual approach to learning and choosing a technology. But let's look at how, like on a global level, how companies do this. How companies, what's their decision process like choosing a technology or, for example, looking to add a
18:42
map to their service. So perhaps it looks like this for some companies. So let's hire a GIS consulting firm and do some research for us and choose the right technology stack and then help us set it up and consult our developers so that they could get more familiar with it. And
19:03
well, for most companies, it doesn't work this way. So how it actually works, and I've experienced it in a lot of companies, including the biggest and most successful tech companies, it works like this. Hey, front-end guy, make a map. And then we see the same problems that we
19:32
saw when we choose the technology individually and try to use it. So yeah, front-end guy starts to explore existing tools and maybe starts to use the one that's most simple. And they
19:46
create some prototype that kind of works and only then they like learn along the way and start
20:02
companies have what I call the tinkerer culture. So it's a culture of never-ending experimentation and playing and being creative and like feeling the freedom to do everything you want. So yeah, it's like this in Mapbox, it's like this in GitHub.
20:25
So when people are creative and when they are productive, when they're happy as a consequence of simplicity, they make amazing applications. And when people make a lot of amazing applications
20:43
using some technology that's really simple like Leaflet, like making lots of beautiful maps and visualisations, it leads to community growth, exponential community growth, and tech exposure. That's how Leaflet gets popular. And simplicity attracts a vibrant community.
21:08
So simplicity means focus on the essentials. This means that the code you write is
21:20
much higher quality because you don't spend things on unimportant things. And Day Straw said simplicity is a prerequisite for reliability and this guy knew a lot of stuff about algorithms and complex technologies.
21:44
And there's a mantra that I feel that you all should learn. Those shall not try to cover all the use cases. So let's look at how usually standards appear. I'm sure it happens like this in OGC too. So we have 14 standards and
22:08
some people appear, oh, we need to make one universal standard that covers all the use cases. And now, after that, there are 15 competing standards.
22:21
So when you're faced with a situation like this, you have to learn to say no. Maybe like this. Or maybe when someone like your friend tries to cover all the use cases,
22:41
then maybe you should do like this. So let's look at a basic chart. So on the Y scale, there's the need for a feature, like how many people actually use this,
23:01
and on the horizontal scale is complexity of a solution. So, for example, like on the left-hand side, there are lots of features that are really essential and lots of people use them, but as you add more features, they become less and less needed. And
23:26
a lot of GIS software and generally a lot of technology that's considered super complex, they try to cover all the use cases, and it looks like this. We spend so many energy trying to
23:43
do everything for everyone while having diminishing returns, and the act of simplifying technology means that trying to find the balance between how features are needed and like how much effort is spent implementing them. Also, simplicity means easier profiling and less
24:11
bottlenecks, and this leads to much better performance, and I experience this again and again. So I have a hobby of making really small, little, simple libraries that solve one
24:26
problem. For example, I wrote an R3 implementation JavaScript that is insanely fast. It's many, many times faster than any other R3 implementations in JavaScript, and I was able
24:42
to achieve that because I was building this with simplicity in mind, and I was intentionally trying to simplify to write as less code as possible, and it was so easy to profile that and optimise gradually that it grew. Since its first release, it became four times or
25:07
ten times faster because it was easy. When you have a really huge library with lots of bits and pieces, and it's really hard to do this kind of thing.
25:21
So, another thing that I created is simplify.js. It's a really simple 100 lines of code implementation of geometries, using a combination of Douglas Becker and some other algorithms, and it's insanely fast. 74,000 points are processed in less than one millisecond.
25:47
I was able to do this because it was a really simple approach. Also, just recently, a couple of weeks ago, I was tasked to write a triangulation implementation because I was not
26:03
satisfied with performance of existing solutions. I deliberately chose an algorithm that is relatively simple, that takes four times less code to implement than algorithms that were usually
26:20
implemented for this. It was the fastest library for triangulation. What is fun about this is that I found an algorithm that was considered really fast because it had very nice asymptotical
26:44
complexity, so it scaled really well with millions of points. It was not growing too fast. But I was still not satisfied with performance. I decided to, just for fun, try to implement an algorithm that is considered to be much, much
27:08
slower, because the previous algorithm was nearly linear complexity, and the one that I decided to implement was squared complexity. It turned out that, for a small number of purchases,
27:31
like for a couple of guns that are really simple, this simple algorithm that took 20 times less code than my previous attempt, it performed 10 times faster.
27:45
And, wow, how does it happen? I was really, really surprised, but then I realised that complexity has its overhead, and you really need to look at your domain and see if this
28:01
complexity is justified. In this case, most of the data that I needed to triangulate was really simple. OpenStreetMap buildings, for example, I'm talking about Mapbox, GL.js that we announced recently, the vector maps in WebGL, and an algorithm that is considered much slower
28:25
was actually many, many times faster because it was really simple, and I could optimise it to the maximum. Also, a really important point is that simplicity makes people less hesitant
28:42
to contribute, because I'm sure a lot of you tried to contribute to different open-source projects, and many times you were kind of afraid to make a change to some product, because you thought, well, it's such a complex technology, the code is so smart, and my skills
29:05
are not nearly as good as those of the creators of this library or product, and so you just didn't contribute because you thought that it would not get accepted or it would harm, and so, like, with complex products, you're always faced with situations like this, but
29:28
if you try to make your product as simple as possible, not only concerning API and the UI, but also the code itself, how it's written, like, simplify the approaches, try not to use
29:44
really smart and clever ways to code, but use the most straightforward and simple ways possible, and always try to simplify and simplify and simplify. It actually makes a big difference because people actually start to contribute because they don't feel this friction and this
30:02
fear of rejection, and that's how Leaflet got, like, 200 contributors in a couple of years, and simplicity makes it much easier to concentrate, and I know what I'm talking about, because,
30:20
like, specifically for me, it's much easier to concentrate when there is war going on in your country, and it's much easier to concentrate when you're a father of twin girls. Yeah, that's mine. So, also, simplification is how the technological progress happens,
30:46
so we see how it works. So, you have a hard problem, like, all your domain that you're working in is really hard, and what you're trying to do is to simplify and simplify and
31:00
simplify, and when you simplify, you manage to reduce your problem domain to something simpler, more manageable, and you simplify and simplify and simplify until it becomes a simple problem, and when something that was hard before becomes a simple
31:20
problem, you can finally move on to a harder problem, and that's how the technical progress happens. Yes, so, actually, like, there's a good example, like, if you look at the history of application development at, like, many years ago, people had to write code in binary,
31:46
and it was really, really hard, and really, really complicated, and you just couldn't, like, put the stuff in your head, and so, like, applications you could write were really simple, and there were some hardware limitations, but the biggest limitation was that it was really
32:06
hard to do, and then there was assembler, which is kind of a simplification. It made it much, much easier to programme for CPUs and, like, do different kinds of applications, and when
32:22
assembler appeared, like, it skyrocketed the application development scene. Like, applications started to be much more advanced and do more stuff, and then, when it became kind of hard, like, C was invented, and it made it once again super easy compared to somewhere to write
32:45
applications, so it, like, it hides a lot of the complexity to allow you to concentrate on important things and write awesome applications, and lately, there was a search of, like,
33:01
development of scripting languages, like Ruby, and Python, and PHP, and JavaScript, that once again, like, advanced the technology much, much further, because they made it much simpler to write code. And we can look at other examples, like, for example, jQuery.
33:24
If you remember the days before jQuery, where you had to deal with really, really complicated browser bugs, like, there was IE5, IE5.5, IE6, IE4 Mac, and you had to deal with different bugs
33:43
and different platforms for different versions, and it was taking, like, 80 per cent of your experience to deal, work around those bugs than to actually use the technology, and when jQuery appeared, it suddenly made it really simple, like, you didn't have to think about,
34:04
like, browser bugs, or how the DOM works, or how the DOM events work much, so people just started writing code right away without learning, getting into the complexity much. So, the influence of jQuery on the web development is hardly overstated, so
34:28
it made huge advancement of web technology. Of course, a lot of other libraries appeared after this, and, like, there is a new generation of developers that consider, like, jQuery,
34:41
but it had a really huge role for advancing web technology, and I can say the same thing for server-side technology, because, like, Ruby on Rails made it extremely easy to write well-written code that's really terse, and that does a lot of things.
35:06
Like, it embraced the conventional configuration principle fully, and it was so influential that all the other languages that, like, had server-side involved started copying the Ruby
35:24
on Rails principles, and a lot of similar frameworks appeared not only for Ruby but for all other languages, like PHP, and JavaScript, and Python, and et cetera, so it had a huge influence because it embraced simplicity, and there's Node.js. There's a lot of critics
35:46
that say that Node.js isn't actually as efficient as it claims. There are much more efficient ways to write concurrent server-side applications, like Scala or Erlang, but the most, the greatest
36:06
thing about Node.js that made it so prevalent nowadays is that it's really easy. It's simple. Like, you don't have to learn a new language. Everyone knows JavaScript, and it's kind of easy, like, it's really easy to program Node.js, and that again advanced the technology landscape
36:27
further. So, simplicity is the outcome of technical stability. It's the goal, not the starting point. I really like this quote by Maurice Archie. It actually means that
36:43
you have to work to make your technology simple. You don't start with simplicity. You strive towards it. And there's also a really funny argument that people make when we talk
37:01
about simplicity, like, oh, but we're not paid to do simple things. Like, if everything is simple, I wouldn't be called a professional because I'm so cool, I have a lot of knowledge to tackle complex problems, but this kind of thinking is really destructive, and
37:25
I remember the times when we, when I was an HTML CSS developer, and we developed, we wrote, like, HTML pages, and it was really hard to work around all the IE bugs, and
37:42
when IE 9 was released, that finally, like, solved lots and lots of CSS issues, then there were people that were really sceptical because they said, oh, man, we're going to lose our jobs, because, like, 80 per cent of our experience was how to deal
38:02
with browser bugs, and when, like, Internet Explorer finally becomes really good browser, our knowledge won't be relevant any more, so they're kind of resistant to change, and this is a really bad attitude, because people who resist progress and unwilling to learn and
38:22
adapt continuously to an ever-changing landscape of technology, they are in denial, and this kind of people always fail. So, another problem, especially with the GIS industry, is that
38:41
you don't really think about simplicity when complexity is taken for granted, and there is an analogy that comes to my mind. I'm actually a big fitness enthusiast, like I do strength training, and martial arts, and all kinds of sports, and the
39:02
weird thing about fitness is that you don't actually realise the benefits of regular exercise until you become more physically fit, and that makes it really hard, because, like, people try it for a bit, and they don't, it's really hard, everything hurts,
39:20
and you don't really feel the benefits at all. Your life actually becomes worse, so they think, well, I'm not created to be fit. Nature created me out of shape, and that's how it goes. They move on with their life. They don't feel the immediate problem of being out of shape.
39:46
The life goes on. They were like that for most of their life, so they don't feel the problem, but when they persist with consistency, and the most important
40:03
thing in exercise is not how you choose a program, and not how you exercise actually, but it's consistency, the fact that you exercise regularly, and not coming from one side to another to a different program, and constantly switching sides. So simplicity is a muscle.
40:25
It needs to be exercised consistently. It needs to be consciously worked on, and that's how you achieve it. So, to conclude, let's make a collective conscious effort to
40:44
simplify GIS technology so that we can be happy, and build more awesome stuff. Maybe at first we'll be looking like this, but eventually we'll feel the freedom and
41:02
unleash our creative potential. Thank you. We have probably a bit of time for questions, but I'm not sure whether we need this, or maybe it's better to ask me questions in the
41:27
whole week. Okay, so catch me in the hallways. Thank you for listening.