piebro/osm-data huggingface dataset:
papamat15 (2022-01-29 19:16:51+00:00): Danke für den Hinweis,
habe hier nach meinem "Kampf" mit einer kleinen Ergänzung wohl zu wenig das Gesamtergebnis überprüft.
Nach einer "kleinen" Ergänzung an einem sergment der Finnbahn meldete JOSM in seiner Prüfung immer wieder, dass diese Laufbahn nicht durchgehend gemappt ist und auch nicht geschlossen. In mehreren Einzelschritten habe ich nach dem "Problem" gesucht und unteranderem festgestellt, dass auf der gesamten Strecke eine einheitliche Weg-Richtung sein muss. Nur der Eintrag "Sport=running" bemängelte Josm auch, hier habe ich mich an einigen Weg_segmenten orientiert, die auch leisure=track gekennzeichnet waren. Hierzu fand ich unter wiki.openstreetmap.org/wiki/Tag:leisure%3Dtrack auch eine Bestätigung. An einigen Stellen fehlte die Verbindung der Einzelstrecken und am Schluss wurde bemängelt, dass die Running-Strecke einheitlich sein muss - hier habe ich dann der automatischen Korrektur zugestimmt (hier liegt mein Fehler).
Allerdings hatte mich auch erstaunt, dass die Brücke mit Layer 1 gemappt war.

Das Problem der 2 lanes kommt von der nördlichen Strecke die mit dem danebenliegendem Gehweg ursprünglich so gemappt worden ist. Hier habe ich den Fußweg/Wanderweg parallel zur Finnbahn ergänzt.
Falls dir hier noch etwas auffällt, keine scheu für eine Info dazu. Wer die Korrekturen einträgt ist mir egal, aber die Info dazu hilft mir bestimmt.

Noch einen schönen Abend
legofahrrad (2022-01-29 20:43:55+00:00): Ich denke, jetzt sollte alles richtig gemappt sein. Ich habe nochmal zusätzlich area=no auf die Finnbahn ergänzt.
Das "bridge=yes" zusammen mit dem Layer 1 kam von dem Kanal im Osten. Dort schneidet sich quasi das Wasser mit dem Weg.
Siehe auch der Fußweg hier: https://www.openstreetmap.org/way/1025921891 (Dort ist bridge und layer richtig)
Ich habe dafür noch keine passende Lösung gefunden. Beim Weg aufspalten beschwert sich JOSM wieder und das Wasser als Tunnel geht auch nur mit Mühe, da wir hier eine ganze Fläche haben.
Viele Grüße!
Tomas Straupis (2022-01-24 05:51:52+00:00): Mano žiniomis water=lake nieko nekeičia - niekur nenaudojamas :-) natural=water viską pasako.
MindaugasS (2022-01-24 12:26:57+00:00): Puiku. Tik keistoka, kad tas ežeriuko vardas Akis niekaip nepasirodo OSM interfeise, o matyti tik redagavimo režimu. Netoliese esantis ežeriukas Pajus, regis, tokios problemos neturi.
Tomas Straupis (2022-01-24 12:47:34+00:00): Nežinau, kas yra „OSM interfeisas“. Jei kalba apie vieną iš tūkstančių iš OSM daromų žemėlapių OSM-Carto, kuris matosi www.openstreetmap.org, tai reikia tiesiog palaukti, kai serveriai turės laiko - perbraižys :-) Plius dar gali trukdyti ant viršaus užžymėtas sodas, jo tekstas gali neleisti braižyti vandens telkinio pavadinimą. Bet kokiu atveju, su duomenimis viskas gerai, nieko keisti nereikia.
MindaugasS (2022-01-24 13:13:18+00:00): OK. Turėjau galvoje tą OSM žemėlapį, kuris matyti www.openstreetmap.org vos prisijungus ir nieko nekeitus (default). Turbūt, kaip sakote, trukdo sodas, nes kiti pakeitimai paprastai pasirodydavo greičiau. Tiesiog norisi parodyti tuos istorinius pavadinimus, bet, žinoma, kantrybė – dorybė, taigi lauksiu :)
Tomas Straupis (2022-01-24 14:17:05+00:00): Vat kas keista, kodėl tas pavadinimas mūsų lietuviškuose žemėlapiuose (openmap.lt, topo.openmap.lt, places.openmap.lt ir pan.) nesimato... Pas mus kitą dieną bet kokiu atveju turėjo būti. Gal per mažas...
MindaugasS (2022-01-24 19:37:46+00:00): Man ką tik pradėjo matytis per places.openmap.lt; per kitus dar ne.
Tomas Straupis (2022-01-24 21:28:00+00:00): places.openmap.lt - vienintelis, naudojantis seną rastro technologiją. Visi kiti naudoja vektorines technologijas ir išlankstytus vandens telkinių užrašus. Pasirodo buvo susikaupę daug nepaskaičiuotų vandens užrašų, o Akis, kaip toks mažiukas telkinys - pačiam eilės gale. Stumtelėjau, kad paskaičiuotų, tai atsirado: https://topo.openmap.lt/#t/17.91/54.70229/25.26708/0/0/
MindaugasS (2022-01-24 22:36:53+00:00): Puiku, ačiū! Pasitarnavom Vilniaus vietovardžių istorijai :)
JhowieNitnek (2022-07-12 21:41:15+00:00): Hey Glenn, if you match geomatries try not to remove buildings with names that still exist. You accidentally removed https://www.openstreetmap.org/way/1078059124 and merged it with https://www.openstreetmap.org/way/260917265 even though 260917265 is multiple buildings big and not one.
Glenn Plas (2022-07-13 17:47:07+00:00): Hi,
Please check https://overpass-api.de/achavi/?changeset=116516724

