heritage Denkmalschutz

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)

Overpass erstaunt immer wieder… Ich hab das mitgelieferte “Berge in den Dolomiten”-Beispiel abgekupfert und weiss nicht wirklich was da steht, aber es geht: alle historic=* in der Stadt München (nur um mal wieder zum Thema Denkmal zurückzuführen…).

Grüße, Max

Nahmd,

Sofern man kein CORS benutzt: ja.

Und damit verabschiede ich mich von dieser Diskussion und wende mich wieder der Anzeige von Line- und Area-Features in der GK zu.

Gruß Wolf

:sunglasses: Ist sicher wesentlich besser! :smiley:

In diesem Faden (und einigen anderen) riecht’s nämlich etwas nach Fisch.
<°)))o><

Nahmd,

Und ein Wolf interessiert sich mehr für Schafe als für (ranzigen) Fisch.

.oO( Die Weitergabe der Relations-Infos von ProcessPlanet nach ProcessWays funktioniert bereits; jetzt wird es spannend, wieviel temporären Plattenplatz (und IO-Zeit) der Aufbau der gekachelten Line-Features braucht.)

Gruß Wolf