Maxspeed=XX:urban (innerorts)

wyo wrote:

Meiner Ansicht nach sollte nicht jede Strasse einzeln so bezeichnet werden sondern nur das Gebiet (Grenze), das diese Zone umfasst.

1. Gibt es in einem Wohngebiet oft unterschiedliche Geschwindigkeitsbegrenzungen (50, 30 und 7 km/h)
2. Wäre es technisch zu umständlich, die Landeszugehörigkeit einer Straße zu berechnen.
3. Werden die Geschwindigkeitsbegrenzungen ohnehin gelegentlich geändert, so dass sie in jedem Fall von Mappern aktualisiert werden müssen.

Gruß FK270673

Meiner Meinung nach ist maxspeed eine eindeutige Eigenschaft der Straße und sollte daher auch direkt an dieser erfasst werden. Egtl. ist es Konsens (auch nach langen Diskussionen und siehe auch taginfo), dass man im maxspeed nur integer angibt und das XX:urban in source:maxspeed gehört.

Eine Grenze ist schon deshalb nicht nötig, weil die Stadt, etc. (also das Gebiet in dem XX:urban gilt) idR als Polygon vorhanden ist.

aighes wrote:

Egtl. ist es Konsens (auch nach langen Diskussionen und siehe auch taginfo), dass man im maxspeed nur integer angibt und das XX:urban in source:maxspeed gehört.

+1

So können Routing-Apps direkt das maxspeed auswerten..

wyo wrote:

Meiner Ansicht nach sollte nicht jede Strasse einzeln so bezeichnet werden [...]

Zu den schon genannten Argumenten kommt noch dazu: wenn man implizit (d.h. durch "geschlossene Ortschaft" etc.) festgelegte maxspeeds von Straßen wegläßt, ist nicht (bzw. nur mit Zusatztags) unterscheidbar, ob die maxspeed bewußt nicht eingetragen wurde, weil implizit gegeben, oder bisher vergessen wurde. Also fährt einer hin, um nachzusehen, stellt dann fest, daß das so okay ist, trägt nichts ein - und wenig später macht sich der nächste die gleiche Arbeit. Dann doch lieber maxspeed=50 auf die Straße (plus source:maxspeed, wenn man will), und es gibt keine Zweifel mehr.

Es gibt maxspeed:source (dieser Key ist logischer) und auch source:maxspeed (dieser ist beschlossen).

Es gab mal eine Max-Speed-Karte, diese ist aber in den Welten des Internernets untergegangen. Lost in Space.... http://maxspeed.osm.lab.rfc822.org/

Hallo Dennis

meinst du so etwas http://cartography.sandbox.cloudmade.com/navdebug/

Max

@Max: Ja, so ähnlich in der Art war die andere Karte auch. Nur deutlich übersichtlicher. Außerdem wurden die Maxspeed-Werte angezeigt, die auch eingetragen sind. Die Cloudmade-Karte erfindet scheinbar noch neue dazu.

chris66 wrote:

aighes wrote:

Egtl. ist es Konsens (auch nach langen Diskussionen und siehe auch taginfo), dass man im maxspeed nur integer angibt und das XX:urban in source:maxspeed gehört.

+1

So können Routing-Apps direkt das maxspeed auswerten..

Und das bringt genau was? Für die Straßen, wo kein maxspeed gesetzt ist, brauchen sie sowieso eine Tabelle mit den impliziten maxspeeds.

Für die impliziten maxspeeds müssen sie auch fähig sein, an Hand der Ländergrenzen zu jeder Straße das Land herauszufinden. Darum kann man meiner Meinung nach bei XX:urban getrost das XX: weglassen. Unnützer Schreibaufwand, und Redundanzen sind selten gut.

Walter Schlögl wrote:

Es gibt maxspeed:source (dieser Key ist logischer) und auch source:maxspeed (dieser ist beschlossen).

Beschlossen von wem? Hab ich ein Voting verpasst?

source:<tagname> gefällt mir trotzdem besser, weil die source:* (source:name usw.) dann in der Liste gruppiert werden. Und wenn <tagname> selber einen Doppelpunkt enthält, finde ich es übersichtlicher, wenn source am Anfang steht.

Beschlossen wurde das von den Mappern, die es eingetragen haben 😉 Schau einfach mal bei taginfo rein.

fkv wrote:

Und das bringt genau was? Für die Straßen, wo kein maxspeed gesetzt ist, brauchen sie sowieso eine Tabelle mit den impliziten maxspeeds.

Wenn man es ganz genau nimmt ja. Ansonsten, wenn man für primary roads mit Durchschnittstempo 75 rechnet passt das schon.

Wichtig ist das Erkennen von innerörtlichen Bundesstraßen , da dort das Durchschnittstempo (ca. 40) sehr abweicht.

aighes wrote:

Beschlossen wurde das von den Mappern, die es eingetragen haben wink Schau einfach mal bei taginfo rein.

