piebro/osm-data huggingface dataset:
e_w_c (2026-04-21 15:04:43+00:00): Dat fietsen hier verboden zou zijn, is onjuist. Fietsen (zonder motor) is volgens de huisregels in het hele Amsterdamse Bos toegestaan op paden (maar voetgangers hebben voorrang). Er zijn op de kaarten van het park en in de uitvoering wel paden aangewezen als fietspad. Hier staan ook routebordjes van de fietsroutes, en er wordt veel gefietst. Om een of andere reden staan er na de herinrichting nu  soms bordjes voetgangerszone zonder de teksttoevoeging 'fietsen toegestaan' (elders in het park staan die borden wel nog). Zoals het nu gewijzigd is, is verder correct (geen fietsverbod getagged), maar het komt de leesbaarheid niet ten goede want er eindigt nu een aantal fietspaden in het niets. Ik heb geen oplossing dus ik laat het nu maar zo.
meeuw (2026-04-25 05:53:10+00:00): Helemaal mee eens @e_w_c ik heb een melding gemaakt via meldingenamsterdamsebos.amsterdam.nl (SIG-3151796) met de vraag of onderborden geplaatst kunnen worden of dat ze kunnen aangeven hoe de fietsroutes nu lopen.
felipeeugenio (2026-03-03 20:50:57+00:00): Hola. El nombre del puente va en bridge_name=

Además, no creo que sea un viaducto esto. Yo lo corrijo. Saludos y gracias
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/179207272
felipeeugenio (2026-03-03 20:51:55+00:00): veo que ya lo había corregido otro mapero. Saludos
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/179207272
Andrea Musuruane (2026-03-02 15:31:11+00:00): Ciao. In questo caso si usa operator e non name. Ciao, Andrea
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/179207332
NeisBot (2026-03-01 13:06:40+00:00): Welcome, and thanks for your edits!

I noticed a few unintended crossings between roads and/or between roads and buildings in this changeset. This usually happens when geometry snaps incorrectly. Additionally, changes to tagging (e.g. modifying highway types or adding tags) can lead to unexpected crossings being detected afterwards.

In total, I detected 22 potential crossings.

⚠️️ Problematic elements (top 3):
https://osm.org/way/1081689475 v3 | 7 crossings
https://osm.org/way/810403153 v9 | 7 crossings
https://osm.org/way/1067219981 v3 | 8 crossings

⚠️ Dragged Nodes (max 3):
https://osm.org/node/5940504010 v4

Would you mind revisiting those areas?

#CrossingCheck
---
https://resultmaps.neis-one.org/osm-change-viz?c=179207468
NeisReview (2026-03-09 17:33:06+00:00): ✅ Should be fixed by 
https://osm.org/changeset/179216604
https://osm.org/changeset/179528180
Andrea Musuruane (2026-03-02 15:30:11+00:00): Ciao. In genere le fontanelle non hanno un nome. Ciao, Andrea
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/179207573
rempshaener (2026-03-01 18:21:05+00:00): Hallo,
ich habe zwei Anmerkungen zu diesem Beitrag:
- bridge=yes an man_made=bridge ist nicht so richtig passend bzw. redundant.
- Wikipedia ist meines Wissens keine zulässige Quelle für OSM.
Viele Grüße
Waldamsel (2026-03-01 19:11:18+00:00): Der ID-Editor fragt bei man_made=bridge auch den Schlüssel 'bridge' ab. 'yes' scheint mir sinnvoll zu sein, wenn keine andere Auswahl paßt. Redundant mag sein, aber es stört oder beeinflußt meiner Ansicht nach keine anderen Aussagen.
rempshaener (2026-03-01 19:21:48+00:00): Hallo,
das Wiki ist an dieser Stelle eindeutig, https://wiki.openstreetmap.org/wiki/DE:Key:bridge: „Im Zusammenhang mit dem Tag man_made= kann der Key bridge=*, um den Brückentyp anzugeben, auch an Flächen verwendet werden.“
Das bridge=yes ist daher überflüssig.
Passe es doch bitte im Rahmen der übrigen Anpassungen (Quelle) an.
Viele Grüße
mos_next_door (2026-03-05 19:30:29+00:00): Hi Cyprusoossmm, please provide meaningful comments to your changesets instead of reusing 'buildings'. Thanks!
Kees 59 (2026-03-16 14:00:37+00:00): Looks like something went wrong with the lit tag on way 556229126
DerSchmopf (2026-03-16 17:27:23+00:00): Thanks for letting me know, it's fixed now.
giggls (2026-03-02 09:26:56+00:00): Moin,

