piebro/osm-data huggingface dataset:
Bolt032 (2024-03-27 14:12:30+00:00): Hello Szutkes! Is motor_vehicle=no still applicable for way 429384441, way 226840028.
DTHG (2015-07-31 20:05:29+00:00): What were you trying to do here? You didn't remove a One way tag instead you moved a traffic signal slightly. Is there a problem with one of the one way streets in this area or did you just mean to move the traffic signal?
pratikyadav (2015-08-06 05:23:43+00:00): I was working on a task to fix incorrect one-way using to-fix and found only the signal position to improve. Apologies for not changing the changeset comment and delay in reply.

Thank you.
M!dgard (2015-07-28 12:11:27+00:00): The rest of the mapped phone booths in Belgium should be surveyed and if necessary also removed. If they are still present, you can add a note, like 'verified that this phone still exists 2015-07-28'.
woodpeck (2015-07-30 01:03:47+00:00): I commented on your diary entry https://www.openstreetmap.org/user/M!dgard/diary/35474 explaining why edits such as this make OSM worse not better. Please don't do it.
*Martin* (2022-03-07 07:12:00+00:00): Cau. Ta trasa https://www.openstreetmap.org/relation/3365351 je znacena v terene?
PavolG (2022-03-07 07:16:58+00:00): Pochybujem
*Martin* (2022-03-07 07:17:54+00:00): tak to mozem zmazat?
PavolG (2022-03-07 07:23:36+00:00): Mozes čokoľvek. Aj zmazať mtb reláciu:)
chillly (2015-08-02 11:10:06+00:00): Why is this transliteration of Kingston upon Hull useful? Please don't add transliterations, transliterate at render time if you need that.
Batareikin (2015-08-04 12:01:51+00:00): In order to fill the obvious gap in your knowledge I am glad to inform you that this IS useful because:
1. Geographical names in foreign languages are normally transcribed into Russian, not transliterated.
2. The rules for transcribing into Russian are often ambiguous and controversial, even from the same language (for example, English).
3. The rules have exceptions.

Therefore, the correct Russian spelling of an English toponym cannot be always obtained automatically.
Russian spelling of a foreign toponym is normally double-checked in various sources before submitting to the OSM database (and tagging name:ru).
Only after that the correct spelling can be rendered in various applications for about 160 million Russian speaking people.
chillly (2015-08-04 12:36:23+00:00): To fill the obvious gap in your knowledge, we quote sources used. What are these sources? I wonder what the copyright and / or licensing status of these sources are? Since you don't quote them I can only wonder. 

I'm very please Hull will appear on Russian maps, Russians are always welcome there.
Batareikin (2015-08-04 15:16:15+00:00): You doubted usefulness of adding any Russian toponyms at all, and claimed them to be obtained automatically in your first comment, if I understood you well.
So are you worried about the licensing status or correct Russian transcriptions now?
chillly (2015-08-04 15:40:29+00:00): I didn't doubt the usefulness of a name, I doubted the usefulness of transliterations.  You claim they are not transliterations, but checked against "various sources". What are these sources and what are these sources copyright and / or license status? 

