Re: [Talk-de] Potlach 2 - kein bing-Hintergrund-Bild mehr bei Militaerflaechen
Am 02.02.2012 11:38, schrieb Sven Geggus: Falls es in Deutschland Gesetze geben sollte die dazu führen, dass Teile unserer Daten illegal sind, dann sollte man diese schnellstmöglich abschaffen. ich habe gerade mal ein Gebiet (in Aachen) mit Google angeschaut: da ist noch alles klar! Bing hat das erst in den letzten Tagen verpixelt. Ich frage mich nach dem Sinn? Die Aufnahmen sind von einem russischen Satelliten (Bing und Google haben die gleiche Quelle) http://www.tim-online.nrw.de zeigt im übrigen noch viel bessere Luftbilder, gestochen scharf, einzelne Autos sind deutlich zu erkennen, sogar der Typ. Auch Menschen sind durch den Schattenwurf auszumachen. Grüße aus der Eifel Steffen -- Ich verwende die kostenlose Version von SPAMfighter für private Anwender, die bei mir bis jetzt 2652 Spammails entfernt hat. Rund 7 Millionen Leute nutzen SPAMfighter schon. Laden Sie SPAMfighter kostenlos herunter: http://www.spamfighter.com/lde ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Draft für lanes Proposal
Ich habe gerade mit dem Draft für das neue lanes Proposal begonnen: http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension Frage, Wünsche, Anregungen? Her damit! ;-) Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] kommerzieller Kartenanbieter gegen in Frankreich gegen Google-Maps vor.
Johann H. Addicks addi...@gmx.net wrote: Interessant wäre es in der Tat falls wirklich mal ein kommerzieller Anbieter die Wettbewerbsrechtliche Karte gegen freie Software zieht, weil er sich davon seiner Wertschöpfung beraubt sieht. Home Fucking Is Killing Prostitution oder was?! Sven -- Software is like sex; it's better when it's free (Linus Torvalds) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OT: kommerzieller Kartenanbieter gegen in Frankreich gegen Google-Maps vor.
Interessant wäre es in der Tat falls wirklich mal ein kommerzieller Anbieter die Wettbewerbsrechtliche Karte gegen freie Software zieht, weil er sich davon seiner Wertschöpfung beraubt sieht. Home Fucking Is Killing Prostitution oder was?! Das wäre doch DER Job für Darl McBride Sorry, OT.. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Draft für lanes Proposal
Am 03.02.2012 10:44, schrieb Martin Vonwald: Ich habe gerade mit dem Draft für das neue lanes Proposal begonnen: http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension Frage, Wünsche, Anregungen? Her damit! ;-) Man sollte sich noch einmal über die :forward/:backward-Aufteilung Gedanken machen. Ich finde sie spontan etwas fragwürdig, weil sich eben etliche Straßen nicht in zwei Hälften mit jeweils einheitlicher Fahrtrichtung aufteilen lassen. Das hast du teilweise ja schon im Proposal selber zugegeben. Wie wäre es stattdessen mit :left/:right? Diese Anhängsel werden z.B. in JOSM ebenfalls als abhängig von der Richtung des Way verstanden und bei Bedarf umgedreht. So wäre auch das physische Spurlayout unabhängig von Linksverkehr vs. Rechtsverkehr eindeutig. (Dafür, in welcher Richtung man auf diesen Spuren fahren darf, bräuchte man allerdings das Wissen um die örtlichen Verkehrsregeln). Damit in Zusammenhang stehen die lanes:both (die bei left/right wohl lanes:center heißen würden). Ich halte es übrigens für eine schlechte Idee, mehr als eine solche Spur zu erlauben, weil nicht klar ist, in welcher Reihenfolge sie dann angegeben würden. Ein paar Klarstellungen wären noch gut: * Die Spuren werden von innen nach außen angegeben, oder? Die Beispiele legen das nahe, aber es steht nicht explizit da. * left/right als Werte von turn:lanes sind immer in Fahrtrichtung gemeint, d.h. eine Linksabbiegerspur ist unabhängig von der OSM-Wayrichtung immer left? Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Draft für lanes Proposal
Am 3. Februar 2012 14:32 schrieb Tobias Knerr o...@tobias-knerr.de: Am 03.02.2012 10:44, schrieb Martin Vonwald: Ich habe gerade mit dem Draft für das neue lanes Proposal begonnen: http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension Frage, Wünsche, Anregungen? Her damit! ;-) Man sollte sich noch einmal über die :forward/:backward-Aufteilung Gedanken machen. Ich finde sie spontan etwas fragwürdig, weil sich eben etliche Straßen nicht in zwei Hälften mit jeweils einheitlicher Fahrtrichtung aufteilen lassen. Das hast du teilweise ja schon im Proposal selber zugegeben. Wie wäre es stattdessen mit :left/:right? Diese Anhängsel werden z.B. in JOSM ebenfalls als abhängig von der Richtung des Way verstanden und bei Bedarf umgedreht. So wäre auch das physische Spurlayout unabhängig von Linksverkehr vs. Rechtsverkehr eindeutig. (Dafür, in welcher Richtung man auf diesen Spuren fahren darf, bräuchte man allerdings das Wissen um die örtlichen Verkehrsregeln). Ich verstehe den Unterschied nicht zu :forward/:backward. Was sollte dann anders definiert sein bei :left/:right? Damit in Zusammenhang stehen die lanes:both (die bei left/right wohl lanes:center heißen würden). Ich halte es übrigens für eine schlechte Idee, mehr als eine solche Spur zu erlauben, weil nicht klar ist, in welcher Reihenfolge sie dann angegeben würden. Ein paar Klarstellungen wären noch gut: * Die Spuren werden von innen nach außen angegeben, oder? Die Beispiele legen das nahe, aber es steht nicht explizit da. Habe ich ganz am Anfang jetzt noch etwas klarer geschrieben: immer von links nach rechts in Fahrtrichtung bzw. für :both von links nach rechts in OSM-Way-Richtung. * left/right als Werte von turn:lanes sind immer in Fahrtrichtung gemeint, d.h. eine Linksabbiegerspur ist unabhängig von der OSM-Wayrichtung immer left? Korrekt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] FOSSGIS - Anmeldung jetzt moeglich
Hallo, On 02/02/2012 10:58 PM, Tirkon wrote: Das ist dasselbe Zeitkonzept, wie letztes Jahr 2011 in Heidelberg. Hierzu müsste man sich vier freie Folgetage beim Brötchengeber erkämpfen. In Osnabrück 2010 fand die OSM Konferenz im Anschluss an die große Fossgis statt. Es folgte das Wochenende. Da war man nur zwei Tage abwesend. Nachteilig war dort, dass man nicht alle OSM Vorträge besuchen konnte, da zweigleisig gefahren wurde. Also, die Mehrgleisigkeit hast Du auf fast allen groesseren Konferenzen, und das laesst sich kaum vermeiden - ist letzlich aber auch nicht *nur* von Nachteil, denn fuer jeden gibt es zwischendurch auch mal ein weniger interessantes Thema. Auch diesmal sind wir mehrgleisig - zwei GIS-Gleise und ein OSM-Gleis, und man merkt schon, dass sich die beiden immer mehr vermischen; es gab dieses Jahr schon einige Vortraege, die sich gar nicht mehr eindeutig einem der Gleise zuordnen liessen. Das ist auch der Grund, warum viele das Modell OSM und GIS parallel gut finden - weil eben auch ein OSMer durchaus mal davon profitiert, sich einen Vortrag ueber OpenLayers, PostGIS oder andere Technologien anzuhoeren, und umgekehrt. Wie waren denn die Erfahrungen, wenn man die beiden Modelle gegeneinander stellt? Wieviele OSM Teilnehmer hatten wir in Osnabrück und wieviele in Heidelberg? Kann man eine Einschätzung der Teilnehmerstruktur abgeben? War beispielsweise in Heidelberg der Anteil der Hobby-OSMler geringer und derjenigen mit beruflichem/studentischem GIS-Background größer? So genau wird das nicht ausgewertet. Fuer Heidelberg gibt es eine ausgezeichnete Auswertung der Teilnehmerumfrage von Robert Nuske, in der er auch GIS-/OSM-Klientel unterscheidet: http://www.fossgis.de/w/images/3/38/Bericht_zu_Fossgis2011.pdf 2010 wurde die Frage bist Du eher wegen OSM oder wegen GIS hier noch nicht gestellt, und die Ruecklaufquote des Fragebogens war sehr gering, daher ist der Bericht nicht so aussagekraeftig: http://www.fossgis.de/w/images/4/49/Bericht_zu_Fossgis2010.pdf Der 2011-Bericht zeichnet schon das Bild von einer relativ inhomogenen Teilnehmerschaft. Wir hatten immer angenommen, dass das mit der Zeit immer homogener wird. Sollte sich aber zeigen, dass das nicht so ist, dann kaeme auch wieder die Frage auf, ob man a la Osnabrueck entzerrt oder sogar gleich zwei separate Konferenzen macht. Die Videoaufzeichnungen der letzten Fossgis waren hervorragend. Vielen Dank an das Videoteam. :-) So eine tolle Bildführung zwischen Beam und Vortragendem gibt es nicht einmal bei der vermögenden Wikipedia. Für die Daheimgebliebenen wäre es schön, wenn sich das wiederholen ließe. Auf jeden Fall waere das schoen. Ich hab auch gehoert, dass evtl. das bewaehrte Team wieder bereit waere, was zu machen, bin mir aber nicht sicher, wie sicher das ist ;) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Draft für lanes Proposal
Am 03.02.2012 14:50, schrieb Martin Vonwald: Am 3. Februar 2012 14:32 schrieb Tobias Knerr o...@tobias-knerr.de: Wie wäre es stattdessen mit :left/:right? Diese Anhängsel werden z.B. in JOSM ebenfalls als abhängig von der Richtung des Way verstanden und bei Bedarf umgedreht. So wäre auch das physische Spurlayout unabhängig von Linksverkehr vs. Rechtsverkehr eindeutig. (Dafür, in welcher Richtung man auf diesen Spuren fahren darf, bräuchte man allerdings das Wissen um die örtlichen Verkehrsregeln). Ich verstehe den Unterschied nicht zu :forward/:backward. Was sollte dann anders definiert sein bei :left/:right? Die Idee ist dieselbe. Es vermeidet aber Verwirrung, weil es bei deiner aktuellen Version sein kann, dass eine lane:forward eine andere Richtung als forward hat - z.B. both, wie in deinem Beispiel mit der Radspur: direction:lanes:forward=forward|forward|both|forward Du unterteilst die Straße also in Wirklichkeit gar nicht nach Vorwärts- und Rückwärtsspuren, sondern in eine linke Hälfte und rechte Hälfte. Daher ist :left/:right in gewisser Weise die bessere Wahl für das, was du ohnehin schon tust. Der eine konkrete Unterschied bei den Auswirkungen kommt nur beim Linksverkehr zum Tragen. * Die Spuren werden von innen nach außen angegeben, oder? Die Beispiele legen das nahe, aber es steht nicht explizit da. Habe ich ganz am Anfang jetzt noch etwas klarer geschrieben: immer von links nach rechts in Fahrtrichtung Warum das? Mit :left/:right und der Definition innen nach außen hat man wie gesagt den Vorteil, dass man das physische Spurlayout unabhängig von der Unterscheidung Links- oder Rechtsverkehr hält. bzw. für :both von links nach rechts in OSM-Way-Richtung. Dann hat man aber doch ein Problem, wenn man den Way umdreht. Ich hatte aufgrund deiner Formulierungen im Proposal (Big problem here! If the way is reversed the direction information is destroyed.) bisher eigentlich angenommen, dass du mit der Unterteilung des Spurlayouts in zwei (oder drei) Teile gerade das vermeiden wolltest. Wenn du gar kein Problem damit hast, dass die Sortierung der Spuren von der OSM-Way-Richtung abhängig ist, verstehe ich nicht mehr, warum du nicht direkt alle Spuren von links nach rechts in ein Tag packst? Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Draft für lanes Proposal
Hallo, Am 03.02.2012, 15:23 Uhr, schrieb Tobias Knerr o...@tobias-knerr.de: Am 03.02.2012 14:50, schrieb Martin Vonwald: Ich verstehe den Unterschied nicht zu :forward/:backward. Was sollte dann anders definiert sein bei :left/:right? Die Idee ist dieselbe. Es vermeidet aber Verwirrung, weil es bei deiner aktuellen Version sein kann, dass eine lane:forward eine andere Richtung als forward hat - z.B. both, wie in deinem Beispiel mit der Radspur: Ich habe mir damals bei dem parking:lane-Proposal viele Gedanken gemacht zum Thema forward/backward vs. left/right. Damals gab es vornehmlich nur forward/backward. Die Idee, left/right einzuführen begab sich aus der Notwendigkeit heraus, Dinge links und rechts der Straße darzustellen, und zwar insbesondere in dem Falle, dass es sich um eine Einbahnstraße handelt. Mein Fazit zum Unterschied zw. beiden: * Nimm left/right, wenn es sich um *stationäre* Dinge handelt, die sich links/rechts der Straße befinden, z.B. Parkbuchten. (Es geht um Punkte (oder Punktmengen), die sich links oder rechts im Hinblick auf den Way-Vektor befinden). * Nimm forward/backward, wenn es sich um den *bewegenden* Verkehr handelt, z.B. unterschiedliche maxspeed in beide Richtungen. (Es geht um Vektoren, die in dieselbe oder entgegengesetzte Richtungen wie der Way gehen.) Ein Problem mit Linksverkehr ergibt sich bei beiden Möglichkeiten eigentlich nicht. Viele Grüße, Kay ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Draft für lanes Proposal
Am 3. Februar 2012 15:23 schrieb Tobias Knerr o...@tobias-knerr.de: Am 03.02.2012 14:50, schrieb Martin Vonwald: Am 3. Februar 2012 14:32 schrieb Tobias Knerr o...@tobias-knerr.de: Wie wäre es stattdessen mit :left/:right? Diese Anhängsel werden z.B. in JOSM ebenfalls als abhängig von der Richtung des Way verstanden und bei Bedarf umgedreht. So wäre auch das physische Spurlayout unabhängig von Linksverkehr vs. Rechtsverkehr eindeutig. (Dafür, in welcher Richtung man auf diesen Spuren fahren darf, bräuchte man allerdings das Wissen um die örtlichen Verkehrsregeln). Ich verstehe den Unterschied nicht zu :forward/:backward. Was sollte dann anders definiert sein bei :left/:right? Die Idee ist dieselbe. Es vermeidet aber Verwirrung, weil es bei deiner aktuellen Version sein kann, dass eine lane:forward eine andere Richtung als forward hat - z.B. both, wie in deinem Beispiel mit der Radspur: direction:lanes:forward=forward|forward|both|forward Dieses Beispiel stellt ja einen Spezialfall dar und wie beschrieben ist das :forward dort eigentlich unnötig und wird nur verwendet, damit die Spurrichtungen nicht zerstört werden, wenn der Weg umgedreht wird. Du unterteilst die Straße also in Wirklichkeit gar nicht nach Vorwärts- und Rückwärtsspuren, sondern in eine linke Hälfte und rechte Hälfte. Daher ist :left/:right in gewisser Weise die bessere Wahl für das, was du ohnehin schon tust. Hm... dem kann ich nicht folgen. Es gibt in OSM z.B. lanes:forward=2 - das sagt uns, dass es zwei Spuren gibt, welche in die selbe Richtung führen wie der OSM-Way. Ich möchte hier ein bekanntes Konzept verwenden und :forward/:backward ist so eines. Ich muss offen zugeben, dass ich vor dem heutigen Tag noch nie etwas von :left/:right gehört oder gesehen habe. Genau schon wie bei der kurzen Diskussion um den ; gilt auch hier: dieses Proposal definiert hier nichts um. Und das soll es ja auch nicht. Spuren in Wegrichtung wurden bisher als :forward getaggt und das sollen sie auch weiterhin. Spuren gegen die Wegrichtung wurden bisher als :backward getaggt und das sollen sie auch weiterhin. Dieses Proposal gibt dir nur die Möglichkeit Eigenschaften für diese Spuren anzugeben. Der obige Spezialfall ist übrigens gar nicht so unlogisch, denn das :forward am Ende bedeutet ja nach aktuellem Verständnis, dass wir Eigenschaften in Richtung des OSM-Ways definieren. Wenn die Spur nun in diese Richtung verläuft, ist sie eine forward-Spur. Verläuft sie entgegen dieser Richtung eben eine backward-Spur. Das Beispiel ist nicht hübsch, aber es sollte nur sehr selten notwendig sein sowas zu taggen. Der eine konkrete Unterschied bei den Auswirkungen kommt nur beim Linksverkehr zum Tragen. * Die Spuren werden von innen nach außen angegeben, oder? Die Beispiele legen das nahe, aber es steht nicht explizit da. Habe ich ganz am Anfang jetzt noch etwas klarer geschrieben: immer von links nach rechts in Fahrtrichtung Warum das? Mit :left/:right und der Definition innen nach außen hat man wie gesagt den Vorteil, dass man das physische Spurlayout unabhängig von der Unterscheidung Links- oder Rechtsverkehr hält. Nur du verlierst die Information über die Fahrtrichtung! Und diese Information ist viel wichtiger als die Information ob die Vorwärts-Spuren links oder rechts sind: Wenn ein Router keine Ahnung hat ob wir Rechts- oder Links-Verkehr haben, kann er mit :forward/:backward trotzdem korrekte Routen berechnen, er kann nur keine Penaltys für das Linksabbiegen bei Rechtsverkehr (und umgekehrt) vergeben. Wenn ein Router wiederum keine Ahnung hat ob wir Rechts- oder Links-Verkehrt haben, hat er mit :left/:right das unlösbare Problem, dass er nicht weiß, zu welcher Kreuzung die Abbiegespuren führen: zur nächsten oder zur vorherigen. Er weiß zwar wo welche Spuren liegen, kann aber mit diesen Information überhaupt nichts anfangen, da ihm die Richtung fehlt. bzw. für :both von links nach rechts in OSM-Way-Richtung. Dann hat man aber doch ein Problem, wenn man den Way umdreht. Welches? Ich hatte aufgrund deiner Formulierungen im Proposal (Big problem here! If the way is reversed the direction information is destroyed.) bisher eigentlich angenommen, dass du mit der Unterteilung des Spurlayouts in zwei (oder drei) Teile gerade das vermeiden wolltest. Wenn du gar kein Problem damit hast, dass die Sortierung der Spuren von der OSM-Way-Richtung abhängig ist, verstehe ich nicht mehr, warum du nicht direkt alle Spuren von links nach rechts in ein Tag packst? Die Sortierung muss irgendwie definiert sein. Auch wenn direkt alle Spuren von links nach rechts eingetragen werden, muss man definieren, wo links ist. Im allgemeinen geht man davon aus, dass dies aus Sicht der OSM-Weg-Richtung betrachten wird und damit hast du wieder deine Abhängigkeit. vg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Draft für lanes Proposal
Mein Fazit zum Unterschied zw. beiden: * Nimm left/right, wenn es sich um *stationäre* Dinge handelt, die sich links/rechts der Straße befinden, z.B. Parkbuchten. (Es geht um Punkte (oder Punktmengen), die sich links oder rechts im Hinblick auf den Way-Vektor befinden). * Nimm forward/backward, wenn es sich um den *bewegenden* Verkehr handelt, z.B. unterschiedliche maxspeed in beide Richtungen. (Es geht um Vektoren, die in dieselbe oder entgegengesetzte Richtungen wie der Way gehen.) Danke, so habe ich es auch verstanden. Aus dieser Sicht ist es eigentlich klar, dass es :forward/:backward sein muss. Vielen Dank und vg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Draft für lanes Proposal
Am 03.02.2012 17:14, schrieb Martin Vonwald: Mein Fazit zum Unterschied zw. beiden: * Nimm left/right, wenn es sich um *stationäre* Dinge handelt, die sich links/rechts der Straße befinden, z.B. Parkbuchten. (Es geht um Punkte (oder Punktmengen), die sich links oder rechts im Hinblick auf den Way-Vektor befinden). * Nimm forward/backward, wenn es sich um den *bewegenden* Verkehr handelt, z.B. unterschiedliche maxspeed in beide Richtungen. (Es geht um Vektoren, die in dieselbe oder entgegengesetzte Richtungen wie der Way gehen.) Danke, so habe ich es auch verstanden. Aus dieser Sicht ist es eigentlich klar, dass es :forward/:backward sein muss. Hmm? Die von Kay beschriebene Regel entspricht im Grunde auch meiner Denkweise, und genau deshalb kritisiere ich doch deine Verwendung von :forward/:backward. Wenn sich (in Wayrichtung) rechts der Fahrbahn eine Radspur befindet, auf der Fahren in beide Richtungen erlaubt ist, dann ist die Spur permanent dort aufgemalt. Es handelt sich also *nicht* um eine Eigenschaft, die von der Flussrichtung des Verkehrs abhängt. Anders gesagt: Wir haben ein Tag zur Angabe der Lage der Spur. Mit Kenntnis der lokalen Regeln kann man aus der Lage auch den Default für die Fahrtrichtung des Verkehrs darauf ableiten, aber das ist nur eine abgeleitete Information und sie kann bei Bedarf per direction-Tag überschrieben werden. Die Lage ist die *primäre* Information. Ich hoffe, ich nerve nicht zu sehr. Aber aus meiner Sicht ist glasklar, dass hier :left/:right geeignet ist und du einfach falsch denkst. ;) Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Draft für lanes Proposal
Hmm? Die von Kay beschriebene Regel entspricht im Grunde auch meiner Denkweise, und genau deshalb kritisiere ich doch deine Verwendung von :forward/:backward. Kay schrieb: * Nimm left/right, wenn es sich um *stationäre* Dinge handelt, die sich links/rechts der Straße befinden, z.B. Parkbuchten. Ein Radspur mitten auf der Fahrbahn oder eine Straßenbahnspur befindet sich weder rechts noch links der Fahrbahn, sondern ist Teil dieser. * Nimm forward/backward, wenn es sich um den *bewegenden* Verkehr handelt, z.B. unterschiedliche maxspeed in beide Richtungen. (Es geht um Vektoren, die in dieselbe oder entgegengesetzte Richtungen wie der Way gehen.) Die Fahrspuren (Rad, Straßenbahn, ...) besitzen bewegenden Verkehr und es handelt sich um Vektoren, welche in die selbe oder entgegengesetzte Richtung des Ways gehen. Wenn sich (in Wayrichtung) rechts der Fahrbahn eine Radspur befindet, auf der Fahren in beide Richtungen erlaubt ist, dann ist die Spur permanent dort aufgemalt. Es handelt sich also *nicht* um eine Eigenschaft, die von der Flussrichtung des Verkehrs abhängt. Die Radspur hat eine Flussrichtung. Übrigens ist die Radspur nicht rechts der Fahrbahn sondern Teil dieser. Anders gesagt: Wir haben ein Tag zur Angabe der Lage der Spur. Mit Kenntnis der lokalen Regeln kann man aus der Lage auch den Default für die Fahrtrichtung des Verkehrs darauf ableiten, aber das ist nur eine abgeleitete Information und sie kann bei Bedarf per direction-Tag überschrieben werden. Die Lage ist die *primäre* Information. Die Lage ist wertlose Information, wenn du nicht weißt, was du dort machen darfst. Zusätzliche Informationen sollten so wenig wie möglich notwendig sein. Ich hoffe, ich nerve nicht zu sehr. Aber aus meiner Sicht ist glasklar, dass hier :left/:right geeignet ist und du einfach falsch denkst. ;) Du nervst nicht - wir diskutieren. Aber aus meiner Sicht ist glasklar, dass hier :forward/:backward geeignet ist und du einfach falsch denkst. ;) vg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Präzisionszeiger bei JOSM
Hallo hike39, die Meinung hatte ich vor vielleicht einem Jahr auch und im Forum gefragt (Der Mauscrusor mit den vier Pfeilen beim Verschieben von Objekten verdeckt mir zu viel) - dort wurde keine akzeptable Lösung gefunden. Später bin ich darauf gekommen, Objekte mit der Tastatur zu verschieben. Das geht mit Shift+Pfeiltasten (bei mir läuft Win-XP). Wenn also ein Knoten, eine Linie oder eine Gruppe von Objekten ausgewählt (rot markiert) ist, kann man diese mit der Taste für Großschreibung (Shift) und den vier Richtungspfeilen der Tastatur in Pixel-Einheiten des Monitors verschieben. Je nach Zoom ergibt sich dann eine kleine oder sehr kleine Verschiebung. Mit Strg und den Pfeilen kann man den Auschnitt aus der Karte in gröberen Schritten (ein Fünftel des Kartenausschnitts) verschieben. Helfende Grüße, Franz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenimport nach OpenStreetMap
Am 26.01.2012 17:47, schrieb Frederik Ramm: On 01/26/2012 03:42 PM, Chris wrote: An dieser Stelle aber der Hinweis: Falls Deine POIs von Nutzern mit Hilfe einer darunterliegenden Google-Karte eingezeichnet wurden (so a la Du weisst, wo ein AED steht? Zoome einfach in dieser Google-Karte an die richtige Stelle und klicke drauf...), so halten wir die Daten in der Regel fuer ein von Google abgeleitetes Werk, an dem Du bzw. der Erfasser nicht die alleinigen Rechte hat und das deswegen auch nicht unter die OSM-Lizenz gestellt werden kann. Dem ist so. Also hat sich der Import schon erledigt. Wir hatten eine aehnliche Situation vor einigen Jahren mit dem Projekt OpenAddresses. Die hatten auch auf Basis von Google (Luftbild in dem Fall) erfasst und fanden selber nichts dabei; OSM war dann pingeliger und hat gesagt nee, Eure Daten wollen wir nicht. Das war ein bisschen eine bloede Situation damals, und ich persoenlich fand das etwas uebertrieben, aber OSM wollte da halt 100% clean sein. Mittlerweile ist die Situation mit OA ja anders, man editiert praktisch auf der OA-Plattform direkt OSM-Daten. Ist man denn heute immer noch so pingelig bei solchen Importen? Sprich Information x (ohne Geokordinate) aus legaler Quelle wurde anhand google Luftbild (von einem einzigen User) jeweils einer Position zugeordnet. Mittlerweile gibt es allerdings die Luftbilder von Bing mit denen man die Daten dann sozusagen remappen kann - natürlich nur wenn das dann auch aus den Bing Luftbildern hervorgeht. Wo wäre da dann der konkrete Stein des Anstoßes bzw. das zu lösende Problem? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Draft für lanes Proposal
Ich zitiere auch noch mal aus einer deiner früheren Mails, weil ich den Eindruck habe, dass wir nicht dieselbe Anwendung im Kopf haben. Am 03.02.2012 17:12, schrieb Martin Vonwald: Du unterteilst die Straße also in Wirklichkeit gar nicht nach Vorwärts- und Rückwärtsspuren, sondern in eine linke Hälfte und rechte Hälfte. Daher ist :left/:right in gewisser Weise die bessere Wahl für das, was du ohnehin schon tust. Hm... dem kann ich nicht folgen. Es gibt in OSM z.B. lanes:forward=2 - das sagt uns, dass es zwei Spuren gibt, welche in die selbe Richtung führen wie der OSM-Way. Ich möchte hier ein bekanntes Konzept verwenden und :forward/:backward ist so eines. Das bekannte Konzept muss hier zwangsläufig erweitert werden, weil wir bei einer Spur zwei Informationen vorliegen haben: * Wo liegt die Spur? * In welcher Richtung darf man darauf fahren? Es ist leicht zu übersehen, weil bei Autospuren hier wegen der gesetzlichen Regelungen normalerweise eine direkte Beziehung besteht, aber: Von der Lage war im alten Konzept noch gar nicht die Rede. In einem vollwertigen Spurkonzept muss sie aber wiedergegeben werden. Warum das? Mit :left/:right und der Definition innen nach außen hat man wie gesagt den Vorteil, dass man das physische Spurlayout unabhängig von der Unterscheidung Links- oder Rechtsverkehr hält. Nur du verlierst die Information über die Fahrtrichtung! Und diese Information ist viel wichtiger als die Information ob die Vorwärts-Spuren links oder rechts sind: Wenn ein Router keine Ahnung hat ob wir Rechts- oder Links-Verkehr haben [...] Du denkst anscheinend in erster Linie an Router. Bei denen hast du auch Recht, aber Router sollten sowieso die örtlichen Verkehrsregeln kennen. Renderer kennen sie in der Regel nicht und sollten sie auch nicht kennen müssen. Aber der Renderer will wissen, ob er z.B. auf der linken oder rechten Wayseite einen Streifen für Radspur zeichnen soll. In welcher Richtung man dort dann fährt, braucht er hingegen nicht wissen - das wird sich der Kartenbetrachter selbst erschließen. Hier kommen wieder meine beiden o.g. Eigenschaften der Spur ins Spiel: Lage der Spur und Fahrtrichtung. Ein Router sollte idealerweise beides wissen. Einem Renderer reicht hingegen oft die Lage. Und mit der innen-nach-außen-Regel kann man die Lage ermitteln, ohne die Fahrtrichtung zu kennen. Am 03.02.2012 18:58, schrieb Martin Vonwald: Ein Radspur mitten auf der Fahrbahn oder eine Straßenbahnspur befindet sich weder rechts noch links der Fahrbahn, sondern ist Teil dieser. Der Bezug zur Fahrbahn ist aus meiner Sicht nicht entscheidend. Sie befinden sich links/rechts der Mittellinie, auf die eine Straße in unserem Datenmodell reduziert wird. (Oder auf dieser, dann entsprechen sie einer center lane.) Vor dem Hintergrund des bisher Gesagten noch mal zusammengefasst meine Position: Ich will ausdrücken: * Lage der Spur * Fahrtrichtung des Verkehrs darauf. Die _Lage_ drücke ich aus, indem ich die Eigenschaften der Spuren links bzw. rechts meiner gedachten Mittellinie, geordnet nach Entfernung von dieser Mittellinie, als Wertliste aufschreibe. Für die _Fahrtrichtung_ nehme ich an, dass Spuren rechts der Mittellinie in Wegrichtung befahren werden, links davon entgegen der Wegrichtung. (Bei Linksverkehr umgekehrt.) Wo diese Annahme nicht zutrifft, setze ich die Fahrtrichtung ausdrücklich über ein direction-Tag. So, vielleicht hab ich's diesmal richtig erklärt, damit wir zumindest den anderen Standpunkt verstehen können. Ich merke aber, wie ich mich langsam emotional in meine Position eingrabe - und das ist nicht der beste Geisteszustand für eine konstruktive Diskussion. Daher werde ich für heute erst mal den Mund halten und morgen in Ruhe und mit etwas Abstand noch mal über unsere Positionen nachdenken. Vielleicht machst du ja dasselbe? :) Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Potlach 2 - kein bing-Hintergrund-Bild mehr bei Militaerflaechen
In Mannheim sind die amerikanischen Kasernen und Wohngebiete verschleiert. Aber auch militärisch aufgegebene Gebiete, die zum Teil seit vielen Jahren wieder frei zugänglich sind, sind verschleiert. (Die waren Ende 2011 in OSM allerdings als military markiert). Der Auftraggeber der Verschleierung hat also ziemlich nachlässig, wenn nicht schlampig gearbeitet. Und bing hat ohne Not zivile Flächen verschleiert. Tolle Leistung auf beiden Seiten. Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenimport nach OpenStreetMap
Hi, On Fri, 03 Feb 2012 19:29:07 +0100 M northc...@gmx.de wrote: Ist man denn heute immer noch so pingelig bei solchen Importen? Sprich Information x (ohne Geokordinate) aus legaler Quelle wurde anhand google Luftbild (von einem einzigen User) jeweils einer Position zugeordnet. Dadurch hat nach unserer Lesart Google einen Anteil an den Rechten der gewonnenen Information. Mittlerweile gibt es allerdings die Luftbilder von Bing mit denen man die Daten dann sozusagen remappen kann - natürlich nur wenn das dann auch aus den Bing Luftbildern hervorgeht. Wo wäre da dann der konkrete Stein des Anstoßes bzw. das zu lösende Problem? Wenn der Benutzer behauptet, die Daten anhand von Bing-Bildern positioniert zu haben, und niemand ihm nachweisen kann, dass sie von Google kommen, ist die Sache ok. Wenn der Benutzer aber sagt: Ich habe das hier anhand von Google positioniert, aber ich *haette* es genauso gut anhand von Bing positionieren *koennen*, dann ist die Lage unveraendert - Google hat einen Anteil an den Rechten und die Daten sind nicht nutzbar. Das klingt ein bisschen absurd, aber leider gibt es Urheberrecht nicht fuer etwas, was man haette machen koennen ;) Beim Remappen ist es aehnlich - ein Nichtzustimmer hat eine Strasse abdigitalisiert, und ich koennte sie jetzt 100% genau so abdigitalisieren - aber es reicht nicht, dass ich *koennte*, ich muss es tatsaechlich *tun*. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Openstreetmap.de - Suchergebnis zeigt komische Daten an (war: Re: Geocaching.com teilweise zu OSM gewechselt)
Hi Dennis, On Wed, Jan 18, 2012 at 02:39:07PM +0100, Dennis Hesse wrote: Am 18.01.2012 um 14:23 schrieb Michael Krämer: Am 18. Januar 2012 13:39 schrieb Dennis Hesse zor...@googlemail.com: Was mir da gerade aufgefallen ist, hab mal nach TomTailor gesucht, weil die Adresse mir bekannt ist, hab da auf der Ecke gewohnt. Ergebnis ist: Tom Tailor, Hinschkoppel, ALDI Markt, Niendorf, Eimsbüttel, Hamburg, Kreis Pinneberg, Freie und Hansestadt Hamburg, Hamburg (Landmasse), 22453, Deutschland Was ich dabei komisch finde ist: ALDI Markt, Kreis Pinneberg Wie kommen die Anzeigen da hin? In dem Gebäude befindet sich weder ein Aldi, noch ist das im Kreis Pinneberg ? Ok, damit wäre der ALDI geklärt, ich mein, dass die sich ausbreiten war ja bekannt, aber ganz Europa ein ALDI? ;-) Bliebe noch die Geschichte mit Kreis Pinneberg, kann dazu jemand was sagen? Das ist etwas komplizierter. Die Node, die da in die Adresse hereinrutscht, ist diese: http://www.openstreetmap.org/browse/node/309713677 Nominatim wählt diese Node aus, weil es in Hamburg anscheinend keine Grenzen mit Admin-Level 6 gibt und das einfach der nächstgelegene Punkt in diesem Level ist. Eigentlich sollte Nominatim erkennen, dass diese Node das gleiche ist, wie diese Relation: http://www.openstreetmap.org/browse/relation/62408 Das klappt aber (noch) nicht so richtig. Du könntest einfach die Node löschen, das sollte Nominatims Ausgabe verbessern. Oder du kannst es einfach so lassen, und hoffen, dass Nominatim seinen Algorithmus verbessert. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Idee für's lanes-mapping
Um es vorwegzuschicken: Ich bin nicht gegen die Einführung von Linienbündeln. Ich bin nur dagegen, dies ohne grafischen Editor zu tun. Bernd Wurst be...@bwurst.org wrote: Am 02.02.2012 21:32, schrieb Tirkon: Wenn man Linienbündel einführt oder über ein entsprechendes Proposal abzustimmen gedenkt, dann nicht ohne das JOSM Plugin mitzuliefern, mit dem all dies ausreichend visualisiert und grafisch editierbar wird. Außerdem gehört eine nicht nur für Computerfreaks verstehbare Gebrauchsanleitung des Plugins dazu. Das gehört sicherlich nicht zur Diskussion um den Vorschlag an sich. Wir hatten noch nie zuerst ein fertiges Plugin und danach die Sinnfrage. Natürlich muss es neue Denkmodelle und Ideen geben. Man muss den einfachsten Weg finden, um ein gewisses Problem zu beschreiben. Und dieses einfachste und beste Modell entsteht natürlich nur iterativ durch die Schwarmintelligenz. Und dazu braucht es Diskussionen - Keine Frage. Mir geht es darum, dass hier womöglich ein Modell auf die Schnelle durchgewunken wird. Ich hatte daher in meinem Posting das Plugin vor eine Einführung und Abstimmung eines Modells gestellt, nicht vor das Diskutieren einer Sinnfrage. Mehr zum Plugin weiter unten. Möglicherweise bietet eine zukünftige API Features, die das Mappen von Linienbündeln vereinfachen. Wer sie also in OSM möchte, möge sich Gedanken machen, wie das geschehen könnte. Einen Vorschlag mache ich weiter unten. Nein, bitte nicht. Die API muss so minimal wie möglich sein. Wir haben unsere primitiven Datentypen und mit den Tags können wir daraus lustige Dinge machen. Aber die API muss das alles nicht verstehen, nicht bewerten und auch nicht beschränken. Die API kann dem Weg eine Richtung geben. Das empfindest Du offensichtlich nicht als Bewertung oder Beschränkung, sondern akzeptierst sie. Offensichtlich siehst Du einen Nutzen darin. Wenn dasselbe für Tags (und eventuell für Relationselemente) möglich ist, ist das keine Beschränkung, sondern die Aufhebung einer Beschränkung. Auch für Punkte wäre eine Richtungsangabe sinnvoll, z.B. bei Ortseingangsschildern mit beidseitig verschiedenen Beschriftungen. Derzeit braucht man dazu Relationen. Wenn das mit der API wesentlich einfacher ginge, könnte man auch hier darüber nachdenken. Überhaupt: Wenn es mit der API vergleichweise einfach ist, ansonsten nur kompliziert darstellbare und sehr oft gebrauchte Features zu implementieren, sollte man darüber nachdenken. Dabei sind - natürlich - penibelst Einschränkungen der Freiheit auszuschließen. Im OSM Wiki sind eine ganze Reihe ausformulierte Vorschläge zum Thema Linienbündel zu finden. Einige davon sind recht ähnlich zu diesem. Auch einen Workshop hat es schon gegeben: http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Workshops/Linienb%C3%BCndel Nein, da ist keiner dabei, der es erlaubt ein Tag für mehrere Spuren zu definieren. Die im Wiki genannten sind alle wesentlich komplexer und weniger menschenlesbar. Ohne Frage auf den ersten Blick eine gute Idee! :-) Beim algorithmischen Zerlegen einer solchen Idee zeigt sich häufig, wie gut und flexibel sie wirklich ist. Insofern ist das Schreiben eines grafischen Editors sicherlich keine schlechte Gewährleistung dafür. Im Prinzip sind die Modelle daran gescheitert, dass so Getagtes auch maintained sein will. Unter Anderem müssen Linienbündel zunächst eingetragen aber vor Allem auch aktuell gehalten werden. Was nützen fehlleitende Spurassistenten? Mit dem Totschlagargument kann man jede neue Idee die ins Detail geht kaputtreden. Die Linienbündel (mit Abstrichen auch den ÖPNV) sehe ich als einen bisher einmaligen Sonderfall in OSM. Von daher kann man nicht davon sprechen, dass so jede neue Idee totgeschlagen werden könnte oder sollte. Ich will das eingehender darlegen: Es stört kaum jemand Anderen, wenn man Bäume, Kanaldeckel, Vogelhäuschen oder Grashalme mappt. Es stört wenig, wenn da ein Tag nicht stimmt. Hier im Thread aber ist der zentrale Bereich des Straßennetzes betroffen, auf dem die meisten OSM Applikationen aufsetzen. Ohne Straßennetz hätte es OSM - zumindest mit der jetzigen gewaltigen Community Größe - nie gegeben. Hier ist man auf ein durchgehend stimmiges Netz angewiesen, wenn man Routenplaner und Navis auf dessen Grundlage beschicken will. Um das auch in der Fläche sicherzustellen, sind wir auf User vor Ort angewiesen, die ihre Home-Area auf dem Laufenden halten. Im Gegensatz zum falsch bezeichneten Baum, den man explizit ansteuern muss, stößt man Durchgehen eines Straßennetzes unweigerlich auf Linienbündel und muss diese maintainen. Und wenn man dann die User vor Ort, die allein einige zig Quadratkilometer zu betreuen haben, durch eine Verkomplizierung vom Maintaining ausschließt, wird es problematisch. Die Freiheit einer kleinen Gruppe von Abstimmenden steht hier gegen diejenige einer großen und hier nicht vertretenen Userschar, die ausgeschlossen und möglicherweise vergrault wird. Schon bei dem ÖPNV-Schema war das in
[Talk-de] Tag für aufgelassene Militärflächen (was: Potlach 2 - kein bing-Hintergrund-Bild mehr bei Militaerflaechen
In Mannheim sind die amerikanischen Kasernen und Wohngebiete verschleiert. Dexheim, Darmstadt... alles längst an die Gemeinden zurückgegeben, aber halt noch umzäunt, in der Hoffnung möglichst doch den einen oder anderen Buntmetalldieb abzuhalten. Wie tagt man soetwas eigentlich richtig? Also nach Rückübertragung im Besitz der Bundesanstalt für Immobilienaufgaben, der Gemeinde, oder schon bei Schrottflächenbrokern wie Aurelis, Vivico/CA- Immo und Co. Landuse=Military ist ja nichtmehr korrekt. Landuse=Brownfield auch nicht, weil da ja großenteils noch voll benutzbare Gebäude stehen. Landuse=Commercial ist aber auch blöd, wenn dabei der Flächenanteil von Housing überwiegt. Aber Landuse=Residential ist auch falsch, weil ja nun wirklich niemand da wohnt. Vorschläge? Lästerhaft vielleicht: landuse=construction construction=despoilment -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag für aufgelassene Militärflächen (was: Potlach 2 - kein bing-Hintergrund-Bild mehr bei Militaerflaechen
Am 04.02.2012 um 00:51 schrieb Johann H. Addicks: Vorschläge? Lästerhaft vielleicht: landuse=military a.D.? ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Openstreetmap.de - Suchergebnis zeigt komische Daten an
Du könntest einfach die Node löschen, das sollte Nominatims Ausgabe verbessern. Oder du kannst es einfach so lassen, und hoffen, dass Nominatim seinen Algorithmus verbessert. Nominatim wird mit der Zeit durchaus besser. Die Suche nach Klingenberg (bei Google-Maps das erwartete Ergebnis die Ortschaft in Bayern) liefert im Nominatim jetzt zumindest als zweiten Hit das gleiche. Vor einigen Monaten war die Ortschaft noch nichtmal in den ersten 20 (30?) Hits, wenn man sich denn durchgeblättert hat. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Idee für's lanes-mapping
Hi, klinke mich hier nun doch nochmal ein … Am 04.02.2012 um 00:46 schrieb Tirkon: Möglicherweise bietet eine zukünftige API Features, die das Mappen von Linienbündeln vereinfachen. Wer sie also in OSM möchte, möge sich Gedanken machen, wie das geschehen könnte. Einen Vorschlag mache ich weiter unten. Nein, bitte nicht. Die API muss so minimal wie möglich sein. Wir haben unsere primitiven Datentypen und mit den Tags können wir daraus lustige Dinge machen. Aber die API muss das alles nicht verstehen, nicht bewerten und auch nicht beschränken. Überhaupt: Wenn es mit der API vergleichweise einfach ist, ansonsten nur kompliziert darstellbare und sehr oft gebrauchte Features zu implementieren, sollte man darüber nachdenken. Dabei sind - natürlich - penibelst Einschränkungen der Freiheit auszuschließen. +1 Im Prinzip sind die Modelle daran gescheitert, dass so Getagtes auch maintained sein will. Unter Anderem müssen Linienbündel zunächst eingetragen aber vor Allem auch aktuell gehalten werden. Was nützen fehlleitende Spurassistenten? Mit dem Totschlagargument kann man jede neue Idee die ins Detail geht kaputtreden. Die Linienbündel (mit Abstrichen auch den ÖPNV) sehe ich als einen bisher einmaligen Sonderfall in OSM. Von daher kann man nicht davon sprechen, dass so jede neue Idee totgeschlagen werden könnte oder sollte. Ich will das eingehender darlegen: Es stört kaum jemand Anderen, wenn man Bäume, Kanaldeckel, Vogelhäuschen oder Grashalme mappt. Es stört wenig, wenn da ein Tag nicht stimmt. Hier im Thread aber ist der zentrale Bereich des Straßennetzes betroffen, auf dem die meisten OSM Applikationen aufsetzen. Ohne Straßennetz hätte es OSM - zumindest mit der jetzigen gewaltigen Community Größe - nie gegeben. Hier ist man auf ein durchgehend stimmiges Netz angewiesen, wenn man Routenplaner und Navis auf dessen Grundlage beschicken will. Um das auch in der Fläche sicherzustellen, sind wir auf User vor Ort angewiesen, die ihre Home-Area auf dem Laufenden halten. Im Gegensatz zum falsch bezeichneten Baum, den man explizit ansteuern muss, stößt man Durchgehen eines Straßennetzes unweigerlich auf Linienbündel und muss diese maintainen. Und wenn man dann die User vor Ort, die allein einige zig Quadratkilometer zu betreuen haben, durch eine Verkomplizierung vom Maintaining ausschließt, wird es problematisch. Die Freiheit einer kleinen Gruppe von Abstimmenden steht hier gegen diejenige einer großen und hier nicht vertretenen Userschar, die ausgeschlossen und möglicherweise vergrault wird. Zum Pflegen des Straßennetzes in der Fläche sind die User auch von Nöten … Ob die nun ein Linienbündel oder eine normale Straße pflegen, ist meiner Meinung nach egal, solange das Pflegen des Bündels ähnlich einfach ist. Von daher geh ich damit konform, dass vor dem Einführen einer entsprechenden Entwicklung auf jeden Fall ein entsprechendes Tool für den Normal-Mapper nötig ist. Was nützt es wenn sogar ich als Mapper lieber ein propietäres Navi benutze weil das Fahrspuren anzeigen kann? Wenn uns die Mapper wegen steigender Komplexität davonlaufen, werden Deinem OSM-Navi nicht nur die Fahrspuren fehlen, sondern auch die Straßen. Also sollten nach Möglichkeit beide Dinge kombiniert werden, eine vereinfachte Bedienung der Editoren, trotz höherer Komplexität, so dass die Otto-Normal- Verbraucher, die gerne einen Fahrspurassistenten hätten, diesen auch selber durch entsprechendes Mapping ermöglichen können. Wie schon gesagt: Briefkästen sind ein Additiv und ignorierbar. Linienbündel ERSETZEN vorhandene Straßenteile. Vielleicht sollte man daran ansetzen? Ich kenne das Konzept der Linienbündel nicht, hab da noch keine Zeit gefunden, mich einzulesen, aber kann man nicht beides parallel nutzbar machen? Problem Nummer 4 ist das Verwenden eines Modells, das man nicht bis zu Ende gedacht hat und zu Inkonsistenzen oder Nichtabbildbarkeit unbedachter Fälle führt. Wir haben in OSM recht viele Dinge die sehr einfach und konsequent sind und damit nicht alle Eventualitäten direkt abbilden können. Das stört nicht. Man betrachte den ÖPNV in OSM. Hier existieren zig Modelle nebeneinander. Kein anderes Gebiet auf OSM ist derart chaotisch. Und warum? Weil ständig neue Modelle entwickelt wurden, die ein kleines bisschen mehr konnten als das vorige und anschließend von einer kleinen Userschaft, die das so verabredet hatte, genutzt wurde. Einige von diesen Modellen werden nur von wenigen Usern beherrscht und damit auch nicht maintained. Jeder befand sein Modell für das Beste und sah keinen Anlaas, nach Besserem und Umfassenderen zu suchen, bevor man es in den Einsatz schickt. Duchgewinkt wurde das von einer Handvoll Leute, die mit komplexeren Modellen kein Problem haben. Man darf nach nun einiger ins Land gegangenen Zeit wohl mit Fug und Recht behaupten, dass eine gewaltige Mehrheit von Mappern mit den Füßen gegen die ÖPNV Modelle abgestimmt hat
Re: [Talk-de] Draft für lanes Proposal
Guten Morgen, Ich fasse das Ziel des aktuellen Proposals kurz zusammen: Definition der Eigenschaften einzelner Spuren. Da Proposal oft wegen zu hoher Komplexität abgelehnt werden, ist das Ziel bewusst niedrig gesteckt. Durch die Art wie das Proposal das erreichen will ergibt sich die Lage der Spuren innerhalb einer Fahrtrichtung. Die Lage der Fahrtrichtungen zueinander wird nicht definiert, kann bei Kenntnis von Rechts-/Links-Verkehr aber abgeleitet werden. Diese Information ist nicht Teil des Proposals (niedrige Komplexität), kann aber jederzeit durch z.B. ein Tag an den Landesgrenzen bzw. im Grenzbereich direkt am Way ergänzt werden. Dieses Proposal ist beabsichtigt einfach gehalten und vermeidet Umdefinitionen um den Stillstand in diesem Bereich zu beenden. Es ist eine Evolution der bestehenden Tags. So eine Vorgehensweise bringt nicht immer die hübschesten Lösungen, aber man muss immer im Hinterkopf haben was konsensfähig ist und was nicht. Am hübschesten wäre es, viele der bestehenden Tags zu verwerfen und von Grund auf neu zu definieren. Sind wir ehrlich: das wird nicht passieren. Ich habe deinen Standpunkt schon verstanden und bin mir des Problems auch bewusst (siehe Abschnitt Probleme im Proposal). Ich werde das Links-/Rechtsverkehrproblem noch einmal hervorheben und auf die Konsequenzen sowie die möglichen Lösungen hinweisen. Vg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
