Toni Erdmann schrieb: > Norbert Hoffmann schrieb: > >> Guenther Meyer wrote: >> >> >>> sorry, aber diese herangehensweise erscheint mir unlogisch. >>> ein highway=primary und was in der art construction=yes sollte das ganze >>> sinnvoll beschreiben. >>> >> Warum ich das für falsch halte, habe ich ja schon geschrieben: >> >> >>>> Wenn eine Baustelle mit "highway=primary" getagged würde, dann wäre >>>> plötzlich die Bedeutung dieses Eintrages geändert. Bisher ist >>>> "highway=primary" eine größere befahrbare Straße. Wäre "construction" ein >>>> zusätzlicher key, dann können sich plötzlich auch noch Schlammwüsten, Pläne >>>> in einer Schublade oder unausgegorene Ideen in den Köpfen einiger Leute >>>> dahinter verbergen. >>>> >>>> >>> ... und wenn construction gesetzt ist, dann WIRD das eine entsprechende >>> strasse. wenn alles fertig gebaut ist, einfach das construction flag >>> entfernen, und gut is. >>> >> ... und die Routingprogramme müssen wissen, dass "highway=primary" nicht >> immer zum Routing herangezogen werden darf (und so weiter und so fort). >> Wenn es (noch) keine Straße ist, dann halte ich es für Unsinn es als Straße >> zu taggen und noch "Ausnahmekeys" zu erfinden. >> > > Dem kann ich nur zustimmen.Was erwarten wir denn von einem > Routingprogramm? > --> das auf einem u.U. schwachbrüstigem Endgerät a la Handy, PDA > möglichst schnell zu einem Ergebniss kommt, das natürlich auch > noch korrekt sein soll. > > D.h. für mich: macht die Entscheidung, ob eine Straße benutzbar ist > nicht von zu vielen Tags abhängig. > > highway=primary + construction=xxx + start_date= + ... > > ist für die Performance eines Routingprogrammes schlechter als > > highway=construction + ein Mapper der das ändert, wenn die Straße > fertig ist > > nur, um mal zwei extreme Beispiele zu nennen. > > >>> die renderer muessens dann halt auch entsprechend darstellen. >>> > > Sowieso, aber da gibts nicht die Performanceprobleme, denn die laufen > meist auf PCs, oder? > > >> Und das würden sie auch tun, wenn du nicht eine andere als die schon >> genutzte Methode Baustellen zu kennzeichnen verwenden würdest. >> >> > > Derzeit gibt's eine Methode: > > highway=construction + construction=secondary z.B. > > und die funzt. > > Ich finde die aktuelle Methode (highway=construction + construction=secondary) vielleicht nicht optimal, aber auf jeden Fall besser als die idee mit highway=secondary + construction=... Der Grund ist für mich einfach die Grundidee hinter diesem ganzen Tag Value Thema. Normalerweise müssen OSM Tools nur die Tags / Values auswerten die sie auch verwenden - also z.B. mkgmap such gezielt nach bestimmten highway=xxx Tags um daraus abzuleiten, ob dieser Way aufs Garmin soll, und wenn ja welcher Garmin Typ verwendet wird. mkgmap wertet z.B. kein maxspeed=xxx aus. Wenn ich aber nach diesem simplem Schema vorgehe, dann habe ich am Ende auch alle geplanten Straßen kommentarlos im Garmin drin als normale Straße. Der Autor von mkgmap müsste also regelmäig prüfen, ob irgendjemand zu einem highway tag irgendwelche Zusatztags erfunden hat, die aus einem echten Highway einen geplanten Highway machen, oder einen Highway, der vielleicht bei den französischen Revolution mal benutzt worden ist. Ich bin der Meinung, dass die OSM Tools sich auf die Schnittstelle highway=secondary verlassen können müssen ohne permanent auf zusätzliche weitere Key/Value Paare achten zu müssen. Eigentlich ist auch highway=construction hier nicht korrekt, da auch hier manche Tools vielleicht glauben könnten, es handelt sich um einen speziellen Typ von Weg, den sie nicht kennen und würden dann evtl. einen generischen Weg zeichen oder fürs Routing nutzen. Am saubersten wäre gewesen diesen Way mit "planned_highway=secondary" zu taggen. Dann würde es keine Verwechslung mit normalen Ways geben, und tools die das Konzept kennen könnten trotzdem problemlos damit umgehen.
Gruß, Thomas _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
