Rendering der Stolpersteine

Wenn ich's richtig verstanden habe kann (oder will 😉 ) Mapnik nicht nach subtags (in dem Fall: memorial:type=stolperstein)
unterscheiden, somit werden alle memorials gleich gerendert.

Bei den "Stolpersteinen" hätte man von Anfang auch Gruppenobjekte anlegen sollen. So hat man z.B. vier Stolpersteine auf engstem Raum. Alles korrekt erfaßt, aber darstellen kann man das nicht mehr gut ... woran übrigens die Darstellung in der Freizeitkarte gescheitert ist. Aber vielleicht überlegen sich die Kollegen noch was dazu.

Gruß Klaus

Nahmd,

openzzz wrote:

Hat sich eigentlich mal jemand Gedanken gemacht, ob all die Stolpersteine auf
der Standardkarte von openstreetmap.org gerendert werden sollen?

Wenn man jedem der 6 Millionen Kriegstoten einen eigenen virtuellen Grabstein
auf der Karte spendiert würde das ganz schön voll werden.

In DE sind um die 25000 verlegt. In Köln etwa 2000, davon sind die ca. 500 innerhalb der Ringe vollständig erfasst. Also ganz so schlimm ist es nicht.

Hier mal ein Beispiel in typischem Straßenansichts-Zoom:
http://www.openstreetmap.org/#map=18/50.92034/6.96010

Ich persönlich finde die Stolpersteine viel zu dominant in der Karte.
Die stehen da quasi auf einer Priorität mit öffentlichen Einrichtungen, Restaurants,
oder auch den "großen" Denkmälern.

So wirds gemacht: auf Zoom=15 werden sie nicht dargestellt; sie tauchen erst bei Zoom=16 auf und werden deutlich dezenter dargestellt als die “historic=memorial” ohne das Zusatztag. Ebenso wie Gedenktafeln.

Von einem Stadtplan wünsche ich mir, dass die Sachen verzeichnet werden,
die das Wegenetz komplett wiedergeben (inkl. der kleinen Fußwege),
architektonische Features, Häuser und bei den POI eben Punkte öffentlichen
Interesses. Also POI die man aufsuchen würde, z.B. Denkmäler, öffentliche
Einrichtungen, Geschäfte, Unternehmen (als Abbild der "yellow pages"), etc.

Willkommen im Club.

Ob man die Sachen in der Datenbank speichern will oder nicht ist eine andere
Frage.

Ob sie gespeichert werden, ist überhaupt keine Frage. Die sind in der Realität da. Von jedem zu überprüfen. Also dürfen sie in die Datenbank. Es bleibt nur die Frage, ob man sie erfasst. Die aber beantwortet jeder sich selbst, und eine Diskussion darüber ist sinnfrei.

Ich wollte nur mal fragen, ob wir das wirklich auf der Standardkarte haben wollen.

Auf niedrigen Zoom-Leveln? Eher nicht.
Auf sehr hohen Zoom-Leveln: wozu haben wir denn Zoom 19?

Die ganze Diskussion ist allerdings müßig, da die Mapnik-Verwalter nur schleppend bis gar nicht reagieren.¹ .

Gruß Wolf

¹) Wobei das nach der Umstellung des Renderes und die neue Config ja besser werden soll. Die Hoffnung stirbt bekanntlich zuletzt.

Nahmd,

toc-rox wrote:

Bei den "Stolpersteinen" hätte man von Anfang auch Gruppenobjekte anlegen sollen. So hat man z.B. vier Stolpersteine auf engstem Raum.

Das Problem tritt auch bei anderen Objekten auf.

Vielleicht sollte man man einen Teil des gespendeten Geldes einmal nicht für Hardware raushauen, sondern jemanden dafür bezahlen, das unangenehme und bei OSM stiefmütterlich behandelte, aber so wichtige Thema Generalisierung endlich mal anzugehen?

Gruß Wolf

Hallo,

wir hatten letztes Wochenende auf dem Karlsruher Hack Weekend kurz über die Stolpersteine geredet, weil ich einige nebenbei in Karlsruhe abends erfasst habe.

Das Tagging historic=memorial ist eigentlich nicht richtig, weil die Steine selbst ja nicht historisch sind, sondern aktuelle Gedenksteine (seit 1996 einzeln verlegt, ab ca. 2003 regulär) zu den Opferns des NS-Regimes.

