Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
Am 31. August 2008 12:54 schrieb Garry [EMAIL PROTECTED]: Guenther Meyer schrieb: sonsten wird man ja wahnsinnig beim parsen... Das setzt aber voraus dass die Daten richtig eingetragen wird. Die Angabe 7,5t - Anlieger frei kann jeder Mapper richtig eintragen und von jedem anderen leicht überprüft werden. Einen 10Zeiler zu überprüfen der sämtliche Interpretaionsmöglichkeiten wiedergibt manuell auszufüllen ist extrem fehlernanfällig und kaum einer wird alle Angaben überprüfen. der deutsche schreibt anlieger frei, der englaender access only, der oesterreicher Nur für Anrainer, andere Länder was anderes. viel spass beim parsen! Auch ein Ausländer der in Deutschland mapped kann den deutschen Text abtippen - umgekehrt der deutsche im Ausland.Unter Umständen hat so eine übersetze Zusatztafel eine andere Bedeutung wie im eigenen Land, insbesondere die Rechtssprechung kann sich da deutlich Unterscheiden. Garry ja, die Rechtssprechung wird sich definitiv von Land zu Land unterscheiden, sowohl was die Verkehrsschilder als auch andere Elemente wie z.B. die Benutzungspflicht von Radwegen etc. angeht (z.B. auch Hoechstgeschwindigkeiten, Linksverkehr in manchen Laendern, ...). Das sollte aber fuer OSM insofern egal sein, als dass die Situation von den Mappern richtig abgebildet wird, und sich um die Konsequenzen dann der Konsument kuemmern muss, d.h. z.B.: access=destination wurde in den Mapfeatures gem. dem deutschen Anlieger frei definiert. Wenn jetzt in einem anderen Land irgendwo die Bedeutung des dortigen Anlieger Frei nicht der in den Features entspricht, dann muesste man dort eben zusaetzlich ein neues Feature mit anderem Tag einfuehren, selbst wenn die Uebersetzung des dortigen Schildes Anlieger frei bedeuten wuerde. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
Guenther Meyer wrote: Stünde dort jedoch: - rundes weißes Schild mit $MERKMAL und rotem Rand - Anlieger frei ... dann dürften nur Fahrzeuge mit $MERKMAL dort nicht durch, ausgenommen, es handelt sich um Anlieger. Beliebte Kandidaten für solche spezifischen Verbote sind Busse, LKW und Motorräder. ist vom prinzip dasselbe. aber wo liegt da jetzt das problem? es gibt eine zufahrtsbeschraenkung, die von dem access only aufgehoben wird. Man sollte ein Taggingschema haben, dass sowohl die Verknüpfung von Einschränkungen mit und als auch die mit oder erlaubt und daher z.B. auch die folgenden beiden, real vorkommenden Situationen adäquat wiedergibt: 1. Verbot für Fahrzeuge über x Tonnen, aber Anlieger frei. 2. Verbot für alle Fahrzeuge, aber Anlieger bis x Tonnen frei. Wer ein neues Schema vorschlägt, sollte m.E. zeigen, wie so etwas darzustellen ist. Mit der Kombination von access=destination (oder access only) und maxweight=... sind die beiden Fälle nicht zu unterscheiden. Ein guter Vorschlag sollte dann am besten noch das richtungsabhängige Taggen erlauben, weil es in der Realität Straßen gibt, bei denen die Gegenrichtung anderen Beschränkungen unterliegt. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
Hatto von Hatzfeld schrieb: Guenther Meyer wrote: Stünde dort jedoch: - rundes weißes Schild mit $MERKMAL und rotem Rand - Anlieger frei ... dann dürften nur Fahrzeuge mit $MERKMAL dort nicht durch, ausgenommen, es handelt sich um Anlieger. Beliebte Kandidaten für solche spezifischen Verbote sind Busse, LKW und Motorräder. ist vom prinzip dasselbe. aber wo liegt da jetzt das problem? es gibt eine zufahrtsbeschraenkung, die von dem access only aufgehoben wird. Man sollte ein Taggingschema haben, dass sowohl die Verknüpfung von Einschränkungen mit und als auch die mit oder erlaubt und daher z.B. auch die folgenden beiden, real vorkommenden Situationen adäquat wiedergibt: 1. Verbot für Fahrzeuge über x Tonnen, aber Anlieger frei. 2. Verbot für alle Fahrzeuge, aber Anlieger bis x Tonnen frei. Wer ein neues Schema vorschlägt, sollte m.E. zeigen, wie so etwas darzustellen ist. Mit der Kombination von access=destination (oder access only) und maxweight=... sind die beiden Fälle nicht zu unterscheiden. Vielleicht sollte man einfach nur den genauen Wortlaut eines Schildes eintragen - dass kann dann jeder eintragen und überprüfen. Die Auswertung überlässt man dann einem Interpreter in den man den nötigen Gehirnschmalz steckt um anwendungsspezifischen Kartenmaterial zu erstellen. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
Am Samstag 30 August 2008 schrieb Garry: Vielleicht sollte man einfach nur den genauen Wortlaut eines Schildes eintragen - dass kann dann jeder eintragen und überprüfen. Die Auswertung überlässt man dann einem Interpreter in den man den nötigen Gehirnschmalz steckt um anwendungsspezifischen Kartenmaterial zu erstellen. da die daten primaer von programmen verarbeitet werden, ist ein tagging, das zumindest irgendein schema ergibt, absolut vorzuziehen. ansonsten wird man ja wahnsinnig beim parsen... 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] RFC: Tags für Tags - warum so komplizi ert?
Nur eine kleine Ergänzung: Sven Rautenberg wrote: Sollte tatsächlich solch eine Kombination von Schildern auftreten, wird das sicherlich so aussehen: max. 30 km/h Lücke max. 9,5t Zusatzschild: Anlieger frei. Damit dürfte der Sinnzusammenhang einigermaßen ausgedrückt sein, allerdings kann ich mir gut vorstellen, dass manche Verkehrsämter aufgrund der Uneindeutigkeitsmöglichkeit darauf verzichten, diese beiden Schilder an einem Pfosten zu kombinieren. Zusatzschilder beziehen sich immer nur auf das unmittelbar darüber angebrachte Schild. Das musste sich ein Parksünder höchstrichterlich sagen lassen: http://www.bundesverwaltungsgericht.de/media/archive/1110.pdf Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
Am Donnerstag 28 August 2008 schrieb Martin Koppenhoefer: Am 27. August 2008 22:23 schrieb Bodo Meissner [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Koppenhoefer wrote on 26.08.2008 18:33: Am 26. August 2008 07:31 schrieb Marcus Wolschon [EMAIL PROTECTED]: Hört sich nett an, ist aber uneindeutig. Was gilt in deinem Beispiel bei: limit.access[weight:7.5] = yes limit.access[height:3.5] = no für ein Fahrzeug mit 7.5t Gewicht und einer Höhe von 4m? was denkst Du? Wenn eine Hoehenbegrenzung vorgegeben ist, hat das in der Regel seinen Grund. Wenn der LKW im Beispiel nun zu hoch ist fuer die entsprechende Durchfahrt, meinst Du, er sollte trotzdem durchfahren weil er ordentlich schwer ist? Klar. Für einen Menschen ist das alles relativ leicht zu entscheiden, weil man über den Sinn oder Zweck der Tags nachdenken kann. Das gilt auch, wenn man eine bisher unbekannten Kombinationen findet. Es ist aber schwierig, einen Automaten so zu programmieren, daß er für alle nicht eindeutigen Fälle die richtige Interpretationslogik hat. Das bedeutet, man muß alle Kombinationen durchdenken und entsprechende Regeln definieren, möglichst auch solche zum Erkennen fehlerhafter Tag-Kombinationen. Wenn man vollständige Kombinationen fordert, wird es für den Automaten einfacher. Wenn es genau eine passende Kombination gibt, wird die gewählt; gibt es keine oder mehrere, wäre das ein Tagging-Fehler. Bodo so schwierig ist das nun auch wieder nicht: wenn man eine Höhenbegrenzung vorgegeben hat, darf nur der durchfahren, der kleiner oder gleich ist. wenn man eine Gewichtsbegrenzung vorgegeben hat, darf nur der durchfahren, der weniger oder gleich viel wiegt. Sobald eine Forderung nicht mehr erfüllt ist, kann man abbrechen. Für einen Router könnte man schonmal vorfiltern für verschiedene Fahrzeugtypen. eben. wenn mehrere einschraenkungen in dieselbe richtung schiessen, nimmt einfach die restriktivste aktuell gueltige. bei verschiedenen einschraenkungen wird solange weitergelesen, bis eine die durchfahrt verbietet, und dann kann man eh abbrechen. 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] RFC: Tags für Tags - warum so komplizi ert?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Koppenhoefer wrote on 26.08.2008 18:33: Am 26. August 2008 07:31 schrieb Marcus Wolschon [EMAIL PROTECTED]: Hört sich nett an, ist aber uneindeutig. Was gilt in deinem Beispiel bei: limit.access[weight:7.5] = yes limit.access[height:3.5] = no für ein Fahrzeug mit 7.5t Gewicht und einer Höhe von 4m? was denkst Du? Wenn eine Hoehenbegrenzung vorgegeben ist, hat das in der Regel seinen Grund. Wenn der LKW im Beispiel nun zu hoch ist fuer die entsprechende Durchfahrt, meinst Du, er sollte trotzdem durchfahren weil er ordentlich schwer ist? Klar. Für einen Menschen ist das alles relativ leicht zu entscheiden, weil man über den Sinn oder Zweck der Tags nachdenken kann. Das gilt auch, wenn man eine bisher unbekannten Kombinationen findet. Es ist aber schwierig, einen Automaten so zu programmieren, daß er für alle nicht eindeutigen Fälle die richtige Interpretationslogik hat. Das bedeutet, man muß alle Kombinationen durchdenken und entsprechende Regeln definieren, möglichst auch solche zum Erkennen fehlerhafter Tag-Kombinationen. Wenn man vollständige Kombinationen fordert, wird es für den Automaten einfacher. Wenn es genau eine passende Kombination gibt, wird die gewählt; gibt es keine oder mehrere, wäre das ein Tagging-Fehler. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAki1t6oACgkQnMz9fgzDSqd9FACdHGm8lJoREXFGRyKJZuMTTSc7 03QAn1OuNmXHwC9JPhAWlsRxguSbgyVH =CL7K -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
Am 27. August 2008 22:23 schrieb Bodo Meissner [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Koppenhoefer wrote on 26.08.2008 18:33: Am 26. August 2008 07:31 schrieb Marcus Wolschon [EMAIL PROTECTED]: Hört sich nett an, ist aber uneindeutig. Was gilt in deinem Beispiel bei: limit.access[weight:7.5] = yes limit.access[height:3.5] = no für ein Fahrzeug mit 7.5t Gewicht und einer Höhe von 4m? was denkst Du? Wenn eine Hoehenbegrenzung vorgegeben ist, hat das in der Regel seinen Grund. Wenn der LKW im Beispiel nun zu hoch ist fuer die entsprechende Durchfahrt, meinst Du, er sollte trotzdem durchfahren weil er ordentlich schwer ist? Klar. Für einen Menschen ist das alles relativ leicht zu entscheiden, weil man über den Sinn oder Zweck der Tags nachdenken kann. Das gilt auch, wenn man eine bisher unbekannten Kombinationen findet. Es ist aber schwierig, einen Automaten so zu programmieren, daß er für alle nicht eindeutigen Fälle die richtige Interpretationslogik hat. Das bedeutet, man muß alle Kombinationen durchdenken und entsprechende Regeln definieren, möglichst auch solche zum Erkennen fehlerhafter Tag-Kombinationen. Wenn man vollständige Kombinationen fordert, wird es für den Automaten einfacher. Wenn es genau eine passende Kombination gibt, wird die gewählt; gibt es keine oder mehrere, wäre das ein Tagging-Fehler. Bodo so schwierig ist das nun auch wieder nicht: wenn man eine Höhenbegrenzung vorgegeben hat, darf nur der durchfahren, der kleiner oder gleich ist. wenn man eine Gewichtsbegrenzung vorgegeben hat, darf nur der durchfahren, der weniger oder gleich viel wiegt. Sobald eine Forderung nicht mehr erfüllt ist, kann man abbrechen. Für einen Router könnte man schonmal vorfiltern für verschiedene Fahrzeugtypen. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marcus Wolschon wrote on 26.08.2008 07:31: Hört sich nett an, ist aber uneindeutig. Was gilt in deinem Beispiel bei: limit.access[weight:7.5] = yes limit.access[height:3.5] = no für ein Fahrzeug mit 7.5t Gewicht und einer Höhe von 4m? Was soll denn das erste Limit in der Realität bedeuten? Durchfahrt erlaubt nur für Fahrzeuge 7,5t? Oder Fahrzeuge 7,5t von einem allgemeineren (hier nicht dargestellten) Limit ausgenommen? Wenn es keine generelle Einschränkung gibt, soll diese Ausnahme weggelassen werden. Abgesehen davon finde ich limit.access[weight7.5]=* besser, weil man durch verschiedene Vergleiche mehr Möglichkeiten hat. Das Beispiel ist vielleicht nicht ganz praxisrelevant, aber dadurch ist mir aufgefallen, daß es bei einer Menge von solchen Tags nicht unbedingt zu entscheiden ist, welche Variante gewählt werden muß. Es gibt keine definierte Abarbeitungsreihenfolge, deshalb kann man nicht festlegen, daß zuerst Einschränkungen kommen und dann Ausnahmen oder zuerst speziellere Kombinationen und dann allgemeinere. Um das eindeutig zu machen, müßte man immer alle möglichen Kombinationen notieren. Beispiel: limit.access[height3.5]=no limit.access[weight7.5][height=3.5]=destination limit.access[weight=7.5][height=3.5]=yes limit.speed[weight12]=60 limit.speed[weight3.5][weight=12]=80 limit.speed[weight=3.5]=default Die Anwendung könnte dann aus jeder Gruppe die erste gefundene Variante wählen die paßt. Als Kontrolle könnte man noch prüfen, ob es eine weitere passende Variante gibt, und in diesem Fall einen Tagging-Fehler melden. Eine Prüfung auf Konflikte durch den Editor stelle ich mir schwierig vor, da alle Kombinationen gefunden werden müssen. Auch ein Renderer hätte das gleiche Problem. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkizp7QACgkQnMz9fgzDSqdkFwCdHGWZY+fKZb/rCiL8v4XcdROI 8DoAnj4e6Gs+q/gBNA+VJsikx2khAN+Z =Z3Ho -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
Hallo. Am Dienstag, 26. August 2008 schrieb Bodo Meissner: Marcus Wolschon wrote on 26.08.2008 07:31: Hört sich nett an, ist aber uneindeutig. Was gilt in deinem Beispiel bei: limit.access[weight:7.5] = yes limit.access[height:3.5] = no für ein Fahrzeug mit 7.5t Gewicht und einer Höhe von 4m? Bei Verkehrsschildern ist mir noch nie was begegnet, wo derartige UND-Kombinationen gelten. Es sind eigentlich immer ODER-Kombinationen, da jedes Verbots-Schild für sich alleine gilt. Das Beispiel ist vielleicht nicht ganz praxisrelevant, aber dadurch ist mir aufgefallen, daß es bei einer Menge von solchen Tags nicht unbedingt zu entscheiden ist, welche Variante gewählt werden muß. Es gibt keine definierte Abarbeitungsreihenfolge, deshalb kann man nicht festlegen, daß zuerst Einschränkungen kommen und dann Ausnahmen oder zuerst speziellere Kombinationen und dann allgemeinere. Ich hätte jetzt intuitiv gesagt, spezifischere Angabe überschreibt allgemeine Angabe. Machen wir bisher ja auch so, z.B. access=permissive bicycle=no hgv=no Um das eindeutig zu machen, müßte man immer alle möglichen Kombinationen notieren. Hm, nein, das ist unnötiges Aufblasen des Datenbestand. Einfach spezifisch überschreibt allgemein als Konvention festlegen, dann ist es eindeutig. Gruß, Bernd -- Wer gegen ein Minimum Aluminium immun ist, besitzt Aluminiumminimumimmunität 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] RFC: Tags für Tags - warum so komplizi ert?
Am Dienstag 26 August 2008 schrieb Marcus Wolschon: Am 25.08.08 schrieb Guenther Meyer [EMAIL PROTECTED]: eine 'oder' verknüpfung sollte nicht noetig sein, das laesst sich als separates tag schreiben, ein beispiel: limit.access[weight:7.5] = no limit.access[height:3.5] = no das wuerde bedeuten, dass fahrzeuge die schwerer als 7,5t oder hoeher als 3,5m sind, nicht reinfahren duerfen. Hört sich nett an, ist aber uneindeutig. Was gilt in deinem Beispiel bei: limit.access[weight:7.5] = yes limit.access[height:3.5] = no für ein Fahrzeug mit 7.5t Gewicht und einer Höhe von 4m? es darf nicht rein, wegen der zweiten regel. sobald ein verbot erfuellt wird gilt dieses, wobei spezifizierte tags vorrang vor allgemeinen haben. limit.access[weight:7.5] = yes das wuerde bedeuten, dass fahrzeuge ab 7,5t zufahrt haben. dieses tag alleine (das gewicht betreffend), macht aber keinen sinn. denn ohne weitere tags (wie z.B. limit.access = no), ist das ueberfluessig. 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] RFC: Tags für Tags - warum so komplizi ert?
Am Dienstag 26 August 2008 schrieb Bodo Meissner: Marcus Wolschon wrote on 26.08.2008 07:31: Hört sich nett an, ist aber uneindeutig. Was gilt in deinem Beispiel bei: limit.access[weight:7.5] = yes limit.access[height:3.5] = no für ein Fahrzeug mit 7.5t Gewicht und einer Höhe von 4m? Was soll denn das erste Limit in der Realität bedeuten? Durchfahrt erlaubt nur für Fahrzeuge 7,5t? Oder Fahrzeuge 7,5t von einem allgemeineren (hier nicht dargestellten) Limit ausgenommen? Wenn es keine generelle Einschränkung gibt, soll diese Ausnahme weggelassen werden. richtig. Abgesehen davon finde ich limit.access[weight7.5]=* besser, weil man durch verschiedene Vergleiche mehr Möglichkeiten hat. bei verboten wegen gewicht, breite, hoehe, geschwindigkeit usw. geht es praktisch immer um groessergleich. deshalb habe ich fuer diesen standardfall das zeichen weggelassen, was das ganze einfacher, schneller eingebbar und lesbarer macht. sollte mal was anderes vorkommen, kann man's immer noch hinschreiben. Das Beispiel ist vielleicht nicht ganz praxisrelevant, aber dadurch ist mir aufgefallen, daß es bei einer Menge von solchen Tags nicht unbedingt zu entscheiden ist, welche Variante gewählt werden muß. Es gibt keine definierte Abarbeitungsreihenfolge, deshalb kann man nicht festlegen, daß zuerst Einschränkungen kommen und dann Ausnahmen oder zuerst speziellere Kombinationen und dann allgemeinere. Um das eindeutig zu machen, müßte man immer alle möglichen Kombinationen notieren. Beispiel: limit.access[height3.5]=no limit.access[weight7.5][height=3.5]=destination limit.access[weight=7.5][height=3.5]=yes limit.speed[weight12]=60 limit.speed[weight3.5][weight=12]=80 limit.speed[weight=3.5]=default viel zu kompliziert, und vor allem nicht realistisch. den fall moechte ich sehen, der solche gewichtsvorgaben hat... ausserdem, was bedeutet default? die anwendung waehlt das je nach gegebenem fahrzeug passendste und engste tag: also bei gegebenem 12-tonner und tags mit [weight:3.5] und [weight:7.5] wird das letztere verwendet. 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] RFC: Tags für Tags - warum so komplizi ert?
Am 26. August 2008 07:31 schrieb Marcus Wolschon [EMAIL PROTECTED]: Am 25.08.08 schrieb Guenther Meyer [EMAIL PROTECTED]: eine 'oder' verknüpfung sollte nicht noetig sein, das laesst sich als separates tag schreiben, ein beispiel: limit.access[weight:7.5] = no limit.access[height:3.5] = no das wuerde bedeuten, dass fahrzeuge die schwerer als 7,5t oder hoeher als 3,5m sind, nicht reinfahren duerfen. Hört sich nett an, ist aber uneindeutig. Was gilt in deinem Beispiel bei: limit.access[weight:7.5] = yes limit.access[height:3.5] = no für ein Fahrzeug mit 7.5t Gewicht und einer Höhe von 4m? Marcus was denkst Du? Wenn eine Hoehenbegrenzung vorgegeben ist, hat das in der Regel seinen Grund. Wenn der LKW im Beispiel nun zu hoch ist fuer die entsprechende Durchfahrt, meinst Du, er sollte trotzdem durchfahren weil er ordentlich schwer ist? Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
Hallo. Am Montag, 25. August 2008 schrieb Marcus Wolschon: Mein Vorschlag besteht im Kern darin, dass man im XML-Code nicht nur way ... tag k=foo v=bar / /way setzen kann sondern z.B. way ... tag k=foo v=bar tag k=bla v=blubb/ /tag /way Warum sollte das nicht mit der aktuellen Struktur als bla[bar]=blubb oder bla:bar=blubb funktionieren? Wir machen das bei den name name:en name:en_UK ja auch nicht anders und müssen dazu die Struktur nicht ändern. Ja, da sind die Werte wie en, de, ... auch aus einer halbwegs festen Menge an völlig unkritischen Zeichen. Ich bleibe bei meinem Beispiel: * Autos: Höchstgeschwindigkeit 80 km/h * LKW ab 7,5 Tonnen: Höchstgeschwindigkeit 60 km/h * LKW ab 12 Tonnen: Nur Anlieger frei Das ist übrigens ein reales Beispiel. Wie taggt man das? Bei Verwendung des bisherigen Schemas, müsste das Gewicht sowie auch die angabe, dass es ein Gewicht ist, in den Schlüssel. Das ist IMHO sehr, sehr, hässlich bzw. richtig umständlich. Mir fällt sogar grade nicht mal was vernünftiges ein, wie man das abbilden kann. Wir haben bereits die Konstrukte: Schlüssel=Wert Schlüssel:Spezialisierung=Wert Schlüssel=Wert1;Wert2;Wert2 sowie Schlüssel1=Wert1 Schlüssel1_2=Wert1_1 (z.B. highway=motorway+ref=A5) Richtig. Mit keinem der genannten kann man das obige abbilden, da man nur den Key oder nur wen Wert vererbt. Text-basierende Sprachen sind so ein mächtiges Konstrukt... Ja, aber alles was über simples tokenizing bzw. splitting hinausgeht ist ziemlich fehleranfällig (vor allem für den, der das bearbeiten soll) und aufwändig (== langsam). Gruß, Bernd -- Alles Schöne im Leben hat einen Haken: Es ist unmoralisch, illegal oder es macht dick. 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] RFC: Tags für Tags - warum so komplizi ert?
Ja, da sind die Werte wie en, de, ... auch aus einer halbwegs festen Menge an völlig unkritischen Zeichen. Sowohl Schlüssel als auch Werte dürfen alle UTF8-Zeichen enthalten. Wenn jemand chineschische Sachen mit Tag-Namen in Mandarin mappen will, gerne. Müssen die Tools eben mit klarkommen wenn sie behaupten diesem Protokoll zu entsprechen. Ich bleibe bei meinem Beispiel: * Autos: Höchstgeschwindigkeit 80 km/h * LKW ab 7,5 Tonnen: Höchstgeschwindigkeit 60 km/h * LKW ab 12 Tonnen: Nur Anlieger frei Das ist übrigens ein reales Beispiel. Wie taggt man das? maxspeed=80 maxspeed(weight=7.5t)=60 access(weight=12t)=access only Bei mehreren Bedingungen halt sowas wie: maxspeed(weight=7.5t)(Mondfeuchte=grün)=60 * versteht ein Mensch, * ist trivial zu parsen, * ist trivial zu filtern (where key ='access' or key like 'access(%)') * kommt ohne Änderung unseres Datenbankschemas und damit Änderung aller geschriebenen Werkzeuge aus. Ja, aber alles was über simples tokenizing bzw. splitting hinausgeht ist ziemlich fehleranfällig (vor allem für den, der das bearbeiten soll) und aufwändig (== langsam). Unser kritischer Punkt was langsam angeht ist die Datenbank. Diese muss skalieren und darf durch eine Änderung nicht langsamer werden. Die Anwendungen bearbeiten nur eine Hand voll Wege. Das ist vergleichsweise egal. Wenn du deinen Vorschlag weiter verfolgen möchtest, bitte schlage doch ein Datenbank-Schema dafür vor, damit wir öffentlich Vergleichen können welche Auswirkungen daß auf den Betrieb von OSM als riesige, öffentliche Datenbank mit vielen Lese und Schreib -Operationen hätte im Vergleich zu den gewonnenen neuen Tagging-Möglichkeiten. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
Am 25. August 2008 14:30 schrieb Bernd Wurst [EMAIL PROTECTED]: Hallo. Am Montag, 25. August 2008 schrieb Marcus Wolschon: Wenn du deinen Vorschlag weiter verfolgen möchtest, bitte schlage doch ein Datenbank-Schema dafür vor, damit wir öffentlich Vergleichen können welche Auswirkungen daß auf den Betrieb von OSM als riesige, öffentliche Datenbank mit vielen Lese und Schreib -Operationen hätte im Vergleich zu den gewonnenen neuen Tagging-Möglichkeiten. Wo finde ich das aktuelle Datenbankschema? Gruß, Bernd -- z.B. im Buch von Ramm/Topf? oder hier: http://wiki.openstreetmap.org/index.php/Database Hier scheint die Info out of date zu sein: http://wiki.openstreetmap.org/index.php/Database_schema es gibt noch hier die API: http://wiki.openstreetmap.org/index.php/Protocol ich kann Dir leider nichts zur Aktualitaet der angegeben Seiten sagen, und weiss daher nicht, ob Du Deine Frage in Kenntnis der obigen Seiten gestellt hast. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
Am 25.08.08 schrieb Marc Schütz [EMAIL PROTECTED]: maxspeed=80 maxspeed(weight=7.5t)=60 access(weight=12t)=access only Bei mehreren Bedingungen halt sowas wie: maxspeed(weight=7.5t)(Mondfeuchte=grün)=60 Mehrere Bedingungen vielleicht lieber mit bzw. || verknüpft, damit sich das nicht nur auf einschränkende Bedingungen beschränkt. Gute Idee wobei ich irgendwas mit and und or leichter verständlich für Nicht-Informatiker finde. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
Hallo. Am Montag, 25. August 2008 schrieb Martin Koppenhoefer: z.B. im Buch von Ramm/Topf? Nichts gegen die beiden, aber das wird hoffentlich nicht die einzige Informationsquelle sein, oder? Zusätzlich zum Sprit um auf diversen Messen OSM zu repräsentieren will ich nicht auch noch Geld für das Buch ausgeben. oder hier: http://wiki.openstreetmap.org/index.php/Database Verweist nur auf ... http://wiki.openstreetmap.org/index.php/Database_schema ...was veraltet ist. es gibt noch hier die API: http://wiki.openstreetmap.org/index.php/Protocol Die genau was mit dem MySQL-Schema zu tun hat? ich kann Dir leider nichts zur Aktualitaet der angegeben Seiten sagen, und weiss daher nicht, ob Du Deine Frage in Kenntnis der obigen Seiten gestellt hast. Du hast doch selbst gesehen, dass die Wiki-Seite veraltet ist. Das was du genannt hast, kenne ich. Außer dass ich das Buch nicht hier habe. Ich hab auch schon das SVN durchforstet. Da gibt es Ruby-Scripte, die wenn ich das richtig interprtiere die alte Datenbank passend verändern (migration), aber das war mir dann doch zu doof. Gruß, Bernd -- Es vergeht kein Tag an dem ich nicht alles wieder infrage stelle. - André Gide (frz. Schriftsteller) 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] RFC: Tags für Tags - warum so komplizi ert?
Am 25. August 2008 14:51 schrieb Bernd Wurst [EMAIL PROTECTED]: Hallo. Am Montag, 25. August 2008 schrieb Martin Koppenhoefer: z.B. im Buch von Ramm/Topf? Nichts gegen die beiden, aber das wird hoffentlich nicht die einzige Informationsquelle sein, oder? Zusätzlich zum Sprit um auf diversen Messen OSM zu repräsentieren will ich nicht auch noch Geld für das Buch ausgeben. oder hier: http://wiki.openstreetmap.org/index.php/Database Verweist nur auf ... http://wiki.openstreetmap.org/index.php/Database_schema ...was veraltet ist. es gibt noch hier die API: http://wiki.openstreetmap.org/index.php/Protocol Die genau was mit dem MySQL-Schema zu tun hat? ich kann Dir leider nichts zur Aktualitaet der angegeben Seiten sagen, und weiss daher nicht, ob Du Deine Frage in Kenntnis der obigen Seiten gestellt hast. Du hast doch selbst gesehen, dass die Wiki-Seite veraltet ist. Das was du genannt hast, kenne ich. Außer dass ich das Buch nicht hier habe. Ich hab auch schon das SVN durchforstet. Da gibt es Ruby-Scripte, die wenn ich das richtig interprtiere die alte Datenbank passend verändern (migration), aber das war mir dann doch zu doof. Gruß, Bernd -- und ich kann Dir nichtmal sicher sagen, dass die von Dir gewuenschten Informationen im Buch drin sind ;-) Am besten stellst Du Deine Frage nochmal in der dev-ML, das scheint mir die richtigere Adresse zu sein. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
Am 25.08.08 schrieb Sascha Silbe [EMAIL PROTECTED]: On Mon, Aug 25, 2008 at 02:24:47PM +0200, Marcus Wolschon wrote: maxspeed(weight=7.5t)(Mondfeuchte=grün)=60 * ist trivial zu parsen, Nitpick: Das stimmt nicht, insbesondere in low-level-Sprachen ist das alles andere als trivial. Man könnte allerdings Was bezeichnest du jetzt als low-level? PHP, Java. Python, C#,.. geht super. Sogar Shell-Script kann das ausreichend parsen regex und Funktionen) und daß hier jemand sowas in Assember parsen will glaub ich mal nicht, Referenz-Implementationen für die gängigen Sprachen anbieten, d.h. ein Referenz-Implementierung um welche Frage mit Hilfe solch eines Ausdruckes zu beantworten? Halte ich für simplex Ausdruck-Parsen für übertrieben. Klar, kann ich dir für Java in 30min super dokumentiert und objekorientiert runtertippen. Dann weis jeder wie er's in seiner Sprache machen muss und hat etwas zum Vergleichen ob er's richtig gemacht hat. Ich persönlich würde - [] statt () benutzen - Gruppierung per () erlauben - wie von Bernd vorgeschlagen oder-Verknüpfungen erlauben (wobei ich da Klartext ala or und and bevorzuge) gerne doch. Macht Vorschläge! Damit wird aus obiger, noch regulärer Sprache zwar eine kontextfreie (= deutlich schwerer zu verarbeiten), aber der Aufwand für den Mapper ist geringer (der müsste sonst die kon- oder disjunktive Normalform verwenden. Ggf. kann man ja ein Tool schreiben, was aus einem Wort der kontextfreien Sprache ein bis mehrere der regulären Sprache macht. garnicht nötig. Eine Sprache die nur aus (X), (X and X), (X or X) und x:= String [==,!=,,=,,,=] String besteh zu parsen sollte nun nicht schwer fallen. Wenn ein Programm das nicht kann, kann es diese Tags immernoch wie alle anderen ignorieren und weiter nur das default maxspeed=[0-9]* auswerten. Die Anwendungen bearbeiten nur eine Hand voll Wege. Je nach Anwendung. Einen Router mit vernünftiger Geschwindigkeit zu schreiben ist bereits jetzt nicht trivial. Obiger Vorschlag könnte das nochmal deutlich verschlechtern (trotzdem finde ich ihn gut). Was erzählst du mir wdas? Ich schreibe seit letztem Jahr an einem. 1. lässt sich durch leicht verständliche, aber knappe Tagging-Formeln sowie Editor-Support für die gängisten Konstrukte (sogar eine Art Formel-Editor wäre denkbar) erreichen. 1 Wiki-Seite mit 3 Beispiele und die gleichen 3 als Popup im Editor XYZ würden auch schon reichen. ;) Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
Am Montag 25 August 2008 schrieb Marcus Wolschon: Am 25.08.08 schrieb Sascha Silbe [EMAIL PROTECTED]: On Mon, Aug 25, 2008 at 02:24:47PM +0200, Marcus Wolschon wrote: maxspeed(weight=7.5t)(Mondfeuchte=grün)=60 * ist trivial zu parsen, Nitpick: Das stimmt nicht, insbesondere in low-level-Sprachen ist das alles andere als trivial. Man könnte allerdings Was bezeichnest du jetzt als low-level? PHP, Java. Python, C#,.. geht super. Sogar Shell-Script kann das ausreichend parsen regex und Funktionen) und daß hier jemand sowas in Assember parsen will glaub ich mal nicht, Referenz-Implementationen für die gängigen Sprachen anbieten, d.h. ein Referenz-Implementierung um welche Frage mit Hilfe solch eines Ausdruckes zu beantworten? Halte ich für simplex Ausdruck-Parsen für übertrieben. Klar, kann ich dir für Java in 30min super dokumentiert und objekorientiert runtertippen. Dann weis jeder wie er's in seiner Sprache machen muss und hat etwas zum Vergleichen ob er's richtig gemacht hat. Ich persönlich würde - [] statt () benutzen - Gruppierung per () erlauben - wie von Bernd vorgeschlagen oder-Verknüpfungen erlauben (wobei ich da Klartext ala or und and bevorzuge) gerne doch. Macht Vorschläge! ok, gut ;-) mein vorschlag zu benanntem beispiel: * Autos: Höchstgeschwindigkeit 80 km/h * LKW ab 7,5 Tonnen: Höchstgeschwindigkeit 60 km/h * LKW ab 12 Tonnen: Nur Anlieger frei limit.speedmax = 80 limit.speedmax[weight:7.5] = 60 limit.access[weight:12] = access only mit der generellen definition, dass: - geschwindigkeiten in km/h angegeben werden - gewichtsangaben in tonnen angegeben werden - das angegebene gewicht immer groessergleich mit einschliesst. eine 'oder' verknüpfung sollte nicht noetig sein, das laesst sich als separates tag schreiben, ein beispiel: limit.access[weight:7.5] = no limit.access[height:3.5] = no das wuerde bedeuten, dass fahrzeuge die schwerer als 7,5t oder hoeher als 3,5m sind, nicht reinfahren duerfen. 'und' verknüpfungen wuerde ich auch durch reines aneinanderreihen realisieren: limit.access[weight:3.5][height:2.8] = access only das sollte sich recht einfach parsen lassen, und lesbar ist es auch... 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] RFC: Tags für Tags - warum so komplizi ert?
Marcus Wolschon schrieb: Bei mehreren Bedingungen halt sowas wie: maxspeed(weight=7.5t)(Mondfeuchte=grün)=60 * versteht ein Mensch, Ich dachte bisher, dass die Vielseitigkeit von OSM auf der Möglichkeit basiert, dass die Daten direkt in einer Software zu verwenden (ohne großartiges parsing). Das Beispiel ist aber auch eine schwierige Nuss, das muss ich zugeben. GeoJ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
Hallo. Am Montag, 25. August 2008 schrieb Marcus Wolschon: Wenn du deinen Vorschlag weiter verfolgen möchtest, bitte schlage doch ein Datenbank-Schema dafür vor, damit wir öffentlich Vergleichen können welche Auswirkungen daß auf den Betrieb von OSM als riesige, öffentliche Datenbank mit vielen Lese und Schreib -Operationen hätte im Vergleich zu den gewonnenen neuen Tagging-Möglichkeiten. Okay, habe das aktuelle Datenbank-Schema jetzt unter http://gweb.bretth.com/osm_schema_latest.sql gefunden. Also ausgehend von dem Schema würde ich mal sagen: Dann kann man einfach eine Tabelle tag_tags analog zu node_tags, way_tags und relation_tags anfügen, das würde auch nicht mehr ausbremsen. Auch wenn ich mir grade sehr sicher bin, dass das aktuelle Schema auch nicht der Weisheit letzter Schluß ist (Nein, ich hab so auf die schnelle keinen Alternativ-Vorschlag in der Tasche). Gruß, Bernd -- Verbesserung der Oberfläche hört sich an wie die Streichung liebgewonnener Features - bei GNOME weiss man ja nie... (gefunden auf www.prolinux.de) 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] RFC: Tags für Tags - warum so komplizi ert?
Hallo. Am Montag, 25. August 2008 schrieb Bernd Wurst: Also ausgehend von dem Schema würde ich mal sagen: Dann kann man einfach eine Tabelle tag_tags analog zu node_tags, way_tags und relation_tags anfügen, das würde auch nicht mehr ausbremsen. Okay, bei nodes scheinen die tags ja gar nicht ausgelagert zu sein sondern sie werden serialisiert in ein Text-Feld geschrieben. Wenn sich das bei der Datenmenge wirklich als sinnvoll herausstellt, kann man auch sub-tags entsprechend in die einfachen tags rein codieren. Zusatzfeld subtags in der alles serialisiert wird was es gibt. Dadurch würde es weitestgehend abwärtskompatibel der Form, dass eine einfache Filter-Anfrage i.d.R. nur auf Haupt-Tags kommt und ein filtern danach identisch zu jetzt wäre. Wie die Tags bei den Nodes serialisiert werden und warum das bei nodes Sinn macht, bei ways aber offenbar nicht, ist mir weiterhin nicht ganz klar (vermutlich wegen: Es gibt viele Nodes ohne Tags, aber ganz wenige ways ohne Tags), aber das sind Details, die sich von der bisherigen Erfahrung 1:1 übernehmen lassen. Gruß, Bernd -- Wegen des Loches im Staatshaushalt wurde das Licht am Ende des Tunnels gelöscht. 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] RFC: Tags für Tags - warum so komplizi ert?
Hallo. Am Montag, 25. August 2008 schrieb Sascha Silbe: Ich dachte, das wäre inzwischen geändert? Meine Info basiert auf besagtem DB-Schema, das keine Angabe über die Aktualität beinhaltet (latest, sic). Bin allerdings gerade zu faul, die entsprechende Mail auf -dev rauszusuchen Siehst du, ich schmolle jetzt hier auch weil ich derart grundlegende Info nicht durch Recherche finden kann. Man findet zwar Aufrufe des dev-teams, dass sie Leute suchen die das DB-Schema optimieren, aber das aktuelle ist gar nicht öffentlich. Also müssen jetzt alle die sich für begabt halten, aktiv nach dem Schema fragen ohne zu wissen wie das aktuelle aussieht und ob man da wirklich nen Tipp hat. Da vergeht mir die Lust zur aktiven Mitarbeit. Gruß, Bernd -- Keine zwei Menschen gleichen einander, und beide sind froh darüber 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] RFC: Tags für Tags - warum so komplizi ert?
Am 25.08.08 schrieb Guenther Meyer [EMAIL PROTECTED]: eine 'oder' verknüpfung sollte nicht noetig sein, das laesst sich als separates tag schreiben, ein beispiel: limit.access[weight:7.5] = no limit.access[height:3.5] = no das wuerde bedeuten, dass fahrzeuge die schwerer als 7,5t oder hoeher als 3,5m sind, nicht reinfahren duerfen. Hört sich nett an, ist aber uneindeutig. Was gilt in deinem Beispiel bei: limit.access[weight:7.5] = yes limit.access[height:3.5] = no für ein Fahrzeug mit 7.5t Gewicht und einer Höhe von 4m? Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
Am 23.08.08 schrieb Bernd Wurst [EMAIL PROTECTED]: Hallo. Am Samstag, 23. August 2008 schrieb Guenther Meyer: eine baumstruktur laesst sich halt leider nicht vollstaendig und vor allem lesbar in unserem key/value system abbilden; zumindest wuesste ich nicht wie... Naja, ja, bisher nicht. ;-) Aber wenn das spezifiziert wäre, denke ich dass es für einen Editor leicht wäre, das übersichtlich darzustellen. Schließlich gibt es Baumstruktur-Widgets und eine einfache Einrückung reicht im Zweifel auch aus... Denke dabei bitte auch an ein sinnvolles und sehr schnelles Datenbank-Schema dafür ohne Verletzung der ersten Normalform. Mein Vorschlag besteht im Kern darin, dass man im XML-Code nicht nur way ... tag k=foo v=bar / /way setzen kann sondern z.B. way ... tag k=foo v=bar tag k=bla v=blubb/ /tag /way Warum sollte das nicht mit der aktuellen Struktur als bla[bar]=blubb oder bla:bar=blubb funktionieren? Wir machen das bei den name name:en name:en_UK ja auch nicht anders und müssen dazu die Struktur nicht ändern. Wir haben bereits die Konstrukte: Schlüssel=Wert Schlüssel:Spezialisierung=Wert Schlüssel=Wert1;Wert2;Wert2 sowie Schlüssel1=Wert1 Schlüssel1_2=Wert1_1 (z.B. highway=motorway+ref=A5) Text-basierende Sprachen sind so ein mächtiges Konstrukt... Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