hast Du eine Referenz zu diesem ominösen Zeltplatz? Unter https://www.kulturcarre.de finde ich da nix.
Copymaster86 (2026-03-02 11:14:48+00:00): Hallo,
Ich habe die Internetadresse von der dort vorgefundenen Infotafel. Tatsächlich gibt es dort folgende Info: https://www.kulturcarre.de/eisenach/veranstalter/wildniscamp-das-eichhornchen

Wahrscheinlich haben die mittlerweile eine eigene Internetseite, die vielleicht besser für den osm-Eintrag geeignet ist?: https://wildniscamp-eisenach.de/
giggls (2026-03-02 12:09:19+00:00): OK, dann klebe mal stattdessen diese Webseite dran.
Das ist aber dann wohl eher kein Campingplatz deshalb ist tourism=camp_site nicht geeignet.

Meines Erachtens wäre amenity=events_venue
passender.

Gruss

Sven
Copymaster86 (2026-03-02 12:18:47+00:00): Ah Danke, Ich ändere es :)
Ltrlg (2026-03-02 10:18:28+00:00): Ces noms sont déjà présents sur les landuse=residential autour, aucune nécessité de les dupliquer.
Sébastien Chopin (2026-03-03 15:01:24+00:00): En effet. Je ne voyais pas cette info sur le terrain via Streetcomplete.
Ltrlg (2026-03-02 10:38:19+00:00): « ball » ?
Sébastien Chopin (2026-03-03 15:05:03+00:00): Problème de doigts crochus.
Corrigé : ball->hall
democat (2026-03-02 04:51:16+00:00): Why do you follow the right edge of the lane instead of the actual centerline? There are also weird kinks in the entrance/exit ramps to/from the service road. Also, you are being particularly passive-aggressive with these changeset comments, despite not putting your own comment on the original changeset that made these geometry changes.
selillium (2026-03-02 08:14:08+00:00): I’ve replied to the affected changesets. Sorry about the passive-aggressiveness: it was a particularly aggravating night for other reasons, and I let that bleed over here.

