Wäre es ein Mappen für die Anwendung, wenn man ein Autobahnkreuz oder -dreieck mit dem zugehörigen Wikidata Objekt verknüpft? Man bräuchte das beispielsweise, um bei Wikipedia mit dem sogenannten Kartographer eine Karte auf OSM-Basis in einen Artikel einzufügen. Unabhängig von der Nutzung bei Wikipedia ist jedes Autobahnkreuz ein geografisches Objekt. Somit wäre IMHO rein aus OSM-Sicht ein Erfassen vertretbar. Dieses Objekt lässt sich nicht mit einer Overpass Abfrage, sondern nur per Hand erfassen. Jedes Autobahnkreuz ist bereits als Wikidata-Objekt vorhanden und müsste nicht mehr erstellt werden.
Wenn das erlaubt wäre, stellt sich die Frage, wie man das angehen sollte. Fasst man in einer Relation die beteiligten Straßensegmente, junctions und Brückenbauwerke zusammen? Diese Relation wird dann mit Wikidata verknüpft. Welchen Relationstyp sollte man nehmen und welche Rollen für die Mitglieder?
Es geht ja darum, dass man alle zugehörigen Segmente auf einer Karte hervorheben kann. Einfach nut die Koordinate gibt es bei Wikidata ohnehin schon.
Wikidata=* direkt an die Segmente funktioniert jedenfalls nicht, da diese bis auf die Verbindungsstücke ja schon das Item für die Autobahn dort haben. Zwei Wikidataitems an einem Segment über Wikidata=* zu verknüpfen ist nicht vorgesehen. Damit ist eine Relation eigentlich die einzige Möglichkeit. Dabei ist dann auch die Frage wo das Autobahnkreuz eigentlich anfängt und aufhört.
Man könnte natürlich auch ein motorway_cross:wikidata=* einführen, das müsste dann aber auch noch in Kartographer eingebaut werden.
Für ein Autobahnkreuz braucht es keine Relation, die Gruppierung doch ist allein über den Namen der highway=motorway_junction möglich. Oder übersehe ich da etwas? Zudem stellt sich bei einer Relation, die Straßenstücke enthält, die Frage, wo es aufhören und enden soll.
Ich störe mich allgemein daran, dass wir allein für Wikidata/Kartographer unnötige Sammelrelationen angehen (z.B. tunnel-Relationen für Eisenbahnbrücken, die die Gleise im Tunnel trotz tunnel:name=* gruppieren), weil deren Software/Datenmodell nicht damit klarkommt, dass ein realweltliches Objekt aus mehreren OSM-Objekten bestehen kann. Wir haben in der deutschen Community associatedStreet-Relationen vor Jahren als veraltet bestimmt und jetzt fangen wir an, wieder irgendwelche Straßen-Sammelrelationen zu pflegen, weil jemand keine Aggregierungs-Funktionen in seiner Datenbank nutzen will?
ehrlich gesagt finde ich “KISS” im Zusammenhang mit place=locality nicht so gut, weil das hier eher zu simpel wäre, DNKITSS
wir hätten natürlich auch Berggipfel, Quellen und Höhlen und sonst was alles als localities taggen können, und der Name wäre mit einem Ort verbunden gewesen, aber es ist durchaus nicht uninteressant zu wissen, mit was der Name assoziiert ist, d.h. wenn man vorhat, alle Autobahnkreuze als Objekte zu taggen, wäre es meiner Meinung nach schon sinnvoll, sich dafür einen tag auszudenken (bzw. zu verwenden) der genau “Autobahnkreuz” sagt.
Richtig, das ist der Hintergrund. Es soll nicht nur ein Kartenausschnitt gezeigt werden, sondern auch Linien- und Flächen- Objekte in unterschiedlichen Farben hervorgehoben werden, wie beispielsweise die größten Städte Deutschlands. Man gibt dazu eine Aufzählung der Wikidata Objekte dieser Städte an und teilt jeder Stadt eine Farbe zu. Das Beispiel ist hier auch mit einem Video beschrieben.
Das ist genau der Punkt, auf den ich hinaus wollte, als ich vom Mappen für die Anwendung sprach. Bei einem Autobahnkreuz könnte man noch argumentieren, dass das ein geografisches Objekt ist. Aber es gibt genug andere Beispiele, wo dieses Argument nicht mehr zieht. Wenn ich beispielsweise bei der oberen Karte in diesem Wikipedia Artikel die Straßen von den umliegenden Städten hin zum Standort der Klinik hervorheben wollte, wäre das ganz klar ein Mappen für die Anwendung, wenn ich dafür eine Relation anlege und diese mit einem Wikidata Objekt verknüpfe.
Der Nutzen des Wikipedia Kartographer auf Grundlage von Wikidata Items ist nach meinem Verständnis viel zu beschränkt. Ich frage mich, ob man nicht viel besser uMap als Grundlage hätte nehmen sollen. Dort hätte man dann noch die Möglichkeit einbauen können, dass live während des Renderns eine Overpass Abfrage durchgeführt wird. Für das Beispiel mit den Straßen zur Klinik hätte man sich der existierenden Funktionalität eines Navigationsrouters bedienen können, wie hier sichtbar wird. Man kann dann mit Zwischenzielen an der Darstellung herumzupfen, bis dass die gewünschte Linie angezeigt wird. Das würde auch für den von Nakaner beschriebenen Tunnel funktionieren. Die Navigationsrouter-Funktionalität müsste für die Wikipedia-Karten zudem von Straßen auf beliebige Linienobjekte erweitert werden, um beispielsweise Eisenbahn- oder Flussabschnitte hervorzuheben.
Was meint ihr? Sollte man bei Wikipedia nicht uMap mit den gerade beschriebenen Erweiterungen anstatt des jetzigen auf Wikidata Items fußenden Kartographers vorschlagen? Oder seht ihr ein besseres existierendes Tool für die Karten in der Wikipedia auf OSM Basis?
Bei der Beschreibung frage ich mich ob es überhaupt immer neu abgefragte Daten aus OSM braucht. Es reicht doch einmal die Daten über Overpass herunterzuladen und dann als geojson auf Commons zu speichern.
Da sehe ich den Lösungsweg nicht. Könntest Du anhand der oben genannten Karte in diesem Wikipedia Artikel demonstrieren, wie ich dort eine Hervorhebung der Straßen von den umliegenden Städten zur Klinik erreiche? Mit welcher konkreten Overpass Abfrage kommt man zu einem geojson-Code, wie er von der Wikipedia Syntax dieser Karte benötigt wird. Ich bin gespannt, wie das geht.
Leider löscht das Forensystem das Zitat, auf das ich mich beziehe. Wozu soll das gut sein? Ich habe einen Buchstaben aus dem Zitat entfernt, damit das stehen bleibt.
Vollzitate werden nicht übernommen, das ist wie eine Antwort auf den Beitrag. Ist halt so.
Mammi71
(One feature, Six mappers and still More ways to map it)
10
Das wird systemseitig nur gelöscht, wenn Du den unmittelbar vorstehenden Beitrag vollständig zitierst. Wozu soll ein Vollzitat des unmittelbar vorstehenden Beitrages gut sein? Das ist doch, wie Vinzenz bereits schrieb, eine unmittelbare und direkte Antwort auf den vorherigen Beitrag.
In anderen Forum wird man darauf dressiert, klarzumachen worauf man sich bezieht. Das ist bei den zwei Sätzen präzise genug. Anders wäre es natürlich, wenn ein ganzer Aufsatz vollzitiert würde.
Woher weiß man, dass sich eine Antwort ohne Zitat nicht auf einen anderen als den unmittelbar vorstehenden Beitrag bezieht?
Wenn sich eine Antwort auf den unmittelbar vorhergehenden Beitrag bezieht, sieht es wie in dieser meiner Antwort auf Deinen Beitrag aus, bzw. so wie in der Antwort von @SpaLeo auf Deinen Beitrag:
Eigentlich ging es nach der Überschrift darum, es einfach zu verknüpfen und da fehlt in OSM eben einfach ein Objekt.
Alternativ könnte man eine virtuelle Umgrenzung um das Kreuz zeichnen, finde ich auch nicht so toll, oder die Zu- und Abfahrten jeweils verknüpfen oder wie angedacht, eine Relation bilden. Wir müssten uns dann 1000 Beiträge lang darüber unterhalten, was zum Kreuz wirklich außer den Abfahrten gehört:
die durchgehende Fahrbahn, die Wartungswege im Kleeblatt, die Wegweiser bis 2km vor dem Kreuz, die Ampel am Ende der Abfahrt …
Nach diesen Überlegungen fand ich die Idee mit dem einfachen Punkt irgendwie charmant
Ich habe die die Daten über das QuickOSM Plugin in QGIS heruntergeladen und alle Wege die zu viel heruntergeladen waren gelöscht. Außerdem habe ich alle unnötigen Attribute gelöscht.
Für Georgsheil habe ich dann noch alle Linien zu einer zusammengefasst um die Daten weiter zu vereinfachen.
Beim Autobahnkreuz habe ich noch Attribute für Styledaten hinzugefügt und das ref Attribut in title umbenannt.
Ursprung war schon die Darstellung von linien- und flächenförmigen Objekten im Kartographer der Wikipedia. Und ist in den dortigen Diskussionen ist man beispielsweise bei den von Nakaner beschriebenen Tunneln der Meinung, dass man die als geografisches Objekt erfassen darf, während man bei OSM der Meinung ist, dass man das durch eine Abfrage erledigen kann. Ein Autobahnkreuz ist ein geografisches Objekt, bei dem die Abfrage nicht geht. Daher ist es als Beispiel für eine Behandlung sinnvoll und deshalb habe ich dieses gewählt, um nicht das ganze Fass aufzumachen.
Bei OSM wird bei in der Realität unscharfen Objekten die Entscheidung dem Mapper überlassen, ob beispielsweise ein Pfad nur von Fußgängern oder auch von Radfahren benutzt werden kann. Das Gleiche gilt für das, was zur Relation von klassifizierten Straßen gehört. Und bei Kreuzen kann man ebenso den Mapper über den Umfang entscheiden lassen. Der Druck seitens Wikipedia durch die Kartographer Software für eine Erfassung geografischer Objekte durch Linienformen ist da.
Der einzelne Punkt funktioniert nur in kleinen Zoomstufen und verschwindet, wenn man in das Objekt hineinzoomt. Die zum darzustellenden Objekt gehörenden Objektteile werden nicht dargestellt. Ein Fluss, der im ganzen Land verläuft, muss ebenso wie ein Autobahnkreuz in Verästellungen sichtbar bleiben, wenn man hineinzoomt. Der einzelne Punkt ist dafür genau so wenig eine Lösung, wie eine ungeteilte Linie für das Micromapping jedes einzelnen Parkplatzes oder das behindertengerechte, metergenaue Mapping von Gehsteigen.
Um auf das von Nakaner aufgeworfene Problem einzugehen, habe ich oben versucht, Lösungen vorzuschlagen, wie man die Software bei Wikipedia anders aufbauen könnte, um eine Überflutung von OSM mit Objekten zu verhindern, die man technisch anders und leistungsfähiger lösen könnte. Zu diesen Objekten zählen aber Autobahnkreuze für Artikelkarten nicht, denn sie lassen sich nur von Hand zusammenstellen.
Ich könnte mir übrigens vorstellen, dass sich im Zuge der Vektorisierung von OpenStreetMap ganz neue Wege bei der Darstellung von Objekten auftun.