Die Objekte sind ja per Subtag memorial:type=stolperstein eindeutig erkennbar. Und entweder die Renderregeln würden dieses Sub-Tag berücksichtigen und/oder wir könnten auch ein anderes Haupttag verwenden. In der OSM Hauptkarte müssen die auch aus meiner Sicht nicht sichtbar sein.

Insgesamt sind es derzeit 42.000 Steine in 16 Ländern, allerdings der größte Teil in Deutschland und wohl einige Hundert in den Niederlanden.

Die Erfassung jedes einzelnen Steins mache ich auch, weil jeder Stein an ein individuelles Opfer erinnern, das sollte unbedingt beibehalten werden.

Ich würde vorschlagen, es macht jemand ein Ticket in dem Github-Projekt für die Hauptkarte auf und wir warten, ob es evtl. kurzfristig gelöst wird.

Wenn da nichts passiert, könnten wir ein alternatives Tagging überlegen. Ein neues Haupttag, speziell für Stolpersteine, wäre wohl übertrieben, da müssten wir wohl überlegen, welche anderen Objekte über historische Fakten dann ähnlich zu handhaben wären (allgemein Gedenkmäler, die auch nicht historisch alt sind?)

Zum Beispielgebiet in Köln: sorry, da fehlen noch etliche, aber die kriegen wir hoffentlich auch noch in OSM 😉

Viele Grüße

Dietmar

openzzz wrote:

6 Millionen Kriegstoten

Bei Deiner Formulierung läufts mir eiskalt den Rücken runter. 6 Millionen Tote eines Völkermordes wäre wohl ehrlicher.

PT-53 wrote:

openzzz wrote:

6 Millionen Kriegstoten

Bei Deiner Formulierung läufts mir eiskalt den Rücken runter. 6 Millionen Tote eines Völkermordes wäre wohl ehrlicher.

Sorry, hatte die falschen Zahlen im Kopf. Ich meinte ca. 60 Millionen Kriegstote, davon ca. 6 Millionen aus dem Holocaust.
Die bisherigen Stolpersteine decken wohl nur einen winzigen Teil der jüdischen Opfer ab.
Wie gesagt, gegen die Stolpersteine an sich habe ich nichts, als Gedenkstein am betreffenden Haus.
Die Sache ist nur, ob wir das unbedingt im Standard-Stadtplan von OSM darstellen müssen.
Zoomlevel 19 ginge vielleicht noch, aber in der City-Übersicht finde ich das zu unübersichtlich.
Typischerweise besucht man die auch nicht gezielt auf touristischen Exkursionen, anders als die
großen Mahnmale wie z.B. das Völkerschlachtdenkmal.
Wenn man in Hiroshima für jedes Opfer der Atombombe einen OSM-Eintrag in der Karte darstellen
würde, was meint ihr wie viel man dann noch von der Stadt an sich sieht?
OSM ist schließlich kein Friedhofsführer. Würdet ihr auch für deutsche Friedhöfe die Grabsteine
namentlich erfassen?

Analog in Wikipedia gibt es auch Relevanzregeln, dass keine Artikel über gewöhnliche
Einzelpersonen geschrieben werden. Relevanzregel ist, dass ein Artikel enzyklopädisch sein soll.
Das müssten dann schon Personen öffentlichen Interesses sein. Manchmal finden sich auch
unbekannte Professoren darin. Naja, ist halt schwer da eine Grenze zu ziehen.

Für OSM wünsche ich mir die Hauptkarte auf openstreetmap.org als besseren Stadtplan (in der Stadt)
bzw. als die bessere topografische Karte (für das Land).
Ich finde an diesen "Originalen" sollte man sich orientieren. An der Nützlichkeit der Darstellung.
Man könnte ja auch noch viele andere Gedenksteine aufnehmen, die so an den Häuserwänden hängen.

Warum nicht einfach als Spezialkarte, oder als Overlay mit den OpenLayers?

Auf der Hauptkarte könnten Gedenksteine doch einfach herausgefiltert werden, oder?
Im Prinzip finde ich die Render-Regel, alles darzustellen schon Ok, für das was man bisher sieht.
Außer ein paar "Sammelaktionen", die die Karte optisch überfrachten -> würde für eine
Blacklist statt einer Whitelist sprechen.

