Falsches Kartieren von straßenbegleitenden Parkflächen

Graf Westerholt · 2017-02-05 23:16:28

http://osmand.net/go?lat=50.81179&lon=6.97578&z=19

Diese Parkplätze werden doch mit

https://wiki.openstreetmap.org/wiki/DE:Key:parking:lane

eingetragen und nicht mit

https://wiki.openstreetmap.org/wiki/DE: … ty=parking

Harald Hartmann · 2017-02-06 07:59:55

Die Unterscheidung und Diskussion über richtig oder falsch würde ich nicht führen.
Das Problem hier, wie auch bei vielen anderen Sachen, parking:lane ist halt auf Grund der fehlenden Visualisierung (außer in JOSM, und ehemals parkinglane auf openstreetmap.de) einfach nicht Populär genug, letztendlich ist es aber auch ein Henne-Ei-Problem.

Jo Cassel · 2017-02-06 16:41:25

Die Polygon-Darstellung von Parkflächen ist einfach leistungsfähiger bzw. genauer.
So haben Parkbuchten häufig einen anderen surface als die Fahrbahn,
oft alternieren Parkplätze mit Straßenbegleitgrün wie Bäumen,
mitunter liegt zwischen Fahrbahn und Parkfläche ein Rad- oder Fußweg,
oder ein derartiger Weg verspringt auf der fahrbahnabgewandten Seite um eine Parkbucht ... usw.
Wenn man ernsthaft kleinmaßstäblich arbeitet zeichnet man Parkflächen,
die sich von der Fahrbahn absetzten,
auch als Flächen ein, die sich von der Fahrbahn absetzen - ganz einfach.

kreuzschnabel · 2017-02-06 16:47:55

Graf Westerholt wrote:

https://wiki.openstreetmap.org/wiki/DE:Key:parking:lane

Meine Fresse, wer hat die Seite denn geschrieben? Das ist nicht nur furchtbar getextet, da hat auch einer noch nicht verstanden, was mit :forward bzw. :backward gemeint ist.

--ks

Harald Hartmann · 2017-02-06 16:59:24

kreuzschnabel wrote:

da hat auch einer noch nicht verstanden, was mit :forward bzw. :backward gemeint ist.

Dann schreib uns doch mal, was du denkst, dass derjenige NICHT verstanden hätte? Weil aktuell verstehe ich deinen Einwand nicht. Der Verfasser hat doch plausibel dazu geschrieben, warum nicht forward/backward sondern left/right... und hat das sogar noch verlinkt

kreuzschnabel · 2017-02-06 19:02:34

Harald Hartmann wrote:

kreuzschnabel wrote:
da hat auch einer noch nicht verstanden, was mit :forward bzw. :backward gemeint ist.
Dann schreib uns doch mal, was du denkst, dass derjenige NICHT verstanden hätte? Weil aktuell verstehe ich deinen Einwand nicht. Der Verfasser hat doch plausibel dazu geschrieben, warum nicht forward/backward sondern left/right... und hat das sogar noch verlinkt

Richtig ist, dass :left und :right in diesem Fall einzig sinnvoll sind.

Falsch ist, dass sich :forward und :backward auf die _Fahrtrichtung_ bezögen – noch untermauert durch die Behauptung, dass :backward in einer Einbahnstraße überhaupt keinen Sinn ergäbe. (Gegenbeispiel: Einbahnstraße als oneway=-1 getaggt, dann ergibt _nur_ :backward einen Sinn.)

--ks

Harald Hartmann · 2017-02-06 21:15:31

ohne jetzt zu offtopic zu werden

kreuzschnabel wrote:

...untermauert durch die Behauptung, dass :backward in einer Einbahnstraße überhaupt keinen Sinn ergäbe.

Macht es ja eigentlich auch nicht, wenn man endlich mal den englischen Abschnitt, der eindeutig oneway=yes mit der korrekten "Wegrichtung" empfiehlt auch ins deutsche bringen würde.

Aber zurück zum eigentlich Thema: beides ist definitiv kooexsistent, das eine (parking:lane) ist eher wie highway abstrakter Natur, parking-Flächen analog zu area:highway dann eben für Micro-/Detailmappings

geri-oc · 2017-02-07 08:35:34

