Talk:Good practice

From OpenStreetMap Wiki
Jump to navigation Jump to search

Corrections based on less accurate data

Is that the right place to explain that you should not move existing ways/points if you're not sure that your source is more accurate than the existing data. I'm thinking about people adjusting GPS sourced ways/nodes to fit the Yahoo! Imagery which is considered as less accurate (at least in countryside) ? Pieren 11:37, 28 February 2008 (UTC)

Yeah that could be added onto this page, as a general rule I guess.
I'd like to see a section called 'Accuracy' on the Yahoo! Aerial Imagery page, presenting some examples of inaccuracies. Screenshots of images being misaligned and offset from reality, as measure by multiple indepedant GPS traces. Presumably this varies from place to place, so where are the worst places for accuracy in the Yahoo imagery? We need more information on the wiki about this. That will also help us to establish when it is just people getting inaccurate GPS traces, and trying to blame the imagery (which I'm sure must be the case at least some of the time) If we build up a better idea of the scale of the problem, somebody might decide that it's worth developing some tools for collaborating on imagery correction offsets or something.
-- Harry Wood 12:28, 28 February 2008 (UTC)
That's an old discussion. We now have a page Yahoo! Aerial Imagery/Accuracy. Hurray!
That page should now be moved for re-purposing in relating to bing perhaps. There's lots of talk about the accuracy of bing: Talk:Bing#Poor alignment. There's also a True Offset Process idea to tackle the probelms.
-- Harry Wood 14:42, 2 May 2011 (BST)

Map what is on the ground

While that is true for current rendering, recording historic information is equally important. ONE of the reasons I want to be able to play with OSM data is for tie in with genealogical data, so additional historic tags will be important. Lsces 20:21, 28 February 2008 (UTC)

There are also tags to hold what was on the ground like old_name=. But also here applies the on the ground-rule when there existed different names for one feature at the same time. Since the existence of nations there are also different views about the location of borders, but generally there's only one nation that exercises (military) power in the area in question. When you've got an idea for a catchy phrase, feel free to add it. -- Fröstel 15:08, 6 March 2008 (UTC)

Erm well I have to correct you here, but I guess this is why we need to spell out good practice guidelines like this.

It's widely agreed (and actually dictated by common sense really, when you think about it terms of verifiability) that we don't put things into OpenStreetMap if they don't exist... and yes that includes things which used to exist, and now don't. Recording historic information may be important to you. I would certainly question whether it is "equally important" (Two buildings on the map next to eachother. One exists. One doesn't. "equally important" to have in our geo-data? I don't think so. But maybe that's a matter of personal interests). But in any case, we don't do it. OpenStreetMap doesn't record information about things which no longer exist, in the central OSM geo-database. That's what this page says, and that's what community consensus settled upon a long time ago.

We do have various tags for historic/ruined/abandoned/vacant things which *do* still exist on the ground. There's also a longstanding discussion about the path of old railways for some reason but even then, I believe the majority of the community agree that they do not go into the database if there is zero evidence on the ground.

-- Harry Wood (talk) 12:34, 26 July 2013 (UTC)

Initially, as I read it when it was written, "what's on the ground" was not devised to to prevent former features or attributes from being recorded - just that the tags depicting currently present features should have the tags, e.g. name=*, which correspond to what the local people (or government) calls it. From all that was said, it was meant as a resolution to end naming disputes (in osm, that is), in areas with disputed borders or relatively recently changed governance. A building no longer present is not building=*, but e.g. was:building=* + end_date=* - that's not a "building that doesn't exist", but "the former placement of a removed building". If such elements get in the way of editing current data, sure, they might be "freely deletable", but then it's at least not impossible to extract the historic data (from the full history dump). It's often a fine line between abandoned-but-visible and "gone", anyway (save for the "let's tear down the whole suburb to build a new one") ? Also, with the same sources (which should be freely available, if they're used initially), anybody can compare the relative locations of other features nearby, and come to the same or different conclusions - verify. It's not like people would draw past stuff out of thin air. Alv (talk) 16:21, 15 October 2013 (UTC)

There are two issues being dealt with here. Map what's on the ground - I totally agree with but OSM doesn't. What I see on the ground is an area of tarmac. OSM shows this AREA as a LINE and has it coloured red because it's a'primary route' as randomly decided. What's on the ground is a width, quite possibly split into lanes of width. This data is usually missing from OSM but we have less important data about the highway. OSM, to me, shouldn't have pretty-coloured roads at all, it should just have the details and it should leave 'preferred' routes down to the map reader (person or routing software) based on the information available on the ground.

