[Talk-de] [KA-Geo] Strassen in Bau (highway = construction ist ungeeignet!)

Guenther Meyer d.s.e at sordidmusic.com
Mi Apr 30 18:28:33 UTC 2008


Am Mittwoch 30 April 2008 schrieb Thomas Hieber:
> 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.
naja, aber eine strasse im bau ist durchaus (entsprechend markiert) sinnvoll. 
in real ist da ja auch was zu sehen...

> 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.
drum versuchen wir ja, uns auf ein tag zu einigen.

> 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.
das kommt immer auf das jweilige tool an.
ein router zum beispiel muss je nach fortbewegungsart auch tags fuer 
hoehen/breiten/geschwindigkeits-limits verarbeiten. oder access-restrictions.
das sind in der summe wesentlich mehr als die paar construction dinger...


> 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.
richtig. genau deswegen der andere vorschlag.

> 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.
>
finde ich nicht gut. dann brauchts solche keys auch fuer eisenbahnen, fuer im 
bau befindliche objekte usw.
das machts dann von der performance und struktur noch schwieriger.
ein construction key koennte all das abdecken, und ist wesentlich einfacher zu 
handeln.

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: This is a digitally signed message part.
URL         : <http://lists.openstreetmap.org/pipermail/talk-de/attachments/20080430/8ae12a36/attachment.sig>


Mehr Informationen über die Mailingliste Talk-de