Wenn ich alles per Script umtagge, gilt das dann ebenfalls als beschlossen?

chris66 wrote:

fkv wrote:

Und das bringt genau was? Für die Straßen, wo kein maxspeed gesetzt ist, brauchen sie sowieso eine Tabelle mit den impliziten maxspeeds.

Wenn man es ganz genau nimmt ja. Ansonsten, wenn man für primary roads mit Durchschnittstempo 75 rechnet passt das schon.

Ich finde nicht, dass das passt. Denn erstens ist es einfach falsch, und zweitens ist es in Ländern wie DE und AT, wo 100 erlaubt ist, doch weit daneben. Gerade auf Freilandstraßen fährt man den 100er wirklich (wenn man nicht grad einen Tankwagen vor sich hat, den man schwer überholen kann).

Wichtig ist das Erkennen von innerörtlichen Bundesstraßen , da dort das Durchschnittstempo (ca. 40) sehr abweicht.

Es wäre im umgekehrten Fall (residential außerhalb Ortsgebiet) genauso wichtig, nur ist der nicht möglich. ;-)

BTW: Im Ortsgebiet hängt die Fahrzeit hauptsächlich von der Zahl der Ampeln ab. Es wär dringend nötig, für Kreuzungen mit mehreren Schnittpunkten endlich mal einen Gruppierungsstandard zu finden.

fkv wrote:

Wenn ich alles per Script umtagge, gilt das dann ebenfalls als beschlossen?

Entweder dass, oder es finden sich Leute, die deine Aenderungen automatisch rueckgaengig machen ;-)

chris66 wrote:

fkv wrote:

Und das bringt genau was? Für die Straßen, wo kein maxspeed gesetzt ist, brauchen sie sowieso eine Tabelle mit den impliziten maxspeeds.

Wenn man es ganz genau nimmt ja. Ansonsten, wenn man für primary roads mit Durchschnittstempo 75 rechnet passt das schon.

Ich finde nicht, dass das passt. Denn erstens ist es einfach falsch, und zweitens ist es in Ländern wie DE und AT, wo 100 erlaubt ist, doch weit daneben. Gerade auf Freilandstraßen fährt man den 100er wirklich (wenn man nicht grad einen Tankwagen vor sich hat, den man schwer überholen kann).

Es geht dabei nicht nur um die Durschschnittswerte fuers Routing (wobei die 75 schon ganz gut hin kommen, man haengt ja doch staendig hinter einem LKW, Trecker oder Wohnmobil), sondern auch fuer die Anzeige des aktuellen Tempolimits auf dem Navi. Dort will man dann zwar nicht zwischen explizitem und implizitem Limit unterschieden, aber dafuer um so deutlicher zwischen bekanntem Limit (es wird angezeigt) und unbekanntem Limit (nichts wird angezeigt).

BTW: Im Ortsgebiet hängt die Fahrzeit hauptsächlich von der Zahl der Ampeln ab. Es wär dringend nötig, für Kreuzungen mit mehreren Schnittpunkten endlich mal einen Gruppierungsstandard zu finden.

Ueber einen groben Pauschalwert wird man da nie mit statischen Daten hinauskommen, da hilft einem auch die Anzahl der Ampeln nicht grossartig weiter. Die koennen naemlich z.B. als gruene Welle geschaltet sein, so dass sie gar nicht weiter stoeren. Im Stadtverkehr ist dagegen viel wichtiger die aktuelle Verkehrsdichte (wenn ich im Stau stehe, ist es egal ob da vor mir eine Ampel ist oder nicht), und da wird man immer zusaetzliche, dynamische Datenquellen fuer brauchen.

Gruss
Torsten

Max2509 wrote:

meinst du so etwas http://cartography.sandbox.cloudmade.com/navdebug/

Bzgl. maxspeed ähnlich, ja.
(Die "echte" konnte auch noch smoothness, lit, maxheight, width etc. anzeigen)

Woher nimmt die cloudmade-Karte die Info innerorts/außerorts, die offenbar drunter liegt? (mit außerorts=oliv, innerorts=weiß)

Mueck wrote:

Max2509 wrote:

meinst du so etwas http://cartography.sandbox.cloudmade.com/navdebug/

Woher nimmt die cloudmade-Karte die Info innerorts/außerorts, die offenbar drunter liegt? (mit außerorts=oliv, innerorts=weiß)

Ich vermute mal über die "Residential Area", aber sicher bin ich nicht.

Wyo

wyo wrote:

Mueck wrote:

Max2509 wrote:

meinst du so etwas http://cartography.sandbox.cloudmade.com/navdebug/

Woher nimmt die cloudmade-Karte die Info innerorts/außerorts, die offenbar drunter liegt? (mit außerorts=oliv, innerorts=weiß)

Ich vermute mal über die "Residential Area", aber sicher bin ich nicht.

Wyo

Meinst Du "landuse=resiential"? Die sicherlich nicht in KA, deswegen frage ich ja ... 😉