If you claim to use a source it fair for me to ask what that source is. OSM cares a great deal about sources. I depend on surveys as my source. Surveying Hull I have not seen the name in Russian or Ukrainian. That's why I ask.
Batareikin (2015-08-09 13:57:22+00:00): Ну если Вы всё-таки не поняли в чём полезность "транслитерации" (и отличие её от транскрипции), отвечу на родном языке.
Что касается конретно этого английского города, то даже в онлайне источников предостаточно (https://yandex.ru/search/?lr=2&clid=2186618&msid=22897.21761.1439126405.47858&text=%D0%9A%D0%B8%D0%BD%D0%B3%D1%81%D1%82%D0%BE%D0%BD-%D0%B0%D0%BF%D0%BE%D0%BD-%D0%A5%D0%B0%D0%BB%D0%BB).
Ну если хотите в частности https://www.wikidata.org/wiki/Q128147

Если Вы не видите табличек с названием города на русском и украинском языках, то это совсем не означает что таких названий не существует.
А если интересно как образуются рускоязычные названия, то можно ознакомится с https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B3%D0%BB%D0%BE-%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%B0%D1%8F_%D0%BF%D1%80%D0%B0%D0%BA%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F_%D1%82%D1%80%D0%B0%D0%BD%D1%81%D0%BA%D1%80%D0%B8%D0%BF%D1%86%D0%B8%D1%8F#.D0.9B.D0.B8.D1.82.D0.B5.D1.80.D0.B0.D1.82.D1.83.D1.80.D0.B0.
И в частности с литературой из раздела "Литература" вышеуказанной статьи.
chillly (2015-08-09 14:25:50+00:00): Wikipeadia is NOT an acceptable source. It's content can come from any source which may not be acceptable to OSM.
Batareikin (2015-08-21 19:31:34+00:00): Вы вообще внимательно прочитали моё сообщение и поняли его? 
А что касаемо что может быть источником для русскоязычных названий, а что нет решаете не вы.
Сергій Дубик (2015-07-28 12:28:54+00:00): Будь ласка, не видаляйте точки зі public_transport=stop_position (там схема http://wiki.openstreetmap.org/wiki/Key:public_transport і назва на 2 точках і 1 зв’язку)! На POI (Оскар) не потрібно навішувати адресних тегів якщо ця точка є всередині будинку чи території, що вже мають адресні теги (можна хіба вказувати повну addr:full=).
Антон Марчевський (2015-07-28 14:53:17+00:00): ок, зрозумів.
Aleks-Berlin (2016-01-01 12:21:02+00:00): why do you use ele=no for buildings in Leipzig?
ele=elevation=HöheÜberMeeresspiegel (unit = meter).
ele=no means nothing and should be avoided.
PS: height vs. ele should be considered.
Владимир К (2018-08-08 07:54:36+00:00): номера подъездов надо через ref отмечать,  а не через названия. я исправил.
jiazheng (2015-07-28 23:41:00+00:00): PS: 有些不一樣的屋頂顏色卻被畫成同一棟建築物，是我看Google街景只要是柱子和牆面一模一樣又連再一起的就當同一棟建築
streckenkundler (2015-07-28 13:39:59+00:00): Hat der New Yorker - Laden zugemacht? oder warum hast du ihn gelöscht?

Neulich war er noch offen...
mattse666 (2015-08-09 13:03:53+00:00): Mahlzeit, der New Yorker hat tatsächlich geschlossen und es ist leider nicht absehbar was dort hineinkommt. mattse666
streckenkundler (2015-08-09 20:54:33+00:00): Boah... und das in meiner Heimatstadt... Ich kann es fast nicht glauben... Nun... denn... seis drum...Ich war in den Jahren eh nur ein oder zweimal drin... War eher nur Plunder... 

...Danke und viele Grüße,

Sven
Rui Oliveira (2015-07-28 14:04:14+00:00): A intersecção da avenida professor gama pinto, com a avenida professor egas moniz não tem intersecções de pontos, tal como mostra o seguinte imagem:
(ver setas amarelas)

http://tinypic.com/r/2rf81g4/8

Essas intersecções segundo as boas práticas do openstreetmap têm que ser estabelecidas de modo ao software que depende dos dados (nomeadamente a navegação GPS), possa indicar que há intersecções entre as avenidas e disponibilizar  assistência de navegação ao condutor.
DoubleA (2018-01-08 20:57:35+00:00): Hi Rudy355,

could you please check way 362762617? Untagged, maybe that is a bridge over the river?

Cheers
arav_ind (2019-07-23 08:41:02+00:00): Hi AkuAnakTimur,

Trust you are well. While reviewing the road network in Alor Setar, I have come
"node 5351338567
node 5351338564" 

has been tagged with 'turning circle'. However, going by the aerial imagery and other ways around, there is no median here.

Please suggest if it is otherwise

Thanks in advance.
Jose Riha (2018-06-08 13:56:53+00:00): zdravim,

https://www.openstreetmap.org/node/3670267291 - toto je naozaj nazov objektu? Podobne tiez https://www.openstreetmap.org/node/3670332537. Dakujem
aceman444 (2019-02-12 01:07:31+00:00): Tiez mi to pride divne a hlavne popis changesetu je na jedno taborisko ale zmenil ich kopu na ploche 1000km^2.
aceman444 (2019-02-12 01:09:58+00:00): Okrem tohto ma len kopu changesetov s nicnehovoriacim popisom "DRONTE" kde pridava slipway s podivnymi nazvami. Ale vyzera, ze pred 3 rokmi uz skoncil.
Jose Riha (2019-03-31 21:18:55+00:00): source vyzera byt na https://www.dronte.cz/cs/rentals/93-maly-dunaj

otazka je, ci ma nieco taketo vyznam v OSM mat
aceman444 (2019-03-31 21:36:36+00:00): A co to teda je? Miesta, kde tato firma organizuje splavy ci vie doviest lode? Ak je tam slipway, tak tu zrejme chceme, ale firmu nie, rampu predsa moze vyuzit ktokolvek.
aceman444 (2020-07-19 11:04:08+00:00): Bol som osobne na dvoch miestach, kde su v OSM tieto "slipway" s nazvom Dronte. Su to miesta, kde vodaci spustaju clny na vodu, niekde su aj mola. Nazov pristaviska nie je velmi znaceny, ale ine spolocnosti organizujuce splavy nejake nazvy pouzivaju. Nikde v okoli ani stopa po spolocnosti Dronte, ani po takom nazve. Podla webu maju pozicovni len v Zalesi, tak ten bod s amenity=boat_rental vyzera OK. Odstranim teda zo vsekych tych nazvov slovo "Dronte" a potom sa mi javi, ze nazvy pristavisk budu aj celkom spravne, podla toho co som videl. Tiez odstranim opisne nazvy ako "Prenos lodí pravý breh", co sa da vyjadrit znackami whitewater=egress a pod.
SomeoneElse (2023-06-24 12:19:09+00:00): Hello,

I hope you don't mind me asking about an edit from 8 years ago. On this changeset you added a "source=Google" tag on https://www.openstreetmap.org/node/3670239133 here. We can't actually use that as a source in OSM because the Google's licence doesn't allow it to be used here - it would cause real problems for the project if we were found to be using Google Maps as a source.
If this is somewhere that you are familiar with, then "source=local_knowledge" would be perfectly OK.

Best Regards
Andy Townsend, on behalf of OSM's Data Working Group
SomeoneElse (2015-08-06 01:10:37+00:00): Like you did with Walton Wood elsewhere, you've also broken Cuckney Hay Wood in this changeset, so that it's impossible to edit.  http://www.openstreetmap.org/way/359674431/history was previously a polygon of a specific type of trees; you've made it into one edge of a relation.  Similarly there's no indication now that https://www.openstreetmap.org/way/359674428/history forms part of Cuckney Hay Wood at all - this was present (see http://osm.mapki.com/history/relation.php?id=5353764 ) until your edit.

I would at some stage like to continue mapping both of these areas but it will be impossible to do so until you undo your changes.  Maybe since you have made it impossible for other people to edit these areas your are going to do the surveying yourself?
rbuch703 (2015-08-06 09:05:12+00:00): "http://www.openstreetmap.org/way/359674431/history was previously a polygon of a specific type of trees; you've made it into one edge of a relation."

I actually I made it into an edge in *two* relations: relation http://www.openstreetmap.org/relation/5397178 still represents your polygon with specific types of trees. And it is also a part of the overall Cuckney Hay Wood relation, http://www.openstreetmap.org/relation/5353764 to represent the overall wood's outline.
rbuch703 (2015-08-06 09:10:46+00:00): "Similarly there's no indication now that https://www.openstreetmap.org/way/359674428/history forms part of Cuckney Hay Wood at all - this was present (see http://osm.mapki.com/history/relation.php?id=5353764 ) until your edit."

That is true, but is unavoidable with the current specification of OSM multipolygons. For a valid multipolygon, two rings *must not* overlap, unless one represents a hole in the other. But exactly that was happening with way 359674428 being a subarea - and not a hole - of relation 5353764.
rbuch703 (2015-08-06 09:13:01+00:00): "I would at some stage like to continue mapping both of these areas but it will be impossible to do so until you undo your changes."

Have you tried using a different editor? I find it reasonably efficient to work with multipolygons in the iD editor, and find it quite efficient in JOSM.
rbuch703 (2015-08-06 09:19:49+00:00): As a side note, to me the underlying issue here seems to be that you are trying to use object hierarchy semantics ("OSM entity X has property A. And OSM entity Y is a part of entity X, inheriting all its properties and adding property D"), but OSM has currently no way to validly specify such hierarchies. It might be worthwhile to specify such semantics first, for example based on the "part" role of building relations (http://wiki.openstreetmap.org/wiki/Relations/Proposed/Buildings ).
SomeoneElse (2015-08-06 09:23:21+00:00): (re JOSM) I regularly use it for tasks that it can manage, but its waypoint support is abysmal (see https://help.openstreetmap.org/questions/7675/josm-is-it-possible-to-convert-an-individual-waypoint-in-a-gpx-file-to-a-node ) so it simply isn't an option for most of the survey-based mapping that I do.  Also, its rendering of route relation memberships is very poor compared to e.g. P2, and it doesn't render duplicate nodes at all well (I regularly have to "bucket and shovel" local areas edited by JOSM users of dupe nodes before adding what I came to map in the first place).
SomeoneElse (2015-08-06 09:25:55+00:00): Re "For a valid multipolygon, two rings *must not* overlap" - can you explain why not?  What real-world problems does it actually cause?
rbuch703 (2015-08-06 09:53:51+00:00): Being invalid practically means that multipolygon parsers (e.g. those in osm2pgsql, imposm, etc.) will go into quirks mode and use *heuristics* (=guesses) to make it into a valid multipolygon. This may mean that they will just ignore the inner ring - which is possibly what you intend them to do for rendering. It is also possible that such a parser just assumes this to be a valid inner ring with an invalid role "outer", assumes that the role was supposed to be "inner", and cuts a hole into the multipolygon. A parser could also just drop all but the first of a set of overlapping rings, meaning that it might omit the whole wood and just keep the small part. Or, a parser might ignore this inconsistency and keep the overlapping areas, which will lead to rendering issues if the areas are rendered with an outline (in this case the outline of the subarea may be displayed or may be overdrawn, depending on the - random - rendering order) or are rendered semi-transparently (in which case the overlap will render in a darker shade than the remaining wood).

Overall, being invalid means that using a different parser will produce a different result from the same data. Put another way, it means that there is no unambiguous interpretation of this data, reducing its practical value.
SomeoneElse (2015-08-06 10:18:53+00:00): There's lots of "mays" and "coulds" above - like I mentioned previously on the "Walton Wood" changeset ( http://www.openstreetmap.org/changeset/32932368 where I explained the usage of osm2pgsql's --multi-gemetry flag ) I'm reasonably familiar with osm2pgsql's historical behaviour with multipolygons* - can you provide a _specific_ example of a real-world problem caused by the previous mapping here?

* see recent osm2pgsql github discussions for chapter and verse - multipolygon handling is by no means a "solved problem" there.
rbuch703 (2015-08-06 11:22:05+00:00): 'There's lots of "mays" and "coulds" above'
.
- Yes, and these are exactly the point: The multipolgon specification requires valid mulitpolygons to have certain properties, and unambiguously specifies the semantics for those valid multipolygons. Thus, as long as multipolygon parsers are implemented correctly, they will all yield the same results - but only for *valid* multipolygons. For any multipolygon *violating* the specification, the "mays" and "could" above apply. That's exactly why formally invalid multipolygons are undesirable.

Now one might be inclined to ignore the specification and model geographic features just so that they render correctly when using the osm2pgsql workflow. But this would not be future-proof (osm2pgsql may change its opinion of what to do in a given situation of an invalid multipolygon at any time without violating the specification), and IMHO is an instance of http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer (section "General Meaning"), which is generally frowned upon in the OSM community.
SomeoneElse (2015-08-06 11:51:44+00:00): Currently the way that you've mapped these simply doesn't represent the situation on the ground.  If I don't hear a _specific example_ of the problems caused by the original mapping here I'll change Walton Wood and Cuckney Hay Wood back as they originally were when I next need to edit them.  Because you've used exceptionally wide changesets, this may affect other items.
As I've said before, (and many other people have said before me) OpenStreetMap's scarsest resource is mappers - changes like this to Cuckney Hay Wood and also to Walton Wood prevent mappers from mapping and are actively harmful to the project.  Please, before making any changes such as these, ask yourself "how does my change help mappers to continue mapping this area"?
SK53 (2015-08-06 13:44:01+00:00): I'm all for reverting this changeset. OSM is about mapping things, not dealing with how OSM data is processed by tools. If tools cannot deal with real-world cases then fix the tools not the data. As it existed the data was previously treated as expected by osm2pgsql. If osm2pgsql changes the way it processes polygons then I'm sure we would notice in rendering output. These edits fix a putative problem not a real one, and introduce a more serious one.

As an aside multipolygon does not any kind of formal specification. It has implementations which may be regarded as de facto specifications: but there are as least two current widely accepted behaviours for multipolygons. Some, but be no means all of this described (not specified) on the wiki).

I should also add that these areas are an important experiment in working out how to map woodland areas in detail. See my blog passim for some of the issues.

In summary, revert.
rbuch703 (2015-08-06 15:40:01+00:00): @SK53: I completely disagree. Yes, OSM is about mapping things. But mapping things is all about giving meaning. And meaning depends on existing specifications - even if there are only de-facto specifications. If you create something that is explicitly forbidden by a specification - and usually for good reason - you are not adding meaning. OSM data can only have meaning if there is a specification that describes it, because it is only this specification that all software implementors and human readers can rely on to interpret the data. Meaning is not given by things through "osm2pgsql does it that way!", because the current interpretation of osm2pgsql may change any day without notice, while a specification won't.

Yes, if current tools cannot handle real-world cases, then by all means adjust the tools. But first find a sensible way of doing so. Multipolygons are a concept to represent areas, not to represent hierarchies. If they can be extended to represent hierarchies without sacrificing robustness - fine, do it. But if they cannot - and it seems to me that multipolygons are ill-suited for this case - then create an orthogonal concept and make sure that the existing concepts stays unaffected.

I did not know that this area is an important experiment in working out how to map woodland areas in detail. I found the two areas based on a tool that finds geometrically invalid multipolygons, and those cases were two out of only about 200 broken multipolygons in all of the British Isles. That both woods appeared in such a short list of geometric errors indicates to me that the used way of mapping was not in line with usual OSM best practices.

My edits also did not fix only a putative problem. They fixed a data incosistency that potentially affects all software that parses OSM data - even if osm2pgsql rather coincidently gave the desired output. And they only potentiall negatively affect a tiny fraction of all mappers - namely those that want to actually edit one of these two tiny woods in the UK.

I won't stand in the way of a reversion if that is the consensus. But I think that the important more general questions raised here (1. How should hierarchies of information be modelled in OSM? 2. Are overlapping or touching outer rings a reasonable way of modelling multipolygons in OSM?) should first be discussed in a broader context.
rbuch703 (2015-08-06 15:41:12+00:00): @SomeoneElse: My specific example is this: Mappers ocasionally incorrectly set the roles for multipolygon members, and so some holes erroneously become "outer" members. There are probably thousands of these types of multipolygons out there. But to a piece of software they look exactly like your sub-woods! So either all of these multipolygons need to be fixed permanently. Or - by majority vote - their semantics (that an outer ring inside an outer ring is an error and should be interpreted as "inner") and not yours represent the most widely used interpretation of overlapping "outer" rings in multipolygons.
SomeoneElse (2015-08-06 17:32:52+00:00): Re "But to a piece of software they look exactly like your sub-woods!":

According to http://osm.mapki.com/history/relation.php?id=5353764 the http://osm.org/browse/changeset/32539732 version of the relation clearly shows one multipolygon relation with multiple way members with the role "outer".  If whatever QA software you're using can't tell that from missing relation roles, (which are indeed a genuine issue) then you need to fix it.

To be clear - previously what was mapped was Cuckney Hay Wood (a relation) consisting of multiple non-overlapping polygons, each with role "outer", so your "specific example" does not apply here.  Humans (as SK53's comments above confirm) had no problem understanding what had been mapped;  osm2pgsql with the -G flag set either way also had no problem; once the data was in the database, the renderers also had no problem.  

The basic relationship of different sections of trees forming part of one wood has been removed by your edits, and no we no longer have a model in OSM of what is actually there on the ground.
BCNorwich (2015-08-02 17:46:01+00:00): Hi, you don't make a route relation or add to one by duplicating streets, you add the existing street to the route relation.
Weide (2015-07-29 14:55:11+00:00): Bitte beim Verschieben eines Platform-Nodes auf die Fahrbahn alle Relationsrollen anpassen. Vier Routen halten jetzt zweimal am Rathaus.
Peilscheibe (2015-07-28 15:28:54+00:00): Could you please rework this changeset a bit? I'm sure Salzburger Straße is not a ford. 
At least for Sankt-Pöltener-Straße it's sufficient to add a oneway:bicycle=no if it's free in opposite direction. 
The you have moved a traffic sign by 255 metres (https://www.openstreetmap.org/node/3480652985). I'm very sure the sign hasn't moved the last time.
Peilscheibe (2015-07-28 17:28:10+00:00): Well, I now reverted the changeset since there was no substantial improvement but much errors. Salzburger Straße has no bicycle lane, is not a ford and a traffic sign was moved. The current tagging now reflects the reality.
SomeoneElse (2015-07-29 21:31:51+00:00): Would it be possible to explain what the problem was with Walton Wood?  You've split the outlines of the various patches of woodland into lots of individual ways such as http://www.openstreetmap.org/way/362775405, so it's effectively impossible to edit now.  Could you possibly explain how what you've done here is an improvement?