Re: [Talk-de] Verbesserungsmoeglichkeit fuer API 0.7? war Re: Doppelte Wege

2009-08-12 Diskussionsfäden Georg Feddern
SLXViper schrieb:
> Trick für JOSM: wenn man nicht lange mit mittlerer Maustaste und Strg
> arbeiten will, kann man die gestapelten Wege an den virtuellen Nodes
> auseinanderziehen.
>   

Danke für den Tip.
Hab ich zwar schon intuitiv mal gemacht, aber diesen Nutzen noch nicht 
verinnerlicht. Hilft mir ungemein.

> Ja, es gibt tatsächlich sinnvolle und notwendige Anwendungen für
> gestapelte Wege. Beispielsweise bei unmittelbar aneinandergrenzenden
> Gebäuden. Wenn das eine eine Kirche und das andere ein "normales"
> Gebäude ist, komme ich da gar nicht drumrum, da sich das nicht per
> Relation oder sonstwas lösen lässt. Mehrere physikalische Gebäude in ein
> osm-building zu packen halte ich für unschön und unpraktisch. Andere
> Fälle sind aneinander angrenzende landuses, bspw. residential und forest...
>   

> Nett gedacht für lineare Features, aber es gibt da durchaus Fälle, die
> sich nicht so lösen lassen, siehe oben ;)
>
> Grüße
>   

Was ist an einem Gebäude, einem Landuse oder anderen geschlossenen Wegen 
anders als an z. B. einer Gemeindegrenze?
Lässt sich m. E. wunderbar mit einer Relation abbilden.
Die Brandmauer ist dann halt in beiden Gebäuderelationen enthalten.
Und der externe Glockenturm wäre dann ebenfalls in der Kirche(nrelation) 
enthalten.

Und mal ganz abstrakt gefragt:
Was ist ein way anderes als eine geordnete Relation von nodes?
Mal abgesehen davon, das er sich so schon grafisch darstellen und 
einfach bearbeiten lässt.

Prinzipiell sind geschachtelte Relationen eigentlich DAS Mittel, um 
Objekte anhand von Koordinaten zu beschreiben.

ABER:
Jetzt als fortgeschrittener Anfänger haben die Relationen ihren 
Schrecken für mich verloren, auch aus beruflichem Hintergrund.
Damals als blutiger OSM-Anfänger hätten sie mich aber trotz beruflichem 
Hintergrund schon ein wenig - oder mehr - abgeschreckt.

Fazit:
Ohne entsprechende Editor-Unterstützung und ohne das Verständnis von 
Relationen sehe ich Mapper damit ziemlich verloren - im wortwörtlichen 
Sinne.

Gruß
Georg


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Verbesserungsmoeglichkeit fuer API 0.7? war Re: Doppelte Wege

2009-08-12 Diskussionsfäden qbert biker

 Original-Nachricht 
> Datum: Wed, 12 Aug 2009 11:03:51 +0200
> Von: SLXViper 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Verbesserungsmoeglichkeit fuer API 0.7? war Re: 
> Doppelte Wege


> Ja, es gibt tatsächlich sinnvolle und notwendige Anwendungen für
> gestapelte Wege. Beispielsweise bei unmittelbar aneinandergrenzenden
> Gebäuden. 

Also notwendig sind sie sicher nicht, uebers sinvoll laesst
sich streiten. 

> Wenn das eine eine Kirche und das andere ein "normales"
> Gebäude ist, komme ich da gar nicht drumrum, da sich das nicht per
> Relation oder sonstwas lösen lässt. 

Eine Relation umschreibt das eine Gebaeude, die naechste
das zweite. Ich sehe nicht, warum sich das nicht loesen 
lassen soll. Mit den Relations ist die Abbildung im Aufbau
sogar konsistenter, denn der way sagt nur, dass da eine 
Begrenzung (=Mauer) ist und die Relations sagen aus, wer
diese Begrenzung wie nutzt. 

> Mehrere physikalische Gebäude in
> ein
> osm-building zu packen halte ich für unschön und unpraktisch. Andere
> Fälle sind aneinander angrenzende landuses, bspw. residential und
> forest...

Auch hier: Eine relation umschreibt eine Flaeche und nutzt
schon existierende Elemente, z.B. eine Strasse mit. 
 
> JOSMs Validator warnt auch vor solchen Stapeln, leider pauschal, was bei
> den genannten Fällen lästig ist. 

Eine Logik zu finden, die jede unsaubere Benutzung von
Stapeln abbildet, ist auch nicht einfach, zumal sich ja
die Regeln und tags auch aendern. Und das Fehlerpotential
fuer unabsichtliche Verbindungen bleibt hoch und wird vom
Validator AFAIK nicht abgefangen.
 
> Nett gedacht für lineare Features, aber es gibt da durchaus Fälle, die
> sich nicht so lösen lassen, siehe oben ;)

Es gibt lineare Features und Flaechenfeatures. Aber die
Stapel bringen auf allerunterster Ebene (nodes, ways)
eine Pseudo-3-Dimensionalitaet rein, die so ja gar nicht
existiert. Es geht ja nicht um echte 3-Dimensionalitaet
wie Bruecken oder Hoehenattribute, sondern ueber Dinge,
von denen wir uns wohl einig sind, dass sie sich auf
einer Ebene, sprich der Boden, abspielen. 

Und, wie schon geschrieben, es ist eine Idee fuer eine
naechste Ausbaustufe, hier API 0.7 genannt. Mehrfachnutzung
vorhandender ways statt aufstapeln von immer neuen ways,
die erstmal nichts voneinander wissen. 

