AND Data/AND-tag-mapping-to-OSM

This document specifies the Mapping of the TAGs used by AND to the TAGs used by OSM. This document may not be accurate. Please contribute and help fixing!!!

Copied from the wikified AND_Data/Spec on 10. July. Please update any later changes of the AND Specification to this document.

The first part of this document discusses the major differences of those tagging schemes. Here we collect all items which may impact OSMs current tagging scheme, these may additional tags or even changes to the current tagging scheme. Feel free to include any other differences worth being considered. At a later point of time it will be needed to officially propose new features or generate corresponding feature change requests (see Proposed features).

The second part of this document describes the mapping of ANDs tags to OSMs tags in detail.
Use the "discussion" tab to suggest new or better tags.

* ANDs Scheme mixes governmental function "Capital" with size definition* ANDs Scheme does finer detail the number of habitants* At least in Germany the decision whether something is a town or village is not a purely decision by the number of inhabitants, however an administrative decision. Thus the numbers have limited meaning* We should not mix administrative decisions with population numbers in one tag.

Tagging of Nation Codes and Province Codes (differences)

* The nation code is an AND-specific code.* It is generated from the feature geometry + country boundaries.* Seems to be orthogonal to the current data in the OSM. Thus inclusion my be deferred.

* Ignoreor* Add to Country Borders to OSM Database and Tagging scheme

Province Code

n.a.

* The province code is an AND-specific code.* It is generated from the feature geometry + province boundaries.* Requires Province boundaries in OSM* Seems to be orthogonal to the current data in the OSM. Thus inclusion my be deferred.

* Inclusion into OSM might be considered, however journey times may change or different ferries may have different journey times. Additionally should this journey time include waiting time? Thus is the OSM database really the right place to put it. Needs discussion.

* Ignoreor* If proposed as new feature consider uncertain outcome and discussion period

Sea plane base

n.a.

* Inclusion into OSM might be considered.

* Ignore so faror* Propose as new feature

Rest area with parking, ...

amenity=parking

* Inclusion of "amenity=rest" into OSM might be considered.

* Ignore so faror* Propose as new feature

TMC-code

n.a.

* Have TMC codes any benefit to OSM?* With digital Radio replacing FM radio, TMC will be replaced by TPEG [1]

* Ignore

Virtual

n.a.

* These are either relations between train stations and nodes in the road network, or virtual connections that connect "islands" to the main road network.* Artificial things like "virtual" are hard to integrate into Josm* This seems to be used to calculate travel times, when a vehicle type other than car is used (ferry, flight, walking) within a journey. Instead of modeling the possible ways in the database the virtual connections seem to provide, e.g., information on average walking time duration.* Journey

* Ignore for ferries, as OSM would be mapping the ferry route* Get some discussion how we want to model the walking routes and travel times within Airports, Ferry Terminals, Railways Stations including their Platforms and Exits, etc.* Will likely take a long time until we will take care for these details.

* The OSM tag applies only for lakes.* ANDs tag applies to lakes, rivers, canals and seas of major importance. This means that these features are meant to be shown on large scale maps.

* Use OSMs tag?* Create new tag

Minor water boundaries

natural=water??? (Area)

* The OSM tag applies only for lakes.* ANDs tag applies to lakes, rivers, canals of minor importance. This means that these features are meant to only be shown on small scale maps.

* Use OSMs tag?* Create new tag

Maneuvers (differences)

AND provides information for maneuvers for navigation. OSM has no such information and prefers generating navigation data from the OSM database using some kind of transformation. Any information currently missing in the database (such as turn restrictions, etc.) is expected to be added to the database at some time in the future. Currently, a feasible editor concept is missing for such data.

While it is unlikely that OSM with overtake AND's maneuver concept, we are interested in learning more about this concept from AND:

How has AND implemented maneuvers?

Which lessons have been learned when applying this concept in practice?

AND has implemented maneuvers as a relation between a "from" segment, a "via" node and again a "to" segment. The node is necessary in case of U-turn restrictions, where the "from" and "to" segments are the same. This approach has been chosen with route planning in mind.

AND Roads file -> mapped to OSM Ways

Please note! AND knows only segments which connect 2 nodes. Segments can also have intermediates (shape points), that define the shape of the road. The AND segments get tagged to define the type of road they use. OSM however knows Segments which connect two NODE and Ways that combines. OSM does not tag the OSM segments.

When mapping AND data to OSM, each AND Segments should be represented by one or more OSM Segments plus an OSM Way. However OSM does not tag the Segment, but the Way.
In a next step OSM Ways that are directly connected to each other and that carry exactly the identical set of attributes and point to the same direction could become merged to a single way. This process could be made manually or automatically.

Update: AND's shape files do actually contain shapes made up of multiple segments. These shapes are (mostly) converted one-to-one to OSM ways. These ways are however split at unfortunate positions such as landuse-boundaries. In several cases this means that for example house number information is duplicated, there may be multiple shapes with the same road name and house number range (see RD_OTHER below).

Administrative division boundaries

The level of the administrative division can vary from country to country, but it is called the province boundary layer in all cases, and is the most detailed level of administrative division supplied for each country.

Administrative divisions format

Associated with the province boundary layer, there are four comma-separated "*.lst" files:

*_p.lst (Province)

*_r.lst (Region)

*_s.lst (State)

*_c.lst (Country)

Administrative divisions in the data

The number of hierarchical divisions that occur is country-specific.
All countries receive the lowest or most detailed administrative division, i.e., the "Province".

The term "Province" is used here and refers to the most detailed level of administrative division represented by AND within a country. Due to the large variation in use of this term between countries, it does not always indicate actual provinces as described within a country in its administrative hierarchy. The same is true for the terms "Region" and "State".

Currently, a maximum of three administrative levels (below country level) exists in AND's Global Road Data. For the purpose of this document the most detailed level will be described as the "Province", the level above this as the "Region" and the one above this as the "State" division.

Administrative Division Hierarchy in AND Data

The provision of province, region, state and country information in the AND data varies between and within datasets as the following table illustrates:

These are corresponding with OSM Areas. Does OSM have own boundary data to be used instead?

This can be used to match the boundaries to their corresponding entry in the <dataset>_p.lst file.

Example

The <dataset>_r.lst file and <dataset>_s.lst file are not directly linked with the graphical data. Instead they provide extra information on the region or state in which each province resides.

The associated region and state for each province is identified in a "region code" and "state code" field in the <dataset>_p.lst file. The process by which region or state information can be retrieved and linked to the graphical data is described in the next section.

Linking and mapping all administrative data

The country or <dataset>_c.lst file can be linked to all other *.lst files as follows:

Example of administrative division mapping

The following example shows how these links can be used to map all administrative information to the province boundary layer.

In Switzerland, there are 2 hierarchical administrative divisions (below Country) – province and region. There is the AND province boundary data, a <dataset>_p.lst file, a <dataset>_r.lst file and a <dataset>_c.lst file.

Each province in the AND province boundary data has a six-digit code. This can be used to link information from the <dataset>_p.lst file. Once this record has been identified, further information in the "region code" and "state code" fields can be used to link the <dataset>_r.lst file and <dataset>_s.lst file to the map.

Alias format file

The purpose of the alias file is to provide alternative names for named nodes addressable on the administrative level, e.g., cities.