You are welcome.

One note per location (not per object) is, obviously, okay. No, there is no standard procedure. You can:

• Leave a Note near that object
• Just edit it once you found it (especially if it’s something non-existent - you can just delete it)
• Add “fixme” tag with a value that briefly says “misplaced”

In the first and the last cases, other mappers will see a note or a highlighted “fixme” feature (in JOSM editor, not in iD) and would be able to participate in fixing these errors.

I’m talking about a single note for each object, not a single note for all of them together. I think you’ve missed a point of notes feature.

It could be more effective to use Notes feature osm.wiki/Notes than just list these locations here. Notes are not for personal ToDo lists, but other local mappers could help you to fix these locations.

@Warin61, I mean that there are multiple existing views on what https://wiki.openstreetmap.org/wiki/Tag:landuse=grass and https://wiki.openstreetmap.org/wiki/Tag:natural=grassland mean. So, people want to have their favorite tags to represent what they want (like, “managed lawn”). It is logical, that there should be an “atomic” tag to indicate wooded vegetation without any implications, but since people prefer to have what they like to what is logical, I don’t see any sense in trying to introduce this kind of tag due to public resistance.

https://wiki.openstreetmap.org/wiki/Tag:wood=coniferous wasn’t anyone’s favorite. But it has an obvious disadvantage - you never know, if it is used as an indication of conifers or as an indication of evergreen plants. https://wiki.openstreetmap.org/wiki/Tag:leaf_cycle=evergreen together with others solves this problem perfectly. Resistance was very subtle because nobody wanted to keep old tags that much.

So, that’s all about what people like and want. If they want some bullshit - this situation doesn’t deserve wasting your time on it.

Sorry, I meant to say https://wiki.openstreetmap.org/wiki/Tag:wood=coniferous" and leaf_cycle=evergreen`.

@Warin61, there is at least one massive case of getting rid of a nonsense scheme - https://wiki.openstreetmap.org/wiki/Tag:wood=evergreen and so on. The situation with grass doesn’t deserve to be changed since there are multiple unclear views on the same tags.

The problem here is that there are as many opinions what exactly “fast food amenity” is, as OSM contributors. Having that kind of discussion in the Russian community, for example, I’ve got variants such as: “these are certain brands”, “these are American restaurants”, “these are places with junk food” (whatever it means) and other kinds nonsense.

There can not be any definition that will suit a majority of cases, period.

Yes, Coop brand also exists in Norway. https://coop.no and Denmark https://coop.dk

And in general, if we have a tag that is supposed to have a text value (as an opposite to predefined reserved values), it is a bad idea to mix value types and to have something predefined because you never know (exactly like in the case of “coop”) what free text value could you meet in a real-world case.

So, if I’d want to add a feature for cooperatives, I’d use something like https://wiki.openstreetmap.org/wiki/Tag:cooperative=yes or similar.

A form of ownership or management is often an unknown information that can’t be easily obtained and supported (verified periodically). Therefore, even if there would be a good tagging scheme for it, only a few places would be properly tagged. In addition to that, forms of ownership/management are different in different countries. That makes having a consistent scheme quite problematic.

However, nobody can stop you from adding (and documenting, otherwise it becomes completely unusable) an own tag.

This is the same mess originating from natural language terms as the situation with shops. This issue of exclusive values also applies. Arguments against any improvement of it are old as mammoth feces: “it is too complex”, “nobody will use it” (pure demagoguery, actually).

Regarding of too verbose descriptions of food amenities or shops, it shouldn’t be an argument against changing anything, it should be a question, what level of verbosity is acceptable. Obviously, quoting a full menu is a nonsense. But it doesn’t mean that nothing could and should be described - that would be a false dichotomy like “all or nothing”.

Question about supportability of data is always valid - if there are not enough active mappers in an area, verbose tagging of something that could easily change in time has much higher chance of becoming outdated. In an opposite situation, it makes perfect sense.

@SK53,

