Mapper since:
November 16, 2013



I’m from Luxembourg and i map essentially natural and historical elements in nature such as former industrial zones, archaeological sites, folkloric objects… My main motivations for mapping are exploration, mountain biking/hiking/trail running, share interesting places and that we don’t get lost in the middle of nowhere. This is the main reason why i started mapping in OSM, the map was wrong/needed more precision. See the last heading for my mapping and statistics details.

Feel free to contact me, i am opened to any discussion. If you have recommendations or corrections to suggest, do not hesitate to tell me.




● Reality can be represented in OSM thanks to geometrical elements and described with coding tags “key=value” (example: a polygon area with the tag “building=house”) which will precisely identify what an element is embodying. There are 4 types of geometrical elements :

  • Nodes are points
  • Ways are lines with a direction sometimes meaningful, they can loop on themselves if necessary.
  • Polygons/Areas are looped ways with a direction sometimes meaningful.
  • Relations are a modular approach of several elements linked together to represent a common feature with its own tags. These are setup differently and the procedure to create one depends of the editor you use. Examples: a tourist hiking route gathering several ways and its points of interest - small areas related inside bigger areas (MultiPolygons / MP). There are different kinds of relations defined by the key “type= * “

● Keys have a definition which define either: a family of features, its value being the specific type of that feature (building=house, building=apartments, etc), others will rather be a characteristic and a typical value (height=10, surface=grass). See OSM’s Wiki to find keys, tags and their definitions.

● Some tags are completely machine readable such as highway=residential. If you misspell it or change its name, it won’t be understood by systemic services, (ex. the rendering of a map). Others, only the key is machine readable like “description=write whatever to describe”, “note=…” or “address=…”. Therefore, do not create a new tag for a feature out of your initiative if you haven’t checked in the OSM’s Wiki if there is one already! Duplications complicate the use of OSM’s data. In order to make data meaningful and useful in OSM it should be harmonized broadly data wise and community wise. It is preferable by far to enter the official process for the creation of a new tag.


Before any edit you need to check/compare with a reliable imagery source that the background layer has no offset relative to real position. You can try to find a node with the tag “man_made=survey_point”, these nodes should never be displaced, you rather move the layer’s offset until you see its feature visible on the photos aligned to the node. Again: never displace such node unless you absolutely know its needs to be corrected and where to place it! Example here. In Luxembourg they are rather rare. Hopefully “ Mapper’s Delight Lidar Hillshade” has zéro tilting and aerial photos are very reliable and consistent through the years. Beware, the images from Mapbox, Maxar, Esri, Bing are bad references, there is an offset, are low resolution and are quite deformed, they need to be corrected multiple times in an editing session. Another factor, aerial photos with predominant tilting angle, which makes the higher features (roads on/and big steep hills/cliffs/mountains/buildings/antennas…) get deformed. To verify if there is a tilt, check the closest tall and vertical features (buildings, firs, antenna…), if you can see its walls or top misaligned with ground, it means the photos of that area are tilted. So you will need to either find another background source or correct the imagery’s offset in the background settings, but only for the current small region as tilting may change. Providers should really be precise on this matter, it’s not an option as so many people rely on these images without proper knowledge.

Precise position of elements is crucial for information! Hence why we made sure there is no offset with other factors on the previous point outside the obvious hand plotting. Why:

  • For orientation purposes when comparing position.
  • On ways & their route planning, position and shape suggest facts. A sinuous or zigzagging trail is longer than a straight line, it can also suggest that the way is on a steep section, there may be obstacles, etc…
  • Often maps are over-layed with DEM data or elevation contour, a few meters off and you may see a big drop in elevation.
  • For statistics calculation of how much % specific areas are being used in a region
  • In the future, we may require AI to correlate data between OSM and photos, DEM, etc…

Using one of the tags for the 1st time, check OSM’s Wiki and respect the feature you want to represent! It has a consensus adopted by the OSM community and explains how to define elements. Trustful pages have a “status=adopted” or “status=de facto”, sometimes different btw languages and the taginfo statistics shows that it’s widely used, over several thousands is a good start. Some are widely used but without status, like “natural=wood”, others rarely used because of their specific kind. By the way, i noticed also duplicated features with different tagging scheme, you need to dig OSM’s Wiki a bit. If you are not thorough, the data will be false, counterfeit the map and even mislead users and third party services which rely on OSM’s data consensus to provide their services. Example… For an accident in nature, often rescues use tracks with an all-terrain vehicle to reach the person, confusing paths and tracks is noxious. Imagine, if one day the map is used to rescue you.