As for historical data, I think it should be included and tagged with start date and end date. In fact, each tag value should include from and to dates. Name="Clock Tower" 1870-2012 Name="Elisabeth Tower" 2012-... Renderers and map users should be able to choose the date range so they can see what the map was like at that time. There is an 'open history map' division but to incorporate the data in OSM is a much better way to deal with historical data.

-- User:Pmailkeey003 22:02, 21 April 2015

Bit of an old discussion, and we're talking about a variety of cross-purposes here I think. Anyway, I'll note a couple of nice updates since then: The colour of roads changed to be less random on the standard style. Roads are now various shades of orange. Still not tar-mac coloured though. Cartography is still cartography. And there is now an Open Historical Map allowing for the 1870-2012 aged buildings use-case you describe (or trying to allow for that at least. The project currently needs work, but is gaining some interest and momentum) -- Harry Wood (talk) 00:29, 20 December 2015 (UTC)
"recording historic information is equally important" - I strongly disagree. historic information that is not covered by "what is on the ground" is a complicated mess that is mostly completely unverifiable and should not be mapped Mateusz Konieczny (talk) 18:01, 25 May 2018 (UTC)
I strongly disagree with you when there are strong references for them, and even if new entities may have appeared, the former one are still in use and coexit for contractual or legal reason. Various legal entities continue to exist (even if their role is decreased and not accepted for creating new contracts or laws), and it frequently takes before all legal cases are handled. Many statistics are also not applied on new entities, and there's a legal requirement to manage the coexistence and continuity, even if this requires sharing some reponsabilities between successors and an agreement to share the costs and benefits between the successors.
This exception for keeping historical data exist notably for administrative boundaries. The successors may not have exactly the same responsabilities as their predecessors, and some responisabilities may be transfered to another entity possibly located elsewhere. These entities exist aslso for fiscal and cadastral reasons (need to keep a track for proof of ownership: these tracks are kept often for about a couple of centuries, until all right holders are dead and at least 70 years have passed and all legal procedure to oppose a past decision are extinct, and all judiciary affairs about them are also officially solved, closed or classified for too long absence of new elements to continue the procedures). Just consider the case of people birth places; this is part of their identity and proof of nationality or citizenship, or may be used to claim some rights or legal exceptions that were kept after the change: adminsitrative units survive for their whole life and until their successors have validated the succession, and no other claim can be made (in many countries this is at least 70 years, plus time of war, or time of national service for the defunct person). Consider the case of international borders: they are enacted by legal acts kept in secure custody by other countries (or by an UN agency), and they are surviving centuries and multiple political regimes. — Verdy_p (talk) 18:16, 25 May 2018 (UTC)

Figure added to On the ground

@Krauss - I have problems to understand the figure you have just added to the on-the-ground rule. In particular the arrows flowing back from the map to the world are insufficiently explained. It looks like inserted out of context, and not well fitting on this page? How does it help to understand the section it is in? Also, OSM as a database is not immediately a map. --Polarbear w (talk) 16:46, 2 February 2019 (UTC)

Thanks for the attempts to improve. Sure my edit is a mapping event. But what do the arrows mean that point back to the real world? --Polarbear w (talk) 22:54, 2 February 2019 (UTC)

Uploading of GPS traces

There is a section telling to average out GPS traces, and I think we could add a recommendation to upload the complete traces (not only simplified versions). Traces where only 10% of the points are left aren't to much help when editing and trying to adjust a way to several traces. Btw, this page should IMO be linked from some of the beginner guides. --Erik Lundin 01:26, 6 February 2009 (UTC)

"Don't map your local legislation, if not bound to objects in reality"

"Things such as local traffic rules should only be mapped through the objects which represent these rules on the ground, e.g. a traffic sign, road surface marking. Other rules that can not be seen in some way should not be mapped, as they are not universally verifiable."

So one is supposed to leave roads with default maxspeed, set by national legislation and not modified by maxspeed tags untagged? And remove already tagged ones? Either this rule is highly confusing or it is proposing something going against common, widespread and OK tagging practise. Therefore I propose to remove this section. Mateusz Konieczny (talk) 06:16, 28 October 2015 (UTC)

