Madrid Addresses Import

From OpenStreetMap Wiki
Jump to navigation Jump to search

See https://lists.openstreetmap.org/pipermail/talk-es/2014-June/012453.html (es)



Work in progress for future import

Goals

The goal is to import 165366 of the 204326 addresses from the Madrid city council (Ayuntamiento de Madrid) database. There are some hundreds of addresses already in OSM, most of them poorly tagged, that would be merged as part of the import, substituting them by the new ones, and transfering any useful tags from the old ones to the new ones.

Schedule

  1. Preparation, discussion - due to start the 25th of December of 2016.
  2. Import - expected to start any time after the community has solved any issues, doubts or concerns about this import.

Import Data

Data description

The original dataset updated in December 2016 is in csv format. It includes a total of 203,514 addresses. 13,686 of them correspond to _reserved_ address numbers that may be used in the future, but are currently placed in park spaces or empty plots. These ones won't be imported.

The dataset is in csv format. For its process has been converted to Sqlite format using the instructions in https://github.com/davefx/osm-callejero-importer. You can download the data from here.

Background

ODbL Compliance verified: YES

The license can be consulted here (in Spanish). It requires attribution of the source, so all nodes and the changeset will include source=Ayuntamiento de Madrid. The Madrid City Council (Ayuntamiento de Madrid) is already on the contributors list.

After sending the report with the problems and errors found during the drinking water import, including a section about the license, got a response from the "Subdirección General de Transparencia del Ayuntamiento de Madrid" (the data owner), and they confirmed me that we comply with their attribution clause using their data in OSM if we clearly specify the source and the source:date, the way it was done on the Madrid_Drinking_Water_Import. And they do like the work we are doing :) Kresp0 (talk) 13:25, 16 October 2016 (UTC)

Compatibility with the ODbL was already discussed in the imports and talk-es mailing lists.

Cumplimiento de la cláusula de atribución de los datos abiertos del Ayto. de Madrid en OSM.pdf

Import Type

The import will be done manually, with the data divided in streets and postal code, so it can be assigned to different volunteers.

Data Preparation

Data Reduction & Simplification

As mentioned before, the data file we have chosen is in csv format. Some typos have been corrected manually in a Spreadsheet, producing a modified csv file that has been imported into a Sqlite database using a manual process described in https://github.com/davefx/osm-callejero-importer.

Then, the data has been converted into .osm format using the get-all-addresses.php script in that repository.

Tagging Plans

Here are the original fields, their meaning and how they will be converted to the resulting csv/OSM file:

Tagging Conversion
Original Fields Meaning OSM tag Comments
COD_VIA
VIA_CLASE
VIA_PAR
VIA_NOMBRE
VIA_NOMBRE_ACENTOS
CLASE_APP
NUMERO
CALIFICADOR
TIPO_NDP
COD_NDP
DISTRITO
BARRIO
COD_POSTAL
UTMX_ED Not used
UTMY_ED
UTMX_ETRS
UTMY_ETRS
LATITUD
LONGITUD
ANGULO_ROTULACION

To all the nodes, we will add the following tag:

The addr:housenumber=* tag will be as follows:

addr:housenumber=NUMERO CALIFICADOR

Changeset Tags

We will use the following changeset tags:

Data Transformation

Data is in csv format. After converting the data to UTF-8 and converting latitude/longitude coordinates to correct decimal values using formulas in the spreadsheet, we have imported it into a sqlite database. This database has then been processed by a php script, generating. We open the resulting file with JOSM+Open Data plugin, save the osm file and divide it in chunks of 50 nodes for importing.

Data Import Workflow

Team Approach

Import will be undertaken by experienced OSM volunteers, following a strict workflow. Each volunteer will choose a file with data from a street in a postal code and will import them to OSM, while merging them with the old ones they may encounter.

References

The import has been discussed in the Talk-Es list and in the Imports list.

Workflow

As most (if not all) of the volunteers will be Spanish speaking, they can follow this detailed workflow in Spanish language, with screenshots.

