Parkbuchten: amenity=parking vs. parking:lane

Für Parkplätze am Straßenrand ist der key parking:lane vorgesehen. Zur Benutzung heisst es in der englischen Wiki:

Geographically reflect exactly where their definitions apply on a street way ... the way should be split precisely where the parallel parking starts and stops ...

In der deutschen Wiki wird dagegen das genaue Gegenteil gefordert:

Es sollte nicht beabsichtigt oder unterstützt werden, dass Straßen an mehreren Punkten entlang des Weges aufgetrennt werden, um so kleine Halteverbote oder Ähnliches definieren zu können.

Davon abgesehen ist es natürlich schon eine ordentliche Schnipselei, wenn man eine Straße, an der in Abständen von 30 Metern Parkbuchten für jeweils 2-4 Fahrzeuge angeordnet sind, entsprechend in Segmente aufteilen will, vor allem, wenn sich linke und rechte Straßenseite nicht entsprechen.

Da ist es von der Arbeit her wesentlich übersichtlicher, die Parkbuchten als Fläche mit amenity=parking zu mappen. Man kann die Flächen sauber darstellen und braucht dann auch nicht diese endlos-tags wie parking:lane:left:parallel=street_side oder parking:lane:right:capacity:disabled=*. Ich würde amenity=parking hier auf jeden Fall favorisieren, es wird aber z.B. von Osmose angemeckert.

Ich bin mir sicher, dass das schon früher mal diskutiert wurde, kann aber kein entsprechendes Topic finden. Wie macht man es denn jetzt am besten?

2. Frage: Hier auf den Dörfern gibt es am Ortsrand öfters neben der Straße bekieste Parkplätze ganz ohne Aufteilung oder spezieller Zufahrt. Man fährt einfach an irgend einer Stelle von der Straße auf den Platz und bleibt dort stehen. Wenn man diese Plätze als area mit amenity=parking mappt, wird von Osmose angemeckert, dass der Platz keine Zufahrt hat. Macht es Sinn, dann eine Zufahrt zu erfinden, auch wenn es eine solche OTG nicht gibt, oder die Fehlermeldung als "Falschmeldung" wegknipsen?