- 1 Corrections based on less accurate data
- 2 Map what is on the ground
- 3 Uploading of GPS traces
- 4 "Don't map your local legislation, if not bound to objects in reality"
- 5 Appropriate number of nodes on curves
- 6 temporary events and temporary features clarification
- 7 Exception to the Keep the history good practice
- 8 Suggestion: Don't translate tags to your language
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.
- 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)
- See Also: https://help.openstreetmap.org/questions/65464/two-stones-arrived-naturally-vs-arrived-by-truck-tag-differently Jidanni (talk) 16:52, 21 August 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.)
- 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)
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
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
- 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.
- 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.
- 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.
- 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)
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)