The workflow will be as follows:

  • 0. Before we do anything, we strongly recommend to install the ToDo List JOSM plugin (if we don't have it installed in our JOSM yet).
  • 1. Create, if we don't have one yet, an import specific user account, like username_import (you will need a different email account from the account you used for your regular OSM account). Change the OSM username to that specific account in the JOSM preferences.
  • 2. Download one of the files with a subset of nodes that hasn't been imported yet, and write your username and mark that subset as Work in progress in the table of this wiki. Open that file in JOSM and download the OSM data for that area. If both data are in two different layers, merge both layers into one.
  • 3. Now we set the filters address:street="<Name-of-the-street>", address:postal_code="<postal-code>" and source="Ayuntamiento de Madrid" to add the new nodes to the ToDo List using the ToDo List JOSM plugin. After doing that, in order to see all address numbers, we drop the all the active filters.
  • 4 We go through all the nodes, one by one, using the ToDo list. For each node we first check its correctness, correcting any typos we may still encounter, like lack of accents. If the node is clearly wrong or suspicious of being wrong, it won't be imported in the first place, and it will be added to the comments in the table of this import wiki, so it can be checked afterwards by other mappers to take a decision about it. The mapper will delete that node to make sure it won't be imported.
  • 5. After checking the correctness of the node, we will proceed with the conflation of this new node with the old nodes, or old address information in any building, in case it previously exists. To do so, we delete the tags that aren't needed or wrong, we change or correct those tags that need so and finally we select both the new and old nodes and we merge them with the Merge tool (M), so the old node moves to the new node location, keeping the id and history of the old node, and getting the new node tags added. Keep in mind that the conflation has to be done following the Conflation rules.
  • 6. Once we have finished with all the 50 nodes, we proceed to upload the new data to OSM with our specific import OSM account, using the Import Changeset Tags already explained.
  • 7. Now we go to the wiki and we mark the Status for the subset as Done.

Reverse plan

In case of any trouble, JOSM reverter will be used.

Conflation

There are hundreds of pharmacies already in the OSM database for the Madrid area. Some of them are independent of the 1,701 new ones, and therefore we will leave them in the map unchanged. But many others are a duplicate of one of the new nodes. In this last case we will use the JOSM Merge tool (M), with which we will keep the node id of the old one (and therefore its history), transfer any useful data from the old one (like opening_hours=* for example) and change its location to the new one. As the M tool merges all data, before doing so we will manually delete any tag that isn't needed or it's wrong in the old node, like addr:country=* or name=Farmacia for example.

Tags of the old pharmacies

Here we show what to do with the tags of the old pharmacy nodes:

Tags of the OSM pharmacies to be transfered to the imported ones
Tag What we should do Comments
addr:city=* We ignore it Duplicated
addr:country=* We ignore it Not needed
addr:housename=* We ignore it. There are only 2, and are both wrong
addr:housenumber=* Should be the same as the new imported node
addr:postcode=* Should be the same as the new imported node
addr:state=* We ignore it Not needed
addr:street=* Should be the same as the new imported node
alt_name=* There is only one with this tag. See name=* further down
amenity=pharmacy We obviously ignore this
contact:phone=* Should be the same as the new imported node
date_off=* We ignore it This tag is deprecated, and it's actually for use with the access=* tag
date_on=* We ignore it This tag is deprecated, and it's actually for use with the access=* tag
description=* Only one node has this tag. It says it's open 24 hours, so transfer that info adding the following tag to the new one: opening_hours=24/7
dispensing=* We'll keep only the ones with dispensing=yes or dispensing=no, and ignore the rest.
email=* We'll change the tag key to contact:email=* and transfer their values. There are only 2 nodes with this tag
is_in:city=* We ignore it Deprecated and duplicated
level=* We will copy it to the new one
name=* Some has name=Farmacia, so we ignore those. Some other have a name that duplicates the one of the new counterpart. In this case we also ignore it. In case the value is a possible alternative name, we create a new alt_name=* in the imported node and we transfer that value there. There are more than 150 old pharmacies with this tag, so you will find them often during this conflation process
old_name=* We will copy it to the new one Only one node has this tag
opening_hours=* We will copy it to the new one. Please, correct any errors There are only 12 nodes with this tag
operator=* We ignore it There is only one node with this tag, and it's wrong. It's operator=Lda. Consolacion Pinto Oca, so that could go, probably, to alt_name=*
phone=* Should be the same as the contact:phone=* in the new imported node
shop=* We ignore it It doesn't make any sense. Only one old node has this tag
source:date=* We ignore it
source:name=* You can append its value to the value in the source=* tag of the new node.
source=* You can append its value to the value in the source=* tag of the new node.
time_off=* We ignore it Doesn't make any sense in this context
time_on=* We ignore it Doesn't make any sense in this context
website=* We can check the url, and substitute the contact:website=* of the new node by that value Only 2 old nodes have this tag
wheelchair:description=* We will transfer it to the new one
wheelchair=* We will surely transfer it to the new one

As explained before, if in doubt don't do anything with the node and report the problem in the comments field in the table of the Import Progress wiki.