Zum Beispiel werden Sitzbänke nicht dargestellt, obwohl sie wichtig sind: versuch mal, in der Kölner Innenstadt Dich irgendwo hinzusetzen, ohne einen Kaffee bestellen zu müssen.
Nicht die “Sammelaktion”, wie Du sie zu bezeichnen beliebst, überfrachtet die Karte. Denn OpenStreetMap ist eine einzige große Sammelaktion. Die Renderregeln entscheiden, was dargestellt wird.
Mach Dich bitte mit dem Tagging-Modell vertraut: sowohl die Stolpersteine als auch Gedenktafeln werden (korrekt) als “historic=memorial” kodiert. Deine “whitelist” existiert bereits, es gibt eine Regel zur Darstellung von “historic=memorial” in der Karte. Die Erfasser der Stolpersteine sind jetzt so nett und schreiben ein “memorial:type=stolperstein” dazu (so wie ich nach einem Vorbild in Hamburg ein “memorial:type=plate” an Gedenktafeln pappe).
Die “normalen” Memorials tragen aber kein “memorial:type=plain”. Damit kannst Du nicht die normalen per Weißliste selektieren, sondern must gezielt die speziellen unterdrücken.
Ich bin mit GPS-Gerät vorbeigefahren (von Löwenburg abwärts). Leider war es schon stockduster.
Ansonsten hätte ich die Zielkoordinaten …
Ich meinte hier auch nicht die Erfassung, sondern nur das Rendering auf der Standardkarte,
wie im Thread-Topic angegeben. Da sind die Relevanzregeln deutlich kritischer als bei der Erfassung.
Im Prinzip könnte man ja auch ein 2. Telefonbuch mit einbauen, wo zu jedem Haus Einwohner und Tel.
eingetragen werden. Naja, kann nützlich sein, wäre aber für OSM übertrieben.
Zudem müsste man datenschutzrechtliche Bedenken haben.
Ja genau. Geht doch. Dann kann man die Steine ruhig von der Hauptkarte nehmen,
wenn Interessierte die History-Layer bei Bedarf anschauen können.
Eigentlich ist es auch gut genug, dass man es direkt als Layer auf openstreetmap.de oder .org
anbieten könnte. Es wundert mich sowieso, dass zwar die Layer-Funktionalität existiert,
aber lediglich die Stammtischlocations angeboten werden.
Für Kartennutzer am interessantesten wäre vielleicht die Wikipedia-Artikel-Koordinaten.
Dann hätte man im Prinzip den Reiseführer gleich eingebaut.
Auf OsmAnd funktioniert dies bereits, sogar Offline von SD-Karte.
Im Urlaub war mir das eine große Hilfe.
Zusammen mit den Links auf die NS-Dokumentationsstätte machen die Steine auch mehr Sinn.
Ein Name alleine sagt mir noch nicht viel. Wenn es eine Story dahinter gibt, z.B.
wie im Tagebuch der Anne Frank, Fotos, Lebenswege etc., dann wäre es auch für den Unbeteiligten interessant.
Noch gibt es Überlebende, die man ausfragen könnte …
Klar, ist mir auch schon aufgefallen. Ich meinte “fast” alles. Die Renderer-Entwickler kann ich verstehen,
dass sie sich nicht mit Relevanzdebatten herumärgern wollen.
Ich kenne die Software nicht, am besten würde man Regeln ausdiskutieren, evtl. abstimmen
und dann das Konfigurationsfile ändern. Dann bräuchte man auch keine Kooperation der Softwareentwickler.
Die Parkbänke halte ich übrigens auch für relevant. Ich fahre zur Mittagspause
gerne mal mit dem Rad ins Grüne, um dort irgendwo auf einer Bank einen Snack
zu verspeisen. Da sie so dünn gesäht sind hatte ich schon ernsthaft OsmAnd bemüht
und eine Umkreis-POI-Suche auf “bench” gemacht.
Es würde mir reichen, wenn ich die Bänke bei Bedarf einblenden kann.
Wirklich? Und was ist mit den unbekannten Eintragstypen? Ich hatte es so verstanden, dass per Default dargestellt wird,
was als Typ noch unbekannt ist. Das wäre dann keine Whitelist.
Natürlich muss der Typ für das Icon irdendwie unterschieden werden.
Wenn ich die JOSM-Objekte mit der Karte vergleich ist doch im Prinzip fast alles dargestellt,
gut, das mit den unterdrückten Parkbänken kannte ich schon.
Ist eine Whitelist nicht eine Innovationsbremse? Wenn man erst lange diskutieren muss, um neue Typen
zu zeichnen? Ich fände eine Blacklist besser, nur muss man dann auch reagieren, wenn die Karte
mit wenig relevanten Objekten überfrachtet wird, die das “Stadtplan”-Bild beeinträchtigen (“Sammelaktion Stimmkreise”).
Zustimmung. Man müsste mal Umfragen unter Nutzern veranstalten, was sie von einer Karte erwarten und was nicht.
Ich finde es gut, dass in der Grundeinstellung die Restaurants und Geschäfte verzeichnet sind,
möglichst dezent mit kleinen Icons. Dafür schaut man doch auf so einen Stadtplan, oder?
Die Vorzüge von OSM sind doch gerade diese Vollständigkeit der POI.
Wenn ich im Urlaub ein Eiscafe aufsuchen möchte, ist OSM die erste Wahl. Kein Touristenstadtplan
oder Google ist so zuverlässig. Das liegt ja auch daran, dass Nutzer sofort korrigieren oder ergänzen
wenn etwas nicht stimmt. Wenn es ein neues Eiscafe gibt, oder ein altes dicht gemacht hat.
Besonders praktisch ist das unterwegs mit OsmAnd und der POI-Suchfunktion.
Von der Relevanz her würde ich Restaurants und Kneipen wichtiger
einstufen als die Klamottenläden, denn das sind Treffpunkte zu denen man sich verabredet,
oder die man bei knurrendem Magen auf Radtouren aufsuchen muss.
Bei OsmAnd kann man bestimmte POI-Ergebnislisten (Stichwort “Biergarten”) auf der Karte drüberblenden.
Zum Ursprungsthema: Ich finde diese Stolpersteine im Rendering auch ziemlich störend und würde mir wünschen, sie würden nicht standardmäßig dargestellt. Das gilt übrigens auch für andere “kleine” Gedenkobjekte, etwa die typischen Gedenktafeln an Gebäuden o.ä.
Nach meinen Begriffen fehlt da noch ein übergreifendes Tag für Objekte dieser Gruppe. Das memorial:type=stolperstein wäre zwar ein Anfang, aber imo kann man es Stil-Entwicklern nicht zumuten, jedes einzelne Kunstprojekt weltweit zu kennen und gesondert auszuwerten.
Nur kurz eingeworfen:
die Geschichtskarte ist doch ein Layer über einer Grundkarte?
Und wenn man diesen unter “Historische POI” einblendbar auf http://www.openstreetmap.org/#map darstellt, hätten alle einen Nutzen:
Wer historisches sucht blendet ihn ein. Wenn er es nicht findet, trägt er es bei OSM ein (Fehlermeldung oder direkt).
(Einträge mit weniger als 10 Vorkommen gestrichen)
Es ist keinesfalls zuzumuten, “tourism=information;information=guidepost” anders darzustellen als mit einem kleinen “i”. Kommt ja nur hunderttausendmal vor. Selbiges gilt für “tourism=information;information=board”.
Es ist auch nicht zuzumuten, ”natural=scree” zu rendern. Der Aufwand, in der Config nach “scrub” zu suchen und die zugehörigen Zeilen zu kopieren und darin scrub→scree und das Kachel-Icon auszutauschen, ist – auch wenn das Kachel-Icon für Scree seit Jahren bereitliegt – weit jenseits des einem Menschen möglichen. Dass vier Jahre dazu nicht reichen - wer könnte darob böse sein.
Kommen wir zu “historic=memorial” mit dem subtag “memorial:type”:
Auch hier ist völlig unzumutbar, auf “stolperstein” oder “plate|plaque” abzufragen und anders, ab anderer Zoomstufe oder gar nicht zu rendern.
Mein Vorschlag: wir führen einen Tagging-Namensraum mit dem Prefix “css:” ein. Dann können wir per css:color, css:width, css:border, css:background beliebige Objekte frei gestalten, ohne dass wir den Kartenentwicklern Änderungen an ihren Renderregeln zumuten müssten. Ähnlich wie die Angabe der Wegmarkierungssymbole.
Doch halt! Ich vergaß: wir taggen ja nicht für die Renderer. Mist!
Aber irgendwas ist ja immer…
Gruß Wolf
PS: und mein herzlicher Dank an die Kartenentwickler, die gelegentliche Ergänzungen der Renderregeln nicht als Zumutung ansehen.
Ich schätze, die Stolpersteine als historic=memorial sind einfach nur so “durchgerutscht”. Es hat ja auch niemand wissen können, daß es einmal soviele Memorials auf einem Fleck geben würde.
Genau da liegt der Hase im Pfeffer; das Teil ist inzwischen einfach überfrachtet. Und das Problem ist nicht nur auf die Stolpersteine beschränkt - wenn ich nur an die Wahlkreise denke
Was uns fehlt, ist eine Möglichkeit über einer “neutraleren” Mapnik-Basis-Karte Overlays darzustellen - und zwar vom OSM-Server aus. Dazu müsste man bestimmte Objektklassen aus den Rendering-Rules entfernen und gleichzeitig als WMS-Overlay zur Verfügung stellen.
Sowas wurde z.B. in dieser Karte gemacht. Links ein aufklappbares Menu mit dutzenden einschaltbarer Layer und als Basis eine neutrale auf Osm basierende Karte von Mapquest.
Beispiele:
Basiskarte
Basiskarte + Großstädte
Basiskarte + Bundesstaaten + Großstädte
Straßen von Medford
Basiskarte + Straßen von Medford
Ich hoffe, eure Phantasie reicht soweit, gedanklich aus “Bundestaaten” Wahlḱreise und aus “Großstädten” Stolpersteine zu machen.
Sowas ließe sich - zumindestens für Demo-Zwecke - auf openstreetmap.de realisieren. Da sind wir ja wirklich unser “eigener Herr”, oder?
Gruss
walter
p.s. Ich helfe natürlich gerne mit. Eine lokale Germany-DB mit osm2pgsql baue ich gerade auf, damit ich “mitreden” kann und “mein” Overlay auch auf openstreetmap.de funktionieren könnte. Mit einer Snapshot-DB macht das natürlich keinen Sinn.
Du wirfst hier Dinge, die die Stil-Entwickler durchaus tun sollten, aber bisher nicht getan haben (und sonst auch niemand - oder gibt es fertige pull-requests für diese Kritikpunkte?) in einen Topf mit Tags, die viel zu feingranular für eine brauchbare Auswertung sind.
Wären die Stolpersteine als “ground_plaque” o.ä. getaggt, wäre ich eher für Extra-Regel im Stil. Aber memorial:type=stolperstein ist wie shop=aldi. Das passt einfach vom Datenmodell her nicht: “Stolperstein” ist ein bestimmtes Projekt, kein Gattungsbegriff.
Wir müssen aber sorgsam 3 Arten von Overlays unterscheiden:
Serverseitig: der Server bietet für alle Overlay-Kombinationen verschiede Tileserver-Resourcen an
Rasteroverlay:
es wird auf einer Hintergrundkarte (Rasterkarte vom Tileserver)
eine weitere Rasterkarte gelegt, mit Alphakanal (der den Transparenzwert angibt).
Meist sind dafür genau so viele Pixel nötig wie für die Untergrundkarte (Google Earth kann es auch stretchen).
Der Server muss mehere Raster-Layer übermitteln, der Client erreichnet das Overlay.
Vektoroverlay:
Vom Server werden lediglich Vektordaten übermittelt, sehr datensparsam,
und der Client (Browser/Javascript, JOSM oder Anzeigeprogramm wie GoogleEarth/Marble etc.)
macht das Rendering lokal. Der Server wird also vom Rendering entlastet.
Der Vorteil des serverseitigen Renderns ist der, dass die Objekte besser in das Bild eingebettet werden können,
z.B. der weiße Rand um die Schrift, günstiges Platzieren der Beschriftung (Stolperstein-Schrift neben Straßennamen).
Beim clientseitigen Rasteroverlay hätte man das Platzierungsproblem, da es dann quasi für mehrere
Rasterebenen queroptimiert werden muss.
Das Vektoroverlay hätte auch ein Verdeckungs- und Platzierungsproblem. Ansonsten wäre es
natürlich am flexibelsten. Vektorobjekte könnten auch schön angeklickt werden, um Fotos zu schaun etc.
(wie im Beispiel der Geschichtskarte.
WMS ist immer ein Rasteroverlay, oder?
Da hätten wir dann ein Performance- und Speicherplatzproblem.
Für jede Tile-Layer müsste der Server berechnen und Daten vorhalten.
Gut, falls nur wenige Leute die Geschichtslayer benutzen ist die Last kleiner,
die Caches können kleiner ausfallen.
Aber da OSM nunmal nicht die großen Servercluster hat wie Google, fürchte ich,
das würde die vorhandenen Resourcen überschreiten. Zumal OSM bisher noch kaum
genutzt wird - fast alle die ich kenne schauen nur auf Google Maps.
Wenn OSM beliebter wird könnte die Last extrem zunehmen.
Es sollte nicht unbedingt die Geschwindigkeit beim Zappen durch die Hauptkarte
negativ beeinflussen.
Es hängt auch etwas vom Typ des Overlays ab. POI lassen sich gut
als Vektorlayer einfach drüberzeichnen.
Für das Rendering der Fahrradwege (OpenCycleMap) könnte das
schwieriger werden.
Der Grundsatz “wir taggen ja nicht für die Renderer” ist richtig.
Aber man könnte durchaus die Renderer durch Zusatzinformationen helfen.
Etwas grundsätzliches wäre ein Tag wie “map_display=true/false”.
Oder gibt’s das schon?
Das würde dem Mapper die Gelegenheit geben, etwas Besonderes in den
Datenbestand einzutragen, wo er aber gleich weiß, dass es blöde auf der Karte aussehen würde.
So wie die Wahlkreise. Also Objekte, die eine Sonderanwendung darstellen aber niemals
auf normalen Karten erscheinen sollten. Nur aus dem Grund, dass man vielleicht
irgendwelche Relationen zu OSM-Objekten pflegen will.
Der Renderer könnte das zusätzlich zu seiner eigenen Einstellung berücksichtigen.
Interessant wäre solch ein Tag auch für die Situation, dass man in der Datenbank bestimmte
Dinge vorbereiten will. Z.b. wenn es Baupläne für ein neues Stadtschloß gibt.
Solange es noch nicht existiert will man es sicher nicht auf der Karte darstellen.
Und wenn es steht kann man das Flag umdrehen.
Oder für den Fall, dass das Rendering scheiße aussieht, man die Kartennutzer
nicht nerven will, aber trotzdem die Daten erstmal in der Datenbank lagern will,
bis das Rendering-Problem beseitigt ist.
Ich finde die Texte auf den Stolpersteine für die OSM-Datenbank zu speziell.
Sie wären in einer gesonderten Datenbank besser aufgehoben (wenn eine durchsuchbare
Datenbank dem Grundgedanken des Kunstwerks überhaupt angemessen ist). Verzichtet
man auf die Texte, dann kann man direkt nebeneinander liegende Stolpersteine zum
einem Punkt und Angabe der Zahl zusammenfassen.
Wenn man Namen und Volltexte für ein Projekt aufnimmt, kann man es für andere nicht
verbieten. Es gibt in fast jedem Dorf eine Gedenkstätte mit vielen Namen und reichlich
Messingtafeln an Gebäuden zur Erinnerung an ehemalige Bewohner. Die Texte mancher
Gedenkstätten enthalten Aussagen, die ich nicht in jeder Datenbankkopie haben möchte.
Das bei den Stolpersteinen oft verwendete “name”-tag ist auch nicht korrekt, da nicht der
Stein so heißt, sondern die Person, an die erinnert wird. Der Mißbrauch des “name”-Tags
ist allerdings ein generelles Problem in OSM.
Wir könnten überlegen, wie man historic=memorial in Gedenkstätte, Denkmal und
Gedenktafel/-stein differenzieren kann. Eine Renderregel für Stolpersteine wird es für
weltweite Karten kaum geben, eine zur Unterscheidung von Gedenkstätte und Gedenktafel
vielleicht schon.
Es gab schon Tags zur Beeinflussung des Rendering (“osmarender:renderName” etc.).
Die sind glücklicherweise fast ausgestorben. Eine gute Klassifizierung der Objekte sollte
ausreichen. Dann kann der Kartenersteller festlegen, was er in welchem Maßstab anzeigen
will.
Allerdings hat OSM weltweit einen Revolution der elektronisch verfügbaren POI ausgelöst. Es ist mittlerweile nicht mehr nur eine Karte, sondern auch eine POI-Sammlung. Wenn man bedenkt wie ärmlich die Vorläufer waren. Es gab schon freie POI-Sammlungen, und kommerzielle. Sammelaktionen wie die Aldi’s des Republik waren sogar vollständig. Aber alles war weit entfernt von einem Kneipen-, Restaurant- oder Einkaufsführer. Da fehlte einfach zu viel. Es war einfach nicht zuverlässig, da nachzuschlagen, wo am Urlaubsort das nächste Strandcafe ist. Mit OSM hat sich das grundlegend geändert. Man muss an vielen Stellen schon suchen, um überhaupt noch ein vergessenes Eiscafe zu finden. Und wo ich in Urlaub war ist die Datenbank auch wieder aktuell …
Das ist einfach ein großer Nutzwert. Karten gibt es viele. Aber Karten wo ich den nächsten Friseur, das nächste Indische Restaurant finde … welche Alternativen gibt es da schon zu OSM? Google ist zwar auch gut, kommt aber beim Datenumfang nicht an OSM heran. Lediglich die Verlinkung dort ist besser gelöst, wo man auf Mausklick weitere Informationen zum POI bekommt, z.B. Tel., Homepage, Foto.
Also dieses Feature von OSM sollte unbedingt erhalten und gefördert werden. Ob das alles in eine Datenbank gehört ist für den Nutzer erstmal weniger wichtig. Für ihn zählt nur die Kartendarstellung (und evtl. die Editiermöglichkeiten darin).
Im Softare-Engineering hat man den Grundsatz, möglichst zu faktorisieren. Also ein Programm in unabhängige Module aufzuteilen, die unabhängig voneinander entwickelt und getestet werden. Ich könnte mir gut vorstellen, die OSM-Daten in zwei unabhängige Teile zu spalten, die Karte an sich und eine POI-Sammlung. Ich weiss nur nicht wie man das mit der Hausbindung macht. Manchmal werden Restaurants als POI-Punkt platziert und manchmal ein Hausumriss, also eine Fläche, mit Restaurantnamen bezeichnet. So ganz glücklich ist das nicht. Für einen Restaurantführer (POI auf Karte oder in Suchfunktion) wäre es günstiger eine einheitliche Kodierung zu finden. Eigentlich reicht ja eine Koordinate pro POI. Die konkrete Hausform ist nur für die Kartenzeichnung relevant.
Ansonsten finde ich weniger Begeisterung daran, würde sie also nicht
anhand eines Stadtplans gezielt aufsuchen. Dafür erzählen sie einfach zu wenig.
Wer sich wirklich erinnern will, sollte vielleicht das Tagebuch lesen,
oder die gelungene filmische Umsetzung anschauen: https://www.youtube.com/watch?v=dBXV33g7Uag
Stimmt natürlich, WMS-Layer war zu pauschal. Ich meinte Overlays im Allgemeinen und dabei ist die Technik eigentlich irrelevant - Hauptsache die Daten sind nicht starr in die Basiskarte integriert.
Soweit ich weiss, ja. Allerdings fällt das nicht so auf, wenn man transparenten Hintergrund verwendet.
Da mach ich mir nicht allzu viele Sorgen. Speicher wird billiger (40€/TB ist schon machbar). Außerdem ist die Serverlast gut zu skalieren, indem mehrere Server nach Bedarf parallel schaffen können. Zudem werden die Basis-Renderer entlastet, da sie sich um viele Objekte nicht mehr kümmern müssen.
Stimmt. Und dann noch Clustering dazu, dann sieht das richtig gut aus.
Mein Vorschlag bezieht sich nur auf “unsere” Mapnik-Karte - genau dort haben wir ja diese Relevanz-Diskussionen und den “K(r)ampf” um die darzustellenden Objekte/Daten. Wenn wir diese Auswahl dem Enduser überlassen, sind wir den Stress los und der User ist happy - hoffe ich zumindest.
Die Sache ist wirklich noch nicht ausgegoren, aber ich finde man sollte mal drüber nachdenken - und es mal ausprobieren.
Dazu gehört auch -mal wieder- ein Blick über den Tellerrand. Man sollte wirklich mal genauer hinsehen, was im GEO-Umfeld mit OSM-Daten inzwischen angestellt wird. Ich habe das Gefühl, viele von uns sind irgendwie in dem “Renderer-Schema” gefangen. Da werden Mapnik mit Mapquest oder Cyclemap verglichen, ein eigenes Schema entwickelt und eventuell ein bis zwei Overlays drübergelegt. Das war es dann. (*) Die wirklich innovativen Anwendungen bemerkt man aber überhaupt nicht.
Solange ich nur Äpfel mit Äpfeln vergleiche komme ich nie drauf, daß Birnen auch gut schmecken können - von Bananen oder Feigen garnicht zu sprechen.
Gruss
walter
*) gilt natürlich auch für meine PLZ- und Missing Residentials-Karten. Allerdings sehe ich die als QA-Tool, bei denen der Look total unwichtig ist.
Klar, weil an genau dieser Stelle die Registrierkasse von Google klingelt. Jeder Klick auf einen POI kann Kohle bringen.
Wenn wir mehr als eine DB haben wollten, müssten wir erst das Problem die Verlinkung lösen:
Objekte in OSM haben eine ID, die sich jederzeit ändern kann. Wenn die ID als Link zwischen den beiden DB genommen wird und jetzt ein POI gelöscht/neu angelegt wird (*) , ist plötzlich die Verknüpfung futsch. Ansätze, OSM-Objekten zusätzlich eine unveränderliche UUID zu geben, sind gescheitert. Wenn ein Mapper ein Objekt löscht und danach neu einträgt, kann ihn niemand “zwingen”, die UUID des alten Objektes mitzuschleppen. Und schon sind die erweiterten Informationen verloren.
Das ist wohl nur eine Frage der Abfrage. POI können ja Nodes sein oder sich in Ways/Relationen verstecken. Eventuell könnte man dazu die API aufbohren sodaß nicht jeder Entwickler das Rad (“wie finde ich meine POI?”) neu erfinden muß. Gut sehen kann man das ja bei der zunehmenden Verwendung der Overpass-API. Dort werden derzeit ja die Techniken mit dem UNION-Befehl propagiert. In SQL gibt es das schon lange aber es ist dennoch äußerst lästig, bei jeder Query alle drei Objekttypen abfragen zu müssen. Performant ist das auch nicht gerade.
Gruss
walter
*) Das geschieht häufig wenn die Daten eines POI-Nodes an den Way des Buildings oder gar an die Relation einer Site geschoben werden. Node weg → ID weg → Link weg → Daten weg
Zum einen ist die Beschäftigung mit dem Thema allgemein und die Aufarbeitung konkret für die Opfer eine wichtige Arbeit und da machen auch viele Schulen mit.
Zum anderen ist es natürlich wichtig, das das sehen eines Steins neugierig machen soll und man in Zukunft leichter zu weiteren Infos kommen kann. Es gibt schon mehrere Apps zum Thema, die meines Wissens nach derzeit aber immer nur die Geschichte einer Stadt (Berlin) oder evtl. eines größeren Umfelds (im Saarland) unterstützen.
Wir (einige bei OSM) versuchen auch gerade, die weiteren Infos bereitzustellen. Das kann so erfolgen, das wir die Links auf im Netz vorhandene Biografien ergänzen oder evtl. auch eine zentrale Biografiesammlung bereitstellen. Das ist aber noch im frühnen Planungszustand.
Wenn jemand eine Stolpersteinverlegung mitmacht, ist das auch prägend. Da sind öfters Schulklassen dabei und ich habe schon Nachkommen der Opfer gesehen, die aus den USA oder Israel nur zur Verlegung angeflogen kamen.
Es gibt Einzelschicksale, die aufbereitet wurden und sehr eindringlich sind. Auf der anderen Seite gibt es die immensen Opferzahlen, die kaum fassbar sind.
Die Stolpersteine versuchen die Verbindung herzustellen. Ich finde, das klappt in einem Ort auch ganz gut.
Was mir fehlt, ist die Darstellung des Gesamt “Kunstwerks” (für mich ist es eher ein Erinnerungswerk). Da können wir gerade in OSM die ganze Bandbreite des Werks zeigen. Im Ort die verlegten Steine, vor welchen Gebäuden bin hin komplett herausgezoomt das die in 16 Ländern verlegt sind (wenn wir sie mal in OSM haben).
Traditionell ist ein POI in GPS-Anwendungen einfach nur ein Punkt, d.h. eine WGS84-Koordinate, wie schon der Name “point” of interest sagt. So gesehen besteht dann gar nicht die Notwendigkeit der Verlinkung. Solche Datenbanken könnte man dann unabhängig voneinander führen, separat überlagern, in der Karte auch aus unterschiedlichen Resourcen zusammenführen. Da gibt’s ja auch schon viele POI-Sammlungen, z.b. die beliebten “Blitzer-POI”.
Davon habe ich selbst sehr viele, Tankstellen-POI, Campingplatz-POI etc. Die werden üblicherweise als ASCII-Koordinatenlisten (CSV) geführt. Sehr schön, man kann diese Dateien beliebig hin- und herkopieren. Es gibt viele Public-Domain Sammlungen. Und über Konverter können solche POI auch in die kommerziellen Auto-Navigationssysteme eingespielt werden (TomTom, Navigon, GoPal, etc.). OSM-basierte Navis sind noch nicht so zuverlässig wie die Kommerziellen.
Bei OSM habe ich zum ersten Mal gesehen, dass auch anderen geometrischen Formen, z.B. einem Haus-Polygon, Eigenschaften wie Restaurant-Name etc. zugeschrieben werden. Prinzipiell Ok, aber jetzt haben wir damit ein Durcheinander von “echten” POI und Objekt-impliziten POI. Für die Systematik wäre es günstiger, man hätte die POI irgendwie einheitlicher. Auch für Mapper-Neulinge ist es verwirrend, ob man nun dem Haus die Restaurant-Daten hereinschreiben soll, oder dafür separat einen POI-Punkt überlagern soll.
Ich hab jetzt auch kein Patentrezept wie man das am besten löst. Man könnte auch sagen, die POI-Eigenschaften eines Restaurants kommen grundsätzlich in einen “POI-Punkt”, den man über den Hausgrundriß legt. Das verlinkt dann die Daten noch nicht, aber über die Koordinate ist die Beziehung dann eigentlich klar. Ohnehin wäre es falsch, ein Haus mit mehreren Stockwerken und Restaurant im EG dann komplett mit den Restaurant-Daten zu markieren. Die “POI-Punkte” könnten komplett unabhängig von den anderen OSM-Kartendaten verwaltet werden. Unabhängigkeit schafft Vereinfachung. Vor allem lassen sich so auch unterschiedliche Projekte aus verschiedenen Internet-Quellen verheiraten. Beispielsweise könnte das Stolperstein-Projekt eine eigene Datenbank aufbauen und die entsprechenden POI einer Overlay-Layer zuführen, darin dann gleich die Freiheiten nutzen, die Daten beliebig zu strukturien, z.B. kurze Biographien der Personen mit einzuspeichern. Es würde die Verwaltung von OSM erheblich entlasten, wenn OSM quasi nur die Grundkarte bereitstellt und sich darum herum eine freie Infrastruktur an Overlays bilden kann. Das hindert auch keinen daran, fremde Daten auf der openstreetmap.org Homepage wieder als optionale Layer anzubieten.
Natürlich soll OSM auch weiterhin eine POI-Sammlung bleiben. Ich denke diese Vollständigkeit kommt gerade dadurch zustande, daß Leute auf der Karte ein POI vermissen, z.B. ein Restaurant, und dann einfach über den “Bearbeiten”-Knopf das nachtragen können. Die bisherigen freien POI-Sammlungen hatten nicht diese einfache und einladende Kollaborationsmöglichkeit. Wohl auch ein Grund, warum sie nie wirklich brauchbar wurden. Die Campingplatz-POI waren so unvollständig, dass man doch wieder einen Campingatlas kaufen musste, um keinen schönen Platz zu verpassen. Vollständigkeit haben die POI-Listen nur da bekommen, wo es systematische Sammel- oder Konvertieraktionen gab. Die Aldi-POI oder Aral-Tankstellen-POI kamen sicherlich aus einer anderen Datenbank und wurden vollständig umgesetzt. Da wo die POI einzeln zusammengetragen werden mussten kam dann auch nichts brauchbares zustande. OSM ist diesbezüglich wirklich revolutionär.
Eine solche Vereinheitlichung ist so oder so problematisch. Eigentlich sollten natürlich die meisten “POI” (im OSM-Kontext ist der Begriff natürlich verwirrend) bevorzugt als Fläche erfasst werden, nur ist der reine Punkt eben deutlich weniger Arbeit. Umgekehrt bei der Standardisierung auf einen Punkt würde man verschiedene Möglichkeiten zur Detailerfassung verlieren: Mehrere Eingänge beispielsweise, die Zuordnung mehrerer Gebäude zu einem größeren Gelände oder die Integration mit Indoor-Mapping.
Allgemein ist so etwas fast immer das Hindernis für verschiedene Datenbanken, Daten-Ebenen oder ähnliche Konzepte, bestimmte Daten gesondert abzulegen. Solang man mit einer einfachen Lösung zufrieden ist, scheint die Trennung möglich. Aber bestimmte Anwendungen brauchen dann eben doch wieder zusätzliche Details. Daher hat bisher das Auslagern nur dort geklappt, wo es existierende externe Datenbanken mit (relativ) stabilen IDs gibt.
Bei der christdemokratischen Wallfahrtsstätte kommst Du ein Jahr zu spät. Das Tagging hat freilich keine sieben Stunden durchgehalten.
Aber an den Wegen kannst Du Dich noch austoben
