Re: wieso gibt es keinen landuse=highway?

marek kleciak wrote:

Organisatorisches
1. Wir sind uns im Klaren, dass wir nicht für die ganze Community eine Entscheidung treffen können die weit reichende Konsequenzen für das gesamte Projekt hat. Auf der anderen Seite bleibt das Problem seit 2 Jahren ungelöst. Es kann nicht sein. Daher wollen wir im April 2013 eine Konferenz zu diesem Thema organisieren auf der wir bisherige Entwürfe miteinander vergleichen und abstimmen, für welches Modell wir uns entscheiden. Dazu laden wir Mitglieder ein, die aktiv in dieser Thematik sind. Danach soll dieses Modell gelten.

Naja, Hauptsache man hat dann nicht wieder das gleiche Problem mit zu wenigen Teilnehmern.

marek kleciak wrote:

2. Um diese Entscheidung zu erleichtern, schlagen wir vor, dass man in einem kleinen Testgebiet Modelle nach diesen verschiedenen Entwürfen aufbaut damit man die Argumente dafür und dagegen besser abwägen kann.

Ich hatte bisher teilweise die nötige Fälle per Krakelzeichnung analysiert und hatte dann natürlich keine Lust die noch mal ordentlich zu digitalisieren. In dem Zusammenhang auch danke an aighes für den Hinweis auf die Dev-API, nicht das ich nicht um deren Existenz gewußt habe, aber der explizite Hinweis das man die auch für Schema/Proposal-Entwicklung nutzen kann, ist gut und sollte aus meiner Sicht auch an passender Stelle im Wiki vermerkt werden. Bisher landeten ja viele Ansätze zum Spurmapping in der echten API, auch wenn man da versucht hat, so gut wie möglich die Kompatibilität zu waren.

marek kleciak wrote:

Technisches
1. Es soll ein Stufenaufbaumodell möglich sein

Sehe ich auch so! Man sollte von der flächigen Darstellung aller Objekte ausgehen, da es ja in der Realität keine Punkte/Linien gibt. Aufbauend von der Vollflächendarstellung kann man dann beliebig viele Abstraktions- und Vereinfachungsstufen machen. Vereinfachte Darstellungen braucht man auf jeden Fall auch, wenn man die Daten nicht genau genug erfassen kann und aus Kompatibilitätsgrunden mit der bisherigen Liniendarstellung.

marek kleciak wrote:

3. Einige Entwürfe schlagen Strukturen vor, die von momentan verwendeten Werkzeugen wie z.B. KeepRight als Fehler eingestuft wären. Daher müssen möglichst zeitgleich mit der neuen Struktur auch entsprechende Arbetswerkzeuge umgebat werden.

Naja, KeepRight sieht ja auch amenity=nursing_home als veraltet an... ...keine Ahnung, was den/die Entwickler da geritten hat.

Wie schon diverse Male geschrieben, wären auch einige Grundsatzentscheidungen, wie z.B. die Endscheidung zwischen menschenmappbar und beschränkt oder möglichst menschenlesbares Maschinenschema und mappen mit entsprechenden Tools, echt whilfreich, wobei ich da für Letzteres bin.

Zumindest für mein Schema, wo ich das ja auch so mache, hatet ich schon geschrieben, das da die ganze Kreizungslogig noch mal ordentlich angesehen werden muß, weil ich habe mich da erst mal primär auf das Flächenrouting und die Flächen/Linien-Übergänge konzentriert. Das Kreuzungsschema ist die erste Idee. Momentan haben wir ja eine schlechten Anklatz der GDF-Segmente, wobei die dort ja nur für die Repräsentation der Geometrie da sind (nach dem bsiherigen eher sehr oberflächlichen Überfliegen der Spec) und man dann den ganzen Rest per Relation, unter Verwendung evtl. Hilfsknoten, drauf setzt.

In OSM beschreibt die Linienverbindung ja primär den möglichen Fahrweg, so daß es da auch nur einen gemeinsamen Knoten geben sollte, wenn da ein tatsächlicher Übergang möglich ist.