openzzz wrote:

Wenn man in Hiroshima für jedes Opfer der Atombombe einen OSM-Eintrag in der Karte darstellen
würde, was meint ihr wie viel man dann noch von der Stadt an sich sieht?
OSM ist schließlich kein Friedhofsführer. Würdet ihr auch für deutsche Friedhöfe die Grabsteine
namentlich erfassen?

-1 ... die Vergleich missfallen

Gruß Klaus

Von einem Stadtplan wünsche ich mir, dass die Sachen verzeichnet werden,
die das Wegenetz komplett wiedergeben (inkl. der kleinen Fußwege),
architektonische Features, Häuser und bei den POI eben Punkte öffentlichen
Interesses. Also POI die man aufsuchen würde, z.B. Denkmäler, öffentliche
Einrichtungen, Geschäfte, Unternehmen (als Abbild der "yellow pages"), etc.

Im Zeitalter der interaktiven Möglichkeiten sollte eventuell mehr auf die Wünsche des Nutzer eingegangen werden. Es müssen nicht alle POI (Einrichtungen, Geschäfte, Denkmäler, ...) angezeigt werden.

Grundeinstellung: in größeren Zoomstufen Straßen, Wege und Gebäuden mit Eingang und Adresse - in kleineren Zoomstufen Landflächen mit Straßen. Dazu (einblendbar) eine Leiste mit (auswählbaren) POI, eventuell sortiert nach Bereichen (Gesundheit, Tourismus, Verwaltung, ...)

Moins,

Die bisherigen Stolpersteine decken wohl nur einen winzigen Teil der jüdischen Opfer ab.

Unter anderem (Thieboldsgasse 90)

openzzz wrote:

Wenn man in Hiroshima für jedes Opfer der Atombombe einen OSM-Eintrag in der Karte darstellen
würde, was meint ihr wie viel man dann noch von der Stadt an sich sieht?

Vielleicht sollten wir diese Bewertung einfach den Japanern überlassen?

OSM ist schließlich kein Friedhofsführer. Würdet ihr auch für deutsche Friedhöfe die Grabsteine
namentlich erfassen?

Du erinnerst mich daran, das ich noch die Wege auf dem Rhöndorfer Friedhof und bei der Gelegenheit das Adenauer-Grab erfassen will.

Analog in Wikipedia gibt es auch Relevanzregeln, dass keine Artikel über gewöhnliche
Einzelpersonen geschrieben werden. Relevanzregel ist, dass ein Artikel enzyklopädisch sein soll.
Das müssten dann schon Personen öffentlichen Interesses sein. Manchmal finden sich auch
unbekannte Professoren darin. Naja, ist halt schwer da eine Grenze zu ziehen.

Die Relevanzregel für OSM lautet: erfasst wird, was da ist. Was nicht heißt, dass Du es erfassen musst. Du musst aber dulden, dass es erfasst wird.

Für OSM wünsche ich mir die Hauptkarte auf openstreetmap.org als besseren Stadtplan (in der Stadt)
bzw. als die bessere topografische Karte (für das Land).
Ich finde an diesen "Originalen" sollte man sich orientieren. An der Nützlichkeit der Darstellung.
Man könnte ja auch noch viele andere Gedenksteine aufnehmen, die so an den Häuserwänden hängen.

Ich bin dabei.

Warum nicht einfach als Spezialkarte, oder als Overlay mit den OpenLayers?

Ach was.

Auf der Hauptkarte könnten Gedenksteine doch einfach herausgefiltert werden, oder?

Radio Eriwan antwortet: “im Prinzip ja”.

Im Prinzip finde ich die Render-Regel, alles darzustellen schon Ok, für das was man bisher sieht.

Es gibt keine Renderregel, “alles darzustellen”.

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.

Außer ein paar "Sammelaktionen", die die Karte optisch überfrachten.

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.

-> würde für eine Blacklist statt einer Whitelist sprechen.

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.

Gruß Wolf

mir sind die stolpersteine auch unwichtig bis egal, bzw. je nach zoom aber auch störend.

Netzwolf wrote:

