was kleineres als highway=service+driveway für garagenzufahrten

driveway bedeutet ja laut leo auffahrt bzw fahrweg. gedacht ist die kombination highway=service + service=driveway wahrscheinlich für die privaten zufahrten zu etwas nach innen versetzten häusern die einige duzend meter entfernt sind. in stadtgebieten sind die zufahrten zu garagen bzw in innenhöfe von häusern aber oft sehr kurz. wenn man nun hier auch tür zu tür routing machen will bzw. für potentielles blinden-routing ev. querende ausfahrten bei gehsteigen kennzeichnen will, sollten aber auch diese wege erfasst werden.

momentan tagge ich solche sachen immer mit service=driveway und access=private. mapnik rendert diese aber bei zoomstufe 15 immer noch (sogar im grässlichen rosarot). und bei zoomstufe 14 sehen die hauptstraßen dann auch noch immer ausgefranst aus. bsp: http://osm.org/go/0JhJ1QbZ3

das gleiche problem habe ich auch bei den zufahrtswegen/pfaden bei größeren mietshäusern. entlang eines asphaltierten wegs befinden sich die einzelnen hauseingänge. der weg selbst ist so breit angelegt, dass ein mehrspuriges fahrzeug drauf platz hat, also ein umzugswagen, einsatzfahrzeug, usw. prinzipiell ist der weg aber durch einen bollard versperrt, da normalerweise die menschen ja nur drauf gehen um zu den eingängen zu gelangen. das tagge ich momentan mit highway=service+access=private+vehicle=private+emerency=yes+foot=destination. für autofahrer sind diese wege relativ uninteressant daher würde ich es vom level her auch um “eins niedriger” ansiedeln als service=driveway. eher so auf dem level eines highway=paths+foot=destination.

ich finde, dass es hier noch einer zusätzlichen semantischen unterscheidung bedarf, da sonst renderer niemals eine change haben hier vernünftig details bei niedrigen zoomstufen wegzulassen. irgendwelche vorschläge für service-werte die man in solchen fällen anstatt “driveway” verwenden könnte?

driveway ist eindeutig eine Zufahrt zu einem Objekt. Was Mapnik daraus macht, ist die Sache von Mapnik und kein Problem in den Daten.

Soweit absolut richtig.
Für die Zufahrt zu einer Garage würde ich allerdings service=parking_aisle verwenden.
Die Darstellungsprobleme bei Maponik und anderen dürften sich dadurch jedoch kaum ändern.

Allerdings verstehe ich nicht, warum man jede Garagenzufahrt und jeden Zugang zu einem Einzelhaus überhaupt eintragen sollte. Das kann man wohl nur nach dem Motto ‘Jeder nach seiner Fasson’ verbuchen.

Bei öffentlichen Gebäuden, Firmen mit Publikumsverkehr oder Wohnblocks mag das noch sinnvoll sein. Bei Einzelhäusern sehe ich hingegen keine Notwendigkeit.

Edbert (EvanE)

Für mich klingt service=parking_aisle eher nach einer Reihe auf einem Parkplatz. “aisle” bezeichnet ja auch eher einen Gang oder eine Schneise, weniger eine Zufahrt.

Von daher finde ich service=driveway schon etwas passender, das bezeichnet wirklich eine (Grundstücks-)Auffahrt.

Nun ich sehe das auch so wie EvanE, für öffentliche Bereiche oder größere Flächen sehr gerne aber wenn es in das private geht, bringt es IMHO keinen Mehrwert. Aber probier es mal aus, vielleicht liegen wir ja auch falsch :slight_smile:

Ich habe es viel im ländlichen Raum genutzt, für Stichstraßen (>100m) zu den Gehöften. Die 5m Hauseinfahrt bis zur Garage würde ich auch nicht eintragen.

Ähm das verstehe wer will. Einerseits redet man darüber einzelne Fahrspuren zu erfassen um Blinden und Sehbehinderten eine uneingeschränkte Navigation zu ermöglichen und dann macht man am Gartentor halt. Also in letzter Konsequenz würde ich doch den Weg zum Eingang bevorzugen. Ob dann der Gartenweg im Gemüsebeet auch noch da sein muss ist eine andere Sache.

genau das ist ja der grund wieso ich eine semantische unterscheidung machen will, damit leute denen das nicht wichtig ist bzw die sich davon gestört fühlen eine möglichkeit haben diese auf eigenen karten auszublenden.

sowas

http://www.alltackle.com/GravelDrivewayExample.jpg

mit sowas

http://www.ndclean.com/ss2006pics/driveway-garage.jpg

in einen driveway-topf zu werfen ist meiner meinung nach falsch bzw zu ungenau