If I remember correctly, the intent of that sentence was mainly that mappers shouldn't, for example, tag every motorway with horse=no or every cycleway with motor_vehicle=no - unless there's a prohibiting traffic sign - because if they do and the rules change, we don't have any way of knowing if those tags are correct anymore, and we especially can't tell those from the sections where there is in fact a "no horses" traffic sign. It's however a vague scale from those examples to, for example, an implicit unsigned but not obeyed lower speed limit curve, set by limited visibility (i.e. you have to be able to stop on the visible road surface, but it depends on a) your vehicle and possibly b) the driver's eye level when the visibility obstruction isn't higher than a truck. (Maxspeed is a suboptimal example, since many are using in addition source:maxspeed=* when there's no explicit sign for that section.)
"mappers shouldn't, for example, tag every motorway with horse=no or every cycleway with motor_vehicle=no" I think that this can be stated as "avoid completely redundant info" Mateusz Konieczny (talk) 09:17, 20 May 2018 (UTC)
I tried to find a related discussion about it from the time it was added to Good Practice, on this wiki, and on talk or talk-de lists, but I couldn't, so there could have been some other ideas behind it; I thought the section was older than July 2011. Alv (talk) 07:51, 28 October 2015 (UTC)

Administrative limits are usually only established through regulation/laws and cannot be extracted from the ground (think imaginary lines to specific coordinates as is often the case in North America and Australia; even when the law references natural elements that can be seen and mapped, one will rarely find a sign establishing a boundary). Also, highway classification is often established by the local public administration. Maybe it is better to tell people to avoid wasting time adding certain tags when they'd usually be at their default value, with some exceptions - for example, it is still useful to map oneway=no in major ways (tertiaries, secondaries, etc.) when one has really verified that some way is in fact not oneway.--Fernando Trebien (talk) 19:02, 19 February 2016 (UTC)

I plan on removing this section as it still poorly explaining the intention and contrary to real mapping (maxspeed case) Mateusz Konieczny (talk) 12:13, 28 December 2017 (UTC)

I'm curious about this section. I just made small wording adjustment to clarify that we map maxspeed on the highway object, not the actual speed limit sign. But I do think that this section could be further improved. My guess is that it means we shouldn't map legal fictions which only exist on paper but do not have any force in reality: for example, 1) claims to control territory in Antarctica or large areas of open ocean which are not enforced, 2) Places the government thinks exist but which do not function; eg: A) a school or clinic in a developing country which is disused or abandoned; B) the capital city of the province is officially moved to a remote village, but all of the government offices remain in th old capital. 3) official names of places which are not used in reality - e.g. train station is legally renamed in honor of a certain political patron, but the sign isn't changed and no one uses the new name; the name only exists in the legislative archives. So basically all of these are issues with Verifiability and mapping what is on-the-ground reality vs aspirations, as with many Good practice sections. In contrast, default maxspeeds might be verifiable if there is a sign at the entrance to the municipality, province or country border which lists "80 kmh max unless otherwise signed", or even if local mappers have experienced getting speeding tickets from the police for exceeding 80 kmh on that road. The last example is quite hard for tourists or visitors to verify, but is probably common knowledge among locals. Similarly, marine borders might be somewhat verifiable if the government routinely seizes fishing boats which cross the invisible line without permission - just like the unfenced land border between Papua New Guinea and Indonesia can be mapped due to having real consequences, even if it's precise position is not verifiable everywhere --Jeisenbe (talk) 12:14, 1 July 2019 (UTC)

Appropriate number of nodes on curves

I have once asked at the forum what such a number would be. From the reply I got and how iD works nowadays, I think it would be reasonable to suggest 12-20 points per circle, or 3-5 points per quadrant, or around 20° at each node. What do you think? I've seen geometry with a lot less detail, which seems inadequate, and geometry with much more detail, which seems unnecessary.--Fernando Trebien (talk) 14:13, 25 March 2017 (UTC)

