Talk:Good practice

From OpenStreetMap Wiki
Jump to navigation Jump to search
Talk:Good practice - Other languages

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)

Boundaries

I'm having an argument with somebody who says, "Well, you can't see boundaries, so they are not (included in) 'on the ground' ." (But you map them anyway. So therefore he has the right to map other things that are also not 'on the ground' , as he pleases.) So could someone please beef-up the article. Thanks. Jidanni (talk) 19:17, 12 October 2019 (UTC)

Somewhat amorphous areas

Mention what qualifications are needed (legislation? size? etc.) before somewhat amorphous areas like Ground for falling rocket stages should be mappable. Jidanni (talk) 17:16, 5 January 2020 (UTC)

Even if Wikipedia says this is the exact center of ...

Mention that no, one should not put anything at e.g., at the exact center of Siberia etc., even if Wikipedia says yes this is the exact spot. (Unless there is actually "something" there.) Jidanni (talk) 17:06, 5 January 2020 (UTC)

Well, Wikipedia isn't a usable source because it has an incompatible license. Any data sourced from Wikipedia needs to be redacted from the database.--Alester (talk) 17:32, 7 January 2020 (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)

I made an attempt at rewording the paragraph. I also split it from the verifiability section. Verifiability is of course relevant but seems a separate topic. Legislation may in some cases come with verifiability issues (though certainly not always - often the law is perfectly verifiable), but this is better addressed in the Ground truth article (ground truth versus official truth). --JeroenvanderGun (talk) 19:40, 5 April 2022 (UTC)

thanks for this edit, this is definitely an improvement in my opinion!
Been thinking about something along the same lines for a while. Just made a further edit to make a sharper distinction between rules that apply by default (that can be overruled by traffic signs) and rules that apply by definition (that can not be overruled by traffic signs). I think most people would agree that rules that apply by definition should not be tagged on individual ways. I think its better not to use defaults as an example of what not to tag: defaults can exist on many different levels (such as the legal default, a zonal default -such as from an access sign or a technical default assumed by a data user -that can very well be different from either the legal or zonal default). Such examples might lead to different interpretations and unintentional misunderstandings. Cheers! --Multimodaal (talk) 21:32, 5 April 2022 (UTC)

temporary events and temporary features clarification

My proposed change applies to https://wiki.openstreetmap.org/w/index.php?title=Good_practice&oldid=1594141#Don.27t_map_temporary_events_and_temporary_features

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 https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/lounger&diff=1610355&oldid=1610280

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 osm.org), 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. http://osm.mapki.com/history/ . 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 - https://lists.openstreetmap.org/pipermail/tagging/2019-June/046327.html
> 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 hotmail.com
and July - https://lists.openstreetmap.org/pipermail/tagging/2019-July/046346.html
> "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 gmail.com>
"while this is ok as a joke, I would also support such a move" -- Martin Koppenhoefer dieterdreist at gmail.com
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: https://lists.openstreetmap.org/pipermail/tagging/2019-June/046327.html 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)

