Tuesday, February 7, 2017

CD-OS Standalone Integrated Map Server (IE6 Compatible!)

You can't have a batcave-in-a-box without a fully integrated map server. Executable is at 1.45 MB, the entire web application still fits onto a floppy disk compressed with UPX.

The map server file is a direct export in SQLite R-Tree format of tiles from OpenStreetMap. I am hosting a database sample of tiles from just around Melbourne that is 5 megabytes resolving down to zoom factor of 18 which is enough to make out potholes. You could support the entire planet from OpenStreetMap but it may involve some path assignment to some remote folder if the map is huge and the local storage is not big enough to hold it. I was already planning to do this with UPC barcode lookups - access the reference data in a remote file path where specified. Still working out the nitty gritty details of this kind of expansion.

The drawing and notation tools all work and they were painstakingly ported from an abandoned Raphael layer editor. They are essentially a subset of Google maps at the moment but in time I will support all vector custom icons in addition to the map marker. At present you can draw a complex layer of regions, polygons and markers but it is not quite saved to GeoJson correctly, I have to add some more conversions. This is in VML fallback when SVG is not supported and looks identical on IE6, I tested it about one hour before I posted this blog.

I need a rich ability to select filter layers to turn off custom overlays of radioactive zones, contaminated areas, explored regions, looted blocks, etc. that does not exist yet. I may start with a few hardcoded ones and after some testing find a good way to add a flexible layer system the prepper can customize to his needs.

Obviously this is a terrific tool for planning journeys and designing scavenging runs to known locations. When it is all working it will support complete trip planning including supply lists and checkpoints. At some stage if I get real-time messaging working from remote clients for websockets I could send realtime tracking geolocation messages to find all your people wherever they are at present. I have been gathering information on how to receive Soviet hardened GPS and other alternatives that might survive nuclear war and this will probably be a package in it's own right.

Finally got this working. Believe it or not the REST tile server AJAX call is only about 40 lines of C code. The real intelligence is in the data in R-Tree tables that rapidly look up the correct tiles for given viewport and GPS coordinates.

I have a polyfill for Geolocation coordinates that uses the real-time ones in the device you are carrying or falls back to hardcoded data for the server station to show you where the server is running or you are browsing from.

This map server is separate from "DIAGRAMS" which is a whole batch of additional functionality supporting arbitrary floorplans and layouts with real-time markers on them. These diagrams are intended for internal use inside the shelter or layouts of the prepper retreat buildings, etc. to assist in all kinds of planning including security. Will be demoing those pretty soon.

Once I got the basic architecture sorted out, the rest of the code is falling together really quickly, almost all of it having been working at one point or another in the past.


Ibn Nafis said...

I think this functionnality will be extremly useful post-nuke. When you will run out of food and you will need to go out scavenging, you'll be able to check nearby cities and all that. You're bringing the Fallout universe to life. Now all you need is a Pip-boy ! Think about defenses too. Buy a gun if they are legal in Australia because humans aren't civilized during an apocalypse. They could kill you and your family and loot your bunker and your stuff.

Ave said...

Yeah... well... as for myself I'd rather use paper maps any day.

Tex, will the installation screen have check-box options, in case I wouldn't want this feature installed for instance. I have no doubt it runs, but I would like my setup to be clean and lean (no synthetic voice, no maps, no inventory, just the sensor station)

Texas Arcane said...


I foresaw this in advance and nearly every single option, script and supplemental database has an "Enabled" column field that is set to "true" at present as a default. I saw the installer as running a simple bitfield of features to support and automatically unchecking all features not desired in the deployment. I thought people would just want components in many cases, in particular on tiny machines. If we get it compiling on an Arduino, for example, off a flash card, you'd have about 75% of the default features unchecked.

All the menu entries you see have an "Enabled" flag in the database that determines whether or not they are even loaded and displayed.

Ave said...

OK this is a good feature.

On the road to WW2, France had a crappy fighter (the Morane-Saulnier 406) and a good one (the Dewoitine 520) which was produced in insufficent numbers because the engineers wanted to make an even better model. It never happened, and in 1940 there weren't enough "good-enough" fighters.

Of course you do what you want, but I'd suggest that if you find a new exciting feature you delay its implementation and focus on releasing the existing program as it is.

Sam said...

That is very cool.