Jeder Datennutzer wählt aus, welche Daten er nutzt; bei einem Renderer: welche Objekte er darstellt und wie. Das ist eine der Kernaufgaben. Aufgabe der Datenerfasser und Aufgabe der Erfassungsschemen ist es, den Datennutzern diese Auswahl ermöglichen.
Das ist korrekt. Eine dieser Annahmen sollte sein, dass der Datenbestand dynamisch ist.
Das ist in der Tat unglücklich gelaufen. Grund war aber, dass die Renderregeln der Hauptkarte einfach jede politische Gliederung darstellen. Diese Catchall kann zu einer Weißliste geändert werden, dann ist man vor solchen Überraschungen sicher. Dem Datenerfasser kannst Du da keinen Vorwurf machen: natürlich hätte er seine Aktion vorher bei den Verwaltern der Karte anmelden können; was dann passiert wäre, sagt mir meine Kristallkugel: nichts. Und Du kannst nicht im Ernst erwarten, dass Erfasser erst auf eine Freigabe der Verwalter der Hauptkarte warten soll. Wie sagt die Einblendung in manchen Filmen so schön:“wenige Jahre später”.
OSM ist eine Sammelaktion. Und was auf einem Stadtplan was zu suchen hat, entscheidet der Stadtplan. Der Stadtplan entscheidet aber nicht darüber, was in der Datenbank zu suchen hat.
Das wäre in der Tat schön. Das setzte aber voraus, dass die Verwalter der Hauptkarte auch antworten
Sagen wir es mal deutlich: die Hauptkarte ist von den mir bekannten Karten die am schlechtesten gepflegte.
Genau die machen kein problem, denn deren Verwalter reagieren zeitnah.
Bring Dich bei der “Chaotentruppe” der Verwalter der Hauptkarte ein, und zeig, dass die auf Änderungen reagieren.
Monate? Hey, wir sind hier nicht in Fantasy-Land. Es geht um Jahre.
Wird es in der Hautpkarte nicht. Und in der Geschichtskarte nehmen wir die Herausforderung an, mit dichten Ansammlungen von Objekten umzugehen.
Gut, dann haben wir hier kein Problem. Ich hatte vorherige Äußerungen so verstanden, dass bei bestimmten Tags so ein Denkmalschutz-Logo im Stadtplan erscheint.
Ist forum.openstreetmap.org ein reines Mapper-Forum? Ich dachte es geht hier um das Gesamtprojekt. Normale Menschen nutzen einen Stadtplan oder topografische Karten nicht über SQL-Requests. Die Visualisierung ist sehr wesentlich. So wird OSM über die Webseite wahrgenommen und genutzt. Ich vermute dass die meisten Leute auch nicht aus Sammlerleidenschaft zu OSM kommen, sondern weil sie eine gute Karte brauchen.
Soweit ich das versehe ist die “Blacklist”-Policy auch vom Projekt gewollt, denn sonst müssten Mapper bei jeder Kleinigkeit betteln, damit sie in die “Whitelist” aufgenommen wird. Wäre das denn gewollt? Wenn einige “Exoten” auf dem Plan erscheinen ist das weniger problematisch, wohl aber wenn massenhaft neue Objekte aus Sammelaktionen auftreten. Dann wäre es eben doch vorteilhaft, wenn man das vor der Aktion mit dem Rendering abstimmt.
Stell dir mal vor, ein Koordinaten-Sammler mappt die ganzen Kanaldeckel der Republik. Und die erscheinen dann alle in der Karte. Würde man das monatelang so auf der öffentlichen Karte stehen lassen und den Ruf der OSM ruinieren? Ich würde den Renderer-Programmierern nicht zum Vorwurf machen, die hätten das ahnen sollen. So etwas sollte vorab koordiniert werden.
Niemand verlangt von dem normalen Menschen, daß er SQL-Requests formulieren können muß. Dafür gibt es ja gerade wieder die Renderer, die eine Vielzahl fertiger Karten zu Verfügung stellen.
Ich nehme an, hier beziehst du dich wieder auf die Karte www.openstreetmaps.org? Die sollte nie eine Gebrauchskarte sein sondern ein Schaufenster. Über das Maintaining dieser Karte hat Wolf ja schon genug geschrieben, aber das ist ein anderes Thema, hat sicher nichts mehr mit Denkmalschutz zu tun.
Im übrigen würde ich dich bitten, für Grundsatzdiskussionen über das für und wieder von bestimmten Anzeigeoptionen in der Hauptkarte einen eigenen Thread zu eröffnen, hier sollte es um Denkmalschutz gehen. Ausschließlich. Danke!
nicht 100% aber doch sehr in diese Richtung tendierend. Es ist nur so, dass die Entwickler ein ziemlich elotärer Haufen sind, die noch mehrere weiter Kommunikationskanäle verwenden - Talk-X, xxx-dev, GIT-Hubs bis hin zu Google-Teamware-Software (ja!)
Doch, mir ist sehr wohl der technische Hintergrund der Falschbeschriftung klar. Dass der Bauernhof zufällig im Polygonschwerpunkt des Wahlkreises liegt kann man ihm aber nicht vorwerfen. Schlimmer noch waren die Falschbeschriftungen von Straßen als Wahlkreisnamen/Grenzbeschriftung. Das sind eben Beispiele für mangelnde Abstimmung zwischen Datenbestand und Darstellung.
Ich wollte nur nochmal dran erinnern, damit bei den Denkmälern keine solchen “Unfälle” passieren, vor allem beim Datenbankimport von Denkmalschutzlisten. Heutzutage stehen ja schon gewöhnliche Bauernhöfe unter Denkmalschutz, nur weil da ein bisschen Fachwerk verbaut ist.
Die Karte auf www.openstreetmaps.org halte ich durchaus für eine Gebrauchskarte. Zumindest finde ich sie sehr nützlich, alternativ zu Google Maps, weil dort mehr kleine Wege und POI verzeichnet sind.
Ja, wenn Grenzrelationen Straßen als Member beinhalten - was ja bei Grenzen eh unsinnig ist (*) - wird der Straßenname oft überschrieben oder verdrängt.
Gruss
walter
*) Eine Straße als Member einer Grenze: Was gehört wo hin? welche Seite gehört wo hin? Manchmal kommt sowas vor, aber ganz selten.
Das kann man auch erreichen, indem die Grenze als eigener Way dort lang führt. Sieht auch bei “normalen” Grenzen an ein paar Stellen auf osm.org seltsam aus.
Da die Diskussion sich eh wiederholt sollte man sie besser da fortführen, wo sie schonmal war (ein Moderator könnte auch die entsprechenden Beiträge verschieben).
Nein, das wird (wie schon ein paar Mal geschrieben) als Fehler angesehen. Du darfst gerne dafür einen Patch einreichen (wenn du keinen GitHub-Account hast per PN o.Ä. an einen der dort Beteiligten) und hoffen, dass er angewendet wird.
Wer denkmalgeschützte Gebäude erfassen möchte, erfasst diese mit einem geeigneten Tag. Wenn die Geschichtskarte entscheidet, die so gekennzeichneten Gebäude zu zeigen, werden sie gezeigt. Wenn die Hauptkarte entscheidet, sie nicht anzuzeigen, werden sie dort nicht angezeigt. Diese “lose Kopplung” macht OSM so dynamisch und beweglich.
Ungehörig wäre es, wenn der Erfasser ein ”name=dmg” an seine Gebäude packt, um die Darstellung in der Hauptkarte zu erzwingen.
Ja. Die meisten Nutzer sind reine Nutzer. Etwas anderes wäre sehr merkwürdig. Und natürlich soll die Hauptkarte für möglichst viele Nutzer hilfreich sein.
Das heißt aber nicht, dass man Objekte deshalb falsch gekennzeichnet. Weder sollte man sie falsch kennzeichnen, um eine Darstellung in der Hauptkarte zu erzwingen, noch sollte man sie falsch kennzeichnen, um eine Darstellung zu vermeiden.
Richtig ist: korrekt kennzeichnen mit hinreichend viel Information, um der Hauptkarte (und natürlich allen anderen Nutzern) eine Auswahl zu ermöglich. Der Datenbestand und das Tagging ist dynamisch, und die Hauptkarte (und natürlich alle anderen Nutzer) müssen sich anpassen.
Das eigentliche Problem ist, dass die Hauptkarte sich – wenn überhaupt – nur mit extremer Verzögerung anpasst. Und dafür kenne ich keine Lösung.
Es gibt keine generelle “Blacklist-Policy”. Wenn ich “historic:railway=xxx” benutze, wird da nichts dargestellt.
Einzig das “name=*” wird von der Hauptkarte unter sehr allgemeinen Bedingungen dargestellt, und das führt dann mal – wie zuletzt bei den Wahlkreisen – zu unerwünschten Namen auf der Karte. Hier wären möglicherweise spezifischere Regeln angemessen.
Solche Situationen sind aber selten, und vielleicht schaffen es auch die Betreuer der Hauptkarte irgendwann mal, vielleicht einmal im Monat auf ein Problem halbwegs schnell zu reagieren.
Was heißt hier, “gewollt”? Es ist so. Du musst betteln, umd Deine Kanaldeckel anzeigen zu lassen. Oder Geröllflächen.
Diese Situationen kommen selten vor. Und wenn ab und zu mal ein bisher seltenes Tag “plötzlich” häufiger erscheint, dann ist den Verwaltern der Hauptkarte (und allen anderen Nutzern der Daten) zuzumuten, die Regeln anzupassen. Sag ich jetzt einfach mal so.
Dagegen ist den Datenerfassern nicht zuzumuten, Monate oder Jahre auf eine “Genehmigung” für die Intensiverfassung eines Featuretypes zu warten.
Sofern Du korrekt erfasst hast (also nicht mit “name=Kanaldeckel”), erscheinen die nicht auf der Hauptkarte. Weil es keine Regel dafür gibt.
Das Problem steht seit Wochen an. Hast Du es den Verwaltern der Hauptkarte bereits mitgeteilt? Und wie sieht deren Reaktion aus?
So ich weiß, gibt es an der DE-BE-Grenze Straßen, deren eine Seite zu DE und deren andere Seite zu BE gehört, wo man also beim Überqueren der Straße das Land wechselt¹. Da – und nur da – gehört der Way der Straße an die Grenzrelation.
Gruß Wolf
¹) Ich möchte nicht wissen, wie die Straßenreinigung geregelt wird.
Da kam mal ein Bericht über deutsche und französische Feuerwehr in einem Ort mit verschiedenen Hydranten. Dort sagte der “deutsche” Bürgermeister aus: Die Straße ist “Niemandsland” - da darf weder die deutsche Polizei noch die französische eingreifen - außer es handelt sich um lebensrettende Maßnahmen. (Übrigens habe die Feuerwehren jetzt ein “Pass-Stück” für französische Schläuche an deutschen Hydranten oder umgekehrt.)
Sicher nicht das einzige, aber ein besonders schönes Beispiel ist die Neustraße/Nieuwstraat zwischen Herzogenrath (DE) und Kerkrade (NL), die sogar einen eigenen Wikipedia-Artikel hat. Die Grenze verläuft in der Straßenmitte. Früher trennte ein kniehoher Betonwall die gegenläufigen Einbahnstraßen auf beiden Seiten. An beiden Enden der Straße (etwa an den heutigen Kreisverkehre) befanden sich Grenzübergangsstellen. Anläßlich von Fußball-Länderspielen war die Neustraße regelmäßig Austragungsort größerer Schlägereien.
Ein “gewöhnlicheres” Beispiel: die beiden Lichtenbüsche. Die Grenze - in OSM anhand GPS-vermessener Grenzsteine eingezeichnet - verläuft hier und weiter südlich teils am westlichen Straßenrand, teils einige Meter daneben. Die Gebäude auf belgischer Seite sind nur von Deutschland aus zu erreichen. Man wechselt also das Land ungefähr beim Verlassen der Fahrbahn.
Um in der Region zu bleiben: Der Hergenrather Weg verläuft laut amtlichen Karten komplett auf Aachener Gebiet (die Grenze in OSM ist wegen nicht auffindbarer Grenzmarkierungen hier noch unpräzise). Die belgische Nachbargemeinde hat dennoch - auf belgischem Gebiet, also abseits der Straße - ein eigenes, anderslautendes Straßenschild aufgestellt (iirc Aachener Straße entsprechend dem Namen, den die Straße weiter südlich trägt), sodaß die Häuser auf belgischer Seite (wenn ihre Hausnummern irgendwann erfaßt bzw. importiert werden sollten) zwar am Hergenrather Weg liegen, aber addr:street=“Aachener Straße” haben.
Der Sonderfall der Vennbahntrasse einige Kilometer weiter südlich ist ja schon hinlänglich bekannt. An jedem Übergang über die Bahnstrecke (heute: Radweg) betritt und verläßt man innerhalb weniger Meter belgischen Boden.
Die Lösung wäre eine bessere Kommunikation zwischen Rohdatenverwaltern/-produzenten und Visualisierern. Vielleicht ist der Bug-Tracker nicht die geeignete Kommunikationsform. Ist schon klar, dass für die Datenbank die konsequente Strukturierung im Vordergrund steht.
Am besten würde man solche Dinge über Konfigurationsdateien lösen, um nicht bei jedem Problem an die Programmierer gehen zu müssen. Ein zentraler Admin prüft regelmäßig, ob die Visualisierung mit dem Datenmodell passt und justiert notfalls an den Config-Dateien. Ist OSM denn noch nicht flexibel konfigurierbar?
Das catchall-Problem wurde bereits gemeldet. Aber hier meine ich, dass solche temporären Geodaten, die für die Nutzer auch quasi Null Nutzwert haben, überhaupt nicht in die Datenbank gehören. Das bindet nur unnötige Mapper-Aufmerksamkeit. Die Objekt-Masse im JOSM-Editor ist schon groß genug. Sollen die etwa von der OSM-Community auch noch gepflegt werden? Ist doch für die Katz, wenn sich die Wahlkreisgrenzen für jede Wahl sowieso ändern und amtlicherseits als Shapefile bereitgestellt werden. So eine Spezialkarte kann sich jeder selbst Overlayen, ohne OSM dafür belasten zu müssen. Das wäre so, als ob man als Tag zu den Tankstellen-Gebäuden gleich noch die Benzinpreise in der Datenbank vorhält. Sicher nützlich für den Normalbürger, aber das lässt sich auch als von OSM unabhängiges Overlay realisieren.
Denkmalschutz-Eigenschaften sind natürlich interessantere Objekteigenschaften. Obwohl man da vielleicht unterscheiden sollte, ob es wirklich um ein Denkmal im Sinne einer Sehenswürdigkeit handelt oder um ein x-beliebiges Fachwerkhaus (wo der Denkmalschutz wohl eher dem Besitzer auf die Nerven und ans Portemonnaie geht). Ersteres ist durchaus als Overlay-Karte sinnvoll.
Wie ist eigentlich der Ausbaustand? Ist OSM aktuell? Ich hatte gehört, dass dieses Jahr noch ein Lückenschluß anstehen sollte. Ein Teil ist noch gestrichelt dargestellt und endet im Luxemburgischem Nirvana. Ich wollte da immer mal lang fahren …
Hier sind die Radwege schön dargestellt: http://cycling.waymarkedtrails.org/de/ (wo gibt’s da eigentlich die Kartenlegende?)
Sorry, aber Luxemburg liegt weit außerhalb meines Aktionsradius. Auf den ersten Kilometern wurden in den letzten Monaten Rettungspunkte markiert, die Lücke zwischen AC-Walheim und belgischer Grenze ist geschlossen und der Mäusetunnel unter der B 258 ist fertig. Aber wir geraten OT.
Die Erzeugung der Hauptkarte (wie wohl der allermeisten) Karten wird (schon immer) über eine Konfigurationsdatei gesteuert. Wie auch sonst?
Der braucht überhaupt nicht zu prüfen, denn das machen die Nutzer der Karte. Das Problem besteht ausschließlich darin, dass die Verwalter der Hauptkarte die Config nicht anpassen. Und ist begrenzt auf die Hauptkarte; die Verwalter der anderen Karten sind erreichbar und antworten auf Wünsche. Was natürlich nicht heißt, dass sie alle Wünsche erfüllen. Aber das erwartet auch keiner.
OSM?
Meinst Du den Renderer, der die Tiles der Hauptkarte erzeugt? Der ist vor kurzem noch umgestellt worden, um leichter Anpassungen vornehmen zu können.
Ich bin auf die Reaktion der Kartenverwalter gespannt. Meine Kristallkugel befrage ich lieber nicht.
And now for something completely different: die Relevanzdiskussion.
Du hältst etwas für irrelevant, also raus damit aus der Datenbank. Ginge es nach mir, würde ich den ganzen 3D-Firlefanz™ und alles was mit Seefahrt zu tun hat tilgen. Das erste, weil es mich nicht interessiert und eine wie schwach auch immer definierte Vollständigkeit nicht erreichbar ist, das zweite, weil ich mangels Grün-Sensoren in DE keine Lizenz dafür bekomme.
Bevor es jemand in den falschen Hals bekommt: würde ich natürlich nicht. Weil nicht ich entscheide, was relevant ist.
Nein, die ist noch viel zu klein. Deshalb sammeln wir doch wie wild. Was meinst Du, welche Datenmengen uns 3D- und Indoor-Mapping noch bescheren werden?
Und wieder eine andere Geschichte: alle Daten in der OSM-Datenbank können (und werden) veralten. Ich kann nicht für jeden von mir erfassten Weg garantieren, dass ich einmal im Monat nachschaue, ob der noch da ist. Ich trag die aber trotzdem ein.
Ob Wahlkreisgrenzen in die Datenbank gehören, dazu habe ich keine Meinung. Das Datenvolumen ist überhaupt kein, und das mögliche Veralten nur ein schwaches Argument gegen die Aufnahme.
Die Anbindung externer Datenbanken an OSM ist ein ungelöstes Problem. Natürlich kann ich jeden Firlefanz über die Karte drübermalen. Aber: eine Anfrage “wieviele Schulen gibt es in den einzelnen Wahlbezirken” kann ich bei integrierten Daten leicht beantworten lassen, aus dem Shapefile eher nicht. Unabhängig davon, ob die Anfrage sinnvoll ist.
Nicht alles, was hinkt, ist auch ein Vergleich: auch die Eisenbahnlinien lassen sich als Overlay realisieren. Buslinien sowieso – da die sich bei jedem Fahrplanwechsel ändern können. Und Geschäfte: andauernd öffnet oder schließt eins. Und die 3D-Objekte: warum sind die nicht in einer externen Datenbank in einem standardisierten 3D-Format gespeichert?
Einfache Antwort: weil die unterschiedlichen Mitstreiter bei OSM unterschiedliche Interessen haben. Und weil nur die Daten mit überschaubarem Aufwand verarbeitbar sind, die sich in der Haupt-Datenbank befinden. Lösch die T5 und T6 Pfade aus der Datenbank (“sowas hat in nem Stadtplan nix verloren, pack das in eine eigene DB und machn Overlay”), und ich bin weg. Lösch die 3D-Infos, und die 3D-ler sind weg. Lösch die Seefahrt-Infos, und die Seeleute sind weg.
Du vermanschst “heritage=*” und “tourism=attraction”.
Denkmalgeschützt ist definiert durch die Aufnahme in einer entsprechenden Liste (und oft eine Plakette am Haus). Ob Du ein Gebäude für relevant hältst, ist für die Eigenschaft “denkmalgeschützt” belanglos. Es sind auch Gebäude denkmalgeschützt, die Dich nicht interessieren. Weil denkmalgeschützt nicht sehenswürdig impliziert. Und sehenswürdig nicht denkmalgeschützt.
Wenn die Geschichtskarte Sehenswürdigkeiten zeigt, dann nicht, weil sie Sehenswürdigkeiten sind, sondern weil sie historisch oder geschützt sind.
Wir hatten den betreffenden Mapper diese Woche auf dem Stammtisch. Er hat die Kritik bezüglich der Namen der Stimmkreise berücksichtigt und die aus seinen Wahlkreis-Relationen entfernt (was seine Arbeit in Zukunft erschwert). Den “Wahlkreis Bonn II” hat er dabei offensichtlich übersehen. Das wird er in den nächsten Tagen korrigieren.
Darüber hinaus, hat er ein Ticket erstellt, boundary=election in Mapnik nicht mehr darzustellen. Auch wenn sich beim OSM-Stil von Mapnik einiges tut (Namen erschienen am Umriss, statt in der Flächenmitte), kann das Auflösen einer Catchall-Situation jedoch einiges dauern. Aber dann ist dieses spezielle Thema endlich erledigt.
Wahlkreise sind einiges dauerhafter als so manches andere in OSM. Das Lokal für unseren Stammtisch hat in den letzten 12 Monaten zweimal den Betreiber und den Namen gewechselt. Der dritte Betreiberwechsel hat bereits stattgefunden, ein neuer Name wird im nächsten Monat erwartet.
Wahlkreise hingegen werden 1-2 Jahre vor der Wahl festgelegt und sind dann bist zur nächsten Festlegung gültig. Für Auswertungen werden die z.B. auch nach der Wahl noch gebraucht. Temporär ist wohl was deutlich anderes.
Über die Nützlichkeit sollte man bei OSM besser nicht diskutieren. Für den Ersteller sind die Daten notwendig.
Doch, genau das meine ich, wenn das zwischen heritage und tourism sauber differenziert wird, ist es Ok - ich meine natürlich explizit auch das Rendering. Nicht dass da auf der Hauptkarte überall die blauen Fähnchen erscheinen
Der Vergleich zwischen Wahlkreis und Geschäft hinkt tatsächlich, was deren Nutzwert anbelangt. Oder die Buslinien. Die können sich zwar verändern, sind aber nicht temporär nur für eine Wahl interessant, sondern von allgemeinem Nutzwert, vor allem auf Verkehrskarten.
Gibt es den Datenbankrequest “gibt mir alle Objekte innerhalb einer Fläches/eines Polygonzuges?”. Das ist natürlich interessant für den Datenauswerter. So einen Algorithmus hatte ich auch mal programmiert. Nur braucht man dafür keine Relationen zwischen Objekten. Das ist eine rein geometrische Entscheidung anhand der Koordinaten (Punkt vs. Polygonzug).
Eine Intersection zwischen einem Node und einer Fläche ist natürlich auch möglich. ST_Intersects sucht dann halt alle Nodes, die innerhalb (oder auch außerhalb) einer Fläche liegen.
Irgendwas in der Richtung selber zu programmieren, hatte ich inzwischen für Schwachsinn unnötig. Das ist inzwischen in jeder vernünftigen GIS-Software drin und steht auch in Form von Bibliotheken für alle gängigen Programmiersprachen zur Verfügung.
Die Hauptkarte ignoriert “heritage=*”. Was sie aus “tourism=attraction” macht, weiß ich nicht.
Die Geschichtskarte ignoriert “tourism=attraction” und beachtet “heritage=*”, dabei auch die Werte von “heritage=” und auch von weiteren Tags, je nach Werten wird das Symbol ausgewählt und erst ab einer bestimmter Zoomstufe dargestellt.
In all diesen Fällen: eine Diskussion darüber, ob und mit welcher Geschwindigkeit erfasst wird, ist eine Relevanzdiskussion, und die ist wegen unterschiedlicher Interessen der Mitstreiter müßig. Aufgabe der Erfasser ist es, ein Schema zu finden, dass den Auswertern die Möglichkeit gibt, vernünftig mit den neuen Objekten umzugehen: siehe “memorial:type=*”, siehe das Tagging der Wahlkreise. Aufgabe ist nicht, sich monate- bis jahrealten Auswerteregeln unterzuordnen.
Du bist wieder bei Relevanz. Darauf werde ich nicht mehr eingehen.
Selbstverständlich.
Der ist aber natürlich nur anwendbar, wenn die Flächen sich auch in der Geodatenbank befinden.
Eine hinreichend™ schnelle Implementierung eines Algorithmus, der die Schnittmenge zwischen zwei allgemeinen Polygonen (also auch konkav, auch mit Löchern), würde mich schon sehr interessieren: also her damit!
Siehe oben: die Abfrage ist nur anwendbar, wenn sich die Daten in der gleichen Datenbank befinden.
