-------- Original-Nachricht -------- > Datum: Fri, 9 Apr 2010 16:03:09 +0200 > Von: Thomas Ineichen <[email protected]> > An: Openstreetmap allgemeines in Deutsch <[email protected]> > Betreff: Re: [Talk-de] track/footway/dogwalk: Konstruktion vs. Widmund vs. > Nutzung
> Hallo M<Winkelzeichner>rtin, > > >> Für mich ist wichtig: "da muss ich normalerweise > nicht mit > >> zweispurigen Fahrzeugen rechnen, also setze ich ein highway=path. Eine > >> genauere Angabe, wie breit der Weg ist, setze ich im width-Key." > > > Wenn Du den Weg nur vom Satellitenfoto kennst, wie willst Du dann > > beurteilen, ob Du da mit zweispurigen Fahrzeugen rechnen musst oder > > nicht? > > Mein obiger Absatz war allgemein formuliert und nicht auf den > konkreten Weg bezogen. > > > Dass zwei Personen den selben Weg unterschiedlich bewerten können, es > daher kein "richtig oder falsch" gibt und ich meine unvollkommene > Beurteilung nicht als den "einzig wahren Weg" durchsetzen möchte, > sollte eigentlich aus meiner Mail bereits hervorgegangen sein.. Das eigentliche Problem ist, dass man zwei Abhängigkeiten in eine Skala presst und das wird immer zu den genannten Problemen führen. Solange Ausbauzustand und Nutzungsbeschränkung nicht unabhängig voneinander erfasst werden, kann ich mir weder beim Ausbau, noch bei den Beschränkungen wirlich sicher sein, was ich vorfinde. Wenn man so eintragen möchte, dass die Daten später richtig interpretiert werden, sollte man sich nicht auf die Einordnung als track oder nicht verlassen, sondern mit getrennten Attributen beschreiben, was man vorfindet. In diesem Bereich ist ein explizites access und ein explizites surface Gold wert, denn niemand weiss, wie sich die Sichtweise auf implizit vermutete Eigenschaften von track morgen wieder ändert. Grüsse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