I would suggest 20-32 points per circle (i.e. about 15-20°). This allows correct positioning of concentric features. But you may need more depending on the size of objects. Actually the number of points should depend on distance: if this is a highway curve, that curve should still fit within the lanes and not exit it. So the highway width conditions the maximum length of segments and so you'll need more nodes, even if deviation angles go below 10 degrees. For example, in roundabouts, 24-36 nodes would be better to adjust correctly details (positioning the oneway accesss, the footway crossings, the giveway positions, possibly traffic lights and other signals. More will be needed if there are sections for bridges/tunnels or stacked highways in a junction, and you need to add barriers along the ways but still not block the footways or cycleways beside them. If you need to zoom in more to see these details, you'll easily see when more nodes are needed. But simple circular tank or communication tower, 16 to 20 nodes is generally enough as there's not much details to add around them. The default settings in iD when you use the "circle" tool is to have at least 19 nodes (about 19 degrees) and it is fine for most objects (needing a bit more only in roundabouts only for connecting the highways, if you do that, just reapply the "circle" tool to regularize the form with more evenly distruted nodes; on very large roundabouts you may want to add a few more to follow more precisely the internal dashed border line of the outermost lane and keep a good looking circle without too visible angles at the high zoom levels).
So all depends on the surrounding objects you want to detail. In all cases, the highways should not cross a lateral strem or ditch, and should not pass through a building (unless there's an explicit tunnel through it).
We cannot give precise figures but all is linked to the relative size of objects in all their dimensions, not just the linear drawing of highways that actually have a surface and are not just a single line: we should avoid collisions of different objects and keep drivers, cyclists and walking people on the right way without entering dangerous areas or areas impossible to cross. — Verdy_p (talk) 14:53, 25 March 2017 (UTC)
Surely object collision should be avoided (I'm not suggesting geometry should be simplified carelessly). For large objects I actually use the default rule of JOSM's simplify function, that is, as many nodes as necessary to maintain a maximum error of 3 metres from the actual feature's contour. Then, naturally, on large curved objects there would be many more nodes and that's ok. I'm mostly concerned about how much detail is desirable on small features. --Fernando Trebien (talk) 15:47, 12 January 2018 (UTC)
3 metres of error distance between the central curve and the actual path is generally good for most highways for motor vehicles (that have 2 lanes and are about 7 meters wide). For highways with higher number of lanes, it is still the good distance to allow mapping and rendering correctly the curves and possibly the additional lanes, without creating too many collisions with what is beside it (buildings, trees, barriers, water drains, street lights, extinguishers and water pumps, urban furniture...). When there's no sidewalk or on narrow highways and roads that have a single lane, the 3 metres may be improved by dividing it by 2 to reduce the error. For this reason, curves with very large radius will need more nodes. If you're in the desert (not many things significant around, including natural features that could be obstacles or holes, and the road is in fact a track, there's not a very precise way or multiple alternate tracks. So you just map an approximate in the rough central area where these tracks are passings. In cities, the lanes are normally very visible and countable and there are many other things aound to locate and being precise will allow positioning them correctly to the correct side (including tiny objets such as address nodes which shbould be on the correct side, or trees, trafic signals, street lights.) In cities, where lanes are precisely delimited, it's best to follow the central lines as precisely as possible to provide correct instructions to drivers, or allow correct estimation of actual driving speed and travel times or obstacle that you'll encounters (even if they "zigzag" because there are parking lots alternating on both sides: this is not a straight drive, you have to take these zigzag even if the whole street width is straight including the parking lots and footwalks).
So for me, in cities, the max error for curves is about 1 metre, but it's easy to have nearly decimetric precision (no need to go below that: 1 decimetre is almost the width of the painted lines and even the most precise imagery where you can see details that 10cm-wide with two or three pixels are not perfectly orthorectified to that precision due to approximations of the terrain model data used to take variable elevation into account; note also that terrain model data is often less precise than surface model data which is now quite accurate to measure the top of roofs and trees but cannot see really what is at their feets, and an accurate mesurement requires imageries taken from different angles). — Verdy_p (talk) 00:23, 13 January 2018 (UTC)

temporary events and temporary features clarification

My proposed change applies to

I propose to explicitly state that it is not excluding seasonal and regularly occurring features - for example spring present only in wet season, or marketplace active on each morning, or street vendor present with cart at given location every tuesday

This is response to

Mateusz Konieczny (talk) 09:13, 20 May 2018 (UTC)

Maybe it would be better to discuss this on the talk or tagging mailing list in order to reach more people?
Personally, I'm fine with the current guideline. As for the portable loungers: who can tell that every summer the same amount of loungers is put at the same place? Also, portable loungers can't be easily verified, whereas a spring or stream only carring water in wet season can, as there is always a stream bed or culvert. --SelfishSeahorse (talk) 14:16, 20 May 2018 (UTC)
If features or events are present regularly, and there's a stable source of information about when and where they occur or are planned, they are suitable for inclusion (along with tags like "opening_hours"): I don't seee why weekly streetmarkets would not be mapped but we would still tag offices, shops or public services that are open to the public only once a week, or bus stations that are serviced only some days or at specific hours, or only for some class of travelers (e.g. children only for bus schools).
What is important here is the stability of who manages these events or features, and that they provide adequate information (and frequently permanent no on the web or by visible displays restricting accesses or car parking specifically on these hours or days...)
Seasonal events are also convenient to map: they will be there for long period and will have smamm changes across years, and the basic equipment is also kept so they are easily reinstalled (or prohibition of construction are permanent, to keep the area open for these events or seasonal features). — Verdy_p (talk) 17:10, 25 May 2018 (UTC)
As well some "fords" may be placed on roads even if most of the time they are completely dry, but they exist because the risk of being flooded can occur at any time (e.g. after some heavy rains which will not be precisely announced). Knowing in advance that the risk may exist will avoid people going in that area if it starts raining and they can pass elsewhere to avoid a possible local trafic jam: the wet condition may be extremely temporary and rare, but the risk is still permanent.
For extreme events however (like the volcano in Hawaii, or after a major earthquake or cyclone) it makes sense to map the affected area, because this will have effect for long period of times (with variable damages on structures whose reparation will take unpredictable time and will require long planning efforts, multiple studies by experts, and lot of financial investments by collectivities or organizations over several years). This tagging will reveal the current state of the area, but will require additional surveys to follow the situation and fix what has been restored or definitely demolished or areas that will remain permanently banned or protected.
If you consider events like "Paris Plage" (Paris Beach), the places where they occur along the Seine River is now known and each year the streets along the river bank are closed on the same areas, and the kind of temporary equipement is also relatively stable (there's not much posible places where to put a sandbox, and banks or chairs and keep a usable way that pedestrians and emergency services can still use).
If you consider the case of festivals, many are occuring each year at the same place: this could be a large parking or grass field, closed and transformed for one or two weeks with the temporary installation of an outdoor scene. — Verdy_p (talk) 17:14, 25 May 2018 (UTC)
"Maybe it would be better to discuss this on the talk or tagging mailing list in order to reach more people?" I just started a thread on the talk mailing list Mateusz Konieczny (talk) 18:02, 25 May 2018 (UTC)

Exception to the Keep the history good practice

Hi. First time on a talk page here.

The exception to Keep the history rule is nodes that mark pedestrian crossings or semaphores. There's no reason to keep the history of those kinds of features.

I originally first thought of the crossing, but then it came to me that semaphores also apply, so we may have a pattern going on here. That could be just insignificant features to keep record, thought.

I think it's worth to add a note in regard of these kinds of things, but since I'm a newbie and it may require more discussion, I'm hesitating to do so. Dhiegov (talk) 20:51, 2 February 2019 (UTC)

Welcome Dhiegov. I think you misunderstand what we mean with history in this context. Each object in OSM has a version number. When you refine a road, the version number is increased, and e.g. it has more details or the tagging has changed. Keep the history means her that you should indeed refine the existing object, and not delete it and create a new one. Thus this is not different for pedestrian crossings. --Polarbear w (talk) 22:49, 2 February 2019 (UTC)
Oh, now that I read my suggestion, I forgot to mention that there's no reason to keep the history of those kinds of features (semaphores, pedestrian crossings, etc) if they are not there anymore and they only served to represent the now inexistent feature.
For example, imagine two ways crossing, the transit departament draws a ped. crossing on one side of the crossing, but months later, for whatever reason, they just erase it (or maybe it gets erased by time and deterioration). Now there's no reason to keep that node on the way since it was just representing a crossing that now does not exist anymore.
I'm sorry for wasting your time with such an error. Dhiegov (talk) 02:22, 3 February 2019 (UTC)
No worries, we are happy to explain. And you are right that nodes/ways for objects that do not exist in reality anymore, can eventually be deleted. It is however a good idea to mark e.g. a razed building with a lifecycle prefix (razed:building=*) for a while, to prevent somebody without local knowledge tracing it again from aerial photography that is older than the razing. The same could be the case for a zebra crossing that has been removed but is still visible in imagery. --Polarbear w (talk) 10:43, 3 February 2019 (UTC)
Thank you, that makes sense. Do you know if these lifecycle prefixes are recognized by the renderers (i.e. the map at, so that they don't appear on the map anymore (and mislead end-users in thinking they still exist), but still alert other mappers that they are gone? I think the most probable case is that they just are not matched to get the apropriate icon. For example, renderer x displays every closed way that has a tag "building=*" as a building, but, using your example, one tagged as "razed:building=*" does not match to "building=*", so don't gets displayed. It is still very dependant on the implementation, though, so we can't know for sure.
A solution could be to delete all of the now wrong tags (i.e. highway=crossing for what was a pedestrian crossing) and leave a note=* alerting the outdated imagery, since that's the purpose of note=* anyway. What do you think? Dhiegov (talk) 19:24, 3 February 2019 (UTC)
AFAIK objects with the lifecycle prefixes like razed:*=* are not rendered in OSM carto style. This is one intention of the prefix system. Only highway=construction is rendered, which is a lifecycle tag that was already being used before the prefixes were invented. Thus no worries about using a note. Using a prefix is just adding a few letters, thus it is much easier, and it is unambiguously in the correct place. Thus, the prefixes are the solution. If you know when something was razed/removed, adding end_date=2019-02-04 would add even more clarity. --Polarbear w (talk) 12:32, 4 February 2019 (UTC)
To any renderer which does not make an explicit effort to add support for them, keys with lifecycle prefixes are simply completely different, unknown keys, so they don't negatively impact the appearance of rendered maps. Nevertheless, I personally prefer note=* over lifecycle prefixes for communicating with other mappers. After all, note is unambiguously designed for internal communications, whereas lifecycle prefixes are designed to be evaluated by data consumers. (There are applications which want to show features under construction, or vacant shops, for example.) Thus, I consider mapping features with razed:* a slight violation of Good practice#Don't map historic events and historic features, unlike internal-only tags such as note=*. --Tordanik 17:55, 12 February 2019 (UTC)

Suggestion: Don't translate tags to your language

This is maybe obvious, but when you are dealing wiki non-technical and novice contributors, they might think that instead of data for programs to use, they are making notes to other people to look at, so they doesn't need to be following any practice.

In the other hand, non-technical (or even technical) users start on iD (that's what I suppose, since that's my background) so they only get to know that OSM data are simply text tags a bit later on. Anyway, I don't know. What do you think?

Another problem we might have is that this good practice only makes sense on translated version of this page, since the "your language" for English speakers are obviously English and the tags are already in English. --Dhiegov (talk) 17:25, 10 March 2019 (UTC)

Can you point to examples of novice users "only making notes"? I've been watching the activity in Denmark for many years now and seen a lot of new users at wildly varying levels of technical competency. The best advice I can give here is to watch your primary area of interest and try to guide those that might need it (comment on their changesets) as much as you can or simply correct errors where guiding isn't enough. Most non-technical contributors can't be expected to read this guide anyway.
Also the Good Practice is as important for english speakers as for everyone else. A lot of the advice can't be learned from just looking at tags. --Hjart (talk) 17:39, 13 March 2019 (UTC)
You're right. I suggested for precaution, though, as the heading containing this good practice would be a nice link to put right beside a translation of a tag, made to add more meaning for a tag to a non-english speaker. E.g. in a translated page:
> The source=* tag (from English, "source" in the translated page language, but [[Good practice#Don't translate tags to your language|don't translate tags to your language]]) can be used to [...]
--Dhiegov (talk) 13:13, 23 March 2019 (UTC)
I doubt that foreign language speakers can be reached with an advice Don't translate tags to your language placed in the English version. Maybe we should add this remark to all translations except for the English base version?--Tubes (talk) 23:10, 14 June 2019 (UTC)
I agree, of course, that it isn't good practice to translate tags to your language. But I'm not sure it's helpful to add such remarks to tag documentation. Do the mappers who misunderstand the purpose of tags usually read tag documentation pages on the wiki? --Tordanik 12:11, 15 June 2019 (UTC)
I think this proposal makes sense, I saw someone in Tunisia add a lot of French language values for English keys which should probably translated, such as sidewalk=n'existe pas, smoothness=bon, surface=enrobé (example here: v1 at bottom), but I didn’t have something written down to point them to. --Awiseman (talk) 21:32, 31 July 2019 (UTC
It would be better to mention that most tags use English keys and values at one of the pages that describe creating or finding new tags and using tags, for example: Any_tags_you_like#Syntactic_conventions_for_new_tags, Proposal process, Elements#Tag and Tags. There are already suggestions at several places to search Taginfo for existing tags to use, even at Any_tags_you_like. So I don't think this needs to be mentioned specifically on the "Good Practice" page. If you find a user that is tagging features with new tags when an existing, popular tag would work, just like to the wiki page of the common tag itself. --Jeisenbe (talk) 04:26, 1 August 2019 (UTC)
Thanks, those are good points. --Awiseman (talk) 00:10, 2 August 2019 (UTC)
It was now added to Any tags you like. Seems like good solution! :) --Tordanik 19:09, 2 August 2019 (UTC)

Slight redundancy

"Keep straight ways straight" starts with a remark on GPS accuracy, which is repeated just in the after next paragraph "Average out GPS-traces".

Currently I can't imagine an elegant phrasing to avoid this. Has anybody got an idea how to write this better?--Tubes (talk) 23:06, 14 June 2019 (UTC)

Section: "Check the history of important objects"

The section labeled "Check the history of important objects" was added recently. I'm not convinced that this is necessary or helpful. It's not so clear what an "important" object would mean, and why checking their history is necessary or helpful. The page is already quite long, so no new sections should be added without discussion and a clear need. --Jeisenbe (talk) 16:04, 29 June 2019 (UTC)

I was the one who added that and in my opinion (as an extremely experienced mapper) this is some very recommendable advice. I do it all the time myself and it has saved my ass many times. --Hjart (talk) 18:53, 29 June 2019 (UTC)
It isn't clear what you mean by "check the history" in this section. Are you referring to checking the history of the database element via the "View History" link on the website, or downloading the latest changeset comments?
It refers to the history discussed in the previous section. After spending ~20k hours with OSM, watching the activity in Denmark almost every day for 5+ years and guiding hundreds of less experienced contributors, I felt it was necessary to underline the importance of this and yes, I get why most less experienced mappers would not understand why it is important. But why keep the history if no one checks it out?
JOSM users would press Ctrl-H to bring up the JOSM history window (example). Other contributors would click "View History" (allthough fairly hard to read) or use tools like i.e. . If you're wondering why an object is tagged or placed in a certain way (which I often do), you would do this in an attempt to judge the trustworthiness of its current state.
Each of those tools shows slightly different information. It needs to be very clear what exact information new users are supposed to check. Is it the latest changeset comments, or changeset source tags? Is it required/recommended to check the user page of the person who last edited the object? This "Good Practice" page should offer clear, concise advice for new mappers, and there is already a section and a whole page about "Good changeset comments" above.
If new mappers are following the early rules about mapping what is "on the ground" and "verifiable", then I'm not convinced that the identity of the last editor is very important. It's more important to know if the data was based on survey or imagery or guesswork. The source tag might be useful, to clarify if old aerial imagery was used that might be outdated, but there is already a 2 sections that warn mappers not to map from outdated or misaligned aerial imagery: "Be sure to check that the existing OSM data you are about to change or delete is indeed older (check its history) than the imagery you are looking at." Isn't this sufficient?--Jeisenbe (talk) 05:26, 2 July 2019 (UTC)
Why should this be recommended for "important objects" but not for all objects? --Jeisenbe (talk) 22:50, 29 June 2019 (UTC)
Because checking the history of every single untagged node would just be way too much work for even the most dedicated mapper and generally quite unneccessary too. So you would generally do it only with objects which could be seen as fairly "important" in some way or to someone.
As mentioned on the mailing list (see below), the importance of a particular object is quite subjective. Rivers are important, but I'm happy to realign them without checking the prior changeset comments or identity of the last editor, if I have up-to-date aerial imagery or GPS traces from survey. If I see that the node for a city that I know well has been moved to the wrong spot or misnammed, I can fix this because I know it's incorrect. But on the other hand, minor things like small bridges or footpaths may appear to be in the wrong place on aerial imagery, if the imagery is older than the source of the latest edit.--Jeisenbe (talk) 05:26, 2 July 2019 (UTC)
This is being discussed on the Tagging mailing list as well:
June -
> What is an "important object?"
I find this "important" very subjective, it varies according to the contributor's interest.
A motorist could consider the bench as insignificant.
A no-smoker may consider cigarette bin as insignificant. -- marc marc marc_marc_irc at 
and July -
> "I've altered the "good practice" page to state that it should not be changed without consulting
> the wider community.  Joking." -- Paul Allen <pla16021 at>
"while this is ok as a joke, I would also support such a move" -- Martin Koppenhoefer dieterdreist at 
It appears that the community does not support adding this section without further discussion --Jeisenbe (talk) 11:59, 1 July 2019 (UTC)

"Don't map insignificant, perishable and mobile objects"

The section labeled "Don't map insignificant, perishable and mobile objects" was added fairly recently, and seems to mostly duplicate the information in the preceding section about "temporary features". I would like to delete this section. --Jeisenbe (talk) 16:12, 29 June 2019 (UTC)

See discussion on Tagging mailing list: and after. Specifically Martin Koppenhoefer wrote about my comment [this section] duplicates advice in the previous section, so I've removed it. "+1 I do not believe the significance of plants correlates generally with their size, and while I agree that things which are moving in an unpredictable way should not be mapped ... it does not imply that things which could be moved but actually don’t, or which regularly occur, should not be mapped". And next Paul Allen agreed with this.

Polarbear_w readded the section with this comment: "revert section removal by Jeisenbe: this advice became necessary after some kid nonsensically started mapping single blades of grass and loose stools."
I still believe this advice is given in the previous sections Good_practice#Verifiability and Good_practice#Don.27t_map_temporary_events_and_temporary_features - blades of grass are temporary, and the location of a chair or stool which is not attached is temporary. However, we do map outdoor seating areas and picnic tables which are always in the same location, and we can map street vendor stalls or carts which are removed every night but replaced each day, so I believe this advice is also not fully correct. I think there are already too many sections on this page, especially since there are now 5 sections about Verifiability, in addition to a whole page --Jeisenbe (talk) 00:25, 4 July 2019 (UTC)

"Keep the history"

This section "Keep the history" is now by far the longest on the page, about 3 times longer than the average. I would suggest creating a new page about this Good Practice, as has been done for Changeset Comments, Verifiability, etc - then the details about how to edit in Josm or other recommended techniques can be moved there. Thoughts Polarbear w? --Jeisenbe (talk) 12:09, 1 July 2019 (UTC)

I've created the page Keep_the_history and moved the later paragraphs about the JOSM plugin and how to move a node into a new area to this new page, along with the recommendations about changesets and checking history. This was discussed on the Talk mailing list. --Jeisenbe (talk) 03:10, 5 July 2019 (UTC)

Don't map historic events and historic features

As a consequence of data needing to be verifiable by local mappers when surveying places in person, it's generally agreed that historical events and features which no longer exist cannot be mapped. However, a section was added in 2013, which says railway=abandoned can be used to map dismantled or razed railways which no longer have any evidence of their existence on the ground. I do not believe this belongs in the Good practice guidelines.

While abandonded railways that still have tracks, ties or ballast can certainly be mapped, it is controversial and not a good practice to map railways that no longer exist on the ground. If there is an embankment or cutting or bridge, these features can be mapped, but a railway with no rails, ties, ballast or other railway-specific features is not be mapped as an abandoned railway based on historical documents or memories alone. --Jeisenbe (talk) 02:38, 4 July 2019 (UTC)

@Jeisenbe railway=razed is meant for dismantled or razed railways not visible anymore. Railway tagged as abandoned are still visible as scar in the landscape.--Faizal (talk) 15:33, 30 July 2019 (UTC)

Mark estimations with FIXME

Is this in fact a generally recommendable good practice? This recommendation can lead to large numbers of "fixme=*" tags in areas with cloudy or low-resolution aerial imagery (eg in the rain forests of Indonesia, where I usually map). Is it in fact recommended to map a roughtly estimated position of a river or road when it has not been surveyed with GPS and cannot be seen on aerial imagery, for example? --Jeisenbe (talk) 04:46, 4 July 2019 (UTC)

Please wait for input

@Jeisenbe If you receive no or nearly no comments on your thoughts here that's no reason to massively change the good practices by your personal taste.

Please wait a little longer or reach out to mailing list, Slack and the board.--N.plath (talk) 15:27, 30 July 2019 (UTC)

The recent changes were discussed on the mailing list in June and early July 2019. If you are not subscribed you can read the relevant archive at [[1]] and [[2]]. I might also suggest waiting for a response before reverting a large number of changes. Do you have any specific objections to any particular changes, or suggestions for improvements? --Jeisenbe (talk) 15:47, 30 July 2019 (UTC)
N.plath, do you have any concerns or comments about any of the specific changes that were reverted? I'm inclined to restore the changes, which offered for discussion at the Tagging list as mentioned above. --Jeisenbe (talk) 12:48, 2 August 2019 (UTC)

Using proposal pages to document new tags?

A little while back there was a section added to the part about documenting your custom tags, which says:

"Please do not use the map features section of the wiki for this (including all pages where the URL starts with // or //, as these are the community endorsed tagging recommendations reserved for well established tags with significant usage."

However, if you read the Talk page of the Proposal process page and past discussions on the Tagging list, it appears that many mappers believe that it is appropriate to document tags that are already in use by creating a regulaar wiki page. Certainly a proposal page is correct if you are inventing a new tag or suggesting a tag which isn't already used, which needs discussion. Perhaps we can clarify this? --Jeisenbe (talk) 01:01, 4 August 2019 (UTC)