Dann einmal auf diesen Note klicken:
http://osm.org/go/0NGAY2p98--?layers=N

Wenn sich jemand vor Ort für "eine "Mappingart" entscheidet, sollte man es auch akzeptieren.

Mir ging es vor Jahren so - da wurde auf die parking:lane=* verwiesen. Wenn man aber sieht, was und wie viele Schlüssel heute an einem hw hängen, ist mir das auch etwas zu abstrakt (- und trotzdem mache ich es "teilweise" so ...).

Jo Cassel · 2017-02-07 13:39:48

geri-oc wrote:

Dann einmal auf diesen Note klicken:
http://osm.org/go/0NGAY2p98--?layers=N
Wenn sich jemand vor Ort für "eine "Mappingart" entscheidet, sollte man es auch akzeptieren.
Mir ging es vor Jahren so - da wurde auf die parking:lane=* verwiesen. Wenn man aber sieht, was und wie viele Schlüssel heute an einem hw hängen, ist mir das auch etwas zu abstrakt (- und trotzdem mache ich es "teilweise" so ...).

Ja, da sieht man gut, wie erst die Parkflächen-Darstellung die räumliche Situation (Standort des Straßenbegleitgrüns, Lage der Fußwege) klärt und erfahrbar macht - schwer vorstellbar, vergleichbares durch Straßentagging zu erreichen.

Erschreckend (nicht nur aus Sicht des Mappers der vor 3 Jahren die Arbeit investierte) ist die Reaktion des Publikums:
Der Erste will gleich wieder abreißen, der Zweite macht sich lustig und offenbart dabei nur, dass er sich mit der Arbeit des Mappers gar nicht beschäftigt hat: Dieser hatte die capacity der Flächen nämlich schon 2 Jahre vorher eingetragen.

Chrysopras · 2017-02-07 15:00:36

Generell gibt es einen zunehmenden Trend zum immer genaueren Mapping (das muss noch nicht mal Micromapping i.e.S. sein). Das hat auch einfach mit den besseren Luftbildern u.a. Quellen zu tun. Während „früher“ parking:lane=* sicher mehr als ausreichend war, kann es heute, da mehr und mehr auch Straßenbäume, Straßenlaternen, Mülleimer u.a. Details im Straßenraum gemappt werden, durchaus sinnvoll sein, straßenbegleitende Parkflächen als Flächen zu mappen. Das ist doch etwas Ähnliches wie die Gehsteige/Bürgersteige/Trottoirs: Manche halten die Wiedergabe durch Tags an der Straße immer noch das Beste, aber auch das separate Mapping mit eigenen highway=footway, footway=sidewalk hat seine Vorteile.

Also lassen wir doch den Dogmatismus in der Schublade! Es gibt, wie so oft in OSM, keine „reine Lehre“, an die sich alle halten müssten; und auch was im Wiki steht und was nicht, ist nur von Menschen geschrieben. Am besten lassen wir in allen diesen Fällen beide Möglichkeiten zu. Wichtig sind doch nur zwei Dinge:

1) Wie auch immer man es macht, es muss richtig gemacht sein – z.B. sollte bei separatem Mapping der Bürgersteige das Zusatztag footway=sidewalk nicht fehlen, das erlaubt es den Renderern, Bürgersteige wegzulassen bzw. erst in höheren Zoomstufen darzustellen. (1)

2) Entlang einer Straße, noch besser: innerhalb eines Wohngebietes oder Viertels sollte am besten jeweils nur eine der Möglichkeiten konsequent angewendet werden. Wenn man Parkflächen mit parking:lane=* und separat gemappt einträgt, oder beides direkt nebeneinander abwechselnd, verwirrt das nicht nur andere Mapper, sondern macht auch den Datenauswertern das Leben unnötig schwer; am Ende werden die Parkflächen dann vielleicht doppelt gezählt.

Jo Cassel wrote:

Erschreckend (nicht nur aus Sicht des Mappers der vor 3 Jahren die Arbeit investierte) ist die Reaktion des Publikums:
Der Erste will gleich wieder abreißen, der Zweite macht sich lustig und offenbart dabei nur, dass er sich mit der Arbeit des Mappers gar nicht beschäftigt hat: Dieser hatte die capacity der Flächen nämlich schon 2 Jahre vorher eingetragen.

