heritage Denkmalschutz

Nahmd,

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?)

Diese Konfigurationsdateien gibt es, sie nennen sich Kartenstil. Und sei überrascht, dafür gibt es sogar einen Bugtracker

…über den du auch Personen mit OSM-Account finden kannst (selber Nickname und Aktivität vergleichen), um ihnen dort eine Nachricht zu schreiben. :roll_eyes:

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.

Nahmd,

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. :confused:

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.

Gruß Wolf

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.

Edbert (EvanE)

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 :slight_smile:

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).

Klaro, das Kind heisst bei “richtigen” Datenbanken mit GIS ST_Intersects

Siehe auch die Beispiele mit Grafiken in http://workshops.boundlessgeo.com/postgis-intro/geometry_returning.html

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.

Gruss
walter

Nahmd,

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.

Die Reaktion auf Veränderungen im Datenbestand ist und bleibt Aufgabe der Kartenbetreuer. Bei der Geschichtskarte war die Reaktion auf denkmalgeschütze Häuserreihen eine verkleinerte Darstellung des Symbols; die Reaktion auf dicht beieinanderliegende “historic=memorial” Stolpersteine war die Auswertung des ”memorial:type=stolperstein”, dito bei Gedenktafeln (“memorial:type=plate”).

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.

Gruß Wolf

Nö, du kannst jederzeit in einem Programm mehrere Datenbanken parallel aufmachen und Queries über beide gleichzeitig machen.

siehe: http://www.unityjdbc.com/doc/multiple/multiplequery.php
und für postgresql im Speziellen: http://www.postgresql.org/docs/9.1/interactive/dblink.html

Das einzige wirkliche Problem bei OSM-Daten ist es, einen verlässlichen und robusten Link zwischen den Daten zu finden. Aber das sollte ja wohl inzwischen klar sein.

Gruss
walter

Na im Prinzip ist ja der wikipedia- Tag ein solcher Link. Andererseits halte ich den ref-Tal als einzigesten dafür geeignet.

Beispiel (Natur)Schutzgebiete. Das Tagging-Schema für boundary=protected_area zum Beispiel bietet einen solchen Link. In den erweiterten Tags ist z.B. ref:SCI=xyz möglich. Der Wert xyz steht dann für die Nummer des FFH-Gebietes über die wiederum in einer möglichen Anwendung z.B. Gebietsinfos wie der Standarddatenbogen angezeigt werden kann.
Genauso kann das auf anderes angewendet werden.
Das ganze steht mit uns allen. Wir tragen die Verantwortung für ein sauberes und pflegliches Umgehen mit den Daten und Tags…

Sven.

PS: den/die “Erfinder” des Tagging-Schemas für boundary=protected_area schlage ich hiermit für den (neu zu schaffenden?) OSM-Preis des Jahres vor. Das Schema ist wirklich genial.

Nahmd,

Sorry, ich hatte “mit normalen SQL-Befehlen” und “für einen normalen Menschen” und “mit brauchbarer Performance” dazuzuschreiben vergessen. Das nehme ich per default immer als Randbedingung an.

Natürlich kann man in der IT prinzipiell alles machen. Rendere aber mal eine Karte und binde dabei eine nichttriviale Anzahl von POIs von einem fremden Server ein.

Meine Kristallkugel sagt mir, dass Du stattdessen die POIs auf den eigentlichen Server kopieren und von da nutzen wird. Und damit sind wir bei: siehe oben.

Gruß Wolf

Willst du damit eventuell andeuten, daß ich nicht “normal” bin? :wink:

Nee, gemacht hab ich das auch noch nicht aber ich weiss, dass es geht - und das reicht mir erstmal.

Deine Kristallkugel ist trüb. Wenn ich sowas machen wollte (z.B. POI einer externen DB mit OSM-Daten vom Planeten verbinden), dann würde ich auch auf Aktualität Wert legen ------- aber zum Glück steht laut Aussage meines Projektmanagers kein solches Projekt an.

