Map-it-Yourself project
a small-screen web app that just got bigger!

see copyright notice. Page created 16-Sep-2022 updated 10-Jun-2025. Use the button groups above to navigate quickly around the site.

This browser-based application uses GPS data to show and track the user's location on a map image, which can be anything from a scanned-in paper map to a photo of a site plan or something drawn from scratch. It's recently undergone quite a few changes, so I'll start by describing the latest incarnation, with some historical notes appended.

The user interface comprises three panes, which stack vertically or horizontally depending on the display dimensions. In the first pane, a square map image is overlaid with cursors showing the initial, current, and (optionally) destination locations, and hairline crosses marking the two most recent "trail points". The latter are recorded at intervals during a journey, and can be exported as a text file for later reference.

The second pane shows the map scale and identity, and details of the most recent location fix - date and time, grid co-ordinates (easting, northing and altitude) and National Grid Reference (NGR). Below the information boxes are two clusters of "keys" for control and navigation purposes. I must admit to spending a lot of time crafting these, and perfecting a coloured "backlight" effect to show the current mode: red for "stopped", green for "running" (i.e. plotting location in real time) or blue when replaying a trail.

Map "tiles" are 100km (square), 8km, 4km, 2km, 1km, 500m, or 250m (the latter mainly for finely-detailed local plans). For each scale, a directory (folder) contains jpeg images at a standard size (400x400 px) whose filenames identify their origin co-ordinates. For simplicity, I decided at an early stage to make the navigation keys "hop" from each tile to the next. But I also made the origins overlap by 50% for a more intuitive feel when panning across an area - despite the extra work involved when "cutting up" a scanned map!