Atleast In this changeset the osm ID's you mention wasn't removed.  I just added the correct backreferences to the source Urbis data.

When I check your mods in this changeset https://overpass-api.de/achavi/?changeset=123537940 it's in fact you that removed the building=* tag from the left part and also removed the source tags that were added by this algorithm.   This process doesn't delete buildings, it just does a matching with current Urbis database.  so I am not sure why you think I deleted it.   Please check the changesets with Achavi and try not to delete / try to keep the  source:* tags .   Also see the comment changesets if you want to help with buildings, it's probably better to not use the ID editor for this work.
Glenn Plas (2022-07-13 18:31:50+00:00): Ok, dove a bit deeper into this. 
 
When I delete something , except the occasional mistake not intentional, I always have a pretty good reason to do so.

So here, why are you giving buildings the name = "Double"  anyway ?  That is probably the reason why this way got removed.  If any deletes are done in a changeset it's a manual one and not an automated and most probably because there is  .... erm crap data.  And a name=Double kinda hits that.  But I think the reason why the 'building' disapeared on the map is because you remove the building=* tag at one point.   note that there is an amenity encompassing both buildings

So I think you're talking about this way:  https://www.openstreetmap.org/way/260918023/history

See also:
https://osmhv.openstreetmap.de/changeset.jsp?id=116516724

https://osmlab.github.io/osm-deep-history/#/way/260918023

Diving deeper here I think in essence you are mixing the amenity around both buildings with the idea that I've merged 2 buildings which isn't what happened as far as I can see in the historical viewers.   I do see I deleted the left building, which seems indeed wrong, and I bet I made the mistake of tapping delete on the geometry instead of on the wrong name=Double tag, that was most probably my intention back then.   But I don't see a merge.  However, it would be kinda cool to restore the source:tags.   I'm a bit on a hiatus on OSM after developing the building merge tool so took me longer than usual to visualize the historical action done in all the changeset.

If you care to help the building completion effort on OS, check the comments on https://osmcha.org/changesets/116516724/ on the who, why and how those tags are used in contrast to the initial ref:Urbis one
The chat channel is like the place to be .

I see you're using ID editor a lot, not sure if you know JOSM but in that one it would probably be a lot easier to see that it wasn't a merge but it was 2 buildings  + 1 amenity around it.

I guess the name=Double was a mistake on your part, probably meant to end up in a comment on the changeset or a note on the building.