Ich muß dir allerdings Recht geben: Trivial ist die Sache nicht.

Gruss
walter

Ach ja: Ich bin mein eigener Projektmanager. :wink:

Das mit Schulen innerhalb eines Wahlkreises? Ist trivial.

Man braucht nur die Schul-POI als ASCII-CSV (z.B. aus OSM-Export)
und das Wahlkreis-Shapefile.
Dann ist das für mich ein Einzeiler mit dem Punkt-in-Polygon-Filter.
Das Ergebnis kann anschließend auf Knopfdruck in Google Earth visualisiert werden,
das Shapefile gleich dazu (Shapefile → KML-Polygonfläche), inklusive Beschriftung.
Dieses Vorgehen kenne ich von viel größeren POI-Dateien, wo ich die
Filterung zur Datenreduktion benutzt hatte (weil sonst das Navigator-Gerät
bei der großen POI-Datei zu langsam wurde).

Wenn so etwas exotische Sonderfälle sind, würde ich mich damit
begnügen und nicht den Aufwand einer OSM-Integration betreiben.

Wenn man solche Features auf OSM einführt, macht das auch nur
Sinn, wenn die Daten vollständig sind, bei jeder Wahl von der OSM-Community
gepflegt werden und überhaupt genug Interesse da ist.

Gibt es eigentlich einen öffentlichen Datenbankrequest-Zugang?
Nach dem Motto: gib mir alle China-Restaurants als POI-CSV in 2 km Umkreis
von Punkt x,y oder innerhalb eines zu übermittelnden Polygonzuges?

Das ist doch genau das Thema der Geschichtskarte. Die POI werden doch schon serverseitig selektiert.
Selektionskriterium ist die geografische bounding box des Kartenfensters.

Oder müssen bei Openlayers zwingend alle Layer vom gleichen Server kommen?

Prinzipiell kann man doch beliebige POI-Resourcen überlagern.

Sinnvoll wäre es z.B., wenn die Hydranten-Liste nicht von OSM gepflegt wird, weil die Feuerwehr
bei sicherheitsrelevanten Angelegenheiten sowieso auf eigene Resourcen vertrauen will.
Den Normalbürger hat das ohnehin nicht zu interessieren (nicht das daraus jemand seinen Swimming-Pool füllt).
Behördliche Resourcen könnten aber nachträglich problemlos der OSM-Karte überlagert werden.

Gut, hat jetzt nichts mit heritage zu tun. Das ist nur eine Objekt-Eigenschaft und kein separates POI.

Nee, das mit den mehrfachen Datenbanken - übrigens das einzige Thema in dem es in dem entsprechenden Beitrag ging.

Vieeeeeel zu kompliziert. Sowas macht man u.A. mit QGIS: Shape einlesen, OSM-Datenbank anmelden, Query formulieren, vernünfigen Hintergrund dazu, feddich.

Teil 1 geht mit der Overpass-Api, POI im Polygon wohl (noch) nicht. Ist aber nicht meine Baustelle, da ich alles mit PostGis und natürlich QGIS mache.

Frage: was ist Google Earth und wieso sollte ich das verwenden? :wink:

Gruss
walter

Hallo Walter

In der Overpass-API gibt es die area-Anweisung und damit kann man Abfragen innerhalb eines Bereiches erledigen.
Als Beispiel siehe die Höhenpunkte in Bonn.

So eine Abfrage geht natürlich auch mit Schlüssel/Wert-Paaren, regulären Ausdrücken für den Wert und auch für den Datentyp “relation”.

Wer wie du eine Datenbank betreibt, hat natürlich weniger Notwendigkeit die Overpass-API zu benutzen. Für den Rest von uns, ist die Overpass-API ein gute Möglichkeit auf die Schnelle Abfragen zu erstellen und in Verbindung mit dem Overpass-Turbo zu testen und darzustellen.

Ein Bravo für den Entwickler
Edbert (EvanE)