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.
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.
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.
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.
Willst du damit eventuell andeuten, daß ich nicht “normal” bin?
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.
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.
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.
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…).
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.)
Das geografische POI-Filtern hatte ich für meinen Auto-Navigator gemacht. Der kann custom-POI.
QGIS ist mehr ein Tool zum Karten-zeichnen. Zum Anschauen ist es viel zu langsam
(auch wegen der lahmen WMS-Server als Hintergrundkarte).
Google Earth ist nicht so eine lahme Ente wie QGIS.
Zum Visualisieren eigener Geodaten (Punkte, Linien, Flächen, gemappte Images in KML)
ist Google Earth wirklich sehr praktisch. Bei OSM gibt es dazu noch keine vernünftige Alternative.
Man kann nicht jedesmal einen privaten Webserver aufsetzen, wenn man nur mal ein paar
Objekte aufrufen will, sei es auch nur der gefahrene GPS-Track der letzten Radtour.
Aber dafür ist QGIS auch nicht gemacht.
Sehr schön ist der Overlay der Karte des deutschen Reiches auf Google Earth. http://rumsey.s3.amazonaws.com/Germany1893.kmz
Die Vektorlayer des aktuellen Straßennetzes wird überblendet.
Mit Anpassung der Transparenz kann man die historische Karte noch mit dem aktuellen Luftbild vergleichen.
Nimm es einfach mal als Beispiel, wie flexibel, schnell und praktisch Overlays realisiert werden
können. Auch ohne Programmierarbeit oder Datenbankkopplung, rein lokal von Festplatte.
Ist sicher wesentlich besser! 
