I’ve made so much progress with the maps and whatnot lately, this blog is overdue a visual update (I will get some good screengrabs as soon as possible), but for today I am focussing on implementing better thread management when loading up GridSquares.
I’ve already got a decent POC, which limits the number of threads “in play”, has the ability to kill off no-longer-required threads, and has a (not yet fully working) method for selecting the next thread based on priority.
I will get that priority-determining method sorted at some point today, after which I will move on to designing an intelligent way to pre-gather GridSquares into the “in memory grid” (which I implemented last night). I needed a quicker way to get squares into the grid when limits have been exceeded, because loading from the file system is probably not the most sensible way of getting immediate refreshes…
Now that I think about it, I might want to change the limit detection to perhaps a padded area around the edge of the screen instead of precisely the edge. Should give me a bit more “lead time” to get the data in there.
Aside from that, I’m still trying to find an efficient way to get land outline polygons from Overpass. I probably should solve this before I unveil any screengrabs – definitely need this for the map to look nice.
I’ve now got (almost) good quality spatial data being rendered as part of the grid but, as you can see, there is some discrepancy between the true GPS data (shown in red, rendered line by line using projection method) and the pre-rendered image (shown in white).
Also, for some reason, serialization stopped working for the GridSquares, so I will need to look into that too.
My last (immediate) task is to figure out why the mouse location seems to be out of sync with the GridPanel (by (-2,-2)), which I’m hoping is just an issue related to accessing my machine through a remote connection. I’ll find out later.
So, to formalise my current focus:
- Fix serialization issue
- Solve inaccurate mouse location value
- Get image to fit data properly
After that, I can begin to play with getting a full grid on screen, and auto-updating when grid is dragged/zoomed beyond certain limits, not forgetting playing around with the actual rendering (ie. making the whole thing look niiiiiiiiiiice!).
I’ve had plenty of success the last week or so with gathering raw GIS data, parsing it and processing it into usable objects/data, and (initially) rendering to a graphics object that is subsequently auto-stretched as the view scale changes.
It looks shite at the moment, but after a bit of tweaking – and a lot of work to make it aesthetically pleasing – this is going to be a big deal. The main milestones have already been dealt with, I think, so that’s cause for celebration in itself.
My current/next focus:
- Get the scaling correct for rendering to the GridSquare’s stored image
- Figure out required GPSScale value that corresponds to each map zoom level, resulting in consistent quality of render to, for example, fixed 600×600 image size
- Make sure image lines up correctly with manually rendered GIS data
- Alter query type to omit certain road types as map zoom level decreases (to take in more area)
- Detect point at which map zoom level needs to +/- based on size of GridSquare
Not too much left to do really, in a broad sense, with the GeeOh! client. I guess most of the remaining work will end up being menu implementations, tidy up tasks and other unforeseen issues. I’ll need to make some progress on the GeeOh! server soon, and get this thing off the ground!
Got a little bit of work done on the maps this weekend, I’m quite happy with the progress. I’ve now got the new GridSquare class implemented, with its spatial data stored as GPSPoints, so I’ve got rid of this ridiculous two-tier method which creates the grid in screen coordinates, and then somehow tries to tie itself to GIS data.
My immediate tasks are:
- Implement keyboard shortcuts and toolbar buttons for:
- Zoom in/out
- Map zoom level +/-
- This controls the actual size of the grid squares
- Render stretchable “holding” image in each of the squares
- In anticipation of the correct spatial data bitmaps being rendered/persisted
- Detect points at which zoom value triggers change in map zoom level
While the big task remains: Gathering the raw GIS data in a quick way, in useful format, and process this efficiently into the application.
I feel like this is quite achievable – and will be a massive step forward for me once I’ve done it.