This is a guest post by one of our Map Analyst team interns, Manuela.
While editing the map I stumbled upon clusters of orphan nodes. Basically, orphan nodes have no tags and are not part of a way. One example here:
Some online tools report these as bugs/issues (e.g. osmose). You should be careful, though. These may have been created with a reason. Before proceeding to deletion, ask yourself:
Were these nodes orphan from the very beginning?
Is there just one orphan node in a changeset or are there many?
Are they arranged in a special way/shape?
If so, they may be GPS traces that could be used for mapping. And still, even nodes from GPS traces should be deleted, there is no reason to keep orphan nodes in the map AFTER you extracted all the needed information from them.
You’ll probably find yourself in one of the following situations:
You’ve found a newbie that creates orphan nodes by mistake
The nodes are correct but the user forgot to add the tags
A Redaction bot deleted ways without deleting the corresponding nodes (read more here)
Contact the creator or the used who made the last change via a changeset comment or private message (in a friendly way, of course)
Add relevant tags if that’s the case
Delete the nodes or leave a fixme tag for other users that may know the area better than you
How to find orphan nodes
Osmose will report orphan nodes clusters as issues:
In JOSM, orphan nodes (even isolated ones) can be easily found using the Search tool, with the following queries:
type:node tags:0 -child
type:node untagged -child
The -child tells JOSM to select only those nodes that are not part of a way.
As if that wasn’t enough already, I’ve created a map paint style that highlights orphan nodes and dims other elements. This will help you analyze the distribution of the orphan nodes without needing to select them and will help you take the decision to delete or no.
If you want to use this map paint style, you can find the script and a step by step guide on the GitHub page:
Have fun spotting orphan nodes! But remember to delete them only if you are sure they have no reason to be on the map. If you have any improvement suggestions for this map paint style, feel free to comment below or fork the project.
The best part of using everyday OSM technologies and relying on OSM to make sure that you get “there” on time is that you can directly influence the quality of the experience.
Regardless which OSM technology you’ll be using, to provide you the best experience possible, the routing software has to know as much information as possible about the roads between you and your destination: one-way streets, turn restrictions, speed limits, road closures and much more.
For example, the turn restrictions contribute significantly to the total travel time, and to the correctness of the route altogether, thus, by ignoring them in the traffic network model, essential characteristics of the network might be missed, leading to substandard and unreasonable paths.
Dealing with turn restrictions in OSM
To help us navigate the complexities of properly translating real map scenarios to the ways and points schema of OSM we will rely on JOSM with the turn restrictions plugin installed.
Turn restrictions in OSM are handled by creating a relation
A relation is one of the core data elements that consists of one or more tags and also and ordered list of one or more nodes, ways and/or relations as members which is used to define logical or geographic relationships between other elements. (source)
There is a mandatory requirement when creating a turn restriction relation: it has to consist of minimum three members and must have assigned two tags. (see below example)
A ‘no_’ type relation can also be represented in map data as an ‘only_’ type relation. The prohibited turn restriction relation is preferred by some routing engines instead of an allowed turn restriction relation.
Members of a turn restriction relation are ways and nodes
One simple case can be a turn restriction relation that consists of three members – two ways and one node. The two ways would represent the beginning (‘from’ role) and end (‘to’ role) of the turn restriction. The node would represent the continuity of travel between two ways and has a ‘via’role.
Another case is where a turn restriction relation can consist of three or more ways. Two ways from this type of relation would represent the beginning and end of the turn restriction and at least one way would represent the continuity of travel between the aforementioned ways (‘via’ role).
Workflow for adding turn restrictions
The traditional way
Using the embedded relation editor available in JOSM. A slight disadvantage of this method is that you spend a bit more time to manually construct the relation. Click on the image below for how-to video.
The user-friendly way
Using the turn restrictions plugin, that automatically recognizes the type of relation and roles for each member. Click on the image below for how-to video.
Using the aforementioned tools, we have reviewed 2,000 miles of field trip footage and added nearly 2,500 turn restrictions in the LA/Orange county area, where 85% of the turn restrictions that were added to the map are no_u_turns, followed by 11% of no_left_turns, the rest being covered by the other categories.
Hopefully we’ve managed to illustrate how easy is to map turn restrictions in OSM. Now, it’s your turn!
The INEGI boundaries import project is focused on importing the data of the national, state, municipal and sub-municipal level divisions present in the MGN published by the INEGI in a community monitored process.
One of the current problems in OSM regarding Mexico’s data is the incompleteness of the administrative boundaries for municipalities. Municipalities are the second-level administrative division in Mexico, the first being the state. There are 2456 municipalities, including the ones in Mexico City which are also a second-level division just with a different name – delegations.
The main goal of this process is to enhance the current OSM administrative division coverage of Mexico with open data made available by the government at the end of 2014.
The following steps describe the entire workflow we followed to import the boundary data.
Step 0 – Reprojection of INEGI dataset
Before any other step, the data released by INEGI has to be reprojected to WGS84 (EPSG:4326), from ITRF92, using QGIS, and saved as .shp file. An important thing to mention is that no simplification of the boundary geometries is considered whatsoever for this or any of the subsequent steps since the geometries are official government data.
Step 1 – Conversion to OSM data
Download the state boundary of interest relation from OSM and save it as an .osm file. In QGIS, using Vector > Research Tools > Select by Location, select the INEGI municipalities boundaries that are within the area of interest, in this case Quintana Roo state, and export the selection as .shp file.
The exported features will be polygons. In order to process them, they must be converted to lines in QGIS using the Polygons to Lines option, available in Vector > Geometry tools. Visually, the output will look the same as when the municipalities were polygons.
Using ogr2osm the .shp file containing the boundaries as lines is converted into an .osm file.
Before moving forward, the resulting .osm file has to be modified a bit. Using Notepad++, open the file and search and replace <nd ref=’ with <nd ref=’- and <node id=’ with <node id=’-, so the file will be with negative id.
The negative id is important because JOSM will know that this is new data, not yet added to the map.
Next, the .osm file can be converted to an .osm.pbf file using osmosis.
Step 2 – Processing
We load the .osm.pbf file from the previous step into an internal tool, called Mexico Split. The tool is designed to eliminate duplicate/overlapping ways by detaching them from their parent polygons and replacing them with a single common way of the two involved polygons.
Besides this main purpose, the tool also splits any resulting ways longer than 2000 segments in shorter ways, groups the ways in relationships according to the borders they define and adds some predefined tags to these ways and relations.
We took a backup of the current OSM data previous to the import of the regions that are going to be impacted, using Overpass API. Also, tag related metrics have been recorded – source, population, admin_center, admin_label, wikipedia etc. in order to have an overview of the newly added information.
Step 4 – Delete existing data from OSM and upload fresh data
In some cases the states already have some information regarding municipality boundaries (admin_level=6). These will be deleted, but before deletion we take a look at all the features and relations, to have a very good image of what we should put back in map data after the import.
Next, we upload the municipalities on a state by state basis.
Step 5 – Clean/verify the newly added data
This is a very important step because we verify the data that we’ve uploaded to make sure that there are no errors and manually re-link the admin_level=6 relations to the admin_level=4 boundaries, where required. Any other manual corrections are done at this step.
To ease the process of importing the municipality boundaries, we use the Mexico Import Map paint style for JOSM. It highlights the last node of every way, making it simple to see the length of every way.
The square node also has a certain degree of transparency, so we can see if there is a node under the node. To be able to work in a systematic way, it allows to quickly see duplicated nodes and see the difference between the admin_level=4 and admin_level=6.