Challenges for Indoor Maps
This page lists some of the challenges for adding indoor maps and Indoor Mapping in OpenStreetMap, beyond the technical challenge of making the maps themselves.
Handling of New Data by Existing Software
The OpenStreetMap database is flexible enough to handle indoor data in any of numerous possible formats. However if a large amount of indoor data is added to the databases they may end up having undesirable consequences for existing renderers. This can be seen on existing indoor maps. Some objects from the indoor maps are rendered on different renderers, such as objects with a name or walkways.
There are also some challenges for the editors. The editors will show all the data, and the indoor data can be a mess, particularly when simultaneously looking at all the floors from a multi-story building.
The most likely way to handle this is to have a well agreed upon form of the data and make an effort to accommodate this format in the renderers. Likewise, additions can be made to facilitate handling the data in the editors. The editors do not have to initially be optimized for making indoor maps. But they should at least be made so it is not easy for users to accidentally mess up the indoor data, e.g. reporting errors on intersecting walls on a multi-level mall, when in reality they are in different levels and not intersecting at all.
Stores in a Shopping Center and other Entities on the Map
OpenStreetMap has no means of handling business listings. Businesses are added directly to the map outdoors. Indoors it would be preferable not to do this. The same probably applies to outdoors too.
For the case of a shopping mall it may be preferable to have a database of stores which can then be tied to an object on the map (a unit in a shopping center or a building, to give two examples). The stores in a shopping mall change fairly quickly, monthly, whereas the physical building seldom changes. In addition, this makes it much easier to manage information about the store, such as hours of operation and the description or even the type of store.
To connect a business (or other entity) to an outdoor map, the customary method is using the postal address. Indoors, there is also a concept of address. A shopping center often labels the store units. For example, at the Valley Fair Shopping Center in San Jose, CA, Aeropostale occupies store #2577. The same concept extends to classrooms in academic buildings, rooms in hotels, booths at conferences and even spots on the shelves in a retail store.
The idea of locating objects by reference is important whether stores are drawn from a separate database or not. Other objects must be tied to the map using the reference because they cannot be hard coded onto the map. A good example is the schedule for a class room at a university, or the location of a product in a supermarket.
Other maps indeed treat business listings as separate database rather then including them directly in a map.
To solve this problem, a separate database could be created or an existing open third party database could be used.
- Could you please add some arguments to your conclusions presented? For example, what are the undesirable consequences for outdoor mapping you mention in the first paragraph? Why do you think that outdoor data about shops should not be in main database? Why? --Jakubt (talk) 21:44, 6 February 2014 (UTC)
In most cases the indoors are privately owned places, even if the public is allowed in there. This should not however prevent OpenStreetMap from doing indoor maps since there are some places that will openly invite OpenStreetMap to map them. The legal challenges and the resulting limitations of course have to be considered.
It would be nice to have a solution for temporary maps, such as a convention like Mobile World Congress. This map is only valid for a short period of time. These objects could still placed in the OSM database and later deleted, however this doesn't seem like a good idea. For one thing, there are surely cases where the data would not get deleted and the stale data would pollute the map. Even in the case where someone did return to delete the data, there is a good chance they would delete some good data, such as the conference hall itself or maybe just some of the bathrooms.
It would be good to make a secondary database for mapping temporary data. This has the benefit that the data does not have to be deleted, so the, e.g, map of the 2012 Mobile World Congress could be kept for future reference. Another benefit is that the data can be deleted without damaging the OSM database, so that server expenses for storing and serving it become temporary.