Re: [Talk-de] das Problem mit backward-forward und lef t-right - neues Datenmodell nötig!?
M?rtin Koppenhoefer dieterdre...@gmail.com wrote: Das Auflösen der Fahrspuren in Linienbündel würde den Großteil von richtungsabhängigen Tags und Relationen obsolet machen. Dennoch: Ich halte eine Einführung ohne dazugehörigen grafischen Editor, mit dem man die Linien zusammmenklicken kann, für problematisch, da dann OSM nur noch von wenigen Spezialisten editiert werden kann. Das halte ich für ein Gerücht. Vieles würde durch explizite Ways und Areas für Spuren und Flächen einfacher, transparenter und übersichtlicher werden. Auch Anfänger würden davon profitieren. Hmm, von diesem Konzept habe ich noch nichts gelesen. Gibt es da was im Wiki? Wenn ich Dich richtig verstehe, habe ich zumindest die Einzelspurführung beispielhaft in Ansätzen an dieser Kreuzung versucht: http://sautter.com/map/?zoom=18lat=51.20167lon=6.90545layers=00B000TTFF Meinst Du so etwas? Wenn ja, ist das erst einmal reichlich mühsam. So wie ich jetzt abschätze, mühsamer als wenn man Spuren zusammenklicken könnte, z.B. weil die Tags zigmal gemappt werden müssen. Da müsste der Editor dann kräftig mithelfen - zum Beispiel Taggruppen applizieren durch Mausklick auf Weg. Anzeige der Tags und Relationen durch Maus-Drüberhalten. Und es wirft neue Probleme auf - beispielsweise beim Rendering. Bei Spurtrennung - egal bei welchem Vefahren - reicht der nicht ausreichende Zoom von Online-Mapnik (Osmarender erst recht), um das zu kontrollieren. Wenn jede Spur individuell und nicht als Bündel geführt ist, muss die Auflösung noch höher sein. Außerdem müssen die Renderer erheblich intelligenter werden. Im Augenblick bekommen die es nicht einmal gebacken, eine Radspur oder Eisenbahn neben der Straße nicht zu verdecken. Ein anderes Problem ist, dass beim Einzelspurmapping die Information darüber verloren geht, welche Spuren zu einer Straße gehören. So etwas kann dann an Kreuzungen oder Abzweigungen Routenanweisungen produzieren, wie: Abbiegen von A-Straße auf A-Straße, 2 Meter. Abbiegen von A-Straße auf A-Straße, 1 Meter. Abbiegen von A-Straße auf A-Straße, 3 Meter. Abbiegen von A-Straße auf A-Straße, 1 Meter. Abbiegen von A-Straße auf A-Straße, 2 Meter. In anderen Fällen fehlt eine Abbiegeanweisung, obwohl sie notwendig wäre. Sie fehlt, weil offensichtlich durch das Zeichnen der Abbiegung im Bogen ein Geradeaus-Lauf vermutet wird. Bisher konnte dies offensichtlich über den Abbiegewinkel festgestellt werden. Muss man dann Relationen verwenden, um das Auseinderdividierte wieder zusammen zu bringen bzw. um in der Praxis vorhandene Geradeausführung und Abbiegung deutlich zu machen? Brauchen wir Einsammel-Relationen für Straßen zur Darstellung der funktionellen Zusammenhänge dann nicht nur für Referenzstraßen, sondern für jede spurgeteilte Straße? Sollen gestrichelte und durchgehende Linien auch als einzelne Spur oder als links/rechts gemappt werden? Sind solche und weitere Probleme dabei schon bis zu Ende gedacht? Ich nehme an, mit Areas meinst Du das, was derzeit bei großen Flüssen gemacht wird. Richtig? Ich weiß, eine Menge Fragen. Aber sie drängen sich auf. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] das Problem mit backward-forward und lef t-right - neues Datenmodell nötig!?
Am 25.07.2010 um 14:54 schrieb Tirkon: Ich weiß, eine Menge Fragen. Aber sie drängen sich auf. Ich poste noch einmal mein Konzept, wie ich mir meine Version vom Linienbündel vorstelle, da es etwas unterging. Es würde die Probleme des forward/backward, left/right komplett beheben, das Tagging insgesamt damit auch für Neuuser transparenter und gleichzeitig Fahrspurzeichnen und -tagging ermöglichen. Das Ganze _bei gleichzeitiger Abwärtskompatibiliät_ und es müsste nur eine weitere Datenart für die Gruppierung der ways hinzukommen. Betreff des Themas: Konzept für die Gruppierung von ways (ähnlich Linienbündel) stay tuned ;-) steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] das Problem mit backward-forward und lef t-right - neues Datenmodell nötig!?
Am 25.07.2010 um 03:51 schrieb M∡rtin Koppenhoefer: Am 21. Juli 2010 04:37 schrieb Tirkon tirko...@yahoo.de: Das Auflösen der Fahrspuren in Linienbündel würde den Großteil von richtungsabhängigen Tags und Relationen obsolet machen. Dennoch: Ich halte eine Einführung ohne dazugehörigen grafischen Editor, mit dem man die Linien zusammmenklicken kann, für problematisch, da dann OSM nur noch von wenigen Spezialisten editiert werden kann. Das halte ich für ein Gerücht. Vieles würde durch explizite Ways und Areas für Spuren und Flächen einfacher, transparenter und übersichtlicher werden. Auch Anfänger würden davon profitieren. volle Zustimmung +10 ;-) steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] das Problem mit backward-forward und lef t-right - neues Datenmodell nötig!?
steffterra steffte...@me.com wrote: Ich poste noch einmal mein Konzept, wie ich mir meine Version vom Linienbündel vorstelle, da es etwas unterging. Es würde die Probleme des forward/backward, left/right komplett beheben, das Tagging insgesamt damit auch für Neuuser transparenter und gleichzeitig Fahrspurzeichnen und -tagging ermöglichen. Das Ganze _bei gleichzeitiger Abwärtskompatibiliät_ und es müsste nur eine weitere Datenart für die Gruppierung der ways hinzukommen. Zumindest für meinen Teil ist es nicht untergegangen. Ich hatte auch schon dazu gepostet, dass man das Konzept durchgängig in vielen Situationen gemappt sehen muss. Leider in der OSM karte nicht machbar, da die Gefahr durch Veränderungen Anderer gegeben ist. Und rein aus der Textwüste ist so etwas nicht beurteilbar. Betreff des Themas: Konzept für die Gruppierung von ways (ähnlich Linienbündel) stay tuned ;-) Bin schon öfter nach solchen Ankündigungen gespannt gewesen. Mal sehen, ob trotz der von mir oben schon ausführlich beschriebenen Widrigkeiten und insbesondere ohne Versuchs-Miniplanet diesmal was kommt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] das Problem mit backward-forward und lef t-right - neues Datenmodell nötig!?
Am 25.07.2010 um 22:09 schrieb Tirkon: steffterra steffte...@me.com wrote: Ich poste noch einmal mein Konzept, wie ich mir meine Version vom Linienbündel vorstelle, da es etwas unterging. Es würde die Probleme des forward/backward, left/right komplett beheben, das Tagging insgesamt damit auch für Neuuser transparenter und gleichzeitig Fahrspurzeichnen und -tagging ermöglichen. Das Ganze _bei gleichzeitiger Abwärtskompatibiliät_ und es müsste nur eine weitere Datenart für die Gruppierung der ways hinzukommen. Zumindest für meinen Teil ist es nicht untergegangen. Ich hatte auch schon dazu gepostet, dass man das Konzept durchgängig in vielen Situationen gemappt sehen muss. Da ich auch in anderen Projekten gut eingespannt bin, habe ich derzeit nicht die Ressourcen, das in Bildbeispielen/Screenshots zu erläutern. In einem entsprechenden Proposal würden solche Beispiele aber unerlässlich und sehr zum Verständnis beitragen. Deshalb habe ich das auf jeden Fall im ToDo. Leider in der OSM karte nicht machbar, da die Gefahr durch Veränderungen Anderer gegeben ist. Und rein aus der Textwüste ist so etwas nicht beurteilbar. +1 Betreff des Themas: Konzept für die Gruppierung von ways (ähnlich Linienbündel) stay tuned ;-) Bin schon öfter nach solchen Ankündigungen gespannt gewesen. Mal sehen, ob trotz der von mir oben schon ausführlich beschriebenen Widrigkeiten und insbesondere ohne Versuchs-Miniplanet diesmal was kommt. Ich möchte vorher noch Stimmen dazu sammeln, dass ich sie in einem zukünftigen Proposal einfliessen lassen kann. Ich möchte vorerst nicht den Anspruch auf Vollständigkeit erheben und alles gut durchgekaut wissen, bevor ich da weitere Arbeit investiere ;-) Doch wie denkst Du im Einzelnen zu den Facetten des Konzepts. Wenn Du die Zeit dazu hast, würde ich mich sehr freuen, wenn Du dort noch einmal genauer darauf eingehst. Deine grundsätzliche Sorge teile ich. (s.o.) Gruß, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] das Problem mit backward-forward und lef t-right - neues Datenmodell nötig!?
Hallo, Ich möchte mal ganz wertfrei und ohne Vorbehalte darüber schreiben, was hier zu beobachten ist: Das Problem der drehenden Wege bei Verwendung von backward-forward und left-right für die unterschiedlichsten Zwecke muss irgendwie grundlegend angepackt werden. Ich sehe da OSM einfach bei einer Grenze angekommen. - Ich verstehe, die Befürworter von Relationen für die Abbildung von Wegeigenschaften, die sich nur auf eine Straßenrichtung beziehen (z.B. maxspeed:forward, parking:lane:right, destination:forward, etc.), da mit Relationen eine Richtung festgelegt werden kann, egal wie der Weg gedreht ist. - Ich verstehe aber auch die Bedenken derer, die das lieber getaggt haben, um zu verhindern, dass irgendwann _alles_, was eine Straßenrichtung betrifft, in Relationen gefasst wird. Ich halte beide Version für unübersichtlich und aufgrund der Komplexität beider Varianten auch fehlerträchtig. - Manche versuchen das Problem zu umgehen, indem sie zwei ways für jede Fahrrichtung zeichnen, was aber nur bei baulicher Trennung korrekt wäre, und deshalb falsch ist. Wieso dann nicht die Argumente in einem neuen Datenmodell vereinen? Sicher bin ich nicht der erste, dem das einfällt. Ich habe hier schon des öfteren von Linienbündeln und Fahrspurtagging gelesen. Doch welche Konzepte gibt es bisher? Wie weit sind wir dahin? Steckt OSM da derzeit fest? Warum gehts nicht weiter? -- Ich meine, aufgrund dieser unbefriedigenden Situation gibt es eigentlich immer nur eine Diskussion: Bringt man richtungsabhängige Informationen in Relationen oder Tags am besten unter? Bei genauerem Hinsehen, kommt immer das gleiche heraus: Uneinigkeit, weil es natürlich für beide Varianten Vor- und Nachteile gibt. Sprich wir treten alle auf der Stelle. Doch die Anforderungen an OSM sind gestiegen und deshalb benötigen wir eine Erweiterung unseres bisherigen Datenmodells (so sagt man das doch?) - Mein Vorschlag ist sicher nicht neu und ich behaupte _nicht_, damit den Stein der Weisen gefunden zu haben! 1. Die bisherige Struktur von Nodes und Ways wird beibehalten und kann bei Bedarf an bestimmten Stellen (hier nur für Straßen!) erweitert werden. 2. Diese Erweiterung für Straßen sollte auf diese Weise einfach (von Anwenderseite gesehen) möglich sein: a) Einzeichnen zusätzlicher paralleler ways, die _nicht_ extra durch eine Relation oder einen Tag als zum gleichen way =ohne bauliche Trennung, gehörig verbunden werden müssen. Das sollte durch eine neue Datenart ermöglicht werden. Ich würde diese Funkion Gruppierung nennen und könnte durch eine gemeinsame abstrakte Signatur/ID erreicht werden, die von der DB (oder einem Algorithmus aus den way-id's jedes mal neu errechnet wird, wenn ein way dazukommt, oder abgezogen wird) vergeben wird. b) Diese way-Gruppe könnte in JOSM so dargestellt werden, dass jeder way beim Zeichnen automatisch parallel ausgerichtet wird und mit einer gemeinsamen Hintergrundfarbe hinterlegt ist. Das zeigt, das es sich um einen way im bisherigen Sinne ohne bauliche Trennung handelt. c) Festlegen der Richtung beider ways wie bisher auch und ein Schlosssymbol setzen, das verhindert, dass jemand diese Richtung ändern kann, ohne von JOSM rückgefragt zu werden. d) Taggen der entsprechenden Eigenschaften für die jeweilige Richtung. 3. Wenn man auf solch ein way-Gruppierung stößt, dann weiss man in DE, dass Rechtsverkehr herrscht und dann ist klar, in welcher Richtung -also auf welchem der beiden ways was getaggt weden muss, wenn man die Wirklichkeit abbilden möchte. 4. Es könnten mehrere ways für eine Fahrtrichtung in der Gruppe sein. Z.B. zwei zeigen in die eine Richtung, einer zeigt in die andere. Dadurch wäre auch Fahrspurtagging möglich und durch das Schlosssymbol in JOSM und Potlatch(?) wird man vorsichtig beim Ändern der Way-Richtung. 5. Nun muss noch was gegen die Redundanz gemacht werden: Anlegen eines Datenways. a) Eine Straße, die z.B. je eine Fahrspur in jeder Richtung hat, wird mit _drei_ ways gezeichnet. b) Der mittlere way ist der Datenway, auf ihm werden alle Tags untergebracht, die für die _gesamte_ way-Gruppe gelten, wie z.B. highway= secondary, name=Bündelstraße, ref=B 19. als auch die Relationen-Teilnahme, die für alle ways des Bündel gelten. c) auf den ways links und rechts werden nur die tags untergebracht, die für die jeweilige Richtung gelten, z.B. maxspeed=50 und gegenüber auf dem anderen way maxspeed=40 d) Der mittlere way entspricht der derzeitigen Umsetzung für die mittlere Geographische Lage für ways. Er sollte möglichst die Mitte der Straße darstellen. e) was tun bei drei Fahrspuren? Der datenway wird zwischen beide Fahrtrichtungen gelegt und ist dann insgesamt gesehen der vierte way. 6. Nun zum Rendern und der Darstellung in JOSM: a) exisitert nur ein way, wird verfahren, wie bisher auch, um die Abwärtskompatibilität zum aktuellen Datenbestand zu erhalten b) _gleichzeitig mit der Einführung des datenway_ sollte es
Re: [Talk-de] das Problem mit backward-forward und lef t-right - neues Datenmodell nötig!?
Am 20.07.2010 21:18, schrieb steffterra: Ich möchte mal ganz wertfrei und ohne Vorbehalte darüber schreiben, was hier zu beobachten ist: Das Problem der drehenden Wege bei Verwendung von backward-forward und left-right für die unterschiedlichsten Zwecke muss irgendwie grundlegend angepackt werden. Du schreibst im Folgenden über das Linienbündel-Problem, nicht wirklich über richtungsabhängige Tags. Es stimmt zwar, dass das Linienbündel-Problem auch einige richtungsabhängige Informationen abdeckt, aber Dinge wie Steigungen oder die Richtung eines Flusses sind davon völlig unabhängige Infos. Freut mich also, wenn du dich der Linienbündel annehmen willst, aber das Thema bitte gedanklich ein wenig von richtungsabhängigen Informationen trennen - damit hat es nur am Rand zu tun. Wieso dann nicht die Argumente in einem neuen Datenmodell vereinen? Sicher bin ich nicht der erste, dem das einfällt. Ich habe hier schon des öfteren von Linienbündeln und Fahrspurtagging gelesen. Doch welche Konzepte gibt es bisher? http://wiki.openstreetmap.org/wiki/Proposed_features/lane_and_lane_group http://wiki.openstreetmap.org/wiki/User:%C3%96mmes/Wayparts http://wiki.openstreetmap.org/wiki/Users:cmuelle8/multiple_way_tagging_on_single_geometry http://wiki.openstreetmap.org/index.php/WikiProject_Germany/Workshops/Linienbündel Gibt noch mehr in verschiedenen Diskussionen etc., aber die gängigen Ideen dürften damit abgedeckt sein... Wie weit sind wir dahin? Es gibt mehrere Konzepte, die theoretisch alle denkbaren Situationen entlang eines Wegs beschreiben könnten. Das ist auch der leichte Teil. Auf einige Details, wie etwa die Darstellung von Kreuzungen, gehen die Konzepte meist nicht ein. Das ist m.E. der gängigste konzeptionelle Mangel. Bei den o.g. Konzepten gibt es außerdem keine fertige Editor-Unterstützung, keine Rendering- oder Routing-Unterstützung, und keine nennenswerte Verbreitung. Das sind die praktischen Mängel. Steckt OSM da derzeit fest? Warum gehts nicht weiter? Weil es viel Arbeit ist, so etwas komplett durchzuziehen. Bisher hat noch jeder nach dem Abliefern der ersten Ideen und halbfertiger Konzepte keine Lust mehr gehabt. Ich übrigens damals auch. ;) So, jetzt aber zu deinem Vorschlag: a) Einzeichnen zusätzlicher paralleler ways, die _nicht_ extra durch eine Relation oder einen Tag als zum gleichen way =ohne bauliche Trennung, gehörig verbunden werden müssen. Das sollte durch eine neue Datenart ermöglicht werden. Wenn ich so die Eigenschaften deiner Ways durchlese, dann sind das durch eine Relation verbundene Ways. Ja, ich weiß: Du willst, dass man sie nicht manuell in eine Relation zusammenfassen muss, der Editor sie automatisch parallel ausrichtet, auf höheren Zoomstufen ausblendet etc. Aber das kann der Editor prinzipiell alles auch mit Ways in einer Relation machen; muss man ihm nur beibringen - das ist nicht schwerer, als die entsprechenden Funktionen für einen neuen Datentyp zu bauen, und ließe sich später leicht anpassen. Vorteil: Um ein Editor-Plugin (und/oder ein Beispiel-Rendering) zu schreiben, das dein Konzept intern mit Relationen nachbaut, musst du niemanden überzeugen. Das kannst du ohne die Zustimmung einer zentralen Autorität veröffentlichen. Das beweist dann, dass deine Idee in der Praxis funktionieren kann, und die Leute werden dein Konzept mit eigenen Händen ausprobieren. Nachteil: Du hast vermutlich mehr oder weniger darauf spekuliert, dass eine API-Änderung dazu führen würde, dass sich jemand anderes um die eigentliche Arbeit, nämlich die Editoren und Renderer, kümmert - und du nur die Ideen liefern musst. So hätte ich jedenfalls gedacht. *g* e) was tun bei drei Fahrspuren? Der datenway wird zwischen beide Fahrtrichtungen gelegt und ist dann insgesamt gesehen der vierte way. Es gibt keine klare Grenze zwischen zwei Fahrtrichtungen - zumindest, wenn wir nicht nur über Autos reden. Beispielsweise kann ein Radweg sowohl nur für eine als auch für beide Richtungen zugelassen sein; er wird sich dennoch ganz klar entweder links oder rechts deines Datenways befinden. Allerdings scheinst du bis jetzt ja wirklich primär an Autofahrspuren gedacht zu haben: 8. Fahrbahnbegleitende Radwege, etc. werden nach wie vor am highway getaggt, nun jedoch auf der jeweiligen Fahrspur für die jeweilige Richtung. 9. Parkstände entlang von Fahrspuren: Auch parking:lane ist nun klar, und muss nicht mehr mit right/ left getaggt werden, sondern einfach auf der Fahrspur, die es betrifft. Einer der Vorzüge eines Linienbündels ist doch, dass man Radwege, Parkstreifen und Gehwege als eigene Spur darstellen kann! Sonst hast du viele der der Probleme, für die sich die Einführung von Linienbündeln lohnen würde, gar nicht gelöst: * ist der Radweg jetzt innerhalb oder außerhalb des Parkstreifens? * wie kann ich bewährte Tags wie surface oder width direkt für einen der Radwege setzen? - jemand müsste das in die DB einbauen und auch stufenweise in die populären
Re: [Talk-de] das Problem mit backward-forward und lef t-right - neues Datenmodell nötig!?
Hallo, Ich möchte mal ganz wertfrei und ohne Vorbehalte darüber schreiben, was hier zu beobachten ist: Das Problem der drehenden Wege bei Verwendung von backward-forward und left-right für die unterschiedlichsten Zwecke muss irgendwie grundlegend angepackt werden. Da hatte ich vor ewiger Zeit mal mit angefangen, aber dann war ich länger im Ausland,... s.: http://wiki.openstreetmap.org/wiki/Proposed_features/right_left Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] das Problem mit backward-forward und lef t-right - neues Datenmodell nötig!?
steffterra steffte...@me.com wrote: - Ich verstehe, die Befürworter von Relationen für die Abbildung von Wegeigenschaften, die sich nur auf eine Straßenrichtung beziehen (z.B. maxspeed:forward, parking:lane:right, destination:forward, etc.), da mit Relationen eine Richtung festgelegt werden kann, egal wie der Weg gedreht ist. - Ich verstehe aber auch die Bedenken derer, die das lieber getaggt haben, um zu verhindern, dass irgendwann _alles_, was eine Straßenrichtung betrifft, in Relationen gefasst wird. Ich halte beide Version für unübersichtlich und aufgrund der Komplexität beider Varianten auch fehlerträchtig. - Manche versuchen das Problem zu umgehen, indem sie zwei ways für jede Fahrrichtung zeichnen, was aber nur bei baulicher Trennung korrekt wäre, und deshalb falsch ist. Wieso dann nicht die Argumente in einem neuen Datenmodell vereinen? Sicher bin ich nicht der erste, dem das einfällt. Ich habe hier schon des öfteren von Linienbündeln und Fahrspurtagging gelesen. Das Auflösen der Fahrspuren in Linienbündel würde den Großteil von richtungsabhängigen Tags und Relationen obsolet machen. Dennoch: Ich halte eine Einführung ohne dazugehörigen grafischen Editor, mit dem man die Linien zusammmenklicken kann, für problematisch, da dann OSM nur noch von wenigen Spezialisten editiert werden kann. Wir brauchen aber die breite Masse der Mapper, wenn man bedenkt, dass wir selbst das Basisangebot anderer Karten auch in Deutschland als meisteditiertem OSM Land in der Fläche nicht erreichen. Doch welche Konzepte gibt es bisher? Wie weit sind wir dahin? Steckt OSM da derzeit fest? Warum gehts nicht weiter? ... Sprich wir treten alle auf der Stelle. Doch die Anforderungen an OSM sind gestiegen und deshalb benötigen wir eine Erweiterung unseres bisherigen Datenmodells (so sagt man das doch?) Der Weg zu den Linienbündeln scheint mir weit. Und es liegt eine Menge Entwicklungsarbeit auf diesem Weg. Wie er aussehen könnte, habe ich ich im Folgenden beschrieben, wenn auch recht grobmaschig. Es gibt die ersten OSM-Erfahrungen mit einem komplexeren Thema - dem Oxomoa Schema. http://wiki.openstreetmap.org/wiki/User:Oxomoa/%C3%96PNV-Schema Das Oxomoa Schema hat seine Existenz einem Workshop zu verdanken, bei dem man sich live traf. Nun sind solche Treffen für eine verstreute Community schwierig. Um solche komplexen Themen wie das Linienbündel effektiver bearbeiten zu können, habe ich mir Gedanken gemacht, wie man ohne solche Treffen auskommt. Herausgekommen ist folgendes Online-Werkzeug: Man braucht zunächst einmal einen OSM- Mini Planeten, auf dem man expirimentieren kann und der auch von allen gängigen Anwendungen z.B. Renderern (Mapnik, Osmarender, ÖPNV-Karte), Editoren und Analysewerkzeugen bedient wird. Es muss möglich sein, sich einen Exclusivbereich zu reservieren, damit Beispiele gezeigt werden können, an denen kein Anderer rumpfuschen kann. Denn dieser Gefahr sind alle Beispiele ausgesetzt, die man in der Original Datenbank verlinkt. Gerade das Feature, das man zeigen wollte, ist umeditiert worden. Man kann als Administrator eines reservierten Bereiches anderen Usern, die am gleichen Problem mitarbeiten, Bearbeitungsrecht geben. Schön wäre es zudem, wenn man Mapnik und Osmarender hier triggern könnte, um schnell voranzukommen. Runterladen ist auch aus diesen geschützten Bereichen möglich. Ich bin mir sicher, dass solch ein Wrkzeug auch in vielen anderen Fällen als effektives Kommunikationsmittel dienen und Probleme verdeutlichen kann. Darüber hinaus wäre ein einfaches Online-Zeichenbrett nach demselben Schema nützlich, auf dem man einfache Zeichnungen erstellen und kommunizieren kann. Möglicherweise gibt es so etwas schon. Auch für Schulungen und Demonstrationen vor Publikum wäre der Miniplanet nützlich. Anfänger könnten Gehversuche machen. Illustrierende Beispiele für komplexe Themen im Wiki könnten hier vorgehalten werden, so zum Beispiel für das Oxomoa Schema. Möglicherweise kann man hierzu nicht existierende Koordinaten oder ein Stück der Originalerde für solche Zwecke reservieren. Der Mini Planet wäre zum Beispiel dazu geeignet, sämtliche Vorstellungen, die Du in dem von mir weggeschnibbelten Teil geäußert hast, praktisch darzustellen. Ich denke mal, das wäre viel effektiver und würde mehr Leute dazu animieren, teilzunehmen. Ein Bild sagt eben mehr als tausend Worte. Zur Bearbeitung eines komplexen Themas, wie den Linienbündeln, kann man nun einen Ausschnitt der Originalkarte in den Miniplaneten kopieren und beginnt, Teile davon, nach einem erarbeiteten Konzept zu taggen. Hierbei wird sich zeigen, ob das Konzept Alles meistert und ob es auch in der Lage ist, einen Übergang zu den Straßen zu meistern, die nicht als Linienbündel getaggt sind. Das muss auch an echten Kreuzungen gebündelt/ungebündelt funktionieren. Man kann auch schon ein erstes Mal den Renderer drüber laufen lassen. Nachdem das Konzept (von mehreren) geprüft und optimiert wurde, muss natürlich noch das Editor