I’ve explained my thought process about how these ways are placed at this [changeset](https://www.openstreetmap.org/changeset/179212994#c1562475). I’ll reiterate that, in general, I have two goals:

1. preserve the road curvature with respect to GPS traces; and
2. avoid or minimize ways with placement=transition .

For the on-ramps leading to the junction, I aligned the ways to the right shoulder to minimize the transition way. This also gives me a defined line to trace the way without resorting to strange JOSM hacks. Thus, their position is still following parallel to GPS traces within a margin of error, and the curvature is (hopefully) improved. Renderers can correct for the centerline by ingesting the lane placement and lane widths. Routers already have adjustable margins of error for determining positions on-way.

The kinks you mention from the service roads to the on-ramps are a compromise between minimizing the transition way and keeping lane details. Ideally, I would follow the ramp’s shoulder marking to the junction point and extrude the end to meet the service road, but then the ramp would be unnecessarily long. In this case then, I chose to trace a way 30° about the service road to where the shoulder marking splits from the service road to the ramp. Major map services (I’ve checked GMaps, Bing) seem to also make this compromise.

The strange geometry at the on-ramp to US 75 N at Ozark Dr is an actual faff on my part. I’ll fix that.
olo81 (2026-03-04 20:06:24+00:00): nazwy opisowe do poprawy 
https://wiki.openstreetmap.org/wiki/Pl:Nazwy
george1201 (2026-03-01 18:59:27+00:00): Hallo moritz2k. Willkommen bei OSM. Ich habe eine Anmerkung zu deiner Änderung. Du hast den Weg https://www.openstreetmap.org/way/1229621168 in eine Treppe umgewandelt. Kann das richtig sein? Luftbilder lassen etwas anderes vermuten. Danach beginnt die Treppe erst bei Weg https://www.openstreetmap.org/way/995516688.
moritz2k (2026-03-01 22:03:21+00:00): Hallo george1201, du hast recht, ich habe nicht genau hingeschaut. War mein erster Einsatz mit StreetComplete, werde ich Zukunft besser darauf achten.
Wie kann ich das rückgängig machen?
george1201 (2026-03-01 22:06:21+00:00): Wie hast du aus dem Weg eine Treppe gemacht? Umgekehrt müsste es ja ähnlich gehen.
moritz2k (2026-03-01 22:17:14+00:00): Habe es korrigiert in https://www.openstreetmap.org/changeset/179229239
george1201 (2026-03-02 12:24:12+00:00): Sieht gut aus. Jetzt mit genauer Oberfläche und Beleuchtungszustand. Danke.
NeisBot (2026-03-01 14:54:39+00:00): Welcome, and thanks for your edits!

I noticed a few unintended crossings between roads and/or between roads and buildings in this changeset. This usually happens when geometry snaps incorrectly. Additionally, changes to tagging (e.g. modifying highway types or adding tags) can lead to unexpected crossings being detected afterwards.

In total, I detected 12 potential crossings.

⚠️️ Problematic elements (top 3):
https://osm.org/way/534626272 v4 | 6 crossings
https://osm.org/way/666330459 v2 | 6 crossings

Would you mind revisiting those areas?

#CrossingCheck
---
https://resultmaps.neis-one.org/osm-change-viz?c=179212157
NeisReview (2026-03-09 17:33:07+00:00): ✅ Should be fixed by 
https://osm.org/changeset/179223773
letsridebikes (2026-03-02 00:17:17+00:00): hello, is there a reason why you reverted my changes tagging these paths as shared-use cycleways? I've commuted through here for the last six months and the "official" towpath is chained shut due to frequent river flooding, so all these paths are used by the vast majority of cyclists heading under the footbridge. Thanks!
letsridebikes (2026-03-02 00:20:03+00:00): You also removed the flood_prone tag from the lowest sections of the towpath, which has been frequent this winter whenever river levels rise slightly above average. This is clear from the amount of silt and mud on top of the path
DFW-Backyard7 (2026-03-02 05:40:15+00:00): Hi- I realize I forgot to update the placement tag here, but can you explain why you intend for the way to be aligned to the shoulder instead of the centerline? It's not clear to me as that isn't where traffic generally flows.
selillium (2026-03-02 07:19:49+00:00): My thoughts on this are, generally, that road curvature takes higher precedence than exactly matching the GPS trace. My understanding of the placement proposal, the goal of the key is to allow way geometries to do this. The proposal also recommends avoiding the `placement=transition` tag wherever possible.

When splitting from a Y-junction, I’ll aim to preserve the lane positions of a given car on outlet ways relative to the inlet way. For example, in a 3 lane cleanly splitting into a 2–1 split from offset `left_of:3` or `right_of:2`, a car in lane 2 of the outlet way exiting the junction to the major outlet should ideally stay in lane 2 of said outlet. In this example, I would use `right_of:2` and `left_of:1` on the left and right outlet ways, respectively. I apply this principle when merging Y-junctions.

I’ll also try to give precedence to the curvature of the perceived major outlet, if applicable.

To decide the general lane placement, I manually follow the road along aerial imagery against traffic flow to what I would consider an ideal origin: for example, on highways, this is typically when it becomes a 2 or 4 lane divided road. I then manually trace from that centerline to where I need a accurate lane placement. Sometimes this fails for a given origin and I have to choose a different one upstream; usually, this is at merge points on major throughfares. 

In this scenario, with a 1–2 split with the given downstream placement, I made these assumptions:

1. from personal experience driving here and by signage: the left is the minor outlet (that bypasses to the US 75) and the right, the major outlet;
2. the placement of the inlet way (`left_of:2`) is dominant for significant mileage downstream; and
3. this placement allows for a clean split at the junction point without adding unnecessary `placement=transition` segments.

Considering all this, I decided to place these ways along their respective shoulders with the ideal lane placements. I placed the major right outlet first, then the minor left. Since the right way has curvature precendece, I avoided modifying its curvature when placing the left. I also checked to ensure that the ways were following parallel to OSM GPS traces within an eye-balled margin of error. As of writing, when I pull up traces and OSM data on the site, this is the case.

For the merge point upstream, I decided to maintain the lane placement downstream from the initial Y-junction.
selillium (2026-03-02 08:17:59+00:00): Also, apologies for the passive-aggressiveness: it was a bad night for me. I mean no ill-will.
DFW-Backyard7 (2026-03-03 05:57:42+00:00): My thoughts are that the ways are supposed to be aligned to the center of the real-world object (the road) and the `placement` tag used to specify situations in which this is deviated from for some reason, in order to help renderers display positions properly. It would seem to me that your method is the opposite (i.e. mapping based on the curvature of traffic flow and then using tags to specify the real location). I looked through Proposal:Placement, and it doesn't seem to suggest to me that transition ways should be avoided at all cost; it suggests that they are to only be used when necessary, and goes on to list motorway junctions as situations in which they are inherently necessary, simply because the width of the road changes there. I take it to mean that situations in which they are not necessary would be like, moving the way across the middle of the highway for no reason. While I should have been more careful to place transition tags on all such segments, I don't really agree that drawing ways that strongly deviate from the real-world center of the object in order to avoid them on the exact thing they're intended for is a good idea... If nothing else, it seems to strongly deviate enough from how I've seen everything else mapped everywhere.
DFW-Backyard7 (2026-03-03 06:04:06+00:00): I guess another way to put it is, my understanding is that the usage of the placement tag is discouraged by proxy because its existence on a way implies that the way is not drawn in the center of the road (and not drawing a way in the center of the center is discouraged unless inherently necessary to represent it). Therefore, avoiding the tag by drawing even more ways that aren't in the center of the road just to not use the tag itself feels incorrect to me.
selillium (2026-03-03 06:54:51+00:00): I think there’s a compromise between mapping to a perceived centerline from aerial imagery/traces and a virtual centerline that produces a useful abstraction. Blindly gluing the way to the perceived centerline would give results like [this][1], introducing unnecessary curvature where IRL there is none. If I had just corrected the placement tags, the geometry here would still contain at least 4 unnecessary deviations—4 instances where I would have to partition transition ways—from actual road curvature at the junction and merge points that suggest to a data consumer an unpredictably different reality to what’s present. In this case, this is avoidable by placing the split and merge as I have; in most cases, this is not, esp. with highway ramps as you’ve mentioned.

Since OSM is necessarily a simplification of reality, I would expect compromises between this abstraction of reality and reality itself. Ways are inherently imprecise: we’re still using 2D lines to represent the 3D carriage way area. Even if I wanted to, area:highway is dead: cursed to wander proposal purgatory for the better part of 10 years now, relegated to mere router set dressing. And areas are *still* second-class objects for some asinine reason. If OSM had a functional area routing model, we wouldn’t be having this discussion in the first place since a router would inherently deduce lane placement itself. POI locations are often both inaccurate and imprecise: sometimes the POI is the entire building its contained in, causing routers to blindly route to the ways closest to it—even if it happens to be some back alley or loading dock. Sometimes the POI is just a point placed at the mapper’s discretion: would that point be actual location? Is it the center of the entire space the actual POI occupies? Something else? For these ambiguities, and whatever others I’ve not mentioned, I would prioritze predictability and useability over precise location.

Even so, data consumers must account for all these inherent ambiguities of the OSM abstraction. For ways, as I previously wrote, this includes 

- ingesting the placement tag to correctly render ways;[^3] and
- resolving the mismatch between the user GPS and the virtual way’s positions, typically with some route recaculation threshold.

Also, in the [table][2] enumerating values for placement, the field for transition states that: “This value should be avoided whenever possible and is usually only necessary if the road forks or joins with another one.” I don’t see any other way of interpreting this other than avoiding tracing ways with the tag.

[1]: https://wiki.openstreetmap.org/wiki/Proposal:Placement#Motorway_exit_2
[2]: https://wiki.openstreetmap.org/wiki/Proposal:Placement#Tagging
[3]: Though there is still no widespread support for rendering with it…
selillium (2026-03-03 07:12:49+00:00): Commercial maps appear to prioritze road curvature over centering as well. However, they choose a centerline for the inlet way that, if copied into OSM, introduces avoidable placement=transition ways.

[Google Maps][1] selects the left outlet from the split as the bypass, branching off with what we’d consider a transition way. The right outlet maintains the centerline from the inlet. However, they mangle the centerline at the merge point upstream, shifting it one lane leftwards. An OSM equivalent would have 3 transition ways: 1 for the minor outlet at the split, and 2 for the inlets at the merge point.

[Bing Maps][2] does an arguably worse job: the decision point has been unnecessarily pushed back, and the centerline transitions from the middle lane of the inlet to the right lane of the major outlet. However, it still prioritizes curvature: the left outlet is the bypass again and branches the same, but at a slighter angle than GMaps. At the merge, it preserves the curvature of the major inlet: the bypass merges with another branch. The lane placement transitions from the right lane of the major inlet back to the middle lane of the outlet. This configuration in OSM is objectively worse: it requires about 5 or so transition ways(?).[^3]

The current configuration in OSM is (probably) optimal for avoiding transition ways. I’m not sure if there’s some other selection of centerline for the inlet way at the split that would yield better results.

[1]: https://www.google.com/maps/@33.0639548,-96.6905261,205m/
[2]: https://www.bing.com/maps?cp=33.063694%7E-96.690596&lvl=19.1&style=h
[3]: Eyeballing it, though it probably more.
selillium (2026-03-03 07:30:42+00:00): To address traffic flow relative the centerline: my understanding is that a driver offset some lane count from the centerline of a way should, when the way splits, maintain that offset relative to the outlets. Using the sample 2–1 Y-junction I mentioned in my first reply: a driver in lane 1 or 2 of the inlet should be in lane 1 or 2 of the major outlet, respectively. Similarly, a driver in lane 3 of the inlet should be in lane 1 of the minor outlet.

However, this offset should also consider lane positioning offset left, center, or right of the chosen lane (i.e., as defined by the placement tag). So if a driver is travelling along the left_of:2 line of the inlet should exit the split along the left_of:2 line of the major outlet. Similarly, a driver along the right_of:3 line should exit the split along the right_of:1 line of the minor outlet. Avoiding transition ways would allow routers to use this heuristic; using transition ways introduces intractable ambiguity.
czebureks (2026-06-01 21:06:27+00:00): Cześć, dzięki za poprawki mapy w okolicach kampusu PG. Czy aby na pewno teren, na którym znajduje się biuro Wirtualnej Polski, również należy do Politechniki?
Vlctm (2026-06-02 04:57:37+00:00): Wydaje mi się że należy. Studenci mają tam zajęcia, biura WP już raczej tam nie ma, ale na politechnice nazywają ten budynek WP/Wirtualna Polska, dlatego dałem mu taką nazwę.
eggie (2026-03-01 17:26:46+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privebericht.
MVG,
Eggie
Namens de OSM Community
Wildsharky (2026-03-03 12:03:17+00:00): Fully Reverted: Reverted in changeset id:179281880
Wildsharky (2026-03-05 06:26:16+00:00): Partially reverted in changeset id:179287244
007Transformer (2026-03-02 08:53:56+00:00): Reverted in changeset id: 179242963
Roel G (2026-06-23 20:07:00+00:00): Beste ZldYe,

als gebruiker van OSM en inwoner van Doorn viel mijn oog op de prominente vermelding van 'Militair oefenterrein Doorn-Driebergen', met een groot rood label en markering in op de map. . Voor argeloze  gebruikers van de standaard OSM kaart ziet dit eruit als een ontoegankelijk gebied. Inmiddels ruim 30 jaar in Doorn wonend weet ik dat hier absoluut geen enkele militaire activiteit (meer) plaatsvindt. Feitelijk bestaat dit oefenterrein al sinds de jaren 80 niet meer: mariniers uit de kazerne in Doorn rijden met hun materieel naar de Leusderheide, en oefenen aldaar.

Het (natuur)gebied is eigendom van Utrechts Landschap en landgoed De Treek - Henschoten. Het is vrij toegankelijk en defensie heeft er geen speciale rol meer.

Vier jaar geleden heb jij aangegeven dat dit militaire gebied gehandhaafd moet worden. Wat was daarvoor jouw motivatie? En als die niet (meer) geldig is, zou je dan dit gebied en markering alsnog kunnen verwijderen?  

Alvast bedankt!

Groet,
Roel
ZldYe (2026-06-23 20:54:24+00:00): Beste Roel,

Bedankt voor uw melding. Voor het grootste deel van de Nederlandse oefengebieden geldt dat ze vrij toegankelijk zijn, mits er geen oefeningen worden verstoord. Daarom zijn alle paden op de kaart toegankelijk en routeerbaar. 

Daarnaast is het zo dat het gebied in alle recente onderzoeken / rapportages etc van defensie, gemeenten en provincie nog altijd wordt gehandhaafd als militair oefengebied. Ook al gebeurt er in de praktijk niets. Dit geldt wederom voor meerdere terreinen in Nederland, dus ook hier. 

Indien u graag een kaart wil zonder aanduiding van de militaire oefengebieden, kunt u in het kaartlagen-menu kiezen voor een andere laag.

Als u nog vragen heeft horen we het graag!

Met vriendelijke groet,
Roel G (2026-06-23 21:22:01+00:00): Dit is geen defensie terrein. Ik vraag mij af waar defensie dit gebied (nog?) aanduidt als oefenterrein? Op de defensie website kan ik hier niets over vinden.
ZldYe (2026-06-23 21:30:28+00:00): De officiële kaart staat hier:
https://wetten.overheid.nl/afbeelding?toestandid=BWBR0031018/2020-12-01_0&naam=249740.png&schalen=nee
Ook wordt het terrein genoemd in het NPRD en recente visies van provincie Utrecht. Het is dus wel degelijk defensieterrein, ondanks dat het niet gebruikt wordt.
Roel G (2026-06-23 21:45:41+00:00): Mij is de context van de kaart onder vermelde link niet duidelijk. Wellicht gedateerd? Als ik kijk ik NPRD ( https://www.defensie.nl/site/binaries/site-content/collections/documents/2025/05/23/ontwerp-nationaal-programma-ruimte-voor-defensie/20250523_Ontwerp+Nationaal+Programma+Ruimte+voor+Defensie.pdf ) vind ik alleen iets over Apeldoorn, maar niets over Doorn.
Roel G (2026-06-23 21:48:48+00:00): NB ook Driebergen en Moersbergen komen niet voor in NPRD...
ZldYe (2026-06-23 22:02:59+00:00): Ik zie verder inderdaad dat het oefenterrein steeds afvalt voor nieuwe functies wanneer het genoemd wordt. Het terrein is wel nog officiëel aangeduid als zijnde oefengebied, maar er staan geen bordjes die bij andere (niet gebruikte) oefenterreinen wel staan. Het is dus alleen op papier nog oefenterrein, en daarom niet nuttig voor de kaart. Daarom zal ik dit terrein verbergen van de kaart, als zijnde buiten gebruik. Hiermee wordt het niet meer zichtbaar voor gebruikers. 
Bedankt!
Roel G (2026-06-23 22:06:20+00:00): Mooi, bedankt!
rempshaener (2026-03-01 18:04:43+00:00): Hallo,
darf ich fragen, warum deine einzige Änderung im Umdrehen der Richtung besteht?
Viele Grüße