In some cases the OSM Wiki offers more than one way to map a specific on the ground situation, without giving a clear preference to one specific mapping solution. An example for this would be that most POIs can be mapped as either polygons or points.

I believe there exists an (perhaps only informal) rule that says that in such cases the solution chosen by the mapper who first mapped such a feature shouldn't be changed, except when one adds significant further details and information. I think this is a logical way to prevent edit wars over minor details caused by differing personal preferences. For example, a mapper shouldn't change a shop mapped as a polygon back to a single point, just because they prefer the method of mapping shops as nodes. But in a slightly different situation, where a mapper provide new information about the extent of a parking area, they would be allowed to move the information from a amenity=parking node to the newly mapped way/relation.

Unfortunately, I don't seem to be able to find any place where this rule is written or expressed. I searched the OSM wiki, forum and mailing lists, but the only places where this is mentioned are either very vague or situation-dependent. Of course the mechanical edit guidelines and the "disputes" page somehow touch this topic as well, but only partially explain how to handle this in practice.

Two questions:

  • Is this representation actually the current consensus of the OSM community: “The first mapper has the right to choose whatever mapping method they prefer and it shouldn't be changed except if significant further information is added in the mapping process.”
  • Are there any places where this was already discussed in the past and/or documented?

asked 29 May '19, 11:59

tyr_asd's gravatar image

tyr_asd
1.2k51927
accept rate: 64%

edited 29 May '19, 14:16

This is not an answer to your question, but: I have often remapped restaurants/shops as nodes in cases where the original mapper added the amenity/shop tags directly to building footprints. My impression is that it's incorrect to add these tags directly to a building unless it's a single-purpose building. So if a building has residences or other shops (even vacant), using a node is better.

Another situation would be if the building itself has a name that is different from the POI name. There's no good way to tag that without using a separate element for the POI.

A shop can be mapped as a polygon without any building tag at all, so I'm not sure if "shop mapped as a polygon" in your question implies a building. But if that's the case: I would consider remapping from building to node a mistake if the building is single-purpose, because information (the fact that it's a single-purpose building) has been lost. Likewise, I would consider remapping from building to node to be an improvement if the building is not single-purpose.

(29 May '19, 19:20) jmapb

I wouldn't frame it so strictly. Adding information is generally welcome, especially if combined with local knowledge; the last person to touch a restaurant POI can usually be expected to be the last person to have seen the POI on the ground and therefore their knowledge is most current. However, to cite a recent example, the renderer-driven "adding of information" to a natural=bay by converting it into a multipolygon that contains all the coastline is highly contentious because it doesn't really add anything of value (least of all local knowledge) and makes everything more complicated.

The most frequent situation in which what you say is brought up is in the context of switching between "neigbouring areas which are divided by a linear feature glued together" and "neighbouring areas separated by a linear feature" (German: "Flächen verkleben"). For example, the rejected (but for other reasons) proposal https://wiki.openstreetmap.org/wiki/DE:Proposed_features/Empfehlung_zur_Verwendung_von_Multipolygonen has the sentence: "Bitte unterlasse es, vorhandene Daten, die nicht dieser Empfehlung entsprechen, ohne konkreten Anlass diesen Empfehlungen anzupassen. Das gebietet der Respekt vor der Arbeit anderer Mapper. Verfeinerst, aktualisierst oder korrigierst du allerdings Daten, kannst du sie den Empfehlungen gemäß umbauen. Änderungen nur des Änderns Willen sind unerwünscht." - in English: "Out of respect for other mappers, please refrain from modifying existing data to match these recommendations unless you have a concrete cause. If you improve, update, or fix data then you can re-structure it. Editing for editing's sake is unwanted."

permanent link

answered 29 May '19, 13:12

Frederik%20Ramm's gravatar image

Frederik Ramm ♦
73.3k866641137
accept rate: 24%

Thanks Frederik. Yes, the case of the "glued areas" example was one that I found as well. I'm wondering if this concept could be generalized to other cases?

Some example of cases where this can come into play are cuttings/embankements (embankement=… vs. man_made=embankement), sidewalks (sidewalk=* vs. footway=sidewalk), addresses (addr:street vs. associatedStreet relations), cycleways (highway=path + bicycle=dedicated vs. highway=cycleway), phone numbers (phone=* vs. contact:phone=*), and perhaps many more.

Do I understand you correctly, that in these cases the mapper(s) who contribute(s) the most recent local knowledge should have the right to use their preferred mapping model, but should at the same time refrain from changing the data merely for the sake of personal preference?

(29 May '19, 14:08) tyr_asd
2

I think a good rule of thumb would be "don't change the way something is mapped if the only reason you're changing it is your personal preference".

(29 May '19, 17:40) alester
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×161
×21

question asked: 29 May '19, 11:59

question was seen: 403 times

last updated: 29 May '19, 19:35

powered by OSQA