I should state here that scanned-in maps exist only in my own portable devices, and are used solely for personal, non-commercial purposes. Should the app be made available to anyone else, they'll need to create their own map images! So, why have I gone go to all this trouble when navigation apps are available for free? Well, firstly I'm used to the style and content of the printed maps and atlases I've bought, and prefer them to any of the alternatives I've seen. Secondly, I can launch and use my app without a network connection (and it's ad-free!). But the plain truth is that I enjoy the challenge of creating software like this from scratch, and giving it exactly the features I want. For example, the trail export can be used, following a site walkabout, to fine-tune a completely new map such as one I made (glimpsed on the smartphone photo) of some local playing fields for a "Friends" group. That's why I've named it Map-it-Yourself.

The arrow keys nudge to the next map tile, while the zoom-in ones upscale the selected quadrant, if the tile is available (if not, a "MAP N/A" tile is shown, but the cursors remain functional). ZOOM OUT downscales the tile, while FIND ME loads an appropriate tile at the current scale, and is useful if you've wandered off the edge! (I did try making the map tiles track location automatically, but found it rather distracting). The 3 keys at the bottom-left control the trail replay function.

A tap on SHOW STATS replaces the navigation cluster with a dynamic summary of journey statistics, as pictured. First is the total distance travelled so far "on the ground", and the average speed. Next, the distance and bearing "as the crow flies". The third box shows similar details if a journey destination has been set. Last is the speed and bearing between the two most recent trail points. Metric units, and/or bearings in degrees (instead of compass points) are options in the control panel described below.

The stats legend mimics some of the icons that mark locations on the map. The current-location cursor is actually animated, not only to catch the eye but also to avoid permanently obscuring any map detail. Different cursor styles appear according to the app state - running, awaiting location fix, stopped, or replaying a trail. SHOW NAV restores the navigation cluster.

The third pane, a control panel, is normally hidden on a phone screen; you scroll up to reveal it. Lock Keypads does what it says, placing a black "cover" over the keys in the normal display, to prevent accidental touch operations (there's a little hole in it so that the mode backlight remains visible!).

Hopefully most of the options are self-explanatory. The time and distance selectors determine the resolution, and hence the size, of the stored trail data; Ranges are 2-60 seconds, and 0-1000m respectively. The data is stored, along with all the other app settings, in the browser's local storage; this can optionally be retrieved when the app is next run. Trails can also be exported and imported as text files; the first line contains the start time, co-ordinates and altitude, subsequent lines list incremental changes to these. When Replay Trail is checked, a journey (including statistics) can be replayed step by step from the keypad. The double arrow advances in steps equivalent to 1/10 of the entire journey.

The Show background image feature requires some care in setting up, but can be very useful. It lets you replace a map tile with a portion of any image (including one taken by the device's camera) chosen via the Load image button. Typically this might be a visitor map or plan displayed on-site. Initially the image is shown in Calibration mode, where a special set of navigation keys can be used to match the image size to the current scale, and align it with the current-location icon (of course, these adjustments are only practical if there's a scale on the plan and you know where you are!). I've converted a few such images into properly formed map tiles, which can be accessed at the most detailed scale settings.

The Area list is defined by a JS configuration file, which specifies a "home" map tile for each of an arbitrary number of named areas.

Over time, as I built up a collection of maps, I began to need an on-screen reminder of which areas were covered, and at what scale. This is now automated; a separate utility scans the map folders and creates an image of coloured blocks to overlay on the largest-scale maps. The pretty icon at the bottom left of the control panel is a key to the block colours and their overlaps. The letters (which prefix map file names) are loosely based on imperial map scales - inch [to the mile], half-inch, and two-inch. Or was it two-and-a-half?

Running MiY on an Android™ phone hasn't been without its problems. None of the browsers I tried made it easy to load pages directly from a structured tree of memory files - so I installed Simple HTTP Server to bridge the gap. Then there was the issue of browsers losing GPS updates when the screen timed out; only favoured apps such as Google™ Maps have an "Allow all the time" location option, and there's no longer an "always on" display setting. The upshot is that if I want to record a complete trail for a long journey I have to run Screen Alive to override the screen timeout, and turn the brightness down to conserve power. Incidentally, that's why I made the Lock Keypads control so big. Annoying!

To assist the process of drawing from trails, I've written a PC utility named PlotTrail. It represents a trail as a series of points, on a 400 x 400 pixel "tile" which can be scaled and navigated in exactly the same way as MiY's maps. The points can optionally be joined with lines, and/or tagged with colour-coded altitude bars (displayed either vertically or horizontally, to suit the trail geometry). Copy Plot copies the image to the clipboard, whence it can be pasted into a drawing environment.

On a technical note, I've been working to improve MiY's conversion from GPS data (latitude, longitude and ellipsoid height) to map co-ordinates (eastings, northings and height "above sea level"). Strictly speaking, this requires a Helmert Transformation from the WGS84 datum to OSGB36 - serious computing, the prospect of which rekindled a familiar battle between the Maths and Engineering departments of my brain. As usual, the latter won; to conserve both my sanity and the device's battery power, I coded up a (comparatively) simple TM projection without the datum change. Of course, that produced co-ordinates that were quite a few metres out - but I added tweaks to get the right answers at a local reference point. The improved version refines those tweaks based on latitude and longitude, and now gives results that I believe should be correct within a metre or two over most of Britain.

Altitude, however, has proved to be a minefield. Having carefully crafted a tweak along similar lines (using a "strict" transformation as reference) I found that some devices (such as my tablet) "pre-correct" the ellipsoid height to asl, whereas other (such as my smartphone) don't! So I've put a switch in the config file to turn the conversion on or off as required.

MiY History

It all started back in 2012, when a friend kindly gave me a Blackberry™ Curve 9300 smartphone - a contract upgrade she didn't need at that time. My own mobile, a Philips™ C12, was at the end of its useful life (c.12 years?); I'd extended that life by replacing the original battery with one home-made from individual Ni-MH cells, but lately it had started to shut down intermittently, for no apparent reason. So I lost no time in getting the Blackberry unlocked and transferring my SIM to it.

I quickly discovered that the Blackberry's browser was happy to load pages from a microSD™ card, and it had a (proprietary) geolocation API, providing real-time latitude and longitude data. At the time I was accustomed to going on long walks with paper maps for guidance, so I did some experiments with scanned-in images from these, and by 2014 I'd written some code to compute grid co-ordinates (easting, northing), and position a flashing cursor over maps on the tiny screen. In 2022, having bought a cheap Android™ tablet, I modified the code to use the HTML5 geolocation API, so it could run on virtually any browser. The photo shows the original Blackberry alongside the tablet and a laptop computer.

The Curve's screen resolution is 320 x 240 pixels, and after a few trials I decided to use a 400 x 400 navigation window, with a similar size control panel below it. That proved to be a good compromise between legibility and frequent scrolling, although I often had to zoom the browser when I hadn't packed my reading glasses! Although a higher resolution would suit some screens, I've stuck with the original dimensions, partly to avoid having to re-master a large number of maps! Most smartphones scale graphics to a width of that order anyway, and in fact I've set mine to exactly 400px using the Minimum width setting in Developer options.

To make the most of the small display, navigation was originally done via semi-transparent arrows and zoom-in icons overlaid on the map image. A tap on the centre of the map conjured up the "stats" panel as yet another overlay, dismissed by a second tap. The control panel was a rather messy array of labels and controls, compressed into the smallest space possible! And before the advent of local browser storage, the only way I could think of to save settings and trail data was to store them as "cookies".

top ▲