OpenStreetMap logo OpenStreetMap

MapSplit format OSM data files

Posted by SimonPoole on 6 May 2019 in English.

If you remember in Going completely offline with Vespucci last December I gave some insight in to the improved offline support in Vespucci 13.0. Now that version 13 is available, I need to loose a couple of words on how to generate the files.


The original mapsplit application was created back in 2011 by well known OSMer Peter Barth, at the time it was used to prepare input for OSM2World. The slight rework that I started late last year adds support for producing output in MBTile format (instead of copying a couple of 100’000 or so files to your mobile :-)), higher and variable maximum zoom level for the tiles and an optimisation pass.

When generated from OSM source data that has referentially complete ways, the individual tiles are referentially complete too. That means a tile will contain all nodes referenced by ways included in the tile, and all relations that have members in the tile (but not all members of those relations). If input data contains metadata fields (that is OSM id, version and date) the resulting files can be used by OSM editors just as data from the API. Naturally the data will be at least a bit stale and that needs to be taken in to account when using it in an editor.

While you can simply download the current release and generate files yourself, to make life easier for user that just want to quickly try things out, I’m generating some files for some regions on a daily basis on Within reason I can add more if there is interest.

To configure MapSplit files as a data source in Vespucci, see the 13.0 release notes.

Still in the pipeline is support for updating files (best would be on device, but that will need some work).


Comment from Lee Carré on 30 July 2021 at 22:33

Thankyou for your efforts with all of this. I use Vespucci often (I prefer surveying over armchair); it’s very good (especially given the limitations of nano-computers).

Within reason I can add more if there is interest.

I would be interested in being able to try this, with a view to using it regularly, for (the island / Bailiwick of) Jersey (else the Channel Islands as a whole). Particularly since I don’t have access to a micro-computer at the moment, and so can’t run mapsplit to generate the file(s) myself.

Some of the island’s more remote places have spotty connectivity (if it works at all, then you might get no better than 2G’s EDGE), and due to being an island tariffs for data are either not cheap or not generous. I pre-load via 802.11 before heading out, to minimise data transfer over the mobile network.

I have some ideas for further improving the offline experience, but I’ll raise them on Github.

Comment from SimonPoole on 31 July 2021 at 06:25

If this coverage is enough I’ll add it sometime today (otherwise I need a .poly file for the area in question).

Comment from Lee Carré on 29 September 2021 at 12:44

If this coverage is enough […]

That’s entirely adequate especially for a simple (minimal-node) polygon; includes all the major islands (and excluded ones are, apparently, disputed territory).


Thanks. Been using it regularly for a while, to great effect. I’ve non-trivially changed how I use Vespucci since, which makes my work-flow easier & more productive.

My overall data usage (including over 802.11) has reduced significantly. While out, I find that I’m spending more of that time actively surveying (rather than waiting for data transfers), including in poor-reception areas.

Preparation time (ensuring various apps have recent data) is also now minimal compared to before.

I imagine the load on the API hosts is much less, too, now. The ‘update data’ function used to take several minutes up complete, before.

The time-of-day when the files are generated is sensible, also; at least for European timezones. Capturing all of the previous day’s changes, but ready early enough to fetch first-thing each day.

The only possible complaint (about the data) is the interval of generation; sometimes changes made the same morning are then not available in-editor. However, that seems beyond the scope of a complementary service, and more frequent updates are achieved by generating the data oneself. Else, ideas for software modification I’ll (eventually, maybe over the winter) open GH issues for.

However, because editing activity is low, I’ve yet to encounter a conflict which I couldn’t resolve. Though, for areas with more activity, it may pose a problem.

So, overall, this component of offline-use very much achieves the desired goals for real-world usage. 👍🙂

Log in to leave a comment