We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Live monitoring of ski tracks in Norway

00:00

Formal Metadata

Title
Live monitoring of ski tracks in Norway
Title of Series
Number of Parts
183
Author
License
CC Attribution - NonCommercial - ShareAlike 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 and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language
Producer
Production Year2015
Production PlaceSeoul, South Korea

Content Metadata

Subject Area
Genre
Abstract
This presentation is a complete walk-through of a system for live monitoring of ski tracks, built with open-source components. If ski track monitoring sounds odd to you, it is in principle the same as live monitoring a sweeping truck, snow-plough or any other road maintenance vehicle. The background for the system��s existence is a small, Norwegian town��s obsession with finding out where and when ski tracks were last prepared for them. A few man-hours, combined with the power of open source, has made it possible to create an affordable and efficient live tracking system. In this presentation, every aspect of the solution will be explained in full detail: The GPS tracking unit, the server and database components, and finally the web application that visualizes the data. Despite not being a revolutionary system, the concepts and experience drawn from this project can be useful to other developers who are starting off with open-source and geomatics. However, it may also be interesting to more weathered developers who would like to see a different approach to the problem of spatiotemporal data modelling with PostGIS. The open-source components that the presentation will touch on are the following: - Traccar - GPS trakcing server - PostgreSQL + PostGIS - Arduino - Apache2 + PHP + libpq
126
Extension (kinesiology)Computer fileInformationFunctional (mathematics)Multiplication signGame controllerBitSoftwareComputer fontWeb applicationInsertion lossSoftware developerLibrary (computing)MethodenbankPoint (geometry)Serial portLine (geometry)Dimensional analysisString (computer science)Server (computing)CASE <Informatik>TheoryArithmetic meanVisualization (computer graphics)MicrocontrollerProjective planeMereologyPosition operatorPhysical systemLoop (music)Power (physics)Open sourceWordProgrammschleifeFitness functionHeegaard splittingInformation privacyProcedural programmingGroup actionCartesian coordinate systemStress (mechanics)Endliche ModelltheorieOrder (biology)Goodness of fitMobile appKey (cryptography)Office suiteSerial communicationComputer programmingNetwork topologyConnected spaceDistanceResultantNumberInstance (computer science)Data storage deviceExecution unitTask (computing)SummierbarkeitXMLComputer animation
Landing pageDatabaseHeegaard splittingLine (geometry)Multiplication signString (computer science)Process (computing)Structural loadPhysical systemGraph coloring1 (number)Projective planeServer (computing)Functional (mathematics)Open sourceCommunications protocolRippingOrder (biology)Relational databaseInformationCodeMetadataWeb 2.0outputMethodenbankAxiom of choiceBitComputer hardwareScripting languageTable (information)Product (business)System callHacker (term)CuboidRepresentation (politics)Web browserNeuroinformatikBus (computing)PiVirtual machineMobile appWeb pageInverse elementCartesian coordinate systemDivisorVideoconferencingData structureMathematical optimizationError messageBit ratePlanningFiber bundleFrame problemMassRight angleInsertion lossCodeDemo (music)Formal grammarPoint (geometry)Software testingWave packetState of matterWebsite
Computer animation
Transcript: English(auto-generated)
Okay, my name is Chartan Biersit. I'm a developer from Norway. I work with a company called Norcart, where I get to work with a lot of open-source software.
But I also work a bit with that on my spare time. And that's actually what I'm here to talk about today. So, live monitoring of ski tracks in Norway. Okay, why would anyone do that? So, in Norway during the winter time, there's little else to do other than going skiing.
So that's typically what we do. Back in the day, you would just put on a pair of wooden skis and go skiing as long as you had snow. But as times have progressed, we now have ski groomers, or heist prepper, or something like that. I'm actually not sure what the English word is.
Anyway, they make nice tracks for you to go in, so you go faster, and then you can enjoy skiing even more. But of course, the tracks deteriorate over time because of weather or other skiers. So that leads to a problem. You need to know when the snow grooming actually happens.
When are the tracks laid down? So, when does that occur, and where? So that's a spatiotemporal problem that needs solving, obviously. And then I guess you could say, well, this is already solved. I mean, Google is tracking us basically every day. You have a lot of apps, Runkeeper, Nike,
a lot of fitness apps these days, and you can actually use their APIs to do all this tracking if you want to. But if you choose to go with kind of a cell phone solution for this problem, you're gonna run into some power issues or even privacy issues of tracking the driver of the ski groomer 24-7.
Or, alternatively, he will forget to turn on the tracking. In Norway, we actually have actually several companies that solve this very specific problem. One of them is Shispo Rateno. They actually provide the service for most ski resorts in Norway, I would say.
So, why would I then go ahead and do this? Well, first of all, I didn't really like their solution. On top of that, I kind of like fiddling around with things on my spare time, so I decided to go ahead and create the live monitoring system for, well, ski groomers, for a, actually, ski resort back home from my hometown.
So, this is the solution overview. It's very simple. You need a snow groomer and a tracking unit, which sends data to a server, which is then visualized in a web application. So, that's all simple. Or, in words, GNSS unit, network connection,
a server, one developer, and a bunch of open source projects. So, I started off with my Arduino, which I already had. An Arduino is a microcontroller that you can program using C. You can connect a bunch of sensors to it. You can also connect something that is like modules that are referred to as shields that are a bit more advanced. And I got such a shield with a 3G plus GPS shield.
You can communicate with it, with the Arduino, using serial communication, so it's pretty old school, but it works. You call for a GPS position, get the location, and then you can use the 3G module to actually send the data over HTTP to the server.
The benefit of using an Arduino is that this will actually be powered as long as the power is on, and then it will just run indefinitely, or at least that's the theory. And so, then you just put it into the cigarette ignition in the ski groomer. I actually also 3D printed a case for it.
I'm not a designer. I'm an engineer, so it doesn't look very good. It's probably one of the only half useful things I've ever done with a 3D printer, otherwise it just sits in my office. So, after I had finished my tracker, I went on to create a tracking server,
and that basically needs to consume, store, analyze updates, and then serve ski track information. I chose to go with PostGIS for this task, and at the time I was familiar with Apache, so I just used that. So, what happens then is basically that it just sends data as long as it's on to Apache,
which then inserts it to PostGIS using the libpq library. And that's all PHP, by the way. So, this is the end result, and it shows kind of the outline of what I've done here.
So, the segment network, which is the ski tracks, are referred to, so they're grouped on different loops. So, one loop is like the longest one, which is tajske, and the shorter one is jeset.
So, these things need to be modeled in the way which looks approximately like this. One track, which is the stuff on the left side, can consist of a bunch of segments. Segments can be overlapping, and because of things I will get to a bit later, the segments can also be split up into an arbitrary number of sub-segments.
That's for visualization purposes. So, 4D data in PostGIS, I chose to go with basically just storing x, y, z for a position, and then m for the time dimension, meaning that you just store unix time, UTC, in the m dimension.
And that works pretty well, actually, but it's not so easy to selectively work with different parts of a line string or multi-point when it comes to the m dimension. So, for instance, getting the m number, getting the point along a line that's the most recent one and stuff like that
became kind of a hassle. So, I ended up writing a PostgreSQL extension for it, and that's quite easy, actually, if you keep to PGSQL, procedural language programming, and then you just put a SQL file plus a control file in your extension folder,
and then you can write create extension, just like you do with PostGIS. That's kind of neat. And then you have all the functions available in, yeah, in PostGIS. So, my extension basically had a few functions for building a timeline, so like insert timeline with, that was created or updated yesterday, for instance, at nine,
and then a bunch of helping functions to kind of update the timeline. And finally, a LS split timeline function, which is kind of crucial, it splits up the timeline based on a temporal aggregation. So, if 50% of the timeline or line string
was updated two days ago, that would be one segment, sub-segment, and then the other was updated last year, then that would be another sub-segment. The way it happens then when a position is sent to the server is that it's basically just inserted
by the PHP script. It's a trigger on the raw table that consumes that point, which is then has this trigger update, which runs the LS update timeline function on the segment table, and then figure out which timeline
to actually update, and if that's updated, then there's another trigger which then creates all these sub-segments, the temporally aggregated segments. And finally, I have a very simple REST API, also with PHP, basically just returns
all the temporary segments that you create with that last function there, and then a metadata table, which returns basically what constitutes a track, like which segments and in which order. So, the web client was built in Leaflet because it's very easy to use.
It just needed to show these key tracks themselves in the map, and then also a sidebar with the information about them. And this is the reason why I had to kind of do the whole silly split up or aggregate on time. In Leaflet, at least currently,
you cannot have spatially varying colors along a timeline, so then you kind of need to create two smaller ones instead. I think this should be fairly easy to solve with the WebGL in the future, but right now, and with Leaflet, it is not.
You could, of course, also do that whole processing thing on the go, so when someone makes a request, then split it up. But I have a tiny old server that's running this, so it's better to pre-process it instead of having that load every time someone pulls the server. So, 2014 in November, I was kind of done with all of this stuff.
It actually took quite a while. I installed it in this ski groomer, or pi's machine here, and tested it, and it seemed to be working okay, and I was quite psyched. I also have to add that I live in Trondheim, and this is way far down on the West Coast,
500 kilometers away and 10 hours by bus. So, I went back up to Trondheim and then waited for snow, and when snow finally arrived, I was sitting down in front of my computer waiting for this thing to work, and it did work, but then it crash-burned something terrible, and after half a K, I was not receiving any more data.
And it started turning off and on, and basically I couldn't really figure out what was going on, and it's very hard to debug a Arduino module 500 kilometers away, so I was a bit bummed out. So, then I had a choice of call back my tracker and possibly fix it. It could be environmental, it could be temperature,
it could be a lot of things. So, I kinda opted for another option, which was buying something from China on eBay for $20 and install that instead. So, that's what I went with, so I bought a TK110. It's a very nice eBay product where the manual doesn't make any sense.
I found another manual online, though, and that actually fit the commands, and sending some SMSs to this thing, I finally got it working. There was a bit weird. It was definitely not NMEA data, so I was looking at a bit of server coding again,
but that was until I found Tracker, which is a open source project that I've kind of come to like a lot, actually. It's written by a guy from New Zealand, and it pretty much supports every low-cost GPS tracker you could find on eBay. It just figure out, or you have to figure out
which protocol you have to use, and then it just spits it into a database, and it can connect to MySQL H2 and PostGIS. Now we can also actually, I saw in a recent update, you can also use your phone and direct that towards your server with an app.
So, a new server structure, rip out the Apache thing, get rid of the nice Arduino tracker, put in a new one, and then install Tracker on my server, and I didn't actually have to do anything in the database code or setup,
so that worked pretty neatly. So then I had a working web application, and the entire setup was nice, and it has been running smoothly ever since. I don't actually have live data because there is not much snow in Norway right now, but pay attention over the winter if you want to,
and you can have a look. So, this is actually demo data that I had to color a bit randomly, so it doesn't actually make sense, but the general idea is that you have the same color coding here as you have in the map, so you have like a visual, well, relation there. And then the time is basically just computed
based off of, so, say 60% of the line string is more or less within this time frame, then that is the time that gets printed here. Yeah, I also added a more textual representation,
so this is kind of like the landing page of the ski center in that box up to the left there is the textual representation. It says last updated yesterday, 1.3 kilometers was updated or whatever.
So yeah, that was the final setup. After a lot of hacking and a bit of trial and error, I managed to create a fully automatic tracking system. I also learned that cheap, optimized hardware from China can be better than my hobby Arduino projects.
All this is, of course, thanks to really awesome Fast 4G tracker, PostGIS, Apache, Arduino, kind of, although it didn't work out, and then Leaflet. Yeah, I think that's about it.
I will go ahead and ask if anyone has any questions. Have you tried the tracker apps on iOS or Android?
Sorry, I have not tried it on any of the phones, Android or otherwise, but I'm pretty sure it should work quite nicely. I just saw that online the other day.
Okay, well, I'll call that done then. Thank you.