Maplint
- About
- Maplint may have been the first quality assurance tool developed for OpenStreetMap back in January 2007.
- Impact on OpenStreetMap
- The tool helped contributors to spot errors or misleading tagging.
- Reason for being historic
- For a while Maplint was available as a layer on the homepage, rendered and updated as part of the tiles@home infrastructure which is now decommissioned. You could still run Maplint in a standalone Osmarender configuration, but nowadays various other quality assurance tools are popular. Probably the most similar is Keep Right, which flags up many different types of errors on a map.
- Captured time
- about 2010, with minor changes (links and spelling) afterwards
lint
Lint is everywhere. It accumulates under the bed in your apartment and in the tiny corner of the pocket in your trousers. And every so often you have to go and get rid of it.
The same happens with the OpenStreetMap data: Lint accumulates in some not-so-well-lit corners. This can be ways tagged with deprecated tags or segments which connect node A to node A, misspelled tags or a motorway without a ref tag. There are lots of ways OSM data can be wrong or incomplete.
The Maplint software has a list of some of the problems you can have in OSM data and it has code to check for these problems and generate error reports and warnings. The goal here is to help you in finding problems. It doesn't fix those problems for you, it just finds them. Some problems can be fixed automatically, and somebody can write programs to do that based on Maplint reports. Other problems need a human to fix them. So the Maplint project just reports what it sees and leaves the rest to you. This is only the first but necessary step to help improve data quality in OpenStreetMap.
Maplint is named after the "lint" program of old that every C programmer knows (or should know). It is very picky about the source code of your program and points out all the little problems that lurk in there. Maplint is trying to do the same thing for OSM data.
Maplint tiles@home layer - www.informationfreeway.org
You can see maplint in action at www.informationfreeway.org where it is available as a layer on the slippy map. This is probably the easiest way to see a maplint report for your area. This is possible because maplint has been integrated as a new layer generated by the Tiles@Home distributed rendering project. See Tiles@home/Layers.
Note: Speed of updates will depend on the how quickly Tiles@Home is re-rendering these tiles, but typically you might have to wait several days to see a newly-rendered maplint report after you have made changes. To instantly render your own maplint report, follow the instructions below.
Color guide (as used on www.informationfreeway.org)
- For points
- red - nodes on the same spot
- yellow - unknown tags
- orange - untagged unconnected node
- For ways
- thin orange - residental way without name
- thin red - ways with unordered segments
- thin yellow - unknown tags
- orange - segment without way
- red - tagged segment
Problem severity
Maplint classifies problems in one of three severity levels: Errors, Warnings, and Notices:
An error is something that is definitely wrong. It doesn't make sense to have a segment with zero length going from node A to node A. So that would be reported as an error. We want to check for every little thing like this, even if the programmers told us that it could never happen. Because programmers also make mistakes, so these errors can creep into the database.
A warning is issued when something is probably an error. You should not blindly fix it, but check first, because it might be ok after all. For instance a segment without a way on top could just mean that nobody got around to putting the way there. It is not an error, but something that has to be fixed eventually.
Notices are reported for things which look unconventional and might be or might not be a problem. Unusual tags for instance could mean that there was a typo, or it could be perfectly ok. It is certainly not an error, but you might still want to know about it.
Rendering your own maplint report
First check out the code from subversion at applications/utils/maplint.
Download an OSM file which you want to check and put it into the data subdirectory. Let's say you named it "London.osm".
Run "bin/maplint London" (the maplint program will automatically look into the data subdir and for a file with ending ".osm").
This will create several files in the data directory, all starting with "London" or whatever file name you choose:
| London.osm | Your original OSM file |
| London-maplint.osm | OSM file with test reports included. See Maplint/XML Format for the format. |
| London-maplint-report.txt | A text report of all test results |
| London-maplint-stat.txt | A text file with statistics about found problems |
| London-maplint-with-tags.osm | Another .osm files where the maplint xml reports have been replaced by pseudo tags of the form <tag k="maplint:error" v="..."/> for use by programs which know about tags but don't know about the maplint XML format. |
| London-maplint.svg | If you have Osmarender4 installed (and the OSMARENDER environment variable set to its directory) this SVG file will automatically be generated. See below. |
| London-maplint-waypoints.gpx | A .gpx file containing result POIs/waypoints for loading into GPS units. Has some support for Garmin-specific stuff, but support for waypoints corresponding to Ways is currently limited and incomplete: you may need to filter or decorate the -maplint-waypoints.gpx file for it to be of any use in some units. |
Note that you currently need xsltproc and the make utility to run all this. But that's easy to fix...
Osmarender
You can use Osmarender4 (or newer) to render the Maplint results into a SVG file. This will show errors, warnings, and notices in red, orange, and yellow, respectively. Nodes will get a fat dot, segments filled lines, and ways show up as an outline. The test ID is printed next to the node or along the segment or way. Normal roads, railway lines and rivers are also rendered, but most details are not shown. See the image above for an example of the rendering.
Note that you must use Osmarender4 (or newer) for this. There is a special maplint.xml rules file in the rules directory. Osmarender4 is in the subversion at [1].
Maplint and API 0.5
Maplint is updated to be used on files with API v0.5.
The code for checking relations will not interfere with 0.4 files. It is simply ignored in that case. Rules which check segments have been removed.