Talk:Good practice/Archive 1

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)

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)