Genau das – Streit und gegenseitiges Löschen – sollte es nicht geben.

(1) Ob die Renderer bzw. Kartenstile das wirklich endlich mal umsetzen, ist nicht mein Problem, dafür bitte an die Betreuer der Renderer und Kartenstile wenden.

Last edited by Chrysopras (2017-02-07 15:04:00)

Graf Westerholt · 2017-02-17 07:03:15

Und was ist, wenn man nach einen Parkplatz sucht, z.B. in OsmAnd~ (bietet es an, wenn man am Ziel angekommen ist) und an jeder Straße entlang ist ein Parkplatz eingetragen und die werden alle als Möglichkeit angezeigt? Dann ist die Funktion nicht mehr hilfreich. Daher sehe ich es nicht zielführend, straßenbegleitende Parkflächen als Parkplatz einzutragen. Man darf nicht nur an die grafische Darstellung denken, sondern muss auch an Anwendungen denken und was die Folgen davon sind. Abgesehen davon wird es auch auf einer Karte nicht hilfreich und übersichtlich sein, wenn neben den meisten Straßen Parkflächen gerendert werden. Vielleicht ist das der Grund, warum parking:lane=* nicht dargestellt wird.

hfst · 2017-02-17 07:23:51

Graf Westerholt wrote:

Und was ist, wenn man nach einen Parkplatz sucht, z.B. in OsmAnd~ (bietet es an, wenn man am Ziel angekommen ist) und an jeder Straße entlang ist ein Parkplatz eingetragen und die werden alle als Möglichkeit angezeigt? Dann ist die Funktion nicht mehr hilfreich.
(...)

Mit fortschreitendem Microtagging werden Applikationen lernen müssen zu generalisieren.

Edit: Quote gekürzt

Last edited by hfst (2017-02-17 10:14:03)

Graf Westerholt · 2017-04-02 05:26:14

Wie wäre es, wie schon wohl teilweise gemacht, straßenbegleitende Parkplätze nicht mit dem Tag für große Parkplätze (amenity=parking) zu taggen, sondern mit amenity=parking_lane? Das kann ja auch auf Karten dargestellt werden, aber das von mir in Post #11 beschriebene Problem würde man damit lösen.

Tordanik hat dazu etwas passendes geschrieben:

https://forum.openstreetmap.org/viewtop … 33#p639433

chris66 · 2017-04-02 06:47:52

Naja, Tordanik schrieb dass man das eben nicht machen sollte, da zB GIS Auswertungen wie "wieviel Prozent der Wohnstraßen haben Parkstreifen" viel schwieriger sind.

geri-oc · 2017-04-02 08:03:03

Mappen wir für

chris66 wrote:

GIS Auswertungen ... "wieviel Prozent der Wohnstraßen haben Parkstreifen"

Wir sollten uns an Daten wie sie vor Ort zu finden sind orientieren - Spezialfälle abstrahieren können die Auswerter.

Chrysopras wrote:

Während „früher“ parking:lane=* sicher mehr als ausreichend war, kann es heute, da mehr und mehr auch Straßenbäume, Straßenlaternen, Mülleimer u.a. Details im Straßenraum gemappt werden, durchaus sinnvoll sein, straßenbegleitende Parkflächen als Flächen zu mappen.

+1

Ich möchte auch noch auf die dazugekommen "Detail-Erweiterungen" an den highways selbst hinweisen z.B. lanes, surface, width, ...

scai · 2017-04-02 08:49:48

geri-oc wrote:

Mappen wir für
chris66 wrote:
GIS Auswertungen ... "wieviel Prozent der Wohnstraßen haben Parkstreifen"
Wir sollten uns an Daten wie sie vor Ort zu finden sind orientieren - Spezialfälle abstrahieren können die Auswerter.

Ist die Auswertung von OSM-Daten nicht schon kompliziert genug? Man kann nicht unendlich viel Magie und Glaskugellesen in die Auswerter stecken. https://www.openstreetmap.org/way/463858784 ist als normaler Parkplatz getaggt, woher soll der Auswerter wissen dass es sich um einen straßenbegleitenden Parkplatz handelt? Nur weil er parallel zu einer Straße verläuft? Das kann auch bei einem regulären Parkplatz der Fall sein. Ein Renderer hat das gleiche Problem. Würden wir alle straßenbegleitenden Parkplätze als amenity=parking einzeichnen dann würde die Karte aus lauter Ps bestehen.

