Hi. Die source Tags dürftest du klarerweise wieder entfernen (sollte im JOSM mit einer entsprechenden Suche nach den Tags der Steine und deinem Usernamen kein großes Problem sein). Es sind ja "deine" erfassten Daten, die du selbst verbessern wolltest. Allerdings ist das jetzt auch wiederum nicht soo schlimm die stehen zu lassen. Falls man aber andere Verbesserungen vornehmen würde (z.B. das mit dem guidepost:type=stone – ist aber natürlich auch dir überlassen), könnte man den source Tag gleich mitlöschen.

Zu dem guidepost:type Vorschlag: Natürlich ist da relativ wenig Zusatzinformation was man nicht schon aus material=sandstone erraten kann. Für die Erstellung einer Karte wäre das Tag aber einfacher Nutzbar (da es potentiell sehr viele "material"s gäbe die auf einen Stein schließen lassen). Ich persönlich fände das Tag zusätzlich schon nützlich und es ist ja in anderen Gebieten auch schon im Einsatz. Aber wie gesagt: Am Ende ist es Geschmacksache, und es war ja nur eine Idee von mir das zu verwenden.

Hallo. Danke für den Link.

Ich denke man könnte fast sogar den kompletten Link zu den einzelnen Seiten der jeweiligen Steine als "website" taggen.

Zum Thema source-Tag: Die Überlegung ist hier, dass gerade wenn mehrere Leute das gleiche Objekt bearbeiten, die "Quelle" oft nicht mehr eindeutig ist, z.B. wenn später jemand die Position andhand eines Luftbilds "verbessert", stimmt das alleinige "source=survey" am Objekt gar nicht mehr. Über die Quellenangaben an den Changesets kann man mit Hilfe der History des Objektes alles "korrekt" nachvollziehen. Wobei du ja beides machst, also geht dieser Weg ja nicht verloren. Ich persönlich verwende das "source" Tags an einzelnen Map Features mittlerweile nur noch sehr selten (z.B. wenn etwas sich mit dem gerade "aktuellen" Luftbild widerspricht).

Zum dem guidepost:type tag. Wenn es ein genau definiertes Tag gäbe, würde ich das natürlich auch bevorzugen. Aber solange das (noch) nicht der Fall ist, wäre es noch eine Alternative dazu diese Information gar nicht zu taggen. Das "guidepost" tag selbst würde ich auch eher nicht dafür nehmen, da es offenbar für verschiedenste andere Informationen schon in Verwendung ist. PS: Das Tagging-Modell von OSM ist ja eigentlich schon so konzipiert, dass man gerade den Freiraum hat neue Tags erstmal ganz informell zu nutzen, um deren Nützlichkeit aufzuzeigen. Meist ist die Formalisierung ein erst darauf folgender Schritt. ;) Mehr dazu im Wiki: osm.wiki/Any_tags_you_like

Gruß!

Hi. Tolles Mapping-Projekt mit dem Wegweisersteinen. :)

Erlaube mir ein paar Nachfragen:

Wie kann man die "ref" Nummern der einzelnen Steine herausfinden? Diese sind ja nicht auf den Steinen selbst zu sehen?!

Was hältst du davon zusätzlich auch "guidepost:type=stone" zu taggen? Dann wird es in den Daten klarer, dass es sich nicht um herkömmliche Schilder handelt. Das Tag gibt es bereits ein paar mal: https://taginfo.openstreetmap.org/tags/guidepost%3Atype=stone#overview (momentag hauptsächlich im Siebengebirge verwendet).

Ist mit source=knowledge gemeint, dass du diese persönlich vor Ort verifiziert hast? Das ist ja eine riesen Leistung, Respekt! Ich hätte nur gesagt, es würde reichen wenn diese Information am Changeset steht, und sie nicht nochmal an den einzelnen Objekte wiederholt werden müsste (siehe osm.wiki/Key:source?uselang=en-GB#Historic_usage_on_objects_and_attributes). Außerdem wäre vielleicht "source=survey" passender dafür?

Gruß, Martin

Hoppala. Ich wollte das eigentlich als `disused:highway=track` taggen, damit klar ist, dass der Weg vor kurzem noch ein "Track" war. Danke für den Hinweis!

Hey. Developer here. I'd be really interested in finding out what steps you did which caused these duplicate buildings to be uploaded. Thanks for your help in advance!

This user is was most likely a vandal/spammer trying to game the osmbtc.org "benefit system" :(

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