Glenn
JhowieNitnek (2022-07-13 18:36:51+00:00): The name is Double it wasn't a mistake  I did it in purpose. I can't find the source of it anymore as it has been a long time but the name is Double.
JhowieNitnek (2022-07-13 18:38:22+00:00): I found it https://www.bruzz.be/culture/news/uitbreiding-lesbrigittines-voedt-relatie-met-buurt-2007-08-14
Glenn Plas (2022-07-13 19:27:14+00:00): Woah, that's wicked.   I think it's probably best when you name something to follow the community consensus for BXL to add name:fr=Double name:nl=Dubbelganger and name=Double - Dubbelganger tags (fr<space>-<space>nl) , that would probably help.  But in any case, the delete of the left part is a mistake, the special tool (only runs locally, not public) that matches it does not have 'delete' logic on board, just a flag that is visualized later in JOSM using validator code / custom stylesheet to draw attention for manual review.   I think I just hit the delete on the selected geometry instead of my intented (wrong) move to just supress the name tag assuming it was a mistake.    Concerning the result: basically 2 buildings, surrounded by amenity.  I checked the Urbis database and it also shows 2 buildings, so there's not reason why it wouldn't have matched properly when the geometries are equal within the thresholds of the hausdorf algo.    I also see an issue with the source:geometry:ref and source:geometry:version tag allocated on the amenity.  Those only go on buildings, but when a building also has the amenity key and later on the building is removed and it is split  (which I would recommend in many cases when the building is only a part of an amenity), then those tags and also ref:UrbiS should be removed from the amenity-only way, but kept/moved to the building=* way.   Verifying the source data on Urbis shows me zero reasons to legit remove the left building, so that is definitely a manual action that went haywire at the time.   Thanks for pointing it out though , it was kinda confusing when you mentioned a merge that I couldn't place.
JhowieNitnek (2022-07-13 19:30:30+00:00): I don't think Dubbelganger is the name. The article probably just translated it for clarification of the name so I don't think name:fr=Double name:nl=Dubbelganger and name=Double - Dubbelganger is necessary here as it only has one name
Glenn Plas (2022-07-13 19:56:54+00:00): then officially would have to be tagged as : name=Double - Double when they are the same and name:fr=Double and name:nl=Double.

But I don't think this is a big problem with just using a single double.   This data is often used for apps that offer multiple language support and they would fallback to the name tag when the other lack.  I kinda follow you there on the translation thing.... Been looking around I also kinda doubt that 'Double' is the official name of the right building.  I have a hard time finding this reference back on the website of http://www.brigittines.be/

But I would agree that the general public would refer to this building as the Double and non-official names are often valid for OSM.    I'll add the website on the other building as well.

The article sure uses Double as a name even though the Brigitinnes website doesn't really refer to it like that (but the website is annoying to navigate when hoovering over the bottom menu/ mirroring title - thingy)
SekeRob (2022-01-23 22:10:09+00:00): Impossible to work with, nuts to say the least to have a forest with 2102 members, screens updating as slow a molasses.
o_andras (2022-01-23 23:28:53+00:00): Hi, welcome to OSM and congratulations on your first and second changesets! :)

I noticed that you've added a link to a photo on Google. There's one problem with this one specifically, because it doesn't work (I get a HTTP 403 error (Forbidden)).

And there may be problems with images from Google in general, due to licensing issues/incompatibilities.