Ich finde die Geometrie bei straßenbegleitenden Parkplätzen äußerst uninteressant. Daher bin ich dafür, diese mittels parking:lane einzutragen. Auch das Argument über die Oberflächenbeschaffenheit greift hier nicht, diese könnte man beispielsweise via parking:surface:both bzw. left/right eintragen. Das wäre analog zu sidewalk und cycleway, würde also zu den restlichen Daten passen.

OpenStreetMap soll eine Karte für möglichst viele sein. Daher müssen wir immer sowohl die Editierbarkeit/Verständlichkeit als auch die Auswertbarkeit der Daten im Auge behalten. Es nützt nichts eine Karte zu haben die sich leicht editieren lässt aber schlecht auswertbar ist. Andersherum nützt eine schwer zu editierende Karte natürlich auch niemandem.

Last edited by scai (2017-04-02 09:12:58)

Reclus · 2017-04-02 12:33:16

Wie sollen die straßenbegleitenden Parkflächen denn jetzt taggt werden, wenn man sie als Fläche mappen will?

Ich habe sie in meiner Stadt vor kurzem von amenity=parking zu amenity=parking_lane umgetaggt. Eine andere Möglichkeit wäre amenity=parking & parking=lane. parking=lane scheint wesentlich populärer zu sein als amenity=parking_lane.

geri-oc · 2017-04-02 15:21:30

scai wrote:

...
https://www.openstreetmap.org/way/463858784 ist als normaler Parkplatz getaggt, woher soll der Auswerter wissen dass es sich um einen straßenbegleitenden Parkplatz handelt?
...

http://files.homepagemodules.de/b563523 … uhNgsE.jpg

1. sehe ich den Parkplatz (als amenity=parking) nicht richtig (detailiert) gemappt. Er verläuft direkt an der Straße (und wie es aussieht auch linksseitig der Straße).

Also müsste der rechte
amenity=parking
parking=lane
lane=perpendicular
....
und der linke
amenity=parking
parking=lane
lane=parallel
....
sein. Wichtig ist m.E. auch noch das access=* und eventuell Zeitbegrenzung.

2. Könnte es eine amenity=parking_lane sein, WENN das eben dann auf der "Karte" erscheint - entweder kein Parkplatz oder alle Parkplätze. Und Parkräume sind heute innerstädtisch ein Problem. Da bin ich froh, wenn ich einen Parkplatz auf der Nebenstraße finde (ob straßenbegleitend oder extra), der ordentlich als begrenzter Zeit-Parkplatz oder privat (Anwohner) ausgewiesen ist.

3. Ich bin für die detaillierte Version 1 (habe aber selbst auch welche als amenity=parking_lane. eingetragen). Am hw sollten die Tags, die die Straße betreffen und das sind nicht wenige (bei detaillierter Erfassung).

Tordanik · 2017-04-02 16:19:01

scai wrote:

Ist die Auswertung von OSM-Daten nicht schon kompliziert genug? Man kann nicht unendlich viel Magie und Glaskugellesen in die Auswerter stecken.

Danke! Ich bin ja durchaus der Meinung, dass es sich Auswerter nicht zu beqem machen sollten (siehe z.B. meine Meinung zu Gebäuderelationen), aber es gibt eben einen Unterschied zwischen Information, die man mit etwas Aufwand berechnen kann, und Information, die schlicht und einfach nicht in den Daten drin steckt und bestenfalls erraten werden kann.

Man muss auch nicht mal zu statistischen Auswertungen schauen, um Probleme bei der Auswertung zu finden. Beispielsweise definiert das parking:lane-Taggingschema ja auch Tags dafür, ob quer, diagonal oder parallel zur Straße geparkt wird. Um das z.B. fürs Rendering sinnvoll zu nutzen, braucht man aber wieder den Zusammenhang zur zugehörigen Straße.

Die Diskussion um andere Tags für die Flächen geht von daher auch ein bisschen am Kernproblem vorbei. Die Tags können zwar die Information wiedergeben, dass es sich um einen straßenbegleitenden Parkplatz handelt (was schon mal besser ist als ein bloßes amenity=parking), aber welche Straße denn nun begleitet wird, bekommt man allein mit Tags an einer separaten Geometrie nicht ausgedrückt.

