Hallo

Am 17.01.2011 11:12, schrieb ant:
Hallo,

On 17.01.2011 00:42, Garry wrote:

Es macht keinen Sinn eine einfache Erfassungsmöglichkeit durch
Polygondefinitionen statt Einzeltags zu schaffen wenn man
die dadurch geschaffenen Fehlerquellen nicht einfach erkennen und
beheben kann.

Was ich angeregt habe, soll ja auch keinen Ersatz für den normalen Gebrauch des maxspeed-Tags darstellen. Ich versuche nur zum Nachdenken darüber anzuregen, ob die massenweise Verwendung der source:maxspeed-Tags eine so gute Idee ist. Bisher ist dieses Schema ja noch weit davon entfernt, dass es flächendeckend ausgewertet werden kann, und ich dachte, Polygone wären der effektivere und einfachere Weg. Ich könnte sogar noch einen Schritt weiter gehen und sagen: Wir brauchen nichtmal Polygone zu mappen, denn wenn alle Ortseingans-/-ausgangsschilder einer Stadt gemappt sind, kann das Routingprogramm sich dieses Polygon auch selbst zurechtbasteln.

Das selber basteln halte ich für verkehrt, eben weil es viele Wege gibt, auf denen man die Stadt verlassen kann und auf denen kein Schild steht. Allein schon wenn man eine zweispuriege Straße mit links und rechts jeweils einem Rad-Fußweg müsste man dann 4 Ortsausgangsschilder eintragen, damit der Algorithmus das Polygon zeichnen könnte. Man müsste diese Punkte also ohnehin seperat von den Ortseingangsschildern erfassen, dann kann mana uch gleich ein Polygon machen.

Mit deiner obigen Begründung könnte man sich auch das highway=residential sparen. Alle Wege, die innerhlab von landuse=residential sind, sind per default Ortsstraßen und Abweichungen könnte man explizit erfassen. Das lässt sich aber nur umständlich auswerten und man muss erst das landuse-polygon zeichnen können. Eigenschaften die ein Objekt direkt betreffen sollten auch direkt an diesem Objekt pappen, bzw. indirekt über eine Relation, wenn dies sinnvoller ist.

Viele Grüße,
Henning


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

Antwort per Email an