Just a vague update on the commencement of Gee-Oh! Mobile development. Since I got the server back on track and processing squares again last week, I’ve dived right back into the world of Android.
I managed to score a few quick wins from my previous “barriers to release” list, including the rendering of placenames (fading in and out accordingly), and also added the fading out of motorway/main road labels as we zoom out to particular values.
I did a little bit of housekeeping, removing a superfluous ViewThread class that was never really being used as intended, and lots of other little bits, too many to remember fully. Been a busy boy.
My latest venture is a very large refactor to incorporate multiple devices (for now, only a replayDevice and the debug testFlightDevice) and allow auto-centering on these also whilst preserving our actual location indicator on screen. I’ll do a separate blog on this, actually – ’tis a big ol’ topic.
And so this ends.
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 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.
Oh my God, finally. I’ve been chasing after a bug – on and off – for months now, and at last I cracked it today.
In the new MakingTracksGPS, there was this minor but very irritating bug where the location marker would periodically jump back a little bit during a pinch/zoom event. I tried so many fixes for this, absolutely none of which made a blind bit of difference. Until today.
I noticed that the rendering jump occurs quite reliably if you zoom in/out, then just keep your fingers still on the screen. So it wasn’t due to the actual zoom event, but rather something that wasn’t being reset until you let go.
Upon examining the ACTION_UP code block, I noticed a variable tempDisableInterpolation being set to false, so I followed its behaviour and – lo and behold – when this remains true, it results in incorrect calls to centre display on (effectively an incorrect) location.
I did a bit of refactoring, altered (ie. improved) the general behaviour of interpolated zoom, and now there is zero trace of this tacky, jumpy display error.
Now I’m down to four things on my “Barriers To Release” list:
- UniqueID DB table(s) and handling/monitoring the recording of usage stats
- Placenames rendering
- Pre-population of map tiles on GeeOhTileServer
- Need to be conscious of storage limitations
- ProGuard builds
And that will be it, I’ll be shoving the v2.0 Beta out the door ASAP.