geri-oc · 2017-04-02 16:47:46

Tordanik wrote:

aber welche Straße denn nun begleitet wird, bekommt man allein mit Tags an einer separaten Geometrie nicht ausgedrückt.

Ich bin zwar kein "Auswerter" - aber allein das teilen zweier nodes mit dem hw kann doch als "Bezug" des Platzes zur Straße genutzt werden - z.B. straßenbegleitend zum Südermannweg.
Ist er nicht mit dem hw verbunden sondern über einen Parkplatzweg angeschlossen ist er nicht straßenbegleitend

Wir sollten die Daten eintragen wie in der Wirklichkeit vorhanden. Und da ist der Eckpunkt des Parkplatzes ... m vom Schnittpunkt mit der Straße entfernt (und hat somit andere Koordinaten).

Das ist beim taggen an den hw nicht der Fall, weil ich eine Fläche mit einem Tag an einem Way darstellen soll.
Wenn die Straßen als Fläche getaggt werden, wie tragen wir dann die "Parkstreifen-Flächen" ein?

Tordanik · 2017-04-02 17:12:18

geri-oc wrote:

Ich bin zwar kein "Auswerter" - aber allein das teilen zweier nodes mit dem hw kann doch als "Bezug" des Platzes zur Straße genutzt werden - z.B. straßenbegleitend zum Südermannweg.

Das Teilen von Nodes würde wohl in der Tat ermöglichen, den Zusammenhang wieder zu ermitteln. Allerdings hatte ich bisher den Eindruck, dass es Ziel des Flächenmappings sei, die Geometrie der Stellplätze so abzubilden, wie sie in der Realität ist. Wenn die Fläche künstlich bis zur Straßenmitte verlängert wird, ist das ja nicht mehr der Fall?

Wenn die Straßen als Fläche getaggt werden, wie tragen wir dann die "Parkstreifen-Flächen" ein?

Beim area:highway-Tagging soll die Straßenfläche ja den Way nicht ersetzen, sondern zusätzlich eingetragen werden. So würde ich das auch mit dem Parkstreifen handhaben:

1. Zum einen gibt es den Straßenway, an dem mit parking:lane und den Subtags die Informationen zum Parkstreifen getaggt werden.

2. Zusätzlich kann die Straßenfläche als area:highway und innerhalb der Straßenfläche auch noch eine Fläche für den Parkstreifen gemappt werden. Durch die umschließende Straßenfläche ist dann auch die Zuordnung wieder möglich.

Das hieße: Parkstreifenflächen-Mapping ginge nur, wenn auch die Straße schon als Fläche gemappt ist.

Wenn unser Ziel ist, das Flächenmapping und die Semantik unter einen Hut zu bringen, wäre das zumindest mal eine eindeutig auswertbare Lösung, die zudem auch rückwärtskompatibel ist (d.h. man kann die Flächen ignorieren und weiter nur den Way auswerten, ohne dass Information verloren geht). Damit könnte ich mich durchaus anfreunden.

Reclus · 2017-04-02 17:29:28

In meiner Stadt sind die straßenbegleitenden Stellflächen oft insofern von der Straße getrennt, dass sie Pflastersteine als Oberfläche haben (statt Asphalt) und durch Baumbeete und Fußgängerüberwege durchschnitten werden. Sie wirken wie Einbuchtungen im Bürgersteig. Ich würde diese Parkflächen nicht als Teil der Straße ansehen.

Last edited by Reclus (2017-04-02 18:15:14)

geri-oc · 2017-04-02 18:53:44

Tordanik wrote:

Wenn die Fläche künstlich bis zur Straßenmitte verlängert wird, ist das ja nicht mehr der Fall?

Weil die Straße als Linie gemappt wird - historisch bedingt. Mappen wir als Straße die Straßenfläche wird ja wiederum abstrahiert die Mittellinie (für Routing?) benötigt.

Was bringe ich den alles unter an der Mittellinie der Straße?

lane, surface, widht, ... sind alles keine Liniebeschreibungen sondern die Beschreibung einer "Fläche" - abstrahiert. Mittlerweile wird aber mehr detailliert. Und ich finde das auch gut.

