Torsten Breda <torst...@gmail.com> wrote: >> Ziel meines Modells ist es, eine Geschwindigkeitsbeschränkung, den >> Verlauf einer Buslinie, die ununterbrochene Mittlinie oder die >> Leitlinie etc. genau dort in die Karte "einzuzeichnen", wo man sie in >> Wirklichkeit vorfindet (und das nenne ich "Komplexität(sgrad) der >> Wirklichkeit"), ohne dabei die Straße unnötig an jedem Punkt >> aufsplitten zu müssen, an dem sich eine Eigenschaft ändert. Denn in >> Wirklichkeit ist die Straße an diesen Punkten auch durchgehend. > >Du erzeugst dadurch Pseudo-Ways. Das macht es nicht einfacher.
Im Gegensatz zum "Zeichnen" sollte das "Einzeichnen (von Maxspeed, Busroute, Mittellinie) in die Karte" suggerieren, dass man nicht irgendwo in der Gegend rummalt, sondern dieses mehr oder weniger genau entlang eines Straßenzuges erfolgt. Der Editor gibt dann beispielsweise durch Einfärbung der Route Rückmeldung, welche Straße er als "getroffen" ansieht und speichert sie schließlich als Relation und !!nicht!! als Pseudo-Way ab. Jetzt kann ich jede Relation für sich grafisch ausweiten oder kürzen, ohne eine andere zu schädigen. Wenn ich den Verlauf der Straße zurechtzupfe, könnten die Relationen durch verschiedenfarbige Farbbalken parallel zur Straße dargestellt werden. Eventuell reicht es auch, einen einzelnen Balken zu nutzen, der an jedem Anfang/Ende einer Relation, zwischen zwei Farben wechselt und für "unaufgelöste" Hotspots eine weitere Farbe verwendet, welche zur besseren Wahrnehmung eine Mindestgröße annimmt. Auch getaggte Punkte auf der Straße, wie Bahnübergänge und Zebrastreifen, werden gekennzeichnet. So wird unmittelbar beim Zupfen des Verlaufs klar, wenn man einen Problempunkt mit der Maus in der Hand hält. Bei Mausdrüberhalten oder Anklicken eines Problempunktes könnten nähere Infos (Anfang/Ende von Maxspeed, Buslinie) und zur Lösch- bzw Verschiebeproblematik angezeigt werden. Ich weiß, dass so etwas nicht einfach zu programmieren ist. Mir fällt allerdings kein Mittel ein, welches das OP-Problem besser mildern und transparenter machen könnte. >> Bei dieser Oberfläche gäbe es beispielsweise die Möglichkeit, ÖPNV auf >> sichtbar und editierbar zu schalten, aber die Straßen in beiden Fällen >> außen vor zu lassen ... oder umgekehrt. >> >Wer sagt dir, das diese Möglichkeit bestehen würde???? Das wäre doch Unsinnig. >Natürlich würde ÖPNV auch Straßen mitaktivieren, aber eben nicht >umgekehrt. Ich dachte, das wäre klar gewesen. Eben nicht. Das war der Knackpunkt. Jetzt erklärt sich vieles, auch unter der Kategorie "nie behauptet". >Das musst du mir nicht erklären. In meinem Eingangsposting (vielleicht >noch mal lesen) habe ich geschrieben, dass es Regeln geben soll, die >die Abhängigkeit der Module untereinander beschreibt. Und genau da setzt das von mir beschriebene Konzept der unteilbaren Wege mit Eigenschaftsrelationen an. Analog zur obigen grafischen Beschreibung stellt die "Unteilbarkeit" der Straßenzüge den "ununterbrochenen" Straßenkörper dar, auf dem die Relationen unabhängig voneinander aufgebracht werden. (Wie die darunter liegenden Schichten das in der Datenbank darstellen, steht auf einem anderen Blatt.) Durch diese Unabhängigkeit brauchen Abhängigkeitsregeln für die Relationen untereinander erst gar nicht aufgestellt zu werden. Es bleiben also nur noch die Regeln zwischen Straßenkörper (way) einerseits und Relation sowie getaggte Punkte andererseits. Durch das Konzept können nun diese beiden Mengen mit wenig Aufwand bestimmt werden: 1) Knickpunkte der Straße 2( Anfangs- und Endpunkte der Relationen sowie getaggte Punkte. Wenn ich mich nicht täusche, braucht man zur Abhängigkeitbeschreibung der Module untereinander für die Gruppe 1) und für die Gruppe 2) jeweils eine Lösch- und eine Bewegungsregel, die nicht allzu kompliziert sein dürfte. Dann wäre mit vier Regeln das gesamte Gefahrpotential beschrieben. Eine geringe Anzahl von Regeln hilft natürlich ungemein. Sobald man sich alle verinnerlicht hat, kann man für jede ein Handlungsschema einüben und möglicherweise veröffentlichen. Man ersetze in obiger Beschreibung "Straße" durch "way" und verallgemeinere sie so. Wermutstropfen: Eventuell machen Vaterrelationen sowie Areas das Regelschema komplexer. Falls dies für Veterrelationen zutrifft, könnte man möglicherweise durch Auflöung der Vaterrelation in die Elemente Tochterrelationen diesem beikommen. Dabei bleibt aber aus Usersicht die Vaterrelation erhalten. In dieser Richtung kann ich das Problem noch nicht so ganz greifen. Es muss wohl erst einmal sacken. Ich kenne mich mit der OSM Datenbank nicht aus. Intuitiv vermittelt sich mir das beschriebene Prinzip als eines, das vom bisherigen Schema abweicht und eventuell eine Konvertierung des Datenbestandes notwendig machen könnte. Daher der Begriff "OSM 2.0". _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
