Closed SupaplexOSM closed 1 year ago
In dem Fall von Parkflächen wird die capacity über den Flächeninhalt berechnet. Für https://www.openstreetmap.org/way/1083487551 ergibt das 20,6 / 12,2 = 1,6 und da ich round() benutze, wird auf 2 aufgerundet. Jetzt könnte ich floor()/ceil() benutzen, ich fürchte dann fehlen an anderen Stellen Parkplätze.
Ich fasse zusammen: die Berechnung muss genauer erfolgen. (Für parking_lanes erfolgt sie anhand der Länge)
Ah, interessant. Mir scheint, als wäre floor() dann die bessere Wahl, also abrunden. So tun wir es ja bei den Parkstreifen auch: Wenn sich aus der Länge eines Segments rechnerisch eine capacity von 5.9 ergibt, passen "ordnungsgemäß" dennoch nur 5 Fahrzeuge hin.
Eine Ausnahme könnten kleine Parkbuchten mit einer rechnerischen capacity von <1 sein. Man könnte argumentieren, eine Parkbucht soll immer mindestens ein Fahrzeug aufnehmen können - in der Realität dann also ein eher kurzes Fahrzeug.
Ich würde also vorschlagen: capacity = max(1, floor(Fläche / Divisor))
Ich habe die Formel eingebaut, das obige Beispiel der Karl-Marx-Allee sieht nun gut aus.
Die capacity-Berechnung von separaten Parkbuchten ist noch ungenau, was sich insbesondere bei kleinen Parkbuchten auswirkt:
So gibt es z.B. auf Abschnitten der Karl-Marx-Allee zahlreiche kleine Parkbuchten für je ein Fahrzeug, die zwischen 5 und 7 Meter lang sind. Der Algorithmus scheint die capacity zur Zeit mit "2" anzusetzen, sobald die Länge länger als eine Fahrzeuglänge ist.
Korrekt wäre - für den Fall des Parallelparkens: Ein einzelnes Fahrzeug ist im Mittel 4,4 Meter lang. Ab dem zweiten Fahrzeug kommt zudem je ein Rangierraum von 0,8m hinzu. Damit zwei Fahrzeuge Platz finden, müssten also mindestens 4,4m + 5,2m = 9,6m Platz sein (jedes weitere Fahrzeug würde wiederum je 5,2m Platz benötigen). Bei Längen unter 9,6m darf also nur "capacity=1" angenommen werden.
(Ob das auch nicht-separate Segmente betrifft, hab ich noch nicht geprüft, ist mir dort aber noch nie aufgefallen...)