● 3rd party services which provide the planning of route directions add already the highway’s default access properties. No need to add obsolete access properties which may mislead via the map tiles. Example: adding tag access=no (general access for any means of mobility) and foot=yes on a highway=footway is unnecessary since by default this type of highway is an element made for pedestrians in first place, this tag combination will grey out the way as inaccessible on the rendered map tiles and mislead users who will think it’s not accessible at all.

● Access=no, is also used when the element exists but have a stronger emphasis on its inaccessibility by its default means of mobility or for anyone whether access=private is accessible though only for eligible users, so access=no would also be inaccessible by private owners. Examples: think of a building in ruins or a way having collapsed rocks over a certain portion. Access=permissive is not officially a public element but the private owner allows access until further notice and/or on certain conditions.

● About editor apps : if you are experienced and make many complex edits, use JOSM. If you are beginner and make small new contributions of areas or ways, use iD. Creating big/many or editing elements in iD is tedious though, i heavily recommend JOSM along plugins such as “Improve way accuracy” & “Merge contour” instead (more info in the plugin’s page). Potlatch is outdated, do not use it.

● Creating new tags : if you suggest a new tag in OSM’s Wiki and propose a vote, before make sure that it doesn’t duplicate by definition with an existing tag. Example: “barrier = block” on nodes are large objects blocking passage for certain users. A user suggested “barrier=log” but it’s totally a duplicate.



● Micro-mapping and other superficial data should be avoided. 2020 April, once again OSM servers are overloaded. I’ve been warning for years that we should : - avoid creating unnecessary nodes on straight lines, if you encounter such, there are tools in the editor JOSM which allow a degree of simplification - attach different areas together (share perimeter’s way+nodes) according reality, otherwise there are extra nodes for the same perimeter, it also complicates editing/updating. - avoid exaggerated precision like creating area perimeters around each tree for forests which creates superfluous nodes or separating/detailing a street with several different elements/tags for just 1 or 2 meters only (OSM is limited to zoom=19, this will be barely visible) which would be then needed to be if any route needs) - not create elements which do not exist or exist yet, they are just proposed as project (tag proposed=*), some will never actually and it’s forbidden according OSM consensus

● People not using tags (key=value) properly according reality and what has been approved by consensus in OSM’s wiki. See “Recommendations” above why.

● Too many people contributing without precision up to a point you must wonder if some areas are worth trusting, even with simple polygons. My guess is that they don’t want to disconnect/reconnect all the nodes which in iD and Potlach is very tedious.

● Automations and other importations without post human verification. Consequences: area intersections, awkward plotting (UE SOeS CORINE Land Cover is totally useless), large areas having a huge offset, buildings having multiple tiny polygons whereas it’s a single building, this adds loads of futile data and is tedious to edit, outdated data…

● Duplicated tags: OSM’Wiki is a reference but it has its flaws too. Some people do not verify if a feature has already its tags registered in a consensus and propose a new tag scheme. Worse, some do not even verify and generalize a certain tag just by copying a random tag by someone. Example: - foot=designated (or bicyle) is the original tag which defines the use of a certain highway made in purpose for that mobility, always legally decided by the government whereas you can also find in OSM foot=official (or bicycle) in Germany.



● 8 shaped areas and MP, in other words several areas part of the same MP but touching themselves only at 1 node (hence the “8 shape” name i gave) some of the areas will sometimes not render, depending of some factors (size, tagging…?)

● area and line elements inside highway areas will not render, normal for highway lines but barriers etc should definitely be rendered, you can still make sure to render areas such as buildings by making the highway area as MP and adding an inner relation. My guess for this bug is that these highway areas follow the code structure of the highway lines, so they have also the highest priority of rendering over all other elements.



Areas on map

Global statistics

All users Luxembourg statistics, usually I’m one of the main contributors

Areas I mapped extensively with other users :

  • Terres Rouges (Redlands) ins South of Lu (Lu / Fr side)
  • Grengewald (Lu)
  • Petite Suisse (Lu)
  • Mamerdaal (Lu)
  • Forêt d’Anlier (Be)

Areas i mapped nearly alone :

  • Micheville former industrial zone (Fr)
  • Bois de Butte (Fr)

Areas i plan developing/detailing :

  • Bois de Gaume, Forêt d’Anlier (Be) & other Southern Forests/Woods
  • North of Luxembourg
  • North of Trier (De), meantime contributors have already done a lot work

Cheers! :)