Moins,
Du erinnerst mich daran, das ich noch die Wege auf dem Rhöndorfer Friedhof und bei der Gelegenheit das Adenauer-Grab erfassen will.

Ich bin mit GPS-Gerät vorbeigefahren (von Löwenburg abwärts). Leider war es schon stockduster.
Ansonsten hätte ich die Zielkoordinaten ...

Die Relevanzregel für OSM lautet: erfasst wird, was da ist. Was nicht heißt, dass Du es erfassen musst. Du musst aber dulden, dass es erfasst wird.

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.

Warum nicht einfach als Spezialkarte, oder als Overlay mit den OpenLayers?
http://www.netzwolf.info/kartografie/osm/stolpersteine?zoom=16&lat=50.93749&lon=6.95802&layers.

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

Es gibt keine Renderregel, “alles darzustellen”.
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.

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.

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.
Gruß Wolf

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

geri-oc wrote:

Von einem Stadtplan wünsche ich mir, dass die Sachen verzeichnet werden,
die das Wegenetz komplett wiedergeben (inkl. der kleinen Fußwege),
architektonische Features, Häuser und bei den POI eben Punkte öffentlichen
Interesses. Also POI die man aufsuchen würde, z.B. Denkmäler, öffentliche
Einrichtungen, Geschäfte, Unternehmen (als Abbild der "yellow pages"), etc.

Im Zeitalter der interaktiven Möglichkeiten sollte eventuell mehr auf die Wünsche des Nutzer eingegangen werden. Es müssen nicht alle POI (Einrichtungen, Geschäfte, Denkmäler, ...) angezeigt werden.

Grundeinstellung: in größeren Zoomstufen Straßen, Wege und Gebäuden mit Eingang und Adresse - in kleineren Zoomstufen Landflächen mit Straßen. Dazu (einblendbar) eine Leiste mit (auswählbaren) POI, eventuell sortiert nach Bereichen (Gesundheit, Tourismus, Verwaltung, ...)

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.

Stimmt, das hier ist schon gewöhnungsbedürftig
http://www.openstreetmap.org/#map=18/50.93881/6.95649
Aber was erwartet man schon von der Einkaufsstraße.

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

Nahmd,

Tordanik wrote:

aber imo kann man es Stil-Entwicklern nicht zumuten, jedes einzelne Kunstprojekt weltweit zu kennen und gesondert auszuwerten.

Man kann den “Stil-Entwicklern” im Grunde nicht zumuten, überhaupt irgendetwas zu ändern. Auch nicht, wenn es bereits zigtausen mal genutzt wird.

Beispiel “tourism=information”, subfeld “information=”:

␣22174␣-
92␣audioguide
126␣bicyclemap
32␣blue_plaque
34208␣board
10␣board;audioguide
61␣board;map
459␣citymap
106462␣guidepost
12␣guide_post
28␣guidepost;map
917␣hikingmap
500␣history
53␣info_board
20628␣map
99␣map_board
26␣map;board
819␣nature
6663␣office
27␣orientation_map
12␣pistemap
22␣plaque
30␣sign
26␣signpost
23␣sitemap
53␣tactile_map
69␣tactile_model
372␣terminal
3113␣trail_blaze
20␣viewpoint_indicator
127␣wildlife

