Leadme is a small project which I started in my spare time. I am releasing the current status to get feedback, even though the software is not in a usable state yet. This page was written rather hurriedly, feel free to send me email for details.
The overall aim is to create accurate maps of the inside of buildings that are generated by volunteers, similar to what OpenStreetmap does for outdoor maps. These maps will be useful e.g. to find a particular shop in a big shopping mall, either by searching for its name or the type of product one needs. In big administrative buildings, the search could be for a room number, or for the next restroom or coffee dispenser.
Ideally, the maps would be available on handheld mobile devices, but display or route planning is not the aim of the project at the moment - the maps need to be created first! ;-) Locating oneself inside a building is also not a primary concern at this point. (However, I am planning to include WLAN access point information, including field strength, in the building maps, so that if there is no GPS signal, a device may still be able to find out where it is from wireless AP beacons.)
When creating the maps, it is a problem that GPS does not work reliably inside buildings. Additionally, its accuracy may not be sufficient for small-scale maps. (Maybe differential GPS would be accurate enough, but it will not work in buildings either.)
As of this writing (Dec 2009), to my knowledge no company seems to work on creating maps which are detailed enough to include room numbers in public buildings. The one exception is California-based Micello, but they create their maps from building plans rather than walking through the buildings - no grass-root mapping, but filling in forms to get access to building plans... Furthermore, judging from the DEMOfall 09 Micello video, their mobile navigation applications still seem to be in their infancy.
I have built what (for want of a better term) I call a "position mouse", i.e. a "GPS mouse" which determines its own position using other means than GPS. The device is a trolley whose two wheels I replaced with bigger 100mm wheels. A gaming mouse is attached to each wheel, so it can measure (with sub-millimeter accuracy!) how far it is moved, whether it is turned in another direction and in which direction it is moved. Only gaming mice can keep up with walking speeds.
The two mice are connected to a laptop on the trolley, which runs my software and creates a trail of the position mouse movement. Additional features of the prototype allow assigning labels to points on the map. The position mouse could be extended in many ways - another day.
The software part is also called "Leadme", see below for a screenshot. The maps are stored in XML files whose format is strongly influenced by OpenStreetmap's .osm files. The biggest difference is that rather than storing coordinates as latitude/longitude/height, they are stored as x/y/height, measured in meters. Lat/lon coordinates are still possible on top of this to allow GPS-enabled devices to find out where on the map they are. (I am not sure whether x/y/height is better, at the moment it seems to be more appropriate.)
I was hoping that I could extend an existing OSM editor like JOSM to do what I want. In the end, however, I ended up writing an editor from scratch - this may have been less work than trying to bend JOSM into something it was not designed for.
The indoor map editor differs not only due to the different coordinate system, but it needs to have better support for visualization and editing of many, many layers (i.e. storys in a multi-floor building). Furthermore, the position mouse has the problem that it measures relative movement, not absolute coordinates. Thus, if you walk through a building and then end up where you started, the many small movements measured by the mouse will not add up to "no movement", but may be off by a considerable amount. The editor needs to adjust the map graph "live" (e.g. using a force-directed algorithm, not currently implemented) while it is being recorded to avoid such problems. For example, turns are likely to be right angles in most buildings, and after returning to the starting point, the person doing the mapping should be able to insert a "zero-length rubber way" to indicate that they are back where they started.
Snapshot release (copy of git repository): leadme-git091206.tar.gz
The screenshot above shows the editor with a (nonsensical) example map loaded. A semi-3D/semi-isometric view is used: Ways/nodes with differing z values are offset vertically and drawn with a correspondingly larger or smaller stroke width. At the z value of the position mouse (i.e. the "cursor", dashed circle), the lines are fully opaque, above/below they slowly fade into transparency. Ways are shown dotted if they are not horizontal, i.e. ramps, stairs or elevator shafts. Selected nodes/ways get an orange outline. .osm file of the nonsensical example map.