Re: [Talk-de] Trennzeichen bei Aufzählungen im Wert eines Tags (war: motorway und motorway_link um destination-tag ergänzen )
(oh weia, ich war ein paar Tage unterwegs ... wieviel kann man über so etwas normales und notwendiges wie ein Leerzeichen eigentlich diskutieren) Moin, Am Freitag 04 Juni 2010, 08:17:58 schrieb Schorschi: den Käse übersehe ich jetzt mal Ich seh hier nichts gelbes mit Löchern drin. der Käse kam von dir - in deiner Vor-E-Mail, auf die ich antwortete. Und ich fand den nicht besonders originell, wie ebenso den Diskussionsstil in deiner E-Mail, auf die ich jetzt reagiere ... das wollte ich mit übersehe ich jetzt mal ausdrücken. Besser ausformuliert: könntest du bitte sachlich bleiben? Stimme ich dagegen. Die Lesbarkeit mit Semikolon ist immer etwas eingeschränkt, da macht das auch nichts mehr aus. Ein zukünftiger, guter Editor kann das ja selbst aufspalten und dem Benutzer lesbarer anzeigen. das ist keine Frage der Abstimmung, Oha, keine Abstimmung? Keine Konsensfindung? Du diktierst? nette Interpretation, die auf die Tränendrüse drückt - klassischer Versuch, den schwarzen Peter wegzuschieben. Meine Antwort auf den sachlichen Inhalt: Nein, keine Abstimmung. Das ist wie bei 2 x 2 = 4 ... darüber würde ich auch nicht abstimmen. Mit Leerzeichen sind die Tags besser lesbar, das ist alles. Nein, kein normal denkender Mensch würde die OSM-Tags im Rohdatenformat als Meisterstück der Typographie einstufen und das sollte es auch nicht werden. hat auch nie jemand behauptet Wir sollten so arbeiten, dass man mit den Daten sauber umgehen kann, dass das Datenformat eindeutig und computerverarbeitbar wird bzw. bleibt. das bleibt es auch mit Leerzeichen Wer typografische Ansprüche höher wertet als die Verarbeitung mit einem Rechner, der soll in Gottes Namen nicht an den Rohdaten rumpfuschen sondern mit geeigneten, abstrahierten Werkzeugen arbeiten. das ist ein untergeschobenes Argument, das nicht passt - die Verarbeitungsfähigkeit bleibt auch mit Leerzeichen erhalten und eindeutig. Das ist wieder ein klassischer Fall, wo die Programmierfraktion gegen die Benutzerfreundlichkeit argumentiert Ich sehe keinen messbaren Vorteil für die Benutzerfreundlichkeit. Die Lesbarkeit ... wenndudasnichtsiehst,kannichdirauchnichthelfen. Ich lasse ja auch nicht am Anfang jedes Tags ein Leerzeichen nur weil das in meinem Editor schöner aussieht. Da fängt das Feld an ... der optische Trenner ist schon vorhanden. Dir ist klar, dass wir hier nur von Tags reden, die mehrere Werte beim selben Key haben? Das kommt nicht alle Tage vor und das läuft dem normalen Mapper auch nicht jeden Tag übern Weg. Ja genau, und wenn deshalb die Rechenperformance ein winziges Quentchen schlechter wird, gibt es gar keinen Grund das Leerzeichen wegzulassen. - wofür werden Rechner eigentlich schneller und Speicher größer? Sicherlich nicht für deine obskuren Ansprüche. danke für diese persönliche Ansage (s. o.) Ein paar gewichtigere Argumente wären schon prima, ich denke Lesbarkeit ist in einem System, das in der Hauptsache von lesenden und schreibenden Nutzern seine Informationen bezieht, ein sehr gewichtiges Argument, zu dem ich bisher kein nennenswertes Gegenargument bekommen habe. Alles andere funktioniert ja weiterhin. Gruß, Schusch___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trennzeichen bei Aufzählungen im Wert eines Tags (war: motorway und motorway_link um destination-tag ergänzen )
Am Freitag 04 Juni 2010, 08:19:26 schrieb Schorschi: Leerzeichen zu entfernen ist technisch kein Problem, eine Anwendung sollte das sicherheitshalber schon koennen. Aber da die Leerzeichen keinerlei Vorteil bieten, laesst man sie besser gleich weg. äh, soll ich jetzt sagen: typisch Computer-Freak? nein, Entwickler. Ich hatte es doch geschrieben: Lesbarkeit ... damit Benutzerfreundlichkeit DAS Argument schlechthin, wenn man etwas lesen muss. Ich wage zu behaupten, dass die Daten in den meisten Faellen von Software gelesen und verarbeitet werden. Und ich zumindest kann sowas durchaus auch ohne Leerzeichen lesen. Ausserdem: Wer Benutzerfreundlichkeit will, liest sicher nicht direkt im XML- Code... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trennzeichen bei Aufzählungen im Wert eines Tags (war: motorway und motorway_link um destination-tag ergänzen )
Am Freitag 04 Juni 2010, 08:17:58 schrieb Schorschi: - mit Leerzeichen wird der Inhalt lesbarer und deshalb benutzerfreundlicher Stimme ich dagegen. Die Lesbarkeit mit Semikolon ist immer etwas eingeschränkt, da macht das auch nichts mehr aus. Ein zukünftiger, guter Editor kann das ja selbst aufspalten und dem Benutzer lesbarer anzeigen. das ist keine Frage der Abstimmung, sondern eine der Typographie, Typographie?!?! was hat das damit zu tun? da kannst du gerne dagegen stimmen, es hilft aber nichts. Es ist einfach eine Tatsache. Und das Warten auf zukünftige tolle Lösungen ist auch kein Argument gegen Benutzerfreundlichkeit. nochmal: Tags lesen in Verbindung mit Benutzerfreundlichkeit bringen ist total absurd. Das ist wieder ein klassischer Fall, wo die Programmierfraktion gegen die Benutzerfreundlichkeit argumentiert - wofür werden Rechner eigentlich schneller und Speicher größer? damit man nicht mehr programmieren koennen muss? Ich bin klar für bessere Lesbarkeit - gerne auch auf Kosten von etwas Performance. da man als Entwickler sowieso mit allem rechnen muss, laesst sich das sowieso nicht richtig effizient loesen... leider. Aber hey, scheiss auf Performance, wir haben ja alle Zetabytes an Speicher, Terahertz-Multicore-Prozessoren und 100-Gigabit-Anbindungen zuhause und auf unseren Mobilgeraeten... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trennzeichen bei Aufzählungen im Wert eines Tags (war: motorway und motorway_link um destination-tag ergänzen )
Moin, Alle Leerzeichen aus name/ref zu entfernen ist Käse. Man muss also statt aufspalten am Semikolon plötzlich aufspalten am Semikolon ODER an Semikolon plus Leerzeichen. Viele, vor allem hardwarenahe, schnelle Programmiersprachen verarbeiten ein einzelnes Stoppzeichen wesentlich effizienter als einen String als Token. Neben der Effizienz steigt der Programmieraufwand um 100%, da man statt einem konkreten plötzlich zweierlei mögliche Token hat. den Käse übersehe ich jetzt mal 100 % hört sich dramatisch an ... aber ist es hier wohl eher nicht, insbesondere bei steigender Performance der Rechner - mit Leerzeichen wird der Inhalt lesbarer und deshalb benutzerfreundlicher Stimme ich dagegen. Die Lesbarkeit mit Semikolon ist immer etwas eingeschränkt, da macht das auch nichts mehr aus. Ein zukünftiger, guter Editor kann das ja selbst aufspalten und dem Benutzer lesbarer anzeigen. das ist keine Frage der Abstimmung, sondern eine der Typographie, da kannst du gerne dagegen stimmen, es hilft aber nichts. Es ist einfach eine Tatsache. Und das Warten auf zukünftige tolle Lösungen ist auch kein Argument gegen Benutzerfreundlichkeit. Das ist wieder ein klassischer Fall, wo die Programmierfraktion gegen die Benutzerfreundlichkeit argumentiert - wofür werden Rechner eigentlich schneller und Speicher größer? Ich bin klar für bessere Lesbarkeit - gerne auch auf Kosten von etwas Performance. Gruß, Schusch___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trennzeichen bei Aufzählungen im Wert eines Tags (war: motorway und motorway_link um destination-tag ergänzen )
Leerzeichen zu entfernen ist technisch kein Problem, eine Anwendung sollte das sicherheitshalber schon koennen. Aber da die Leerzeichen keinerlei Vorteil bieten, laesst man sie besser gleich weg. äh, soll ich jetzt sagen: typisch Computer-Freak? Ich hatte es doch geschrieben: Lesbarkeit ... damit Benutzerfreundlichkeit DAS Argument schlechthin, wenn man etwas lesen muss. Gruß, Schusch___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trennzeichen bei Aufzählungen im Wert eines Tags (war: motorway und motorway_link um destination-tag ergänzen )
Hallo. Am Freitag 04 Juni 2010, 08:17:58 schrieb Schorschi: Viele, vor allem hardwarenahe, schnelle Programmiersprachen verarbeiten ein einzelnes Stoppzeichen wesentlich effizienter als einen String als Token. Neben der Effizienz steigt der Programmieraufwand um 100%, da man statt einem konkreten plötzlich zweierlei mögliche Token hat. den Käse übersehe ich jetzt mal Ich seh hier nichts gelbes mit Löchern drin. Stimme ich dagegen. Die Lesbarkeit mit Semikolon ist immer etwas eingeschränkt, da macht das auch nichts mehr aus. Ein zukünftiger, guter Editor kann das ja selbst aufspalten und dem Benutzer lesbarer anzeigen. das ist keine Frage der Abstimmung, Oha, keine Abstimmung? Keine Konsensfindung? Du diktierst? sondern eine der Typographie, da kannst du gerne dagegen stimmen, es hilft aber nichts. Es ist einfach eine Tatsache. Und das Warten auf zukünftige tolle Lösungen ist auch kein Argument gegen Benutzerfreundlichkeit. Nein, kein normal denkender Mensch würde die OSM-Tags im Rohdatenformat als Meisterstück der Typographie einstufen und das sollte es auch nicht werden. Wir sollten so arbeiten, dass man mit den Daten sauber umgehen kann, dass das Datenformat eindeutig und computerverarbeitbar wird bzw. bleibt. Wer typografische Ansprüche höher wertet als die Verarbeitung mit einem Rechner, der soll in Gottes Namen nicht an den Rohdaten rumpfuschen sondern mit geeigneten, abstrahierten Werkzeugen arbeiten. Das ist wieder ein klassischer Fall, wo die Programmierfraktion gegen die Benutzerfreundlichkeit argumentiert Ich sehe keinen messbaren Vorteil für die Benutzerfreundlichkeit. Ich lasse ja auch nicht am Anfang jedes Tags ein Leerzeichen nur weil das in meinem Editor schöner aussieht. Dir ist klar, dass wir hier nur von Tags reden, die mehrere Werte beim selben Key haben? Das kommt nicht alle Tage vor und das läuft dem normalen Mapper auch nicht jeden Tag übern Weg. - wofür werden Rechner eigentlich schneller und Speicher größer? Sicherlich nicht für deine obskuren Ansprüche. Ich bin klar für bessere Lesbarkeit - gerne auch auf Kosten von etwas Performance. Ich meine, sowas hätte ich schon aus deiner letzten Mail rausgelesen, ja. Gruß, Bernd -- Ich bevorzuge junge Männer. Sie wissen zwar nicht, was sie tun - aber sie tun es die ganze Nacht. - Madonna (am. Sängerin und Schauspielerin) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trennzeichen bei Aufzählungen im Wert eines Tags (war: motorway und motorway_link um destination-tag ergänzen)
Hallo, steffterra wrote: Keine Ahnung, vlt. ist auch das Komma mit Leerzeichen ungewöhnlich und man sollte auch beim ref eher Semikolon und kein Leerzeichen verwenden? Weiss da jemand mehr darüber, was bei anderen Tags üblich ist? Wenn es irgend geht, sollten mehrere Werte in einem Tag vermieden werden. Ich weiss, dass es nicht immer geht, aber eine Aufazehlung mit Trennzeichen ist immer die zweitbeste Loesung. Im Falle von ref wuerde ich z.B. Relationen benutzen und am Way selbst nur eine, oder sogar gar keine, der Strassenbezeichnungen setzen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trennzeichen bei Aufzählungen im Wert eines Tags (war: motorway und motorway_link um destination-tag ergänzen)
Am 04.06.2010 um 13:32 schrieb Frederik Ramm: Hallo, steffterra wrote: Keine Ahnung, vlt. ist auch das Komma mit Leerzeichen ungewöhnlich und man sollte auch beim ref eher Semikolon und kein Leerzeichen verwenden? Weiss da jemand mehr darüber, was bei anderen Tags üblich ist? Wenn es irgend geht, sollten mehrere Werte in einem Tag vermieden werden. Zustimmung. Ich weiss, dass es nicht immer geht, ja. Z.b. wenn ein way sich eine Auf- und eine Abfahrt im Gegenverkehr teilt und sich erst beim Anschluss jeweils aufteilt. - nur so als Beispiel. aber eine Aufazehlung mit Trennzeichen ist immer die zweitbeste Loesung. Im Falle von ref wuerde ich z.B. Relationen benutzen Also jede einzelne Auffahrt und jede Abfahrt als Relation erfassen? Was für Vorteile bietet das gegenüber dem kurzen, schnellen einfachen mapping von ref=A 7;A 3 und von destination=Würzburg;Frankfurt? und am Way selbst nur eine, oder sogar gar keine, der Strassenbezeichnungen setzen. O.k. man soll nicht für die Renderer und andere Software mappen. Aber derzeit wird imho zumindest in Mapnik die Darstellung der Autobahn-Nummer durch den ref-Tag erzeugt, oder? Wohl auch dem Vorteil nach, dass wenn man sich da alleine auf (evtl. kaputte) Relationen verlassen würde, das Rendering u.U. auch mal durchlöchtert wäre. Darf ich mal eine Grundsatzfrage stellen? Ich lese ja erst seit kurzem mit. aber ich bemerke immer wieder zwei Lager: die einen, die am liebsten _alles_ in Relationen packen würden und die Verfechter der Meinung, das kurze prägnante neue Zusatztags viele Vorteile bieten. Was sind denn die großen Vorteile von Relationen für _alles_? steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trennzeichen bei Aufzählungen im Wert eines Tags (war: motorway und motorway_link um destination-tag ergänzen)
Hallo, steffterra wrote: Also jede einzelne Auffahrt und jede Abfahrt als Relation erfassen? Ich habe die Auffahrt-Problematik nicht praesent; falls Du gerade vorschlaegst, ein ref=A3 an eine Auffahrt zu setzen, die auf die A3 fuehrt, so wuerde ich dem widersprechen - ref=A3 soll m.E. nur an Strassenstuecke, die Teil der Autobahn sind. Daher ist es auch ein leichtes, die alle in eine Relation A3 zu packen. Die Auffahrt braucht m.E. keine Relation. Das destination=A;B laesst sich auch nicht gut durch eine Relation ersetzen, aber in diesem Fall ist das ja eh weniger ein computerlesbares Tag sondern nur ein abgeschriebenes Verkehrsschild. Darf ich mal eine Grundsatzfrage stellen? Ich lese ja erst seit kurzem mit. aber ich bemerke immer wieder zwei Lager: die einen, die am liebsten _alles_ in Relationen packen würden und die Verfechter der Meinung, das kurze prägnante neue Zusatztags viele Vorteile bieten. Was sind denn die großen Vorteile von Relationen für _alles_? Relationen fuer alles ist Quatsch. Relationen sollten da benutzt werden, wo mehrere Objekte zusammengehoeren und/oder wo ein Tag alleine nicht ausreicht. Also z.B. wenn Du an ein Haus architect=Friedensreich Hundertwasser dranschreibst als Tag ist das voellig ok, eine Relation dafuer waere ueberfluessig (Leute machen das manchmal, weil sie auf einfache Weise alle Haeuser von Hundertwasser aus der Datenbank laden wollen, das geht mit einer Relation gut, aber ich halte das fuer einen Missbrauch). Sobald Du aber anfangen musst, mit einem Semikolon zu operieren, weil ein Stueck Strasse sowohl zum Wanderweg A als auch zum Wanderweg B gehoert, ist eine Relation fuer beide Wanderwege sinnvoll. Oftmals - aber nicht immer - funktioniert die folgende Faustregel: Mappe ich eine wesentliche Eigenschaft eines Objekts, kommt das in ein Tag. Mappe ich hingegen etwas, wo das Objekt nur eine Rolle spielt, dann ist eine Relation besser. Wenn die Stadtverwaltung sich heute entscheidet, dass der Stadtrundgang kuenftig durch die A-Strasse und nicht mehr durch die B-Strasse fuehren soll, dann aendert sich dadurch weder die A-Strasse noch die B-Strasse, sondern der Stadtrundgang - also sollte das auch nicht in ein Tag, sondern in eine Relation. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trennzeichen bei Aufzählungen im Wert eines Tags (war: motorway und motorway_link um destination-tag ergänzen)
Am 04.06.2010 um 20:42 schrieb Frederik Ramm: steffterra wrote: Also jede einzelne Auffahrt und jede Abfahrt als Relation erfassen? Ich habe die Auffahrt-Problematik nicht praesent; falls Du gerade vorschlaegst, ein ref=A3 an eine Auffahrt zu setzen, die auf die A3 fuehrt, so wuerde ich dem widersprechen - ref=A3 soll m.E. nur an Strassenstuecke, die Teil der Autobahn sind. Dem muss ich nun widersprechen - und nicht nur weil genau das etablierte Praxis ist ;-) Laut einem sehr alten Wikieintrag für motorway_link gilt folgendes (und ist imho auch weit verbreitet etabliert und steht wohl auch deshalb im wiki): Die Verbindungen zwischen zwei Autobahnen sollten gewöhnlich mit dem ref=* derjenigen Autobahn markiert werden, zu der sie führen (Ich habe diesen Satz nun um den destination-key erweitert) Dem entsprechend sagt mir die Logik, dass ich nicht nur die Auffahrt mit dem ref der Autobahn mappe zu der sie führt, sondern ebenso die Abfahrt mit dem ref der Bundesstraße (oder was auch immer folgt) zu dem sie führt, mappe. Du begeründest es mit: ref=A3 soll m.E. nur an Strassenstuecke, die Teil der Autobahn sind. Der Kausalität nach gehört imho die Auffahrt zur Autobahn und die Abfahrt zur Bundesstraße zu der sie führt. Demensprechend ref-Autobahn an Auffahrt ref-Bundesstraße an die Abfahrt. Diese Logik ist imho sehr klar und kann so auch an komplizierten AB-Kreuzen/Anschlussstellen durch reine Logik konsequent umgesetzt werden. Diese Art die motoway_links, trunk_links und secondary_links (etc.) zu mappen bringt absolute _direkt nutzbare_ Vorteile für Routingsoftware gegenüber dem Nichtmappen, ebenso wie der destination-key. Daher ist es auch ein leichtes, die alle in eine Relation A3 zu packen. Die Auffahrt braucht m.E. keine Relation. Das destination=A;B laesst sich auch nicht gut durch eine Relation ersetzen, Dann sind wir ja einer Meinung :-) aber in diesem Fall ist das ja eh weniger ein computerlesbares Tag sondern nur ein abgeschriebenes Verkehrsschild. Es geht _nicht_ darum, Schilder zu taggen. Dafür gibt es die Schilder-Relationen. Das Ablesen des Schildes ist nur als Informationsquelle für den destination-key gedacht. Dieser wiederum kann leicht von Software wie z.b. routern ausgelesen und direkt für sehr natürliche Anweisungen genutzt werden, weil der Fahrer die gleiche Anweisung dann auf dem Schild zu lesen bekommt - Diese gleiche Orientierungs-Basis erleichtert jede Navigation. (Negativ-Beispiel: ''Viele Navis, nennen die Namen der Staats- und Stadt-Straßen, wie z.B. St 2245, wenn sie eine Routenanweisung geben. Das ist Quatsch, weil das nicht der Orientierung dienlich ist, da das dass auf keinem Straßenschild steht. Hilft dem Fahrer also nicht wirklich. ) Der ref- und der destination-key jedoch schon, weil er eben vom Auffahrtsschild abgelesen wurde und sich auch auf anderen Hinweisschildern für die Autobahn wieder findet. Das gleiche gilt für Abfahrten: Auf der AB findet man dort den Hinweis auf die Bundesstraße und den Zielort zu dem sie führt. Perfekt im destination und ref-Tag der Abfahrt untergebracht! (siehe obige Argumentation!) Darf ich mal eine Grundsatzfrage stellen? Ich lese ja erst seit kurzem mit. aber ich bemerke immer wieder zwei Lager: die einen, die am liebsten _alles_ in Relationen packen würden und die Verfechter der Meinung, das kurze prägnante neue Zusatztags viele Vorteile bieten. Was sind denn die großen Vorteile von Relationen für _alles_? Relationen fuer alles ist Quatsch. Relationen sollten da benutzt werden, wo mehrere Objekte zusammengehoeren und/oder wo ein Tag alleine nicht ausreicht. Also z.B. wenn Du an ein Haus architect=Friedensreich Hundertwasser dranschreibst als Tag ist das voellig ok, eine Relation dafuer waere ueberfluessig (Leute machen das manchmal, weil sie auf einfache Weise alle Haeuser von Hundertwasser aus der Datenbank laden wollen, das geht mit einer Relation gut, aber ich halte das fuer einen Missbrauch). Wenn man nun alle motorway_links mit Relationen zusammen fassen würde - was würde das für einen Vorteil bringen? Welchen direkten Nutzen habe ich derzeit davon? Sobald Du aber anfangen musst, mit einem Semikolon zu operieren, weil ein Stueck Strasse sowohl zum Wanderweg A als auch zum Wanderweg B gehoert, ist eine Relation fuer beide Wanderwege sinnvoll. Für einen Wanderweg, Radroute, Mottarroute, etc. sicher. Aber doch nciht für die kurzen Wege einer Autobahnauffahrt die maximal (im gemeinsamen Teil, weil nicht baulich getrennt) mehrere 100m beträgt... Oftmals - aber nicht immer - funktioniert die folgende Faustregel: Mappe ich eine wesentliche Eigenschaft eines Objekts, kommt das in ein Tag. Mappe ich hingegen etwas, wo das Objekt nur eine Rolle spielt, dann ist eine Relation besser. Wenn die Stadtverwaltung sich heute entscheidet, dass der Stadtrundgang kuenftig durch die A-Strasse und nicht mehr durch die B-Strasse fuehren soll, dann aendert sich
Re: [Talk-de] Trennzeichen bei Aufzählungen im Wert eines Tags (war: motorway und motorway_link um destination-tag ergänzen)
Hallo, steffterra wrote: Der Kausalität nach gehört imho die Auffahrt zur Autobahn und die Abfahrt zur Bundesstraße zu der sie führt. Demensprechend ref-Autobahn an Auffahrt ref-Bundesstraße an die Abfahrt. Diese Logik ist imho sehr klar und kann so auch an komplizierten AB-Kreuzen/Anschlussstellen durch reine Logik konsequent umgesetzt werden. Das mag ja sein, dass diese Logik sehr klar und durch reine Logik konsequent umsetzbar ist, aber genauso klar waere es, wenn ich sagen wuerde, dass Auf- und Abfahrten grundsaetzlich gar kein ref-Tag haben sollten; das waere sogar ohne Logik konsequent umsetzbar. Ich bin weiterhin der Ansicht, dass mit ref=A5 nur das zu taggen ist, was tatsaechlich die A5 ist, und nicht irgendwas, was irgendwann irgendwo auf die A5 drauf fuehrt. Taggst Du dann auch die Service-Wege einer Raststaette mit A5? Wo steht das eigentlich im Wiki? Hab unter Key:ref nichts gefunden. Ich will mich da nicht weiter reinhaengen, weil ich kein Autobahnexperte bin. Ich koennte mir vorstellen, dass es Leute gibt, die davon ausgehen, dass alles, was mit A... getaggt ist, in Verwaltung des Bundes ist und alles, was mit L... getaggt ist, in Verwaltung des Landes ist; was Du mit Deiner Logik produzierst, wenn eine Autobahnabfahrt auf eine Landesstrasse fuehrt, ist eine Auf-/Abfahrt, die halb in Bundes- und halb in Landesverwaltung ist. Aber vielleicht entspricht das ja sogar der Realitaet, wie gesagt, ich kenne mich mit Autobahnen nicht so aus. Es geht _nicht_ darum, Schilder zu taggen. Dafür gibt es die Schilder-Relationen. Das Ablesen des Schildes ist nur als Informationsquelle für den destination-key gedacht. Dieser wiederum kann leicht von Software wie z.b. routern ausgelesen und direkt für sehr natürliche Anweisungen genutzt werden, weil der Fahrer die gleiche Anweisung dann auf dem Schild zu lesen bekommt - Also geht es doch darum, ein Schild zu taggen? Denn wenn das Schild nicht da waere, oder wenn es anders beschriftet waere, waere ja auch der Inhalt des destination-Tags nicht sinnvoll. Wenn man nun alle motorway_links mit Relationen zusammen fassen würde - was würde das für einen Vorteil bringen? Welchen direkten Nutzen habe ich derzeit davon? Ich wuerde nicht empfehlen, *alle* motorway_links mit Relationen zusammenzufassen. Ich sehe darin keinen besonderen Sinn. Was man hoechstens machen koennte, waere, alle Auf- und Abfahrten, die gemeinsam ein Kreuz oder eine Anschlussstelle ausmachen, in eine gemeinsame Relation zu tun. Da koennte man dann sowas wie einen Mautpunkt speichern oder eben den Namen der AS (den man sonst ja bei einem AK an 4 verschiedenen Abfahrten taggen wuerde). Ich wuerde Auffahrten gar nicht mit ref taggen. Wenn Du es doch machen willst und wenn eine Auffahrt auf eine Autobahn fuehrt, die zwei verschiedene ref-Tags hat, wuerde ich nur den wichtigeren der beiden ref-Tags taggen, denn der hypothetische Router wird eh nicht sagen: Fahren Sie nun auf die A5 beziehungsweise E13 bloss weil da ref=a%;E13 steht. Grundsaetzlich ist die Frage welchen direkten Nutzen habe ich derzeit davon nicht immer eine, die OSM zu verbessern hilft. Man kann von Glueck sagen, dass die Leute, die vor 5 Jahren mit OSM angefangen haben, nicht vorrangig diese Frage gestellt haben ;-) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trennzeichen bei Aufzählungen im Wert eines Tags (war: motorway und motorway_link um destination-tag ergänzen )
Hallo. Am Freitag 04 Juni 2010, 06:28:32 schrieb Schorschi: Der Einsatz des Semikolons für diese Zwecke ist richtig. Aber ich habe keine Ahnung, wer auf die Idee kommt, dass das Semikolon ohne Leerzeichen richtig sein soll: Alle, bei denen ich bisher mit so etwas zu tun hatte. - vom Programmieraufwand her ist es ganz einfach, dass Leerzeichen nötigenfalls zu übergehen Nicht immer. Alle Leerzeichen aus name/ref zu entfernen ist Käse. Man muss also statt aufspalten am Semikolon plötzlich aufspalten am Semikolon ODER an Semikolon plus Leerzeichen. Viele, vor allem hardwarenahe, schnelle Programmiersprachen verarbeiten ein einzelnes Stoppzeichen wesentlich effizienter als einen String als Token. Neben der Effizienz steigt der Programmieraufwand um 100%, da man statt einem konkreten plötzlich zweierlei mögliche Token hat. - der zusätzliche Platzbedarf in der Datenbank ist vermutlich nicht gewichtig Stimmt. - mit Leerzeichen wird der Inhalt lesbarer und deshalb benutzerfreundlicher Stimme ich dagegen. Die Lesbarkeit mit Semikolon ist immer etwas eingeschränkt, da macht das auch nichts mehr aus. Ein zukünftiger, guter Editor kann das ja selbst aufspalten und dem Benutzer lesbarer anzeigen. das einzige Argument gegen ein Leerzeichen ist hier, das jemand nicht weiß, wie man es beim Programmieren übergeht - oder weil jemand zu faul ist. Nein, weil eine simple explode-Funktion in vielen Programmiersrachen nur mit Einzelzeichen so richtig effizient ist, weil man *EIN* und nicht zwei verschiedene Trennzeichen haben will und weil es schlicht und ergreifend eigentlich überall so gemacht wird. Auch hier wieder der Verweis auf das Beispiel CSV-Dateien. Klar wäre es möglich, Leerzeichen links und rechts von OSM-Werten grundsätzlich und nach der Aufspaltung zu strippen. Das könnte auch dieses Leerzeichen dann beiläufig entfernen. Aber Leerzeichen vor oder hinter Werten werden von jedem mir bekannten einschlägigen OSM-Checker-Tool als Fehler markiert und ich sehe nicht ein, warum das hier plötzlich anders sein sollte. Bitte das Leerzeichen auf jeden Fall lassen! Bitte nicht. Gruß, Bernd -- Auf den Alkohol - die Ursache und die Lösung aller Probleme! - Homer Simpson signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trennzeichen bei Aufzählungen im Wert eines Tags (war: motorway und motorway_link um destination-tag ergänzen )
On Friday 04 June 2010 07:43:02 Bernd Wurst wrote: Klar wäre es möglich, Leerzeichen links und rechts von OSM-Werten grundsätzlich und nach der Aufspaltung zu strippen. Das könnte auch dieses Leerzeichen dann beiläufig entfernen. Aber Leerzeichen vor oder hinter Werten werden von jedem mir bekannten einschlägigen OSM-Checker-Tool als Fehler markiert und ich sehe nicht ein, warum das hier plötzlich anders sein sollte. +1 Leerzeichen zu entfernen ist technisch kein Problem, eine Anwendung sollte das sicherheitshalber schon koennen. Aber da die Leerzeichen keinerlei Vorteil bieten, laesst man sie besser gleich weg. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