Das ist nun in OSM so, das es "gemischte Daten" gibt. Und wenn jemand eine Straßenzuordnung der Parkstreifen benötigt (warum?) kann er es m.E. aus den "gemischten" Daten ableiten, falls sie "richtig" eingetragen sind.

Ein Problem ist auch immer die Darstellung in Mapnik - welches als Hauptkarte angesehen wird. Ich kann nicht einen Parkplatz anzeigen und einen Parkstreifen nicht.

Yokr · 2017-04-02 21:59:24

Liegt aber bspw. auch einfach an den Editoren dass es schwierig ist das zu editieren. Wenn man bspw. in JOSM die einzelnen Tags nach bestimmten Kriterien aufteilen und übersichtlicher anzeigen würde, dann könnte man es auch leichter editieren. Ich lade also ein paar Daten runter und dann lasse ich mir nur die Parkplatz-Tags anzeigen und kann diese dann einfach editieren. Das wäre denke ich auch schone eine große Hilfe.

Graf Westerholt · 2017-04-03 06:57:11

geri-oc wrote:

Wir sollten uns an Daten wie sie vor Ort zu finden sind orientieren – Spezialfälle abstrahieren können die Auswerter.

Das ist eine sehr eingeschränkte Sichtweise. Das berücksichtigt weder das Ziel von OSM noch dass die Daten dargestellt und ausgewertet werden müssen; die Daten sollen ja auch verwendet werden, nicht nur eingetragen.

Wie sinnvoll ist es, Straßenlaternen, Bäume, Mülleimer … einzutragen? OSM hat ja einen Zeck, vor allem eine Karte zu sein, mit der man sich orientieren kann, und die Daten für Routenplaner verwendet werden können. Man sollte nichts machen, was kontraproduktiv ist. OSM ist nicht einfach dafür da, ALLES bis auf das letzte Detail einzutragen. Es soll keine detailgetreue Abbildung der Realität sein, eher eine Abstraktion. Man trägt ja nicht jeden Stein eines Weges einzeln ein, sondern den Weg. Bei Straßenlaternen kann man am Weg auch einfach eintragen, dass der Weg beleuchtet ist; zum Orientieren und Navigieren sind die Straßenlaternen nicht wichtig. Möchte man allerdings eine 3D-Darstellung, könnte man die schon anzeigen, also ein Eintrag ist nicht kontraproduktiv, er muss ja nicht auf der Slippy Map dargestellt werden, kann dann aber in einer 3D-Darstellung angezeigt werden.

Wenn alle fünf Meter Mülleimer stehen, wird auch niemand, der einen Mülleimer sucht, erst auf eine OSM-Karte schauen, wo ein Mülleimer steht, sondern einfach den nächsten nehmen, dann braucht man keine Mülleimer einzutragen, ebenso bei Bänken. Allerdings habe ich schon mal in OsmAnd nach einem Mülleimer gesucht, als ich in einem Park keinen gesehen habe und habe dann auch einen eingetragen. Man sollte nicht einfach platt sagen, dass man einträgt, was vorhanden ist.

scai wrote:

Würden wir alle straßenbegleitenden Parkplätze als amenity=parking einzeichnen dann würde die Karte aus lauter Ps bestehen.

Daten müssen es auch ermöglichen, dass sie von Programmen verwendet werden, daher muss man sich überlegen, wie man es taggt, so dass es von Programmen möglichst einfach verwendet werden kann, denn je komplizierter, desto länger dauert die Bearbeitung durch die Programme und desto weniger haben Programmierer Lust, das zu berücksichtigen.

Trägt man straßenbegleitende Parkplätze anders als große, eigenständige Parkplätze, können Programme sie unterscheiden und nur bei Bedarf anzeigen.

geri-oc wrote:

Und Parkräume sind heute innerstädtisch ein Problem. Da bin ich froh, wenn ich einen Parkplatz auf der Nebenstraße finde (ob straßenbegleitend oder extra), der ordentlich als begrenzter Zeit-Parkplatz oder privat (Anwohner) ausgewiesen ist.

Das können Programme natürlich auch mit parking:lane=*

Mir ist es egal, ob straßenbegleitende Parkplätze mit parking:lane=* oder amenity=parking_lane eingetragen werden, es sollte nur nicht identisch mit eigenständigen, großen Parkplätzen sein. amenity=parking und parking=lane sind vermutlich beliebter, weil sie dann dargestellt werden (was mappen für den Renderer wäre).

