Auch wenn Mapnik respektive der Kartenstil für OSM.org sicherlich angepasst werden sollte, so ist das nicht der Kern des Problems.
Solange wir uns an die Regel “Mappen was in der Realität sichtbar und überprüfbar ist” gehalten haben, war alles recht einfach. Grenzen entsprechen nur punktuell diesen Bedingungen, wenn z.B. Übergänge von einer Verwaltungseinheit zu einer anderen durch ein Schild (Willkommen in …) markiert sind.
Wahlkreise sind in der Regel nicht als Grenzen, sondern als Straßenlisten je Gemeinde definiert, also noch ungenauer.
Wie auch immer sind wir bereits mitten in einer Relevanz-Diskussion. Du schreibst sogar selbst “existent und nützlich”. Was ist “nützlich” anderes als ein Relevanz-Kriterium?
Da immer mehr Leute immer mehr Daten in OSM ‘abladen’ wollen, werden wir um diese Diskussion nicht herum kommen. Das fängt an bei vielen Details in den diversen Power-Proposal, die man ohne Firmenunterlagen eigentlich nicht mehr wissen kann. Das geht bis zum Wunsch historische Daten in OSM zu erfassen, auch wenn heute nichts mehr davon erkennbar ist (Stichwort Alte Handelssstraßen, alte Bahnstrecken). Es wird Zeit für eine parallele Datenbank, in der all diese Dinge unterkommen können, ohne OSM direkt zu belasten.
Ich finde auch, dass diese Diskussion angebracht ist. Aber ich finde es nicht gut, wenn man sich jetzt plötzlich ohne Ankündigung jemanden raussucht und an ihm ein Exempel statuieren will … weil Mapnik nicht sauber arbeitet. Meiner Meinung nach sollte die Diskussion losgelöst von dem aktuellen Beispiel geführt werden und nicht nur auf talk-de und hier…womit wir wieder bei den fehlenden Feedback-Mechanism wären.
Und was die parallele Datenbank betrifft…solange es die nicht gibt, ist es das ein KO Argument. Und wenn da wirklich alles reingekippt wird, was sonst keiner haben will, wird das eher ne Müllkippe als eine echte Alternative
Ich finde eher, dass man sich mal Gedanken drüber machen sollte, wie man die Bearbeitung generell vereinfacht. Die Datendichte ist an einigen Stellen so hoch, dass das Bearbeiten recht schwierig ist. Bspw könnte man drüber nachdenken, Layer einzuführen, also ein Landuse-Layer, eins für Straßen und Schienen, ein für Gebäude und POIs etc.
Vielleicht sollte man die Begrifflichkeiten darstellen:
Beim der Bundestagswahl gibt es 299 Wahlkreise. So ein Wahlkreis umfasst auf dem flachen Land ein paar Landkreise und Gemeinden. Ein Wahlkreis kann z.B. die Landkreis A und B sowie noch zusätzlich die Gemeinde G aus dem Landkreis C enthalten. Grenzen dieser Wahlkreise sind Gemeinde oder Landkreisgrenzen (in der Liste stehen da einfach Gemeindenamen).
Größere Städte haben mehrere Wahlkreise. Da ist die Grenze nicht die Gemeindegrenze sondern eine untere Verwaltungsgrenze. In München sind das Stadtbezirke, z.B. in Berlin kann da auch mal eine Straßenliste in der Einteilung vorkommen (“Bezirk Friedrichshain–Kreuzberg und das Gebiet östlich der Straßenmitte Prenzlauer Allee und südlich der Straßenmitte Lehderstraße und Gürtelstraße sowie des Jüdischen Friedhofs” Wahlkreis 084), in Hamburg gibt es das auch (…Gebiet des Stadtteils Sternschanze nördlich der S-Bahnlinie)
Die Straßenlisten kommen in der Regel erst bei der nächsten Unterteilung rein: Jeweils ein paar tausend Leute müssen zu einem Wahllokal. Diese Einteilung heisst “Wahlbezirk” oder gelegentlich auch “Stimmbezirk”.
Grüße, Max
PS: Bei anderen Wahlen heissen Dinge anders. Die bayerische Landtagswahl hat 7 “Wahlkreise” (Regierungsbezirke) die in 90 “Stimmkreise” (Landkreise und Gemeinden) unterteilt sind, die wiederum in “Wahlbezirke” (Strassenlisten) unterteilt sind.
Umgekehrt wird ein Schuh draus. Es gibt einen Fall, bei dem strittig ist, ob die Objekte wirklich in die Datenbank gehören oder nicht. Das macht darauf aufmerksam, dass wir über kurz oder lang eine Relevanz-Diskussion in OSM führen müssen. Das hat nichts mit Exempel statuieren zu tun. Die Tatsache, dass Mapnik auf OSM nicht sauber damit umgeht, hat das Problem nur sichtbar gemacht. Unzweifelhaft sollte auch beim Mapnik-Style nachgebessert werden.
Eine allgemeine Relevanz-Diskussion gehört natürlich nicht zentral in einen DE-Kommunikationskanal sondern vielmehr auf eine internationale Bühne wie die talk-Malingliste. Aber mit den DE-Wahlkreisen ist das aktuelle Beipiel auf DE beschränkt. Daher beginnt hier die Erkenntnis, dass wir mittlerweile eine Relevanz-Frage haben.
Der Hinweis auf eine parallele Datenbank scheint ein Killerargument zu sein. Das ist von mir jedoch nicht so gedacht, sondern als Hinweis, dass man dieses Thema nicht nur andenken, sondern endlich mal konkret angehen sollte (Henne-Ei-Problem). Also schlicht der Hinweis, dass eine “Parallele Datenbank”, das probate Mittel wäre, solche Fälle wie Altstraßen, Wahlkreisgrenzen, alte Bahnstrecken, historische Baustufen, Flugrouten usw. behandeln zu können, ohne die OSM-Datenbank damit zu belasten.
Das war genauso als Hinweis gedacht, wie deine ‘Forderung’ nach Layer für unterschiedliche Objekt-Klassen. Aber auch deine Frage / dein Wunsch gehört auf eine internationale Bühne.
Nicht zwingend. Es gibt ja bei verschiedenen Themen schon länderspezifische Konventionen und Gepflogenheiten. Man könnte ebenso durchaus auch nur DE-weit versuchen eine Vereinbarung zu finden, wo die Grenze zwischen wünschenswerten und nicht wünschenswerten Daten verlaufen soll. Diese Grenze wird in jedem Land unterschiedlich gezogen werden, und auch zu verschiedenen Zeiten unterschiedlich, etwa wenn die Externe Datenbank™ z.B. nur für DE zur Verfügung steht oder bestimmte Funktionen erst später hinzukommen. Oder wenn die Externe Datenbank™ zwar weltweit funktioniert, aber in Land A sitzt und von den Mappern in Land B aus diesem Grund nicht angenommen wird.
Eine nationale Diskussion bietet insofern auch eine größere Chance zur Einigung, weil innerhalb eines Landes Datendichte, Erfassungsgrad und Mapper-Mentalität weniger inhomogen sind als weltweit, ebenso die abzubildende Realität (eine süddeutsche Stadt und ein norddeutsches Dorf sind untereinander deutlich weniger verschieden als im Vergleich zu einer japanische Großstadt oder einem chilenischen Bergdorf). Außerdem besteht eher die Chance, daß ein einmal gefundener Kompromiss anschließend auch akzeptiert und eingehalten wird.
Das lässt sich übrigens als Editor-Funktion umsetzen. Man kann jetzt schon in JOSM einen einzelnen Way laden und dann von da ausgehend immer die anhängenden Ways. Und es gibt ein Plugin, mit dem man die Daten von der Overpass-API laden kann (da ich das nicht nutze weiss ich nicht, ob sich meine Idee schon damit umsetzen lässt).
Man könnte im Download-Dialog (zusätzlich zur Bounding Box) angeben können, dass man z.B. nur landuse=* haben will, womit JOSM eine entsprechende Anfrage an die Overpass-API senden würde. Damit hätte man dann solche “Layer”.
Das selektive Laden könnte aber nur dann sauber und ohne Gefahr von Kollateralschäden funktionieren, wenn sich die Objekte (z.B. Straßennetz und Landnutzung) keine Knoten teilen, oder? Ich denke, das ist zwar immer weniger verbreitet, aber kommt sicher noch oft genug vor. Aus dieser Sicht wäre die Einführung von Layern besser, weil man dann einmal bei Einführung die gemeinsam genutzten Knoten duplizieren müsste, sie dann aber wirklich unabhängig bearbeiten könnte.
Jo, und dann gehen die Probleme so richtig los:
Wenn man dieses “Layer” - also in diesem Falle alle Ways mit landuse=* (was ist da mit den Relationen?) geladen hat und dann daran was ändert, geht das in vielen Fällen in die Hose. Nämlich dann, wenn Nodes geändert oder gar gelöscht werden, die noch in anderen Objekten enthalten sind. Oder wenn Ways aufgetrennt werden. oder …
Sorry, das kann nicht die Lösung sein
Eine “alternative” DB mit den Daten, die für OSM nicht so “wichtig” sind, könnte daran scheitern, dass die Verknüpfung zu den OSM-Daten nicht gegeben ist. So wie ich den Begriff “alternative DB” verstehe, handelt es sich um Datenbanken, die total unabhängig von OSM sind, allerdings zum Rendern von OSM-Karten als zusätzliche Quelle verwendet werden könnten. Wie da allerdings eine Passgenauigkeit erreicht werden soll, ist mir (noch) völlig schleierhaft.
Sorry für meine unausgegoren Bemerkungen aber dafür ist mir die ganze Materie auch noch zu unklar. Ich sehe jedenfalls derzeit nur Probleme.
Ihr habt natürlich beide recht. Ich habe mich schon daran gewöhnt, bei solchen Aktionen immer die Elternelemente nachzuladen, weshalb ich da nicht dran gedacht hatte. Wenn man das erzwingen würde vielleicht?
auch ich war erst nicht erfreut über die Wahlkreis-MPs, vor allem weil sie mir als erstes bei OSMi als Fehler auf den Magen schlugen und noch schlagen (Bsp.). Ich würde mich daher freuen, wenn sich Harald aka black_bike mal drum kümmern könnte.
Nach etwas Nachdenken finde ich allerdings jetzt, dass die Wellen etwas zu hoch schlagen. Wollen wir nun Spezialkarten haben oder doch nur “den einen Renderer”? Auch ich habe Vorlieben für bestimmte Objekte, welche ich auf der Karte sehen möchte (OK, keine Wahlkreise). Und diese Objekte sehe ich auch, nämlich auf meiner Spezialkarte und zwar genau so wie ich es mir vorstelle und nicht wie Mapnik und Co. Und darauf zu warten bis zum Sank Nimmerleins-Tag , nein danke.
Wenn also die OSM-Datenbank nicht mal die paar MB für ein paar neue Ideen übrig hat, dann Auf Wiedersehen. Wikipedia scheint ja schön länger diese Speicherplatz-, auch Relvanzprobleme genannt, zu haben.
Also OSM-Freunde, bleibt friedlich, baut auch Euren eigenen Renderer und dort gibts dann auch keine sinnlosen Namen. Für alle Mainstream-Fans wäre selbstverständlich eine Verbesserung an Mapnik und auch JOSM sinnvoll, und dass nicht nur wegen der paar Wahlkreise (anderes Bsp. → 18 Seiten Diskussion mit dem Endergebnis: wir brauchen bessere Werkzeuge und eine bessere API).
Warum führen wir eigentlich bei jedem neuen Objekt immer wieder diese Grundsatzdiskussionen?
Ähm, Walter, die Nodes/Ways der beteiligten Geometrien müssten natürlich in die beteiligten Layer kopiert, sprich neue Nodes/Ways erzeugt werden. Du Kennst doch QGIS, so in etwa stelle ich mir das vor. Was mit Relationen ist, kann ich die sagen wenn Du mir sagt, welche Art Du meinst. MP werden ja eh durch die Flächentyp abgelöst…irgendwann
Was mir an meiner “fixen Idee” noch Kopfschermzen bereitet sind Punkt-POIs vs Flächen-POIs. Die wären ja in verschiedenen Layern, was Probleme erzeugen würde.
Und die von Dir genannten Probleme hat man teilweise heute schon bspw mit zwei aneinandergrenzenden Landuses unter denen noch ein Highway liegt, den man aber blöderweise nicht sieht.
Wir sind ein Community-Projekt. Die Grundidee, so wie ich sie verstanden habe, ist die, dass Leute mit wachem Blick herumlaufen, das was sie gesehen haben eintragen und andere Leute dann diese Eintragungen anschauen und mit wachem Blick auf Korrektheit prüfen und gegebenenfalls verbessern.
Okay - das ist stark idealisiert, oder kann hier wirklich jemand die “coastline” an der Nordsee als “mean high water spring” mit “…is the highest level that spring tides reach on the average over a period of time (often 19 years).” aus eigenener Anschauung beitragen oder überprüfen?
Wir reden jetzt aber nicht über einen Kompromiss bei der Datenerfassung, ohne den unsere Daten deutlich “weniger wert” wären, sondern über Daten, die:
nur von wenigen überhaupt beigetragen werden könnten und
ganz bestimmt nicht vom Durchschnittsmapper überprüft und verbessert werden können.
Ich stelle mir das mit den Layer etwas flexibler vor. Der Editor lädt alle Daten, es gibt dann aber vordefinierte (erweiterbare) Szenarien. Bspw. will ich Hausnummern editieren. Dann interessiert mich primär highway=, building= und addr:=, jeweils in allen Variationen. Wenn ich was editiere prüft der Editor im Hintergrund, ob ich mit dem Vorhandenen etwas mache, was mit den anderen Daten kollidiert. Evtl. könnte man dem Editor dann auch so einschränken, dass man beim mappen von Hausnummern nur Tags ergänzen kann. usw.
Bis auf die Überprüfung und die Beschränkung ist das schon Heute mit josm möglich. Es ist aber alles andere als Bedienerfreundlich.
Meine Güte. Könnt ihr die dämlichen Wahlkreise schnell aus der Karte werfen? Ich hatte vor einiger Zeit meine Routenplanung und die mobilen Karten (via OSMAND auf Android Smarphone) von der topografischen Landkarte auf OSM umgestellt, einfach weil sie mittlerweile viel detailreicher und zuverlässiger ist. Aber jetzt sehe ich auf manchen Zoomlevels nur noch Wahlkreise, auf anderen verdecken die Wahlkreisnamen gar schon Straßennamen. Was soll denn der Blödsinn? Selbst am Wahltag ist das kompletter Unsinn, denn jeder wird doch über die zuständigen örtlichen Wahllokale informiert. Auf einer Karte für die Öffentlichkeit hat das überhaupt nichts verloren. Schon gar nicht in so dominanter Form. Das grenzt schon an Vandalismus (etwa von der Konkurrenz kommerzieller Kartenverlage?). Die Karte ist so unbenutzbar. Ich wollte kürzlich auch mal einen Ausschnitt ausdrucken, aber wegen der kaputten OSM-Karte musste ich dann auf Google-Maps zurückgreifen. Das kann doch wohl nicht ernsthaft gewollt sein.
Ich habe nichts gegen Themenkarten für Spezialgebiete. Natürlich ist das eine schöne OSM-Anwendung wenn die Wahlhelfer oder Parteistrategen ihre Wahlkreise mit den OSM-Daten verknüpfen können. Aber das sollte dann doch auf diese Spezialanwendung beschränkt bleiben. Solange das die Karte für die Allgemeinheit beeinflusst sollte das möglichst herausgehalten werden. Also erstmal löschen bzw. auf einer separaten Datenbank sichern, um die Karte erstmal wieder zu bereinigen und damit wieder nutzbar zu machen. Es reicht auch nicht, wenn ein bestimmter Renderer das gut filtern kann. Da gibt es noch einige andere Anwendungen, z.B. Vektor-Renderer auf OSMAND, Garmin-Karten, IMG-Karten für Glopus (Navi-Geräte auf WinCE-Basis) etc. Solange auch nur ein großer Anwenderkreis betroffen ist sollten die Wahlkreise erstmal aus OSM verbannt werden. Wen interessiert das denn ernsthaft außer ein paar Parteistrategen?
Langfristig ist natürlich ein Layer-Konzept angebracht. Denn auch Dinge wie die Stolpersteine behindern die Übersichtlichkeit einer Karte. Ich habe nichts gegen die Stolpersteine für die jüdischen Opfer an sich. Aber es sind wirklich sehr viele und das macht die Karten unübersichtlich. Insbesondere füllt es die POI-Liste auf OSMAND, wenn man nach POI der Umgebung sucht. Daher wäre es gut, wenn man so etwas nur auf Anfrage als Layer hinzuschalten würde.
Wahlkreise könnte man lanfristig evtl. auch als Layer oder Overlay realisieren. Es ist aber fraglich, ob die wirklich in den Kerndaten stehen müssen, oder ob man das besser in einer separaten Datenbank führt. Das würde die Datenverarbeitung der eigentlichen Karte entlasten. In Google Earth sind auch Themen-Overlays mit KML-Dateien möglich. So ähnlich könnte man es auch bei OSM machen. Eine solche API wäre ohnehin praktisch, wenn Nutzer einfach eigene Overlays erstellen könnten, ohne direkt in die OSM-Daten eingreifen zu müssen.
Selbst “normale” (nicht so exotische) Layer sind in Google Earth beliebig zu/abschaltbar. Habt ihr mal den Versuch gemacht, alle Layers einzuschalten? Dann ist die Karte vor lauter Überlagerungen nicht mehr wiederzuerkennen. Man sollte sich in der Defaulteinstellung ein wenig an die traditionellen Karten orientieren, also Stadtpläne oder Topo-Landkarten. Geschäfte oder Parkbänke sind ja noch ganz praktisch, aber irgendwann ist eine Karte auch zu voll mit Features.
Du beziehst dich möglicherweise auf Bonn, da dort alle Stimmbezirke für die Kommunalwahl nächstes Jahr von einem User eingetragen wurden/werden. Du bist sicher selber in der Lage, diesen User herauszufinden.
Das Problem sind nicht so sehr die Wahlkreise / Stimmbezirke als solche, sondern die Tatsache, dass die Karte mit Namen zugepflastert wird. Also name=* durch note=* ersetzen, dann erscheinen die ‘Namen’ nicht mehr in der Karte (wo sie vor alem lästig sind), werden jedoch in der Relationen-Liste von JOSM angezeigt (nützlich fürs Editieren).
PS:
Ich bin das nicht, auch wenn ich viele MP-Fehler behoben habe und daher gelegentlich als letzter in der Autoren-Liste stehe.
Ich stecke in den Datenstrukturen nicht so tief drin, um hier Feuerwehr spielen zu können. Nur gelegentlich ergänze oder korrigiere ich etwas, falls etwas fehlt oder falsch ist. In der Umgegung und bei Ausflügen war die Karte ja schon fast perfekt … bis vor kurzem. Jetzt ist sie einfach nur “kaputt”.
Der Stadtwald besteht jetzt auf Zoomlevel 14 ausschließlich aus duzenden Stimmbezirken. Was interessieren schon die Freiwildgehege, oder Biotope Die Sache scheint ja unglaublich wichtig zu sein. Jetzt haben die Wildschweine und Rehe im Stadtwald also schon Stimmrechte. Es fehlen nur noch die Wahlkabinen für die Wildtiere …
hier gibt es auf talk-de zum gleichen Thema auch eine Diskussion. Wenn ich das noch richtig in Erinnerung habe, war das “Ergebnis”: Namen sind korrekt - es muß nur jemand dafür sorgen, dass Mapnik das nicht mehr darstellt. Und das war es dann auch schon
Ich bin auch nicht wirklich glücklich damit.
, nein danke.
Die Sache scheint ja unglaublich wichtig zu sein. Jetzt haben die Wildschweine und Rehe im Stadtwald also schon Stimmrechte. Es fehlen nur noch die Wahlkabinen für die Wildtiere …