Yeah, it's definitely not super clear cut. I would have gone with the definition osm.wiki/IT:CAI#Percorsi_escursionistici, which uses the following description for `rwn`: _itinerari di lunga percorrenza che attraversano più province e/o mettono in collegamento più percorsi ordinari._ I think the 500 trail fits all these requirements.

Yes, there is not really a network of such "medium distance" trails in Italy, but I don't think it should be an argument against using the tag value, as these routes still connect to local and national routes in many places. IMHO `rwn` could provide a good distinction between short "single day" and longer "multi day" routes (that aren't quite of the caliber of the super-long distance routes of say, the SI or E5 for example).

I hiked the 133 (Sentiero Aldo Bonacossa) last summer. I wasn't so sure how to tag that one: It definitely is a multi-day route, but the paths are in parts really narrow (in some sections even pathless) and the route is in large parts only rarely traveled. But given that the route is quite prominently signposted at the start/endpoints, I'd now tend towards also tagging it as a `rwn`. Similarly, the same applies also to the few longer routes of the AVS like the nearby osm.org/relation/5487056. PS: Another nearby hiking route of similar distance which already has rwn is osm.org/relation/11009657

Hey. I'm wondering why you downgraded the network tag from "rwn" to "lwn" of the 500 trail. In my view, this route is more important than your regular local hike, and does fit the definition for "rwn" quite well.

probably! they are not really flowers, though. so I guess man_made=planer fits best.

PS: btw, the mentioned oversight was also my own mistake of not catching the issue in the preset when it was added to iD in the first place. I'd apologize for that! In addition to cleaning up behind my own mess here, I've also [implemented a check](https://github.com/ideditor/schema-builder/blob/main/CHANGELOG.md#530) to make sure that such mistakes do not happen anymore in the future.

Hey!

I'm sorry for the inconvenience, but there is just no "optimal" approach in such cases: on the one hand, I agree that one should avoid unnecessary global changesets, but in this case I wanted to group these changes together in a single changeset, because they do actually belong together: they all fix the same issue caused by an oversight in iD's tagging presets.

I hope you can understand my reasoning.

Happy mapping!

@Audrey101: I'm the developer of the software you used in this map edit (the so called "iD editor"). I believe your change of the "Bahamas" border was not intentional. In order to prevent similar accidents in the future, it would help me a lot if you give us some details of how you started your edit session. I know it has been a few days, but every detail you remember might be important to track the issue down.

For example: Did you use the "Search features" utility, especially the "Search worldwide..." option? Did you maybe click on the "Feature Type" of the "Administrative Boundary" to select a feature type for it? Etc.

Your help would be very much appreciated!

Hey. Yeah… I was wondering the same to be honest, but ended up just mapping the routes from the timetable because it seemed like the "easiest" solution. At first, I thought about splitting it at NOI (as some buses do actually end there), but that would leave the false impression that one would need to make a transfer for some direct connections (like CityClinic -> Kaltern). Making the route a roundtrip would mostly work, having only the small downside that it doesn't allow to properly map the origin/destination (from/to) of the individual buses… But maybe that's not super important, is it?!

Habe jetzt den Verlauf an dieser Stelle (von ca. Plosescharte bis Lüsner Scharte) korrigiert. Die Grenze scheint aber auch darüber hinaus etwas ungenau zu sein. Möglicherweise ist das "Problem" auch nicht nur auf Brixen beschränkt. Man könnte sich vielleicht einmal Gedanken machen die Gemeindegrenzen in ST systematisch zu kontrollieren und ggf. anzupassen.

source: https://geokatalog.buergernetz.bz.it/

Ja das mit "Version 1" bei "nicht wirklich neuen" Ways ist ein Artefakt, wenn man in einem Changeset einen Weg teilt: dann behält einer der Teile die alte Id (mit Version > 1) und der rest eine neue (mit Version 1).

Ich denke mal diese Gebäude hat hier schlicht einfach noch niemand genau gemappt.

Ok, ich frage mal bei der Gemeinde nach und korrigiere den Verlauf bei Bedarf.

Hallo. Du meinst den Verlauf der Gemeindegrenze bei osm.org/way/787613793, oder? Dieser stammt ursprünglich von diesen changesets: osm.org/changeset/558435 und
osm.org/changeset/10631672. Es scheint als wäre ursprünglich zum Eintragen der Gemeindegrenze als Quelle der Datensatz von ISTAT verwendet worden (https://www.istat.it/it/archivio/222527, oder ein davon abgeleiteter Datensatz). Mit 100%iger Gewissheit kann ich es nicht sagen, aber ich würde vermuten dass der Verlauf im https://maps.civis.bz.it/ korrekt sein könnte. Um ganz sicher zu gehen könnte man z.B. bei Gemeinde Brixen nachhaken, https://www.brixen.it/de/amt/servicestelle-fuer-bau--und-landschaftsangelegenheiten_78 wäre wahrscheinlich ein möglicher Ansprechspunkt.

Hey. I have noticed that the mopdifications in this changeset have resulted in a small "spike" of the boundary of Russia at the following nodes: osm.org/node/7770263964, osm.org/node/7770298536 and osm.org/node/266012296. Was this intentional?

Also, the boundary of Estonia doesn't match the indicated source anymore: compare https://www.riigiteataja.ee/aktilisa/0000/0002/4407/Lisa%202.pdf with osm.org/node/266012308/history for example.

PS: Do you have a link to a digital copy of the source you used in this changeset?

honestly, it was quite hard to do with JOSM as well: a) it requires a detailed knowledge of the "multipolygon" data structure, and b) rearranging the multipolygon relation members is a tedious process with such large polygons, especially at the locations where inner members become outer borders of the result(s).

It would be really nice to have a proper tool which allows to automatically split any polygon in OSM with ease. Ssomething like what [JOSM's utilsplugin2 Alt+X](osm.wiki/JOSM/Plugins/utilsplugin2#Split_area_.28Alt.2BX.29), but also works for multipolygons would be my dream ^^.

yeah, this one really should be split into significantly smaller chunks. For a start, I shaved this part off: osm.org/relation/13607045

also osm.org/changeset/104133394

Hi! Die Hausnummer stehen so an den Eingängen der Gebäude. Bzgl building=terrace solltest du dich besser an den Mapper wenden der das ursprünglich so gekappt hatte. ;-)

Merci! Then it looks like it's properly mapped now, except for the additional information (benches, tactile paving, etc.) of course. Happy mapping!

Hey Fox! Just wanted to let you know that you (accidentally) deleted a part of the B83 here. I have undone the changes to restore the road in osm.org/changeset/112365517.

Could you double-check that the bus stop is now properly placed at the following locations: osm.org/node/331613474 and osm.org/node/420866420. Or is that still not fully correct?

:)

Hey,

ich glaube du hast hier einige kurze Stücke der B252 übersehen (bei osm.org/way/360065178) wo noch "highway=construction" oder "access:conditional" gesetzt war. Das habe ich jetzt mit osm.org/changeset/108034564 korrigiert. Vielleicht kannst du nochmal drüber schauen ob jetzt alles passt?

Gruß, Martin