Rendering von Wahlkreis-Namen

Servus,

Dann kann man sich aber über kurz oder lange vor lauter Name-Tags an den Grenzen nicht mehr retten. Wenn man in diesem Fall so streng ist und sagt, wir taggen nicht für den Render, dann müssten wir auch so streng sein und sagen, wir bilden nur ab, was man sieht. Und ich habe noch keine “Willkommen im Wahlkreis xyz” Tafeln gesehen. :wink:

Lg

Ich sehe es auch so, dass das im Mapnik-Style und nicht in den Daten geändert werden sollte. Dadurch steht auch einiges anderes an in dieser Form Nutzlosem auf den Kacheln, was auch Nutzer verwirrt (Quelle: OSM-Notes). Wenigstens finden sich dadurch auch manchmal Fehler, die man sonst nicht finden würde…

Die Diskussion auf Talk-de pendelt auch zwischen den Extremen Löschen ↔ Mapnik korrigieren.
Da wir ja auch noch andere unerwünschte benamte Objekte auf “Der Karte” haben, bin ich für das Filtern: Mapnik soll gefälligst sich die Objekte rauspicken, die er kennt und darstellen will - basta.

Gruss
walter

p.s. macht das osm.de besser? ich schau mal nach.

gemacht: http://www.openstreetmap.de/karte.html?zoom=16&lat=50.23993&lon=8.05003&layers=B000TF

Ja, sowohl osm.org als auch osm.de rendern “ohne Verluste”. Rheingau-Taunus-Limburg als Wahlkreis ist hier auf beiden Karten zu sehen. 1x ganz oben und 1x ziemlich weit unten an der Kreisgrenze :frowning:

Das Problem ist halt auch, das die Wahlkreisnamen nicht nur an der Wahlkreisgrenze erscheinen, sondern auch mitten im Gebiet. Siehe die Note im Ausgangsposting oder bspw. bei http://www.openstreetmap.org/#map=17/51.80006/10.34034&layers=N rechts von der B242.

Ich bin auch für “Mapnik anpassen”. Vielleicht über Negativlisten? “Rendere nichts, was die Tags t1=x, t2=y und t3=z hat”?

Bei einer Negativliste hast du immer das Problem, dass sich die Mapper immer neue Tags ausdenken und du mit dem Pflegen der Liste immer hinterher sein musst. Bei der Positivliste erweiterst du die einfach, wenn du ein neues Objekt der Darstellung hinzufügst.

Klar, für ihn ist das eine Grenz-Fläche mit Rand und Zentrum. Beides wird beschriftet.

Gruss
walter

p.s. bei Talk-de “prügelt” man sich noch immer - inzwischen weiss ich auch nicht mehr ob drin lassen, umtaggen oder löschen besser ist :wink:
Nur daß Mapnik unbedingt besser werden muß und auch seit der letzten großen Umstellung auch werden kann, ist unbestritten.

Ich habe die Diskussion auf talk-de auch grob mitverfolgt und bin für behalten in der jetzigen Form.

  1. Sind die Wahlkreisgrenzen existent und nützlich.
  2. Habe ich keinen Bock auf einen Präzedenzfall für Löschen wegen mangelnder Relevanz.

Also Mapnik ändern.

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.

Edbert (EvanE)

Meine volle Unterstützung.

Dann gibt es solche Grenzen doch gar nicht :wink:

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.

Edbert (EvanE)

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

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.

Gruss
walter

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?

Hallo OSM-Freunde,

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 :laughing: , 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 :slight_smile:
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.

Klar, “irgendwas” muß da schon gemacht werden, damit das mit den Layern klappen kann. Ich wollte nur bemerken, dass es sooo einfach nicht ist.

Genau die meinte ich - Relationen zur Flächenbeschreibung. Da hilft wohl wirklich nur das Area-Objekt.

Jo, da ist noch mächtig viel unklar.

Gruss
walter