Indeed, sometimes, documentation is misleading. However, without shifting from descriptive to prescriptive, it is nearly impossible to maintain any consistency of tagging. Eventually, a certain tag could get a hundred different interpretations. Descriptive and prescriptive parts could easily coexist, describing a certain practice for data consumers and prescribing one (not necessarily the same) to mappers. And I don’t see it as an issue of opinion against another opinion. At least, because opinion with no reason except “I want” or “I’m used to that” has very little value, as well as tagging for a renderer, for example (that is a form of very self-willed tag interpretation).

@SK53, what you’ve described (tagging a territory that is only called “a forest”) is an example of a literal tag name interpretation. That is an obvious mistake since documentation implies a presence of wooded vegetation. But local communities could often be quite stubborn in their misuse of tags.

JOSM can’t guarantee a better quality - it might only suggest fixing something while it’s completely up to any user to ignore warnings.

@tyr_asd, this is another case - someone just doesn’t know how to map 3D buildings properly.

Не “не конкурент”, а “не пытается и не должен быть конкурентом”. Разницу видите? Возможность строить маршруты - это, прежде всего, возможность тестировать роутинг на нескольких основных движках, так что имеет самое прямое отношение к картографированию. А “серьезное планирование” - это, в любом случае, не про OSM.

Аналогия с комментариями к changeset-ам - некорректна, так как обсуждение пакетов правок позволяет проще и более предметно обсуждать правки так, чтобы кто угодно, кто заглянет в историю, мог ознакомиться с возникавшими относительно этого вопросами (чего не происходит, когда обсуждение происходит в личной переписке или где-то еще). Это имеет прямое отношение к картографированию. Чем конкретно типичный спортивно-туристический функционал может реально и непосредственно помочь картографированию?

@Sergey Kozyr, я уже объяснил. Аналитика треков не относится к функциям, которые бы так или иначе помогали картографированию, как таковому. А назначение сайта osm.org именно такое.

@Zverik, ниже нуля, потому что этот функционал противоречит функциям сайта. Этот пул-реквест завернут, и правильно сделают.

Несколько встречных комментариев по пунктам.

1. Вы всегда можете скачать трек и загрузить его отдельно, например, в JOSM.
2. Статистика обычно интересует пользователей спортивных сайтов и т.п., для нужд картографирования статистика практически не нужна.
3. Это было бы хорошо, если бы у существующих треков, как минимум, можно было удалять сегменты вообще (“кляксы” от стояния на месте). Но вообще, каждый добросовестный пользователь может делать это заранее, перед загрузкой. Так что проблема не в отсутствии инструмента, а в отсутствии желания это делать.
4. Фильтрация треков есть в JOSM.

Итого, получается, что ваши предложения либо уже реализуемы (но не на сайте), либо не решают какую-либо конкретную задачу, которая была бы связана с картографированием. Вам стоит понять, что osm.org - технический сайт, обслуживающий нужды участников проекта в области картографирования, а не конкурент Google или спортивным/туристическим анализаторам треков. Сайт служит вполне конкретным задачам, список которых расширять никто не собирается (и этому есть вполне логичное обоснование).

Репозиторий этого сайта на GitHub тут https://github.com/openstreetmap/openstreetmap-website

I’d even say that “circle of error” representation together with text located in the top left block could promote “mapping for Wikidata”. It says:

Large red circles mean the distance is greater than 10 kilometers, which indicates a higher error rate

So, anyone who got used to other validators (where errors are detected by it and presented for confirmation and correction by mappers) could get an idea, that OSM feature is misplaced when there is a large red circle. While it only shows a distance that could probably mean there is an error (but not necessarily).

And there are a lot of false errors related to long linear objects such as rivers because Wikidata works with points only. So, a map gets cluttered and unreadable. Same applies to relatively large areas - there are several ways to define a center of an area. OSM could use one method, Wikidata - another one.

The whole tool only gives you a vague hint on what could be referenced to Wikidata by mistake, it is not a validator by any means.