quoting/correcting myself:

> There is semantic/programmatic/visual/... connection from a url=* tag to the name=* tag

Obviously, I meant to write that there is NO direct connection from a url=* tag to the name=* tag on the same object.

> I added the URLs to provide verifyability for how this exclave is named.

In my opinion, there really is no way to identify this rationale behind your tagging approach. There is semantic/programmatic/visual/... connection from a url=* tag to the name=* tag. This way, it could just as well be understood as a source for the place=region tag. Or as an attempt to advertise certain websites/offers/companies. Which is why I suggest you change it to the widely-used name:source=* tag: source:name=*. And, in my opinion, one (legitimate) source should be enough, you don't have to add source:name:2=*, source:name:3=* etc.

Regardless of the question of choosing a key-value-pair for adding sources to OSM objects:

> They [municipalities' websites] provide long-term, checkable references.

Especially the part about long-term is just not true, considering the phenomenon of link rot.

> I doubt there is another feature that could have this old_name.

That's not the issue here, in my opinion.

> It's possible that other websites (like the ones you mention) handle this differently or have a historic focus

Well, of course websites have different angles. But as soon as you added different websites to this OSM element, you merged those perspectives together, making a statement that they describe the same thing, namely relation/20694323, the region "Appenzellerland". Which is not the canton that existed from 1513 to 1597, but you still refer to the HLS/DHS article about that entity.

Which is why it does not always make sense to blindly link to websites that describe an entity with the same name (and, in this case, similar geographical extent) as an entity in OSM, like here. The (German) wikipedia article for "Appenzellerland" (https://de.wikipedia.org/wiki/Appenzellerland) makes the same point: Appenzellerland, as in this relation, is a geographical term, describing a region, but for referring to the (historic!) political/administrative entity that overlaps geographically, "Kanton Appenzell" is used instead.

Sure, nitpicking, but which better place for nitpicking than OSM.

Hi there, is there any rationale by which you determine which websites to include in these relations of yours? It seems rather arbitrary* to me – why did you tag a local newspaper website? I really do not see why this is relevant for OSM. Another angle of the same question: Why did you choose to add not only one, but *two* tags linking to websites relating to fire brigades/Katastrophenschutz, and not, for example, the local bus timetables? Why did you add the local newspaper website to this relation but not, e.g., add https://www.thurgauerzeitung.ch/ostschweiz/toggenburg to relation/1687206 ? I'm not saying you should do it, just trying to understand the benefits of this tagging for Buchberg/Rüdlingen in the first place.

And, looking past the question of whether this approach makes sense at all, I'd like to point out that the website you added here via url2 literally points to the the website you added via url1. Put bluntly: At this point, is this anything but spamming the database?

I'd also like to point to the phenomenon of link rot: https://en.wikipedia.org/wiki/Link_rot – while the URLs seem to work today, it is not unlikely that e.g. the newspaper or the fire brigade will update their website and then we'll have rotten links not going anywhere, which results in maintenance overhead that outweighs the benefits (are there any?) of adding a bunch of url:*= tags.

And, last but not least, if you still think adding these websites as tags is a good and worthwile thing to do, I'd point you to the OSM wiki page for the url tag: osm.wiki/FR:Key:url, recommending using more specific tags for websites instead of just enumerating url<n>= keys.

Best regards
Moritz

* and unnecessary, in my opinion

see changeset/184094086

changeset/184473273

Hoi Raphael, ich vermute, dass du hier Änderungen für eine spezifische Veranstaltung (European Quadball Cup) gemacht hast, durch die die Anlage zwischenzeitlich verwendet wird? https://www.quidditcheurope.org/european-quadball-cup-2026-division-2

Es sieht so aus, als hättest du temporäre Einrichtungen bzw. Bezeichnungen eingefügt und die regulären Spielfelder gelöscht. Ich gehe nicht davon aus, dass für diese Veranstaltung tatsächlich die ganze Anlage physisch umgebaut wurde, oder?

Vermutlich unabsichtlich hast du die OpenStreetMap-Datenbank direkt bearbeitet, sodass die eigentlich 'korrekte' Kartierung der Anlage gelöscht wurde. Daher sollten diese Änderungen, aus meiner Perspektive, wieder rückgängig gemacht werden. Kurzzeitige Veranstaltungen und dazugehörige Nutzungen werden nicht in OSM direkt kartiert. Dafür kannst du mit der passenden Software, wie z.B. Grafikprogrammen oder GIS-Software, lokal selbst Karten erstellen, ohne die globale OSM-Datenbank zu verändern. Eine einfach zu nutzende online-Alternative wäre z.B. https://umap.openstreetmap.fr/fr/

Viele Grüsse
Moritz

The same goes for your tags for Wikidata, Wikimedia Commons and Wikipedia, which refer to an entity that is different from the HLS/DHS article you are linking to.

Sorry, I think your tagging with old_name:* is actually wrong here. You are designating a boundary=region named Appenzellerland, which in my opinion is a different thing than the historic Kanton Appenzell, even though the two entities overlap completely. If you want to have this relation to reflect the region 'Appenzellerland' as it is known today, I think you should remove the old_name tags, and if you want the relation to represent the historic canton, you should change the boundary value to something like 'historic'. But having both concepts in one relation, as it is now, seems wrong to me.

vgl. changeset/66004703

Hi koko77, ich vermute mal, dass du versucht hast, aus OpenStreetMap einen Situationsplan zu exportieren. Dabei hast du mutmasslich unabsichtlich die OSM-Datenbank direkt bearbeitet, anstatt zu exportieren. Ich habe deine Bearbeitung wieder rückgängig gemacht: changeset/179578069

Wie du OSM-Daten exportieren und weiterverwenden kannst, wird zum Beispiel im Wiki von OSM beschrieben: osm.wiki/OSM_on_Paper

Viele Grüsse
Moritz

Ja gut, die Frage nach dem Nutzen ist natürlich ein bisschen ein Totschlagargument. Und nach dem Prinzip "Je weniger Relationen, desto besser", habe ich auch keine Einwände an deinem Vorgehen, weil ich selbst eh keine Kapazität hätte, die Sachen auf den aktuellen Stand zu bringen.

Jetzt sehe ich gerade auf Wikipedia, dass es zusätzlich zu den Fahrplanfeldern noch den Identifier "Streckennummer" gibt, und zwar erst seit 2018: https://de.wikipedia.org/wiki/Liste_der_bestehenden_Schweizer_Eisenbahnstrecken. Diese sind bisher mWn nie in OSM erfasst gewesen, wären aber ein Kandidat für den Tag osm.wiki/DE:Tag:route%3Dtracks (nicht, dass ich absehbar vorhätte, diese Relationen zu erfassen).

Also mein Stand der Dinge wäre jetzt (um am einfachen Beispiel in Les Ponts-des-Martel zu bleiben):

Verkehrsangebot (Linie R22) => route=train, relation/16923518
Fahrplanfeld (222) => route=railway, relation/1240630
BAV-Streckennummer (234) => route=tracks, bisher nicht erfasst.

Sorry, ich war eigentlich auf dem Sprung, ich wollte noch präzisieren: So wie ich das verstehe, waren die ganzen jetzt gelöschten Relationen mit route=train auch in der Tat (jahrelang) falsch getaggt. Meiner Interpretation nach wäre die 'richtige' Vorgehensweise gewesen, die ganzen Relationen zu behalten* und zu route=railway umzutaggen (und vermutlich das PTv1-Tag zu löschen [und generell mal upzudaten, einige waren sicher nicht mehr aktuell/vollständig]).

Bisweilen, zB bei kleineren Betrieben bzw. kürzeren Strecken, fallen/fielen die Fahrplannummer und die Bezeichnung des Verkehrsangebotes auch zusammen, so zum Beispiel wurde – wenn ich mich nicht vertue – der Regio La Chaux-de-Fonds–Les Ponts-des-Martel auch bis vor wenigen Jahren als Linie "222" kommuniziert, bis dann die Vereinheitlichung der Liniennummern, mWn vom BAV koordiniert, erfolgte, seitdem wird der Regio als "R22" angeschrieben. Dementsprechend gibt es hier auch (und 'korrekt' als route=tracks getaggt) relation/1240630 zusätzlich zum Fahrplanangebot R22: relation/18018717. Hier könnte man ja durchaus argumentieren, dass das eine unnötige Verdoppelung der Relation ist (welche nodes/ways Mitglieder der route=tracks-Relation sein sollten und welche nicht, mal aussenvorgelassen). Aber in den allermeisten Fällen gibt es diese Überschneidung von Fahrplanfeld und Verkehrsangebot nicht, weshalb die gelöschten Relationen mMn auch nicht ein PTv1-Relikt der vorhandenen PTv1-Relationen sind, sondern etwas anderes.

*OB die Fahrplanfelder als solche zusätzlich zu den fahrplanmässig bedienten Relationen überhaupt in OSM abgebildet werden sollen, ist natürlich eine andere Frage.

Hi Piagno, merci für's Aufräumen, aber ich hatte das so verstanden, dass diese ganzen Relationen jeweils nicht den fahrplanmässigen Bahnverkehr betreffen, der ja – wie du schreibst – im PTv2-Schema als route=train erfasst ist.

Bei den hier gelöschten Relationen handelt es sich doch um die Fahrplanfelder an sich, was ja etwas anderes ist, als die Nah-/Fernverkehrslinien, die diese Routen benutzen. Mein Verständnis war es, dass die Routen des öffentlichen Verkehrs als route=train gemappt sind, wie z.B. hier die S36 Lyss–Büren relation/17680047. Die (jetzt gelöschte) Relation relation/34381 repräsentierte dagegen doch das Fahrplanfeld 291 Kerzers–Lyss–Büren, das ja nicht identisch ist mit dem Angebot S36. Dementsprechend finde ich das Löschen dieser Relationen falsch – habe ich etwas übersehen?

Für die Relationen, die die Fahrplanfelder abdecken (also die jetzt gelöschten), wäre zwar osm.wiki/DE:Tag:route%3Drailway der richtige Tag (eben im Gegensatz zu route=train z.B. für die S36), aber eine so grossflächige Löschung scheint mir nicht passend zu sein?

Hi, I reverted these changes to the previous version: changeset/175994947

place=city is used for the largest cities in Switzerland only, and not for those who might be calling themselves cities due to historical documents etc. See all places with the "city" Label in Switzerland: https://osm.li/Sue

And additionally, Wikipedia is NOT a suitable source for OpenStreetMap due to licensing issues: osm.wiki/Collaboration_with_Wikipedia

Best regards
Moritz

Ich gehe mal davon aus, dass "Frey-Grynaeisves" ein Tippfehler ist? Oder?

Hallo misterte,
weshalb hast du hier – und bei den anderen Brücken in Basel offenbar auch – den Strassennamen bzw. das name-Tag entfernt? "Dreirosenbrücke", oder rheinaufwärts "Johanniterbrücke" und "Wettsteinbrücke" etc. sind offizielle Strassennamen dieser Brücken. Mit der Entfernung von bridge:name=* kann ich leben, da die Brückenfläche als Objekt ja ebenfalls erfasst ist. Aber die Brücken in Basel sind jeweils tatsächlich so benannt. Siehe zum Beispiel hier der Open Data-Katalog des Kantons Basel-Stadt für die Dreirosenbrücke: https://data.bs.ch/explore/dataset/100189/table/?flg=de-ch&q=Dreirosenbr%C3%BCcke&location=18,47.55643,7.59468&basemap=9fffa5

Hat es einen bestimmten Grund, warum du systematisch name-Tags von Strassen, bzw. Brücken entfernst? Habe kurz deine sonstigen Changesets durchgeschaut und Namen von Brücken bzw. den Strassen auf diesen Brücken scheinen ja ein Thema für dich zu sein.

In Basel jedenfalls sind die Namen wie erwähnt tatsächliche Strassennamen der Brücken – die Strassen am Ende der Brücken haben dann andere Namen – und sollten m.E. auch dann einen name-Tag bekommen.

Anstatt einfach zurückzutaggen, frage ich aber lieber noch mal nach, was der Grund für diese "Anpassungen" sind. Diese scheinen mir ohnehin keine grosse Halbwertszeit zu haben, da es ja die bekannten Apps gibt, die gerne mal nach Benennungen etc. fragen, und daher der Name eh schneller als gedacht zurück sein kann (vgl. Johanniterbrücke: way/13251973/history)

Yes, thanks for the heads-up, I updated the way changeset/170621644

Und bei relation/7501021 ist wohl auch etwas verrutscht (jetzt farmyard, bisher passend farmland)

Oh, ja, besten Dank, da war die Autovervollständigung von iD nicht so schnell wie meine Finger auf der Tastatur...