Rendering der Stolpersteine

openzzz · 2013-10-11 20:03:34

Hat sich eigentlich mal jemand Gedanken gemacht, ob all die Stolpersteine auf
der Standardkarte von openstreetmap.org gerendert werden sollen?
Vermutlich ist das ein Deutschland-lokales Problem. International kenne ich nichts vergleichbares.

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

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.

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.

Eine ähnliche Relevanzdebatte hatten wir bei den Wahlkreisen, die auch fast
keiner auf der Karte sehen wollte.
Ob man die Sachen in der Datebank speichern will oder nicht ist eine andere
Frage. Ich wollte nur mal fragen, ob wir das wirklich auf der Standardkarte haben wollen.
Die nehme ich mittlerweile als erste Anlaufstelle für Stadtpläne, noch vor
Google Maps.

chris66 · 2013-10-11 20:17:08

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.

Last edited by chris66 (2013-10-11 20:17:19)

toc-rox · 2013-10-11 21:03:08

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

Netzwolf · 2013-10-11 21:05:28

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.

Netzwolf · 2013-10-11 21:16:39

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

okilimu · 2013-10-11 21:56:44

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

PT-53 · 2013-10-11 22:28:26

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.

Last edited by PT-53 (2013-10-11 22:28:43)

openzzz · 2013-10-12 06:32:03

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.

toc-rox · 2013-10-12 10:29:50

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

geri-oc · 2013-10-12 10:55:26

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

Netzwolf · 2013-10-12 11:31:26

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

MoTaBi · 2013-10-12 14:09:10

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

openzzz · 2013-10-12 15:59:32

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

openzzz · 2013-10-12 16:18:22

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.

Tordanik · 2013-10-12 16:26:31

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.

geri-oc · 2013-10-12 16:48:06

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

Netzwolf · 2013-10-12 17:27:09

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.

wambacher · 2013-10-12 17:27:53

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

Last edited by wambacher (2013-10-12 18:09:24)

Tordanik · 2013-10-12 18:39:09

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.

openzzz · 2013-10-12 19:03:32

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.

openzzz · 2013-10-12 19:13:37

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.

seawolff · 2013-10-13 01:25:15

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.

openzzz · 2013-10-13 08:32:01

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.

openzzz · 2013-10-13 08:49:15

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.

wambacher · 2013-10-13 08:55:14

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.

Announcement

#1 2013-10-11 20:03:34

Rendering der Stolpersteine

#2 2013-10-11 20:17:08

Re: Rendering der Stolpersteine

#3 2013-10-11 21:03:08

Re: Rendering der Stolpersteine

#4 2013-10-11 21:05:28

Re: Rendering der Stolpersteine

#5 2013-10-11 21:16:39

Re: Rendering der Stolpersteine

#6 2013-10-11 21:56:44

Re: Rendering der Stolpersteine

#7 2013-10-11 22:28:26

Re: Rendering der Stolpersteine

#8 2013-10-12 06:32:03

Re: Rendering der Stolpersteine

#9 2013-10-12 10:29:50

Re: Rendering der Stolpersteine

#10 2013-10-12 10:55:26

Re: Rendering der Stolpersteine

#11 2013-10-12 11:31:26

Re: Rendering der Stolpersteine

#12 2013-10-12 14:09:10

Re: Rendering der Stolpersteine

#13 2013-10-12 15:59:32

Re: Rendering der Stolpersteine

#14 2013-10-12 16:18:22

Re: Rendering der Stolpersteine

#15 2013-10-12 16:26:31

Re: Rendering der Stolpersteine

#16 2013-10-12 16:48:06

Re: Rendering der Stolpersteine

#17 2013-10-12 17:27:09

Re: Rendering der Stolpersteine

#18 2013-10-12 17:27:53

Re: Rendering der Stolpersteine

#19 2013-10-12 18:39:09

Re: Rendering der Stolpersteine

#20 2013-10-12 19:03:32

Re: Rendering der Stolpersteine

#21 2013-10-12 19:13:37

Re: Rendering der Stolpersteine

#22 2013-10-13 01:25:15

Re: Rendering der Stolpersteine

#23 2013-10-13 08:32:01

Re: Rendering der Stolpersteine

#24 2013-10-13 08:49:15

Re: Rendering der Stolpersteine

#25 2013-10-13 08:55:14

Re: Rendering der Stolpersteine

Board footer