Talk:Good practice

From OpenStreetMap Wiki
Jump to: navigation, 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)

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)

Possible misspelling

Perhaps fixme=postion estimated at the bottom of the page should read as fixme=posItion estimated??? User:Vovkav 16:40, 30 January 2011

Thanks. Feel free to be bold and fix mistakes like that when you see them on the wiki. I also changed "senseful"->"makes sense" in that sentence.
In fact I've changed it to just reference Key:fixme. I'm not sure if 'position estimated' is the best value. fixme=resurvey is a popular one meaning effectively the same thing (fixme value stats) What do people think? Should we recommend a value on this page?
-- Harry Wood 18:19, 30 January 2011 (UTC)

Don't map for the renderer??

That heading is an oxymoron which should be corrected, along with the advice "don't care what the renderers make out of it". It is common to admonish osm contributors against “tagging for the renderer”. The admonition is sometimes elaborated along the lines: “A mis-tag to correct an error of representation by one renderer will likely cause errors by another renderer.” That is sage advice for all contributors.

The admonition is sometimes elaborated (as in the "don't care" advice mentioned above) along the lines: “Just provide an accurate record for each feature: it is the job of renderers, not mappers, to decide how to show the feature.” That is incorrect.

A map does not exist until it is rendered – on paper, on screen, or in the imagination. Anyone with no concern for the rendering of a feature that they have added or edited is not a mapper. Data-entry is not mapping, unless it is accompanied by care to avoid errors on the map.

Responsible mappers will check at least the default rendering (Mapnik in case of osm) to ensure that their entries have not introduced errors. In the event of introduced errors, they will explore how to adjust the data to avoid the error – not mis-tagging but certainly tagging (sometimes creatively) for the renderer!

Mapnik (like all rendering software) has to apply ‘rules’ about the priority of layers and the locations of labels when features overlap in space and when labels might overlap on the map. The rules can give unexpectedly misleading effects. If they are harmful effects, a responsible mapper will think about how to avoid them by a change within the valid scope of tagging. There may be a longer-term solution by the authors of rendering software. But if Mapnik gets it dangerously wrong today so may other renderers. The responsible mapper will seek to avoid harm to users of the map … now.

For example, there can be strange effects from concentric zones with the same centroid. If there is a central zone that is normally rendered (e.g. a national park tagged area=yes) within an outer zone that is not rendered (e.g. a protected_area, which is currently rendered as a label on an invisible boundary; and a label at the centroid of an invisible zone if tagged area=yes) there are a whole range of rendering outcomes in Mapnik, depending on how the outer zone is tagged within valid scope. The central zone may disappear, or it may appear but with the wrong label, depending how the outer zone is tagged or set up as a multipolygon. There is an example, tagged to avoid harm, at [1]. If the effect of adding or editing data is harmful (e.g. by obscuring a hazard or implying an inappropriate usage), the mapper will try different ways to tag (for the renderer!) or maybe as a last resort delete a lower priority feature that is leading to potentially dangerous rendering. The process can be clumsy, because you must wait while the renderer absorbs the new data, and clear any caches of the rendered map, to see if a particular change solves the problem.

So the first principle for osm mappers is ‘Do no harm’ and in that context the first three rules might be:

1. Ensure that your entries and edits do not infringe copyright (e.g. do not trace from a copyrighted map that has not issued a licence to osm).

2. Ensure the accuracy of your entries and edits (and show the source, giving preference to verifiable accurate sources).

3. Check rendering of your entries and edits in at least the default osm map, and correct any of your entries that give potentially harmful effects. (If necessary to avoid harm, change tagging, without mis-tagging, for the renderer).

--Moreton 02:30, 20 September 2011 (BST)-

Have you seen we have a separate page dedicated to Tagging for the renderer which goes into more detail? Why don't you move this comment over to Talk:Tagging for the renderer? -- Harry Wood 03:59, 20 September 2011 (BST)
To me it is this page in the section indicated that is incorrect, not the one on "Tagging for the renderer" --Moreton 09:29, 20 September 2011 (BST)
OK so you don't disagree with the advice. You just disagree with the way it has been summarised on this page? Remember this page is a quickfire summary, spelling things out in simple terms, and often attempting to correct common mistakes made by new mappers. For more nuanced discussion of borderline cases around what the guideline actually means ...see the subpage. (And discuss there. By the way, I'm not sure I agree with you, even in your "strange effects from concentric zones" example. Seriously... if the renderer is rendering it wrong, don't "fix" the data)
We could rewrite that sentence / heading a bit it's true. Also this page isn't particularly a complete or ordered list of rules. Maybe we should try to change it into priority order. And yes I'm thinking a simple heading "Don't copy!", mentioning the license could be a good one near the top
-- Harry Wood 13:35, 20 September 2011 (BST)
Harry, I think that you and the other osm moderators do a great job. Having provided a slightly different perspective as a new and small-scale contributor I am more than happy that the front page should reflect your experience and ongoing commitment. Regards --Moreton 00:01, 24 September 2011 (BST)