This page (https://www.openstreetmap.org/copyright) briefly mentions "Copyright infringement". This page (https://wiki.openstreetmap.org/wiki/Import/Guidelines), though not specific for this situation, provides much useful information regarding sources and their legality for inclusion in OSM.

I would recommend for you to get in touch with your local community and discuss with them what is or isn't appropriate. In the meantime, another possibility is that, if the photo is your own, you can upload it to another website, such as Wikimedia Commons -- see here https://wiki.openstreetmap.org/wiki/Photo_linking

In the meantime, due to the problems mentioned above, I've taken the liberty to revert this changeset: https://www.openstreetmap.org/changeset/116518434

Have fun and happy mapping! :)
Hans Thompson (2022-01-24 01:20:52+00:00): Thanks for the edits.
ahunterg95 (2022-01-24 02:09:49+00:00): Not a problem, I realised that it was an area lacking in detail!
DressyPear4 (2022-01-24 23:51:41+00:00): Olá, para cachoeira selecione um ponto do rio existente e adicione 'waterway=waterfall'
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/116516984
Tulio Franco Silva (2022-01-25 01:01:32+00:00): Ok. Muito obrigado.
aceman444 (2024-01-28 13:40:01+00:00): Dobry den, nastupistia sa nazyvaju podla toho v akej stanici stoja (tu Hlohovec, AS), nie podla toho kam z nich smeruju linky.
Tomas_J (2024-01-28 13:50:11+00:00): Čus, ok, opravím.
aceman444 (2024-01-28 15:05:10+00:00): Samozrejme potom by bolo 10 nerozlisitelnych nastupist s rovnakym nazvom. Tak ale na mieste asi maju nejake rozlisenie (napr. nastupiste 2), tak to sa da do 'local_ref'. Ak nemaju cisla ale rozlisuju ich tymi destinaciami, tak sa da pouzit to.
Tomas_J (2024-01-28 15:08:22+00:00): Destinácie sú priamo veľkým písmom napísané na označníkoch zastávky, preto som ich dal do name. Neviem či maju aj cisla (asi áno) - zistim na mieste do cca mesiaca.
Tomas_J (2024-01-29 14:23:51+00:00): destinacie som z nazvov vymazal - https://www.openstreetmap.org/changeset/146824107
aceman444 (2024-01-29 20:38:30+00:00): Super, dakujem. Tak nakoniec tam cisla nastupist su, v 'ref' (ale su na bodoch stop_position). Prehodte ich na na body 'platform' a do znacky 'local_ref'.
Tomas_J (2024-01-29 20:55:45+00:00): vykonane.
AngocA (2023-07-26 15:45:42+00:00): Hola Doris. Viendo tu importación de las estaciones de monitoreo, creo que están mal de precisión en la fuente, por lo que quedan desfasadas en OSM.
Un caso puntual es este: https://www.openstreetmap.org/node/9443192607/ donde se ve que la estación está 200 metros al sur de los edificios.
AngocA (2023-12-17 01:14:43+00:00): https://www.openstreetmap.org/node/9443192596
No creo que sea "Oro Podrido" sino "Oro Perdido"
Tomas Straupis (2022-01-25 12:51:59+00:00): Ilgesnių privažiavimų nereikia keisti į service. Service - tai jau tokie visiškai vietinės reikšmės keliukai, kurie įdomūs tik pačiuose stambiausiuose masteliuose. Jei virš kokio 100m tai tame keliuke gali kas nori sustoti, mašiną palikti ir eiti... grybauti :-)
sampeto (2022-01-30 20:49:12+00:00): Hallo WAM_SNZ144_ZCH
Du hast in diesem und anderen Verkehrskreiseln ein traffic_calming=island erstellt. Magst du mir erklären, warum du das tust? Gemäss dem OSM-Wiki (https://wiki.openstreetmap.org/wiki/DE:Tag:junction%3Droundabout) werden so die Verkehrsteiler bei den Zufahrtsstrassen zum Kreisel gemapt. Im inneren des Kreisel ergibt das meiner Meinung nach nicht viel Sinn.
Gruss, Sampeto
pitscheplatsch (2022-01-27 16:57:05+00:00): Hi, welcome to OSM.

Great, your first test.
Should be reverted? Thanks.

---
Detected by #SuspiciousOpenStreetMap
https://resultmaps.neis-one.org/osm-suspicious
pitscheplatsch (2022-01-27 16:56:59+00:00): Hi, welcome to OSM.

Great, your first test.
Should be reverted? Thanks.

---
Detected by #SuspiciousOpenStreetMap
https://resultmaps.neis-one.org/osm-suspicious
Diacritic (2022-01-24 07:31:40+00:00): Hello again!

This is a really unique helipad! I think you've done a pretty good job tagging it here.

It's not 100% right to have a taxiway there, as helicopters seem to just hover over road itself, but I don't believe there is a better tag. We can always create a brand new tag for it; do you have any ideas or knowledge that could help?

Good work. :)
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/116517384
ahunterg95 (2022-01-24 09:42:44+00:00): Yeah it is incredibly unique, especially for Australia! 