@Jeisenbe: I think that it depends on quality of other data within editing area. If everything is mapped from low quality satellite images and there is no better source - fixme is pointless. In case of adding new objects mapped with a poor accuracy in well mapped area with local mappers - either do not this at all or at least add also note or fixme to make easier to resurvey the most dubious parts Mateusz Konieczny (talk) 10:32, 6 January 2020 (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 //wiki.openstreetmap.org/wiki/Key:... or //wiki.openstreetmap.org/wiki/Tag:...), 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)

It is fine to create tag page (some describe tags as a complete mistake to be never used), it is different from listing them on other pages Mateusz Konieczny (talk) 14:12, 28 December 2021 (UTC)

Don't map temporary events and temporary features

Say how to deal with month long annual (or other regular or even irregular) events, every year held in the same spot, attracting millions of visitors?

Google Maps has no problem leaving such event sites marked on the map all year.

Which makes sense, as people will be planning trips there months in advance, and the media will still be writing stories about it months afterwards.

However the other 11 months out of the year, the area might just be a field planted with hay.

No we shouldn't need to change the map every six months.

Also what if the hay field is owned by the county: the County Fairgrounds?

Certainly that could be tagged... but then what about the exact same situation, except it is say owned by some different entity?

See also https://www.openstreetmap.org/user/jgon6/diary/44497

Jidanni (talk) 01:56, 21 November 2019 (UTC)

Is your local fairgrounds used as a hay meadow during part of the year? Isn't there some permanetly installed features, like a parking lot, grandstand, roofs etc? In California all of our county fairgrounds and the State fairgrounds are permanent features, which exhibition buildings, roofed arenas and a stadium for rodeos and horse shows, parking lots, toilets, etc. All of these features can be mapped, but I would not map a the "Orange County Fair" as a feature - rather it's the "Orange County Fairgrounds" which should be labeled. These seem to be called "showgrounds" in British and Australian English, so that would be the best term to use. We had a discussion on the tagging mailing list about how to label them, as perhaps a amenity=festival_grounds, amenity=showground, *=events_centre or just as landuse=commercial, but it seems there was no proposal for a particular tag. Perhaps you would be interested in making a proposal? --Jeisenbe (talk) 02:34, 21 November 2019 (UTC)
Well it just goes back to being Seed Improvement and Propagation Station, Nursery #2 for the other 11 months. Jidanni (talk) 03:28, 21 November 2019 (UTC)
I think tagging https://www.openstreetmap.org/way/747470467 as amenity=festival_grounds is fine, but landuse=recreation_ground should be removed - that's a type of open park with pitches for various sports, mainly found in Britain and former British colonies. I would also remove tourism=attraction because all festival_grounds are tourism attractions and that tag doesn't add any useful or verifiable information. --Jeisenbe (talk) 03:50, 21 November 2019 (UTC)
OK. Anyway I hijacked <tag k="operational_status" v="yearly"/> so people would have a hint that any future hours tag I put in would not be all year round... Jidanni (talk) 04:17, 21 November 2019 (UTC)
amenity=festival_grounds is not fine. It isn't rendered yet. Jidanni (talk) 10:53, 22 December 2019 (UTC)
"It isn't rendered yet" is not a good reason for deciding whatever tag is OK Mateusz Konieczny (talk) 01:23, 23 December 2019 (UTC)
Talk:Tagging_for_the_renderer#Make_items_show_up_now_during_rescue_operations. Jidanni (talk) 08:53, 23 December 2019 (UTC)
Showgrounds in Australia are mostly permanent features so don't fit here. They are usually tagged as landuse=recreation_ground as they are used for sports, particularly between annual 'shows'. The additional tag of recreation_ground=showground is also used. Don't apply your local conditions to the world. Warin61 (talk) 04:26, 19 February 2020 (UTC)

Supplementing and clarifying the On The Ground "rule"

In the spirit of addressing the reality that we must somewhat relax the On The Ground "rule" into something which might be better characterized as a "good guideline," I propose the following text (from this talk-thread, inspired by the one or two before it) be included in our section on the Page regarding On-The-Ground:

Independent verifiability is a crucial component of the Good Practice of mapping what is on the ground, as sometimes there is no evidence on the ground that a map feature should exist in OSM or be tagged anything in particular. For example, some boundary=* (multi)polygons are invisible "on the ground," but OSM maps these, and should. Also, there are no or few signs which say "Pacific Ocean" or "Rocky Mountains," yet OSM maps these natural=* features, tagging with an agreed-correct name=*. Similarly, type=route relations (road, bicycle, hiking, equestrian...) enter OSM from ODbL-compatible government-published maps, yet remain unsigned (or poorly signed) in the real world. From what authority must we determine source "verifiability" of these "invisible" or "unsigned" map features? As long as these are independently verifiable (on a government map, by legal / statutory decree, from data authoritatively published on a website, by unanimous agreement among locals and a wider public or at least with very wide consensus), the map feature with its verifiable tags may be entered into OSM following Good Practice. Independent verifiability means any member of the public, freely, anytime and with no special privileges can "consult the source" and verify the data.

At the talk page linked above, Yurik has "seconded" this being entered here for Discussion so that it potentially may be included on the Page. Thank you in advance for good discussion here. Stevea (talk) 20:23, 8 February 2020 (UTC)

  • Symbol support vote.svg Support I think this is very important for the rules to reflect reality rather than exist in the void. Thanks for working on this. I am ok if the above text goes through a few revisions to better convey the main idea. --Yurik (talk) 00:10, 9 February 2020 (UTC)
  • Re: "Similarly, type=route relations (road, bicycle, hiking, equestrian...) enter OSM from ODbL-compatible government-published maps, yet remain unsigned (or poorly signed) in the real world." - Do not add this section. Most types of route relation should only be mapped if they are actually signed. Some which are fixed-route public services can be mapped based on actually riding the route, which is also a real-world method of verification which does not depend on consulting an external map or document. I do not think the "good practice" page should mention mapping routes which are not verifiable in the real world, which only exist on paper. While some mappers like to add such things (like "proposed" bicycle routes or hiking routes which only exist in guidebooks and have no signs), this is not a good practice. --Jeisenbe (talk) 03:22, 9 February 2020 (UTC)
Re: "on a government map, by legal / statutory decree, from data authoritatively published on a website" - these examples are not "good practice" sources for openstreetmap. While many mappers import data from such sources, there is no "value added" in the case that mappers are unable to confirm if the government or "authoritative" data is accurate or inaccurate. Since the data in Openstreetmap can be changed at any time, and often by mistakes caused by new mappers, the authoritative database or source will always be better for database users to consult directly, unless openstreetmap can improve the originally imported data by checking it against reality. Remember, this is the "good practice" page, not the "how things really are done" page: we want to focuse on the "Gold Standard", best practices. --Jeisenbe (talk) 03:25, 9 February 2020 (UTC)
I disagree with Jeisenbe, especially in the case of bicycle routes (especially national, especially in the USA, in other words, USBRs). I spoke on this at SOTM-US in Washington, DC in 2014 and had two DWG members (I'll tell you their names if you ask me privately) similarly talk to me about this. (It was more about "proposed" vs. "actual," though the "unsigned" vs. "signed" semantic is quite similar). But they didn't have the insight some of us did (that the USBRS was in a new stage of evolution well-matched to how we enter data) and the whole of OSM-US has now; in fact, the OSM-US Secretary forwarded a letter of permission from the responsible national organization who granted OSM explicit permission to do enter these early data — no small feat, really. The net result (after six months, in a "careful, we tread with trepidation here" way and after six years, about now) is that "real, but unsigned or poorly signed routes do get entered" (and are not disputed, in fact they are celebrated). This may have to do with their relative importance as national routes, this may have to do with the patchy way that national route signage (for bicycles in the USA) ought to be paid for by states, yet their DOTs frequently struggle with budgeting signage money (in some state's case) over a thousand kilometers — that's a lot of signs, digging and crew! However, I consider deleting this section at Jeisenbe's request, as I understand his perspective (call it "strict") that this may not belong as part of "Good Practice" as we clarify OTG. It DOES belong, if we are documenting OTG (or lack thereof) "for completeness sake." So, perhaps Jeisenbe would like to re-write these with a discouragement, but keeping the important note that "this does happen."
To be clear, these routes DO exist in the real world (as asphalt, paint and infrastructure you can ride on right now), they simply have not "gotten around to being signed," though they also exist on paper, websites with official documents and meet the guideline that John Random Public can freely download and verify them.
Again, I disagree on two points Jeisenbe makes about non-on-the-ground verifiable, but verifiable data. These DO add value, as a boundary, mountain range, ocean, bay, inland freshwater lake, bike route... which has no signage but exists and is named and would be an embarrasement for a map to omit. Just because "The Alps" don't have a sign somewhere (and where, exactly?!) reading "Die Alpen / Les Alpes / Le Alpi / The Alps" doesn't mean we shouldn't map Alps or name Alps: we do and we should.
What if there is no sign, but "everybody knows what that's called" or "we have a place to check on that?" In that case, let's be descriptive that OSM does enter those, and should. You want to be prescriptive? I think we can and should be, especially with your description of "Gold Standard." So, again, let's see two paragraphs, one that is strict and prescriptive, defining "Gold Standard." Then, let's drop down the prescriptive-ness and include a few sentences about boundaries, natural features and routes which DO get included in the map, but which are precisely what we are descriptively calling attention to by way of contrast (for completeness sake regarding OTG, an important thing to include when more-comprehensively describing it). I think we can do that properly and that might be a good way. The trick is making a clean break between "Gold" and "sometimes, for reasons, these happen, too" (boundaries, mountain ranges...) so it is well understood by all wiki consumers that we make both prescriptive and descriptive entries here. Stevea (talk) 03:51, 9 February 2020 (UTC)
As an aside, a few years ago USA admin_level=* values were thoroughly hashed out in talk-us and United_States_admin_level and Talk:United_States_admin_level. One of our Board Members and wiki administrators (I'll call him a friend, Minh_Nguyen) and I agreed that that wiki was quite prescriptive and he wanted one that was more descriptive. He wrote United_States/Boundaries, I tuned it up to our mutual agreement, we both tap-tap at it and we agree that both wikis are appropriate for their respective audiences. As I said in a Talk page, "there are often many books in the library on any given subject." I say this to offer perspective that both a de- and pre- approach can be correct in our wiki, especially as we point out those distinctions. Stevea (talk) 04:32, 9 February 2020 (UTC)
I strongly support Jeisenbe. Typical unsigned hiking/cycling route without traces on the ground has no place in OSM. There are rare exception where it kind of makes sense but it is an unusual exception Mateusz Konieczny (talk) 23:50, 11 February 2020 (UTC)
  • I strongly oppose giving "Pacific Ocean" as something that is a good example of mapping in OSM. place=ocean is highly subjective and questionable at best. Note that there are various methods of diving Earth's water into oceans, with differences not limited to exact area but even count of them. Mateusz Konieczny (talk) 23:49, 11 February 2020 (UTC)
Agreed. Oceans are poorly defined, even worse than continents, which are culturally-dependent. I have also tried mapping mountain ranges myself, and it is quite difficult to find an appropriate way to represent such features in Openstreetmap so that the geometry makes sense but is also verifiable. These are not good examples of the sort of features that are ideal for Openstreetmap. --Jeisenbe (talk) 05:38, 13 February 2020 (UTC)

Do correct errors, be bold

There is some truth to this rule, but how bold you should be should depend on the general maturity of the map and the kind of error fix or edit they want to perform. In areas with many active mappers, unless something is very clear and likely to not be questioned (e.g. a typo in a tag, an update because the real situation has changed, etc.), people should rather be respectful than bold, and contact the authors or local community before making a systematic change to lots of objects, or removing things. People are very different, and while the timid hesitating people should be encouraged to be bold, there is also another archetype which should rather be slowed down and encouraged to collaborate and discuss Dieterdreist (talk) 17:37, 27 December 2021 (UTC)

I think "Do correct errors, be bold" is a good encouragement to new mappers and for the sake of user retention and attracting new users this statement should stay. It wouldn't hurt to include a suggestion to contact other active local mappers who have worked on an object you intend to edit, although it could be a separate good practice and we can keep this one as it is now. --501ghost (talk) 18:27, 27 December 2021 (UTC)
I have just made a edit in an attempt to reflect both viewpoints - (1) be bold when it comes to adding missing or outdated data (2) be respectful to the work of other mappers when data is not factually incorrect. I think both shoud be encouraged. You will probably not hear/see the people the need encouragement on (1). But there is no shortage of people that behave somewhat too bold and go about changing or deleting the correct data contributed by other mappers which often goes unnoticed 9and gets harder to revert because of conflicts arising over time- and whcih gives negative energy to those involved. Please feel free to improve the wording, cheers Multimodaal (talk) 13:05, 28 December 2021 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Good_practice&oldid=2307735"