Wieso? Die Funktion ist bei beiden die gleiche. Die jeweilige Länge des Objektes kann man den Koordinaten entnehmen und entsprechend alle Wege unter 20m Länge rausfiltern.

Ich sehe es auch so wie flaimo, es fehlt irgendwie ein Tag für die ungefähre Spurbreite in PKW-Breiten. Eine Zufahrt zu einem Garagenkomplex oder einer Einzelgarage ist eine normale Gebäudezufahrt, was bei mir auch highway=service + service=driveway ist.

Wenn breitere Wege mit Pollern bestückt sind tagge ich sie als Fuß-/Radweg, da es der realen Nutzung entspricht, auch wenn da emergency=yes möglich ist. Da wäre es aus meiner Sicht auch nötig auch die Breite ungefähr (für width hat ich im Normalfall keine Meßinstrumente dabei) angeben zu können. Ich richte mich da nach der realen Nutzung und so ist das erste Bild oben ja auch eindeutig highway=footway +leisure=park, es sei denn jemand möchte gerne mit dem PKW die Treppe herunter fahren.

Du musst das width auch nicht auf den Zentimeter angeben. Ob der Weg nun 1m, 2m oder 3m breit ist, kann man auch schätzen, ohne das man einen Zollstock mitführt. Da brauchts keinen weiteren Tagg für. Zur Not kann man ein note oder ein fixme angeben.

Ich finde aber im Wiki gerade nirgendwo was zum Toleranzbereich, weil es wäre ja schon praktisch, wenn man da den Toleranzbereich angeben könnte. Es ist ja nur definiert, das die Maßeinheit Meter ist, aber nicht wie man den geschätzen 3 m +/- 1 m Weg vom gemessenem 3 m -Weg unterscheidet. Wenn ich da note=* und fixme=* taggen soll, dann kann man da auch einen Näherungstag für PKW-Breiten einführen, das würde auch das Problem lösen, das z.B. auch für highway=track für breite Fußwege benutzt wird.

Edit: Sehe gerade, es gibt schon est_width=* für die geschätzte Breite.

Wir geben zu keiner Maßzahl eine Toleranz an. Warum auch? Unsere Koordinaten haben einen Fehler von >3m. Auch der Auswerter dieser Info geht nach Grenzwerten. Bsp. 0.5 und breiter für Räder, >2.0 PKW, >2.5 LKW. Ob da du nun 2.0, 2.1 oder 2.09199 ein gibts spielt keine Rolle. est_width wird mit Sicherheit nicht berücksichtigt.

Nun ja, es es die Zufahrt zu einer Abstellmöglichkeit für ein Auto. Von daher halte ich das schon für passend. Anders liegt der Fall, wenn über die gleiche Zufahrt auch der Zugang zum eigentlichen Haus erfolgt.

Da ich die Zufahrt zu (einzelnen) Garagen in Straßennähe in der Regel nicht erfasse, stellt sich mir dieses Problem eigentlich nicht. Hingegen benutze ich service=parking_aisle gerne für die Zufahrt zu einer Reihe von Garagen. Diese sind ja oft von den Eingängen zu den Gebäuden getrennt und auch teilweise mit offenen Stellplätzen gemischt.

Edbert (EvanE)

ich glaube fürs erste werde ich bei den betreffenden wegen einfach ein driveway=garage bzw driveway=courtyard dranhängen und ein ticket für mapnik schreiben, dass diese wege dünner bzw ab zoomlevel 16 gar nicht mehr gerendert werden sollen.

Bitte nicht die absolute Lagegenauigkeit in Bezug auf WGS84, mit der Möglichkeit, die Objektgröße halbwegs exakt zu messen verwechseln, denn mein Zollstock, mit dem ich die Wegbreite messe, hat keine Abweichung von 3 Metern.

Mag ja sein, das du oder dir bekannte Projekte das als Grenzwert sehen, aber zumindest sehen das ja schon Leute bei über 10 000 Einträgen etwas anders, und wenn es heute noch nicht ausgewertet wird, dann bestimmt morgen…

Da wirst bei nicht einmal 100 Vorkommen (laut taginfo) wohl kaum auf Gehör stoßen.
Der Effekt ist schlicht, dass es wahrscheinlich weder gerendert noch von Routing-Programmen berücksichtigt wird.

Edbert (EvanE)

Das sind weder meine Grenzwerte, noch Grenzwerte mir bekannter Projekte. Das sind breiten, die von den entsprechenden Fahrzeugklassen noch befahren werden können. Aber denk dir ruhig neue Taggs aus…aber hoffe nicht auf eine Auswertung. Eher wird es komplett aus dem Rendern ausgeschlossen, da es eher störend ist.

Die Breite von breiteren Straßen werden durchaus aus GPS-Daten ermittelt. Eine Schätzung auf 0.5m reicht aber für die meisten Zwecke völlig aus.