Proposal:Indoormark=beacon

Indoor beacons - Key:indoormark
Proposal status:	Approved (active)
Proposed by:	deuteros
Tagging:	indoormark=beacon Data item
Applies to:	database type -
Definition:	How to tag a beacon inside a building
Statistics:
Rendered as:	icon
Draft started:	2015-07-20
RFC start:	2015-07-30
Vote start:	2015-09-01
Vote end:	2015-09-15

Proposal

Currently there are well-defined rules in Open Street Map for labelling beacons for sea and air transport. Inside a building, the problem to solve is very similar having the same objective: to position and guide a user through the venue. This proposal has an analogue scheme to the mentioned existing tags for sea and air navigation but in this case the idea is to label several types of indoor beacons.

Rationale

Indoor location and navigation are fields of investigation that require a geographical information system to store information. Not only the layout of a building and navigation graphs, also the location of indoor beacons are important for such solutions.

The Ubica2 project developed by Zed with the collaboration of URJC is creating an indoor navigation system based on several indoor positioning technologies. Some of these technologies require the use of beacons such us:

• ibeacons: they provide proximity location enabling triangulation positioning
• NFC tags: they can provide the coordinate of the current position
• QR codes: as the NFC tags, they can provide a known coordinate.

But all these items have to be deployed in a building and therefore, their information has to be stored in a geographical data base. Having this, navigation applications could query the information required to locate and guide the user. This proposal tries to find the best way to store all the data belonging to beacons in Open Street Maps

Tagging

It is proposed to label the markers in a similar way as is established for seamark and airmark tags. To this end, the label indoormark is defined and assigned the value of beacon. Furthermore, we can extend a beacon with a number of attributes that allow accommodate all the information necessary.

The scheme devised as follows:

	Key	Value	Comment	Suitable for
required	indoormark	beacon	Mandatory tag for defining a point which is a beacon	All
required	beacon:type	String	Distinguisses the type of the beacon: bluetooth, nfc, qr...	All
optional	beacon:address	String	Network address identifier	ibeacons, NFC
optional	beacon:uuid	String	Unique identifier given normally for ibeacons	ibeacons, QRs
optional	beacon:major	Integer	ibeacon major number	ibeacons
optional	beacon:minor	Integer	ibeacon minor number	ibeacons
optional	beacon:measured	Integer	signal strength calibration value of an ibeacon	ibeacons
required	level	*	Level where the beacon is deployed. This is specified by Simple Indoor Tagging	all

The only mandatory tag is the indoormark key but it is suggested to add some more information using the other tags shown in the previous table. In addition, the use of the level tag provides compatibility with the specifications written in the Simple Indoor Tagging wiki page. Doing all that, navigation systems could retrieve all the data they need to position the user. For instance, an ibeacon based application should know the major and minor numbers to distinguish any ibeacon. A NFC tag would give its unique address when detected and this value could be use to match an indoormark in Open Street Maps and obtain its coordinates. See the examples below to know how this can be achieved.

Examples

QR beacon

QR codes can be used to give a unique identifier when scanned. An approach to transform that to a position within a building is to match the unique identifier given by the QR with the item tagged in our OSM map. Doing this, we can get the coordinates and also the level where the QR is placed.

indoormark=beacon
level=0
beacon:type=QR
beacon:uuid=123456

NFC tag

NFC can be used in a similar way to QR codes. In this case, the address of the NFC is unique and the procedure to obtain the location could use its value to get the coordinates and level from the map.

indoormark=beacon
level=0
beacon:type=nfc
beacon:address=11:11:11:11:13

bluetooth (ibeacon)

In the case of an ibeacon, we will need more data in order to make work our triangulation algorithm. Useful information to store is the uuid of the beacon, its major and minor numbers and the signal calibration value (measured)

indoormark=beacon
level=0
beacon:type=bluetooth
beacon:uuid=123456789
beacon:major=1
beacon:minor=2
beacon:measured=-56

Applies to

Bluetooth/BLE beacons, NFC tags and QR codes used mainly for indoor location purposes

Rendering

Rendering could be done using icons preferably. In our project we are using a map style for JOSM in order to differentiate all types of beacons

Example of indoor beacons in JOSM

Voting

Voting closed

Voting on this proposal has been closed.

It was approved with 10 votes for, 1 vote against and 2 abstentions.

• I have comments but abstain from voting on this proposal. Looks OK on paper, but the lack of RFC comments is a worry. --Kelerei (talk) 16:53, 1 September 2015 (UTC)
• I approve this proposal. Ok for me, sounds like a scalable schema and pretty well documented Fanfouer (talk) 18:22, 1 September 2015 (UTC)
• I approve this proposal. Clear, useful and simple --PanierAvide (talk) 18:40, 1 September 2015 (UTC)
• I approve this proposal. --Warin61 (talk) 06:24, 6 September 2015 (UTC)
• I approve this proposal. --Tordanik 12:01, 9 September 2015 (UTC)
• I approve this proposal. -- The proposal looks good although I doubt I'll ever use it. AlaskaDave (talk) 07:41, 14 September 2015 (UTC)
• I approve this proposal. --Hedaja (talk) 07:55, 14 September 2015 (UTC)
• I approve this proposal. -- known indoor beacons act like indoor orientation points - a great thing to have mapped Javbw (talk) 10:51, 14 September 2015 (UTC)
• I have comments but abstain from voting on this proposal. I'm not yet clear on how these beacons work. Interesting concept, but totally opaque. Paul Johnson (talk) 11:42, 14 September 2015 (UTC)
• I approve this proposal. --Deuteros (talk) 15:31, 14 September 2015 (UTC)
• I approve this proposal. Well documented. I hope to see the icons in Proposed Icons --Pyro Maggot (talk) 02:09, 15 September 2015 (UTC)
• I approve this proposal. --Jojo4u (talk) 08:38, 15 September 2015 (UTC)
• I oppose this proposal. The name of indoormark tag sounds like it's taking inspiration from the seamark tag namespace. I think this is bad because the OpenSeaMap tags don't fit very well with the rest of the OpenStreetMap tags, often providing duplicate ways of tagging things. Why not man_made=beacon? --Peter Mead (talk) 16:13, 15 September 2015 (UTC)

man_made=beacon could be a water way/sea mark. Indoor ... I don't see that being used at sea nor on the water ways. High'ways' are not confused with water'ways', yet both have the 'inspiring' 'way'. Warin61 (talk) 22:36, 15 September 2015 (UTC)

Yes man_made=beacon could also have a seamark:beacon_*:* tag, or alternative it could have a aeroway=beacon tag, or it could have a new one to identify it as a being indoors.