Ich hätte ja einige ex. Kollegen und Bekannte an der Hand, die sowas schon für andere Software gescriptet haben. Ich kann sowas selber nicht umsetzen, ich komme aus der 3D Ecke und beschränke mich auf Animationen und kleinere Geschichten. So Geschwindigkeitsgeschichten und vieles anderes liegt aber auf Halde, auch mit so individuellen Dingen Schlupf usw. für konkrete Anwendungsgebiete. Das ist ansich kein Hexenwerk, da stand man schon vor weitaus schwereren Nüssen. Das Problem ist die fehlende Offenheit des eigentlichen Backends. Die treten mich in den Hintern wenn ich sie jetzt darum bitte sich einen Kopf über die Umsetzung für hier zu machen, am Ende aber vor verschlossene Türen rennen. Mein Versuch bei den Railways hat mich da vorsichtig werden lassen. Ausser der typisch deutschen Marotte erstmal alles anzumeckern was nicht geht, kam da nichts weiter. Also lieber garnichts ändern anstatt sich mal irgendwas bewegt. Von daher muss ich erstmal wissen, ob und inwieweit sich die Überlegung überhaupt lohnt. Wenn man lieber weiterhin 3 Jahre oder länger an irgendwelchen Schlüsseln herumdocktert, nur um festzustellen, das ganze ist noch immer unzureichend, lohnt es sich nicht. Ich kann nur anregen darüber nachzudenken und lange gängige Standards in ähnlichen Anwendungsgebieten aufzeigen, von denen man hier im Moment noch Lichtjahre entfernt ist. Wenn das nicht auf Interesse stößt dann kann man halt nichts machen.
Ich weiß jetzt nicht, was du schon versucht hast, aber ich denke das ist schon der richtige Weg… Grade, was die gängigen Standards in änlichen Anwendungsgebieten betrifft. Ich kenne mich damit nicht aus, und weiß auch nicht, ob sich die Entwickler wissen wie es “andere” gelöst haben. Gibt es denn schon eine Wikiseite zu dem Thema?
Selbstverständlich kann wo immer möglich komplexes Tagging vor dem “gewöhnlichen” Anwender versteckt werden. Bei Tag-Strukturen wie in diesem Thread gehts also nur um das, was ein “Early Adopter” oder Entwickler zu sehen bekommt. Das kann ruhig etwas länger und komplexer sein, aber man sollte es durchaus noch manuell eingeben und besonders auch verstehen können. Übrigens ist das Erstellen von Eingabemasken Aufgabe der Editorprogrammierer, und die werden normalerweise erst tätig, nachdem sich ein Konzept einigermaßen etabliert hat.
Ich halte das im Allgemeinen schon für einen gangbaren Weg, wenn es mehrere gleichzeitig gültige und gleichartige Dinge eines Typs an einem OSM-Objekt gibt, man könnte sich z.B. überlegen, das für Häuser/Hauseingänge mit mehreren Hausnummern zu nehmen. Oder für die Leuchttürme halt, wo es ja, wenn ich das richtig verstehe, auch mehrere “Lichter” an einem Turm gibt, die voneinander unabhängig sind. In solchen Fällen modelliert man damit quasi Mehrwertigkeit, nur, dass man sogar ganze Key-Gruppen damit mehrfach existent machen kann. Im konkreten Fall “maxspeed” drängt sich mir eine Array-Lösung nicht wirklich auf. Wirklich unabhängige Datengruppen will man dort ohnehin nicht, denn maxspeed:hgv[1] = 100 maxspeed:hgv[2] = 120 wird mir dann nur noch durch zusätzliche Prüfungen verunmöglicht. (Allerdings kann ich bei mehreren Bedingungen durch Umordnung auch ohne Indizes Mist bauen.) Wirklich entscheidende Argumente sehe ich bei maxspeed momentan weder für eine Indexlösung, noch für eine reine “Bedingungskette”, ich halte die Bedingungskette aber tendenziell für leichter auswertbar, zumal eine Indexlösung in der von dir vorgeschlagenen Variante ja auch lokale Bedingungen (das hgv in deinem Beispiel) hat. Wenn es diesbezüglich keine neuen Impulse mehr gibt, erstelle ich erstmal einen vorläufigen Entwurf (Draft) für ein Proposal, auf dessen Grundlage man dann nochmal diskutieren kann, vielleicht sieht man dann auch ein paar bisher nicht erkannte Probleme.
Vielleicht sollte man auch einfach nur die Tags nummerieren, die mit weiteren Bedingungen verknüpft sind. Also Etwa: maxspeed:hgv = 100 maxspeed:hgv[1] = 120 maxspeed:hgv[1]:time = Mo-Fr 12:00-18:00 Dann braucht die Software nicht auf Bedingugen zu prüfen, wenn man nur an den allgemeinen Wert will… Und da hab ich mir noch ein paar Gedanken gemacht, bezüglich dazu wie man es für Mensch und Maschine möglichst leicht gestaltet. Es geht da im Prinzip nur darum den Zusammenhang zwischen zwei Schlüsseln darzustellen. Da ist es nur unnötig Kompliziert den Index mitten im Key stehen zu haben. Vielleicht ist es so besser: maxspeed:hgv = 100 [1]maxspeed:hgv = 120 [1]maxspeed:hgv:time = Mo-Fr 12:00-18:00 [2]maxspeed:hgv = 80 [2]maxspeed:hgv:time = Su 13:00-15:00 Das macht es für die Software wesentlich einfacher den String zu zerlegen. Und ungeübte User müssen sich nicht immer fragen an welche Stelle der Index kommt. Mir fallen da auch noch mehr Beispiele ein. So sehe ich häufig Straßen mit Straßenbahnschienen: [1]highway = secondary [1]name = Wilhelmsruher Damm [2]electrified = contact_line [2]name = Tram M1 [2]railway = tram Hier würde das funktionieren, ist aber nicht wirklich verwendbar da nichts mehr gerendert werden würde… Daher denke ich jetzt eher, dass von API-Seite eine Verknüpfung zwischen den Schlüsseln hergestellt werden können muss.
Woran genau machst du fest, “hgv” nicht als Bedingung aufzufassen? Dass es nur ein einzelner Terminus ist? Würdest du das bei anderen Modifikatoren (das vorgeschlagene “wet” etwa) dann auch so machen oder hier ein weiteres Tag mit wet=yes oder so was anhängen? Noch was: Wie würdest du das hier maxspeed:weight>3.5 = 80 in dein Schema überführen?
Spontan finde ich es “seltsam”, liegt aber wahrscheinlich nur an der Gewöhnung an Array-Syntax. Müsst ich noch mal drüber nachdenken, aber wahrscheinlich kann man die “Trennstelle” wirklich auch durch die anderen Tags finden.
Das ist wieder eine Lane-Frage, schließlich ist die Straßenbahn genauso Teil des gesamten Verkehrsbündels wie, sagen wir, ein Radweg oder eine Abbiegespur. Da sollte man m.E. gar nicht erst mit Taghaufen anfangen, sondern mehrere Objekte anlegen (wie auch immer die letztendlich sich durchsetzende Lane-Lösung aussieht).
Schaut euch bitte mal die ISO-Zeitangaben an, das würde evtl. etwas bringen !
Welche ISO meinst du denn? Die Zeitangaben beziehen sich momentan auf diese Richtlinien: http://wiki.openstreetmap.org/wiki/DE:Key:opening_hours
Die ist sehr gut geeignet, um Zeitpunkte anzugeben, dafür würde ich sie definitiv auch verwenden. Um wiederkehrende Zeitintervalle, wie wir sie hier oft brauchen, (“immer Samstags und Sonntags”, “jeden Montag zwischen 8 und 18 Uhr”, “zwischen Juli und Oktober”) anzugeben – und das nach Möglichkeit auch noch leserlich – sehe ich dort keine Syntax. Darfst mich da gerne korrigieren.
Sehe ich genauso. Für unsere konkreten Beispiele (Mo-Fr 12:00-18:00) finde ich dort nichts.
Das geht mit der ISO nicht, richtig. Dort wurden aber einheitlich Zeitangaben definiert, an die mal sich halten kann. Eine Erweiterung auf der ISO-Basis kann auch nicht schaden. Es wird also ein wöchentliches Intervall genötigt, das sich wöchentlich 5 mal wiederholt, am Montag (Wochentag 1) anfängt, 6 Stunden, ab 12Uhr, dauert und mit einem Computer verarbeitet werden kann.
Meinst du Saturday oder Sunday, wo wir mal wieder bei einigen praktischen Problem sind …
Sunday, sonst hätte ich ja “Sa” geschrieben. 
Die englischen Wochennamen sind da unverwechselbar. Kannst du mal ein konkretes Taggingbeispiel geben, wie du das taggen würdest?