Gruesse Hubert
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Verbesserungsmoeglichkeit fuer API 0.7? war Re: Doppelte Wege

2009-08-12 Diskussionsfäden SLXViper
qbert biker schrieb:
> Grundsaetzlich bleiben Stapel immer eine leastige
> Fehlerquelle
+1
>  weil sie per Werkzeug schwierig zu erfassen
> sind. Die Selektion durch den Stapel hindurch ist
> zwar machbar, aber wieviele Anwender koennen so gut
> mit den Editoren umgehen, dass sie das hinbekommen?
>   

Trick für JOSM: wenn man nicht lange mit mittlerer Maustaste und Strg
arbeiten will, kann man die gestapelten Wege an den virtuellen Nodes
auseinanderziehen. Die so erzeugten Nodes kann man einfach wieder
löschen ohne den Verlauf verändert zu haben, wenn man fertig ist.
Meistens löscht man ja eh alle Wege bis auf einen. Beispiel:
http://home.arcor.de/SLXViper/osm/doppeltgemoppelt.png

> Es bleibt die Frage, warum es diese Stapel ueberhaupt
> geben muss und warum man sie nicht gleich beim Eintragen
> in die Datenbank oder beim Erstellen mit dem Editor
> unterbindet. Es muesste nur eine saubere Loesung fuer
> Mehrfachnutzung eines ways gefunden werden.
>   

Ja, es gibt tatsächlich sinnvolle und notwendige Anwendungen für
gestapelte Wege. Beispielsweise bei unmittelbar aneinandergrenzenden
Gebäuden. Wenn das eine eine Kirche und das andere ein "normales"
Gebäude ist, komme ich da gar nicht drumrum, da sich das nicht per
Relation oder sonstwas lösen lässt. Mehrere physikalische Gebäude in ein
osm-building zu packen halte ich für unschön und unpraktisch. Andere
Fälle sind aneinander angrenzende landuses, bspw. residential und forest...

JOSMs Validator warnt auch vor solchen Stapeln, leider pauschal, was bei
den genannten Fällen lästig ist. Ein bisschen Feintuning (nicht warnen
bei gemeinsamen ways in buildings und landuses) hier sollte das aber
beseitigen können. Hier liegt es am Benutzer, Unsinn zu verhindern.
Potlatch weist den Benutzer da allerdings nicht auf den Fehler hin, man
kann problemlos mehrere Straßen komplett stapeln (eben getestet). So
einen Fall hatte ich vor ein paar Wochen mit einem Anfänger, der mal
eben bis zu 9 Wegen gestapelt hat und nicht bemerkt hat, was er da
wirklich gemacht hat.
Was Merkartor da anstellt, weiß ich nicht.

Inwiefern Probleme aus unvollständigen uploads auch mit api 0.6 noch
entstehen können, kann ich gerade nicht beurteilen. Sollte hier noch
Gefahrenpotential vorhanden sein, müsste man entsprechende Vorkehrungen
treffen.

> Mit einem Mix aus Mehrfachattributierung und Relations
> sollte das gelingen, also z.B. dass ein way gleichzeitig
> ein highway und ein railway ist (Tramschienen auf 
> Fahrbahn) und konkurrierende Attribute auf relations
> ausgelagert werden.
>   

Nett gedacht für lineare Features, aber es gibt da durchaus Fälle, die
sich nicht so lösen lassen, siehe oben ;)

Grüße


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


[Talk-de] Verbesserungsmoeglichkeit fuer API 0.7? war Re: Doppelte Wege

2009-08-12 Diskussionsfäden qbert biker

 Original-Nachricht 
> Datum: Wed, 12 Aug 2009 01:49:03 +0200
> Von: Michael Bemmerl 
> An: Openstreetmap allgemeines in Deutsch 
> Betreff: Re: [Talk-de] Doppelte Wege

> 35 Ways übereinander. Und das gleich zweimal.

Und es ist dann reiner Zufall, welche Ebene dann mit einem
kreuzendem way verbunden ist. Gibt nette Effekte im Router ;)

Variante 1: Verschiedene Kreuzungen nutzen verschiedene
Nodes im Stapel. Wird erst beim Routing sichtbar, da aber
wundert man sich ueber eigenartige Ergebnisse. Kreuzungen
sind verbunden und trotzdem wird man kreuz und quer 
gefuehrt.

Variante 2: Alle Nodes sind mit allen ways im Stapel
verbunden. Da wird dann im obigen Beispiel aus einer
Strecke von 10 Nodes ein Netz mit 10*35 Knoten,
die das Routing aufloesen muss. 

Grundsaetzlich bleiben Stapel immer eine leastige
Fehlerquelle weil sie per Werkzeug schwierig zu erfassen
sind. Die Selektion durch den Stapel hindurch ist
zwar machbar, aber wieviele Anwender koennen so gut
mit den Editoren umgehen, dass sie das hinbekommen?

Es bleibt die Frage, warum es diese Stapel ueberhaupt
geben muss und warum man sie nicht gleich beim Eintragen
in die Datenbank oder beim Erstellen mit dem Editor
unterbindet. Es muesste nur eine saubere Loesung fuer
Mehrfachnutzung eines ways gefunden werden. 

Mit einem Mix aus Mehrfachattributierung und Relations
sollte das gelingen, also z.B. dass ein way gleichzeitig
ein highway und ein railway ist (Tramschienen auf 
Fahrbahn) und konkurrierende Attribute auf relations
ausgelagert werden. 

Nur mal so als Anregung fuer die neahere Zukunft

Gruesse Hubert
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de