(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”.

Beispiel “natural=”:

␣␣␣236␣arete
62146␣bare_rock
31558␣bay
68462␣beach
491␣bedrock
518␣C3061
105␣C3081
167␣caldera
122␣canyon
2152␣cape
101␣cave
11465␣cave_entrance
134963␣cliff
751968␣coastline
184␣coastline_old
208␣col
716␣crater
728␣desert
812␣dune
181␣feature
7564␣fell
164␣field
176␣fjord
195␣food_bush
918␣forest
126␣geyser
20916␣glacier
2664␣grass
48087␣grassland
193␣headland
70979␣heath
383␣hedge
162␣high-water
1183␣hill
290␣hills
1100␣island
115␣islet
37628␣land
3865␣landform
133␣landslide
215␣lava
12515␣marsh
850␣meadow
109␣moor
6268␣mud
108␣oasis
157␣oilfield
800␣old_coasline_import
321␣old_coastline_import
470␣old_coasttline_import
274373␣peak
202␣peaks
106␣plant
431␣point
4552␣reef
4505␣ridge
992␣riverbank
223␣riverbed
142598␣rock
418␣rock_outcrop
536␣rocks
1240␣saddle
26386␣sand
16790␣scree
475780␣scrub
316␣shingle
114␣shoal
469␣sinkhole
191␣slope
42650␣spring
2968␣stone
327␣strait
270␣swamp
2742447␣tree
20609␣tree_row
290␣trees
733␣valley
2949␣volcano
4916757␣water
2403␣waterfall
677802␣wetland
138␣wild_animals
1863740␣wood
161␣woodland

(Einträge mit weniger als 100 Vorkommen getilgt)

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

␣53072␣-
18␣cross
18␣hand_print
17␣obelisk
92␣plaque
282␣plate
143␣statue
9660␣stolperstein
66␣stone

(alles unter 10 Vorkommen getilgt)

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.

openzzz wrote:

Für OSM wünsche ich mir die Hauptkarte auf openstreetmap.org als besseren Stadtplan (in der Stadt)
bzw. als die bessere topografische Karte (für das Land).
Ich finde an diesen "Originalen" sollte man sich orientieren. An der Nützlichkeit der Darstellung.
Man könnte ja auch noch viele andere Gedenksteine aufnehmen, die so an den Häuserwänden hängen.

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.

Warum nicht einfach als Spezialkarte, oder als Overlay mit den OpenLayers?

Haben wir doch mit der Geschichtskarte

Auf der Hauptkarte könnten Gedenksteine doch einfach herausgefiltert werden, oder?
Im Prinzip finde ich die Render-Regel, alles darzustellen schon Ok, für das was man bisher sieht.
Außer ein paar "Sammelaktionen", die die Karte optisch überfrachten -> würde für eine
Blacklist statt einer Whitelist sprechen.

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.

edit: Typo

Netzwolf wrote:

Auch hier ist völlig unzumutbar, auf “stolperstein” oder “plate|plaque” abzufragen und anders, ab anderer Zoomstufe oder gar nicht zu rendern.

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.

wambacher wrote:

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.
...
Sowas ließe sich - zumindestens für Demo-Zwecke - auf openstreetmap.de realisieren. Da sind wir ja wirklich unser "eigener Herr", oder?

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.

Netzwolf wrote:

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!

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.

Apropos Erinnerung:

Im Pflaster erfüllen die Stolpersteine durchaus ihren Zweck:
http://www.youtube.com/watch?v=LuBv9rDhV_4

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

Und was viele nicht wissen, es gibt auch eine polnische Variante:
https://www.youtube.com/watch?v=XwhkbkP2L_A

Das ist erinnern, das brennt sich ins Gedächtnis wie kein Stein im Pflaster.

openzzz wrote:

wambacher wrote:

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.

Wir müssen aber sorgsam 3 Arten von Overlays unterscheiden:

- Serverseitig: ...
- Rasteroverlay: ...
- Vektoroverlay: ...

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.

WMS ist immer ein Rasteroverlay, oder?

Soweit ich weiss, ja. Allerdings fällt das nicht so auf, wenn man transparenten Hintergrund verwendet.

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.

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.

Es hängt auch etwas vom Typ des Overlays ab. POI lassen sich gut
als Vektorlayer einfach drüberzeichnen.

Stimmt. Und dann noch Clustering dazu, dann sieht das richtig gut aus.

Für das Rendering der Fahrradwege (OpenCycleMap) könnte das schwieriger werden.

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.
  

openzzz wrote:

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.

Klar, weil an genau dieser Stelle die Registrierkasse von Google klingelt. Jeder Klick auf einen POI kann Kohle bringen.

Ich könnte mir gut vorstellen, die OSM-Daten in zwei unabhängige Teile zu spalten, die Karte an sich und eine POI-Sammlung.

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.

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.

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 🙁
  

Hallo openzzz,

openzzz wrote:

Apropos Erinnerung:

Im Pflaster erfüllen die Stolpersteine durchaus ihren Zweck:
http://www.youtube.com/watch?v=LuBv9rDhV_4

Danke für den Link 😉

openzzz wrote:

Ansonsten finde ich weniger Begeisterung daran, würde sie also nicht
anhand eines Stadtplans gezielt aufsuchen. Dafür erzählen sie einfach zu wenig.

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.

openzzz wrote:

Wer sich wirklich erinnern will, sollte vielleicht das Tagebuch lesen,
oder die gelungene filmische Umsetzung anschauen:
https://www.youtube.com/watch?v=dBXV33g7Uag

Und was viele nicht wissen, es gibt auch eine polnische Variante:
https://www.youtube.com/watch?v=XwhkbkP2L_A

Das ist erinnern, das brennt sich ins Gedächtnis wie kein Stein im Pflaster.

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

Viele Grüße

Dietmar

wambacher wrote:

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

• ) 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 🙁
  

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.