I thought the taxiway might be a little overkill... Sometimes helicopters do hover-taxi along taxiways so I felt it appropriate for this location since it is basically a designated corridor between the two helipads.

I doubt it's necessary to create a hover-taxi tag since any taxiway can be used by a helicopter if it's safe to... I'm not an absolute expert though.
Diacritic (2022-01-25 04:17:29+00:00): Hey mate,

I've done some research and now know much more than I did previously about helicopter operations!

The markings on the east of Bentinck Street are a "aiming point": https://www.icao.int/APAC/Meetings/2016%20Annex14VII/ICAO%20Bangkok%204-2016%20Visual%20Aids.pdf

Helicopters don't set down there, but descend until they cross the road. I've altered the tags for the aiming point accordingly. :)

I've also added an additional tag to the taxiway: taxiway=air, to indicate that this is a "special" taxiway.

Let me know what you think. :)
ahunterg95 (2022-01-26 00:08:27+00:00): Perfect, that PDF is very interesting!

I think your adjustments to the tags are just right. A good compromise for a unique location!

Thanks for your input.
Diacritic (2022-01-24 07:06:45+00:00): Hello!

Thanks so much for your edits so far. I can see you're really busy in some areas of the state that don't tend to get a lot of attention!

I noticed you've created quite a few helipads in remote areas. The tagging system for helipads can be a bit unconventional, but some of these helipads look to be designated emergency landing sites. Rather than aeroway=helipad, I'd suggest emergency=landing_site is a more appropriate alternative. https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dlanding_site

Happy to help out further if needed; keep up the good work! :)
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/116517557
ahunterg95 (2022-01-24 09:36:56+00:00): Thanks for the tip Diacritic,

Yep, I love the more regional parts of Vic :)
I can probably amend one or two, however, a good portion of these seem to fit within the "Aeroway=Helipad" description... I certainly feel that this one in particular does; it caters to fire fighting helicopters during summer and is specifically built for helicopters.

I'm loving adding some of the missing locations into the map!
Diacritic (2022-01-24 10:52:08+00:00): No problem at all.

It's okay if you don't feel like this particular place is suitable for the emergency landing site tag; there is always some grey in the wiki. :) I appreciate you saying that some of the others can be retagged.

 OSM is addictive. :) If you are feeling social, I'd encourage you to join the talk-au mailing list. It's a cool group of people. https://lists.openstreetmap.org/listinfo/talk-au
5m4u9 (2022-02-08 00:03:14+00:00): hola, qué es tecnopreco? una empresa?
dadavid (2022-03-11 12:26:39+00:00): Hallo, 

bist du sicher, dass diese Verkehrsinsel Guglern-Kreisel heißt? 

Viele Grüße
David
WAM_SNZ144_ZCH (2022-03-11 12:30:21+00:00): Ja, eigentlich schon ! So ist es zumindest in unserer Datenbank hinterlegt.
WAM_SNZ144_ZCH (2022-03-11 12:44:54+00:00): https://de.wikipedia.org/wiki/Datei:Buttisholz-Gluggere-Kreisel.jpg
dadavid (2022-03-11 12:55:14+00:00): alles klar, dann würde ich vorschlagen, die Wege des Kreisels, also die Teile der Straße mit junction=roundabout mit einem official_name=Guglern-Kreisel zu versehen, denn die haben ja den Namen, nicht die Verkehrsinsel (traffic_calming=island) in der Mitte

Viele Grüße
Lee Carré (2022-01-24 23:50:49+00:00): Much smaller changeset areas, please: http://wiki.osm.org/wiki/Changeset#Geographical_size_of_changesets
richardhsmith (2022-01-25 00:04:13+00:00): Will do. I'm new to mapping and am working my way through my two main areas of local knowledge. Thanks for pointing me to the wiki.
Lee Carré (2022-01-25 00:40:27+00:00): Welcome to OSM, then. Thanks for your contributions.