There is no policy of "only one tag per concept"

I would like to suggest the following addition:

There is no policy of "only one tag per concept"

Each tag should correspond to one, and only one, concept, but one concept is often represented by more than one approach to tagging.

Contributors are encouraged to be consistent in the way they use established tags, but OSM data is contributed by a large number of users, who are also encouraged to recognise subtle differences between features. There are unavoidable variations in terminology and priorities across the world. Over time tagging practice is evolving as the database content becomes increasingly sophisticated, new applications are discovered, and contributors develop their understanding of how others identify different features and how the data is used. Contributors will always differ in their level of experience, their perceptions, priorities and in the level of detail that they are prepared to document. Data users have different views of which features are relevant to their application, and hence view the data from different perspectives.

The practical effect of this is that data users who wish to extract a particular set of features from the data will normally need to identify a number of variants in way those features have been tagged. They will often need to put processes in place to ensure that, after it has been extracted from OSM, the data they are using is consistent from the particular perspective of their application.

Experience has shown that attempts within the OSM database to improve data consistency from one particular perspective often result in the loss of valuable information when data is viewed from another perspective. So while there are processes in place to maintain a degree of consistency in tagging practice, these will normally only be successful where widespread consultation has resulted in a high level of consensus across different perspectives of how data may be used.

--Peter Reed 08:42, 30 August 2012 (BST)

Ugh! Such a statement risks being used by ego-tripping mappers to make life more difficult for everyone.
My motivation to map for OSM is to build a mass-market product (the database), not a niche one. Even people who take advantage of the opportunity to make special-purpose maps often want ‘straight information as well.
I’m not clear what the experience you’re talking about is that would justify this section as well as the “don’t tag for the renderer” section. Andrew 13:19, 30 August 2012 (BST)
There are different views around how best to achieve a good balance between consistency of tagging, and recording subtle differences between different features. I'm not sure that this is a debate worth having with anyone who opens their response with "Ugh!" and uses terms like "ego-tripping mappers" in relation to people who contribute content. However, underneath the emotion, I think you are trying to raise a couple of issues that we probably agree on. One is that it is key to the whole project that the data is widely usable. My conclusion from that starting point is that it needs to be capable of supporting a variety of different perspectives - not one. I fear that over-standardisation will detract from widespread use of the data in the long-term. We may differ on that. The second is that there needs to be a balance. There are clearly some areas where standardisation is vital, and others where it is impractical. We probably agree on that, but not where the balance should lie. I don't see much discussion of factors that need to be considered - which is a shame, but a bit off topic. What you don't mention is the issue I was trying to address - how to give data users and contributors some guidance on what to expect, now, in terms of good practice on the degree of consistency in tagging. In my mind this is quite different from "don't add incorrect tags to achieve the rendering you want". Perhaps you would like to rephrase your objections. --Peter Reed 11:51, 31 August 2012 (BST)
Maybe the following changes will help move discussion forward:
"While contributors are encouraged to comply with established tagging schemes wherever possible it is normal for different tagging schemes to coexist for the same type of feature. This is not viewed as a flaw in the database design, but a healthy sign of an active and evolving community." Data users who wish to extract a particular set of features from the data will therefore need to identify a number of variants in way those features have been tagged. They will often need to put processes in place to ensure that, after it has been extracted from OSM, the data they are using is consistent from the particular perspective of their application.
Experience has shown that premature attempts to improve data consistency from one particular perspective often result in the loss of valuable information when data is viewed from another perspective. So while there are processes in place to maintain a degree of consistency in tagging practice, these will normally only be successful where widespread consultation has resulted in a high level of consensus across different perspectives of how data may be used.
--Peter Reed 07:53, 1 September 2012 (BST)

"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)

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)

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)