openzzz wrote:

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.

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.

Netzwolf wrote:

Du erinnerst mich daran, das ich noch die Wege auf dem Rhöndorfer Friedhof und bei der Gelegenheit das Adenauer-Grab erfassen will.

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 😉

Oli-Wan wrote:

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 😉

Also beim Grab kann man sich gern auch austoben und die Relation in die ewigen Jagdgründe schicken. Wir sind keine Personendatenbank.

Nahmd,

Oli-Wan wrote:

Netzwolf wrote:

Du erinnerst mich daran, das ich noch die Wege auf dem Rhöndorfer Friedhof und bei der Gelegenheit das Adenauer-Grab erfassen will.

Bei der christdemokratischen Wallfahrtsstätte kommst Du ein Jahr zu spät.

Nicht wirklich. Zum einen sind die Koordinaten falsch (Node offensichtlich aus der Entfernung grob abgeworfen), zum anderen ist das ein historisches Objekt ohne Foto.

Das Tagging hat freilich keine sieben Stunden durchgehalten.
Aber an den Wegen kannst Du Dich noch austoben 😉

Der Waldfriedhof ist (Überraschung!) dicht bewaldet und liegt in einem engen Tal, da dürfte der Empfang nicht wirklich gut sein.

Tordanik wrote:

Also beim Grab kann man sich gern auch austoben und die Relation in die ewigen Jagdgründe schicken. Wir sind keine Personendatenbank.

Auf Personenrelationen bin ich zum ersten Mal gestoßen, als ich beim Lesen des Planets die Schachteltiefe von Relationen untersucht habe (zur Zeit gibt es 7 auf Schachteltiefe 11, 0=Relation enthält keine Relation, 1=Relation enthält nur Relationen, die keine Relationen enthalten, usw.) und dabei auf zyklische Relationen gestoßen bin: durch Relationsmembers ausgedrückte Verwandschaftsverhältnisse: A = Vater/Mutter/Elter von B, B = Sohn/Tochter/Kind von A.

Die Relation hier ist sinnlos, beeinträchtigt aber die Funktion der OSM-DB nicht. Also mag wer auch immer die löschen, ich tu's nicht.

Gruß Wolf

PS: falls jemand neugierig ist: das sind die 7 Relationen auf Level 11:

- 420339
- 420344
- 420345
- 420346
- 420348
- 420349
- 1524411

Und falls jemand Langeweile hat: das sind die zyklisch verknüpften Relationen:

- 285836
- 1085634
- 1154653
- 1205072
- 1368401
- 1543698
- 1750007
- 2132897
- 2133498
- 2431858
- 2431861
- 2435464
- 2579600
- 2718415
- 2813982
- 2885227
- 2990554
- 3018045
- 3018206
- 3047822
- 3119737
- 3120098
- 3122622
- 3122640
- 3170559
- 3187114
- 3208182
- 3228416
- 3253167
- 3256779
- 359309
- 3236785

Tordanik wrote:

Also beim Grab kann man sich gern auch austoben und die Relation in die ewigen Jagdgründe schicken. Wir sind keine Personendatenbank.

Von mir aus gerne. Ich hatte damals keine Lust, mich mit dem Massenumtagger zu streiten, erst recht zumal ich in der Gegend auch nur zu Besuch war. Wie neulich bereits festgestellt, scheint Zbigniew_Czernik an seiner (sinnfreien) Schöpfung zu hängen.

Netzwolf wrote:

Der Waldfriedhof ist (Überraschung!) dicht bewaldet und liegt in einem engen Tal, da dürfte der Empfang nicht wirklich gut sein.

Ist mir noch in Erinnerung, danke.