StreetComplete is only for surveying (physically there, in person, at the time; hence source=survey). For changes from memory, please use an editor which allows you to specify the source, and set the value appropriately. I can suggest some, if you're unfamiliar.

For distinct areas, split changes into different changesets. This should avoid country-spanning bounding-boxes.
felipeeugenio (2022-01-31 22:55:04+00:00): Estimado, por favor no unir las casas con las calles
GITNE (2023-02-10 14:47:05+00:00): Please stop adding turn restrictions because apparently you do not understand how they work. You are adding garbage and thus burdening the OSM database and navigation apps unnecessarily.
snake21 (2023-02-11 02:51:04+00:00): Are you interested in explaining what I am doing incorrectly? let's make this a learning experience rather than an attack
GITNE (2023-02-11 11:50:43+00:00): It is not an attack but a mere observation and statement of fact, followed by a suggestion how you can stop bloating the database and harming others by breaking routing.

For example, you have added multiple, effectively identical and useless, turn restriction relations to many `NY 27` segments with just two members. Turn restriction relations require at least three members in the `from`, `via`, and `to` roles. A `via` member should be a (one) node but can also be mapped with multiple `via` member ways. `from` and `to` members must start or end at the `via` node. In other words, all members have to be connected. Additionally, you do not need to add `oneway=yes` ways to turn restrictions in the `to` role if traffic would flow in the `backward` direction of the way. Furthermore, do not add `restriction=only_*` restrictions unless absolutely necessary. Try to map with `restriction=no_*` restrictions first. And finally, even after you have managed to add three members to turn restriction relations you have fallen into the novice mapper pitfall: You created too many `restriction=no_u_turn` restrictions with identical ways in the `from` and `to` roles. These specific turn restriction relations do not add any value to the map nor to routing, nor do they represent in the OSM database what mappers think they are mapping. Most novice mappers start adding these when they feel or have the impression that their navigation app suggests a u-turn at the strangest places. Then they usually naively assume that there must be something wrong with the map, which in most cases is not. In these cases, usually the routing algorithm is broken. In short; routing algorithms should always calculate loops (or navigate to a `highway=turning_circle` or `highway=turning_loop`) instead of suggesting a u-turn whenever they *think* is necessary.

Long story short; please read about the basic concepts of relations first and then about more complex relation concepts, like turn restrictions on the OpenStreetMap Wiki before adding any new or modifying any existing turn restriction relations.
BCNorwich (2022-01-24 09:59:03+00:00): Hi, Welcome to OpenStreetMap.

OSM likes to be precise as possible. So I've moved your node from being attached to the highway to approximately the position of the premises, (as near as I can tell). I also removed the untagged highway and mapped the service road.

I can't find out the shop address or a current website so can't add any more detail. If you can give more info, address and position I could further improve the OSM data.

Regards Bernard.
eggie (2022-01-24 15:10:46+00:00): Je waterweg is niet gesloten.. Dus het zal niet als een vlak water renderen.
eggie (2022-01-26 14:07:41+00:00): Teek de waterweg heb ik gesloten.
Wetland verbangen door water. Gr eggie
eggie (2022-01-26 14:31:44+00:00): verbangen?? > typo vervangen  door water.
confusedbuffalo (2023-07-27 17:40:37+00:00): Thank you for adding the house numbers here, but note that it's best to use the address fields for house numbers, rather than the name field.
I'm fixing the houses here, but I'm not sure what to do with the sheds and garages (they don't really have an address or a name, but I see that we want to show how they are linked to the house.
Aikonhill (2023-07-27 23:50:45+00:00): I did this i think a year ago or more happy in my own little world. Took me I think 2 weeks to do the whole villiage. There was someone following me around undoing the shed thing a few days later so assumed they'd done this aswell. If I'd realized it hadn't I would of fixed it
Leo Slager (2022-01-24 12:03:08+00:00): Daar heb je helemaal gelijk in.
Maar die aanduiding is wel noodzakelijk voor de navigatie apps die anders het adres Hoefsmidstraat 39 niet bereiken.
ik pas wat aan.