Ich möchte noch mal auf das Problem aufmerksam machen, dass OsmAnd bei Erreichung des Ziels eine Parkplatzliste anzeigt. Wenn an der Straße nun jeder Stellplatz mit amenity=parking einzeln eingetragen ist, sind das sehr viele Parkplätze, welche in der Liste von OsmAnd stehen, welche man dann aus dem Auto auch sowieso direkt sieht. Die Funktion von OsmAnd ist ja sinnvoll, aber sie wird kaputt gemacht, wenn man straßenbegleitende Stellflächen einzeln mit amenity=parking taggt.

Nebenbei:

geri-oc wrote:

Tordanik wrote:
Wenn die Fläche künstlich bis zur Straßenmitte verlängert wird, ist das ja nicht mehr der Fall?
Weil die Straße als Linie gemappt wird – historisch bedingt. Mappen wir als Straße die Straßenfläche wird ja wiederum abstrahiert die Mittellinie (für Routing?) benötigt.

Man kann auch die Breite der Straße mit width=* angeben, leider kenne ich keine Karte, welche das width=* berücksichtigt.

Und Mapnik ist keine Karte, sondern eine Software, welche verschiedene Karten, die Slippy Maps, generiert:

http://wiki.openstreetmap.org/wiki/Mapnik

Announcement

#1 2017-02-05 23:16:28

Falsches Kartieren von straßenbegleitenden Parkflächen

#2 2017-02-06 07:59:55

Re: Falsches Kartieren von straßenbegleitenden Parkflächen

#3 2017-02-06 16:41:25

Re: Falsches Kartieren von straßenbegleitenden Parkflächen

#4 2017-02-06 16:47:55

Re: Falsches Kartieren von straßenbegleitenden Parkflächen

#5 2017-02-06 16:59:24

Re: Falsches Kartieren von straßenbegleitenden Parkflächen

#6 2017-02-06 19:02:34

Re: Falsches Kartieren von straßenbegleitenden Parkflächen

#7 2017-02-06 21:15:31

Re: Falsches Kartieren von straßenbegleitenden Parkflächen

#8 2017-02-07 08:35:34

Re: Falsches Kartieren von straßenbegleitenden Parkflächen

#9 2017-02-07 13:39:48

Re: Falsches Kartieren von straßenbegleitenden Parkflächen

#10 2017-02-07 15:00:36

Re: Falsches Kartieren von straßenbegleitenden Parkflächen

#11 2017-02-17 07:03:15

Re: Falsches Kartieren von straßenbegleitenden Parkflächen

#12 2017-02-17 07:23:51

Re: Falsches Kartieren von straßenbegleitenden Parkflächen

#13 2017-04-02 05:26:14

Re: Falsches Kartieren von straßenbegleitenden Parkflächen

#14 2017-04-02 06:47:52

Re: Falsches Kartieren von straßenbegleitenden Parkflächen

#15 2017-04-02 08:03:03

Re: Falsches Kartieren von straßenbegleitenden Parkflächen

#16 2017-04-02 08:49:48

Re: Falsches Kartieren von straßenbegleitenden Parkflächen

#17 2017-04-02 12:33:16

Re: Falsches Kartieren von straßenbegleitenden Parkflächen

#18 2017-04-02 15:21:30

Re: Falsches Kartieren von straßenbegleitenden Parkflächen

#19 2017-04-02 16:19:01

Re: Falsches Kartieren von straßenbegleitenden Parkflächen

#20 2017-04-02 16:47:46

Re: Falsches Kartieren von straßenbegleitenden Parkflächen

#21 2017-04-02 17:12:18

Re: Falsches Kartieren von straßenbegleitenden Parkflächen

#22 2017-04-02 17:29:28

Re: Falsches Kartieren von straßenbegleitenden Parkflächen

#23 2017-04-02 18:53:44

Re: Falsches Kartieren von straßenbegleitenden Parkflächen

#24 2017-04-02 21:59:24

Re: Falsches Kartieren von straßenbegleitenden Parkflächen

#25 2017-04-03 06:57:11

Re: Falsches Kartieren von straßenbegleitenden Parkflächen

Board footer