Got round to doing a bit of re-branding this week – I have officially discontinued MakingTracksGPS and will be going forward as Gee-Oh! Mobile, which brings the Android application in line with the rest of the Gee-Oh! system.
While I’m here, I may as well summarise the remaining tasks before release:
- Pre-load all UK map data (in progress, currently ~25% complete)
- Improve sanity check for GridSquares on level above, kick-starting if required
- Kick-starting null squares (for current level and level above)
- Fix “zoom out too fast” issue, where we see background grid when we shouldn’t
- Implement ability to auto-centre on any provided device, not just device installed on
- Put Gee-Oh! button just above auto centre button
- Render placenames
- ProGuard build
- Website improvements/alterations
And that’s about it, really. Looking forward to getting v1.0 released ASAP.
It turns out that my initial estimates regarding the required storage for Gee-Oh! map tiles were a little out…
I somehow came up with the figure 66Gb for 597871 squares (representing a full 4->10 run) but, having just completed a 4->9 run, things are actually looking a lot sweeter.
For the 66430 tiles already produced, it only required 2.2Gb of storage, and this scales up to only ~20Gb for the lot. Won’t hardly touch the sides of my available storage!
This means I can back up the entire UK quite handily when this is done (as well as quickly copy across to new server(s) etc. for scalability), and also be confident of expanding to other geographical areas (Europe and the US).
Anyway, that’ll do for now. I’ve just started the final run (to be completed in roughly 45 days…) Buh-byyyeee!
Just a quick update on the pre-processing of map tile coverage for the UK – there are currently 52,815 map tiles on file, which constitutes just under 77% of a level 4 to level 9 run. This has taken roughly 5 days.
Once this is complete, I also need to do level 10 to finish it off, which will take approximately 9 times longer (hopefully less, since each square will contain 9x less data).
So I’m looking at around 11th June for the main UK pre-load to be complete. Hopefully under a Labour Government by then…
Of course, looking at the image above, we can see that there are sections of Scotland and Eire that will need to be processed additionally, and the tip of Cornwall by the looks of it (possibly a Channel Island or two for good measure), but essentially 11th June is a good estimate.
Once that is done, no more delays server-side. It’ll be all about getting the Android App finished.
I have finished GeeOhTileProcessor and have got it running in live right now, pre-populating the UK map tiles.
What you can see above is the “heat map” which is part of the GeeOhTileServer monitoring suite, displaying the current progress of level 8 tiles. Strange that the water tiles are not being represented in blue, but that is an issue for another day…
The run currently in progress is from level 4 down to 8, and I will be increasing this to 9 and 10 in the next week or so. Full UK coverage coming soon!
That is all!
EDIT: Problem solved – GeeOhTileServer was just not recording (for processtile API) on heatmap if blank file already exists, and if it didn’t already exist it was just recording it as a land tile. Looks a bit better now…
I’ve just replaced GOTSLoadBalancer (a SpringBoot application) with LoadBalancerApplication, which I wrote in Node/Express and I’m very confident that I made the right decision.
Deployed live some moments ago.
I fully expect Node’s natural qualities to shine through as a load balancing application, especially since I’ve recently tried hammering Node with JMeter and it’s held up perfectly.
It will certainly handle more load than the services it is load balancing for, so that’s fair enough.
Anyway, it’s 1.32am, I’m knackered and I’ve got to go. Happy Easter.
I’ve been thinking about the quantity of storage required to support GeeOhTileServer – I suspect it will be creaking under pressure from day one in its current state – and I’m now exploring the idea of limiting MakingTracksGPS/GeeOh requests to a max. level 10, as opposed to 11.
This will reduce the number of required GridSquares by a factor of nine – in real terms, a reduction in total from 5380840 to 597871 for the fully recursive processing of a single square at zoom level 4.
In order to maintain some level of image clarity, ie. avoid excessive blockiness, I will investigate increasing image resolution from 800 x 800 to 1000 x 1000, keeping a careful eye on optimising storage so I don’t completely wipe out any gains I’ve made by cutting out level 11 completely.
It’s likely that I will have to reduce the maximum scale factor allowed by MakingTracksGPS, so the user can’t just zoom in to absolute block-world, but I should be able to get that balance right quite quickly.
Whilst I’m working on the server, I might as well revisit the colour scheme too. I shall take a look at toning down the default green background colour to something more grey, possibly, and look at changing the colour of the railways back to the original orange/yellow. I might even look at what the accepted standards suggest!
And I’m done.
I have been wrestling, on and off, with a very mysterious crashing bug in an Android app of mine for quite a while now, and I’m hoping there may be light at the end of the tunnel.
What happens is, seemingly at random and extremely intermittently, the application will just stop and display a dialog saying “Unfortunately your bastard application has stopped” – or words to that effect.
I thought, “I’ll catch this, no worries” and added an UncaughtExceptionHandler ages ago.
The whole thing just bombs out and fails to catch any exceptions that might be causing this particular crash (has worked for other exceptions).
My next attempt was to put a ton of manual logging in – before, during and after every suspected event – but this became so unwieldy as to adversely affect the app’s performance, so I had to undo it all.
Now, onto my last ditch effort: I am temporarily diverting all logcat entries to a file on the SD Card so that I can read exactly what is going on just before the crash. With any luck it will die and surrender a full-on stack trace. Failing that, I will still hopefully see some tell-tale signs of what the actual problem is.
Wish me luck.