IOTA Area Codes: A Proposal to Geo-Tag IOTA Transactions

IOTA is a flexible protocol that can be utilized in various ways. The most common is value transfer via the native token. However, IOTA can be easily extended by building standards on top of the base protocol. Both Masked Authenticated Messaging & Flash Channels are perfect examples of this.

Today we are proposing a new standard that will enable IOTA-based applications to be built around geographic regions.

IACs are short, tryte-encoded, location codes that can be used to tag and retrieve IOTA transactions related to specific locations. The IACs are typically 10 tryte long and will represent a 13.5m by 13.5m area at the equator. However, IACs can be 11 trytes long and represent a 2.8m by 3.5m grid.

IACs are a direct copy of the Open Location Codes, also known as Plus Codes, proposed by Google Zurich in 2014. There are a few minor changes to make it compatible with IOTA’s encoding.

When publishing information on IOTA there is no way to easily identify transactions that relate to a geographic area. These transactions could contain localized service advertisements, sensor information, or any number of other data formats.

In order to find transactions related to an area, you’d have to register your transactions with a centralized service, like a data marketplace, that collects locations to store and serve them to consumers.

By using IACs in the first 11 trytes of the 27 tryte tagfield in an IOTA transaction, we can localize an IOTA transaction to a 2.8m by 3.5m area. This allows someone to find a transaction related to a small area; however, the real value of this system comes from the ability to query large swaths of land for related transactions.

The original OLC protocol is able to accurately represent areas on the globe by using 5 pairs of characters. Each pair of characters added to the code represent a 400x increase in accuracy. A side effect of the code being determined by a sequential set of pairs, rather than a unique code, is that we are able to vary the accuracy by removing pairs from right to left. This allows us to ingest and store the pairs in a way that we can query somewhat efficiently.

So by querying the initial four trytes of tags, that match the correct IAC format, we can find transactions in a 100km by 100km area.

Example: By querying for all tags that start with NPHTwe can find all items in a 100km by 100km area covering Berlin & parts of Potsdam. Then by using these 6 trytes: NPHTQOwe are able to see transactions within a few suburbs in central/north Berlin.

Example: By querying for all tags that start with NPHT we can find all items in a 100km by 100km area covering Berlin & parts of Potsdam. Then by using these 6 trytes: NPHTQOwe are able to see transactions within a few suburbs in central/north Berlin.

Today, we are publishing the library that enables the encoding and decoding of location data. Along with this, Martyn Janes has created a fully featured demonstration that allows you to do the following:

Create and convert IACs
Publish IAC messages to the Devnet
Wildcard query all IAC transactions on the Devnet.
Watch IAC transactions appear in real time on a map.

Demo Application: https://iota-poc-area-codes.dag.sh/

GitHub Library: https://github.com/iotaledger/iota-area-codes

NPM Repo: https://www.npmjs.com/package/@iota/area-codes

IACs are meant to be a catalyst for the community. The standard, in its current format, is useful but could be much better. We encourage you to drop by GitHub and create some pull requests to improve the code or suggest examples.