Parkeren in residential area

Nu met BGT op komst en andere voorbeelden de laatste tijd op het forum.

Waarbij vooral amenity=parking word gebruikt, resulterend in vele kleine vakjes met een blauwe P.

Hoe maken we het onderscheid tussen een parkeerplein en parkeren in residential omgeving.

Ik heb al eens iemand aangesproken, die al deze residential parkeervakjes aan het deleten was, om de reden dat hij vond dat deze parkeerplaasten niet voor algemeen gebruik waren en op de osm.org kaart niet aangegeven moest worden met een blauwe P.

parking
amenity=parking

Je hebt ook amenity=parking_space voor de enkele parkeerplaasten

Gaan we deze vlakken ook aangeven als area:highway=parking, lijkt mij wel, dit zou mijn eerste tagstap zijn nu, en de rijbanen op een parkeerplein als area:highway=service service=parking_aisle. (Parkeerplaats bij een bedrijf is service=driveway) Het geheel als amentiy=parking. Dit op een relatie.

Maar hoe het aangeven van het residential kararkater in deze residential area’s, voor mij hoort daar geen blauwe P te staan, er staan ook geen verkeersborden met een P.

Je kan geen access gebruiken http://wiki.openstreetmap.org/wiki/Proposed_features/parking#General_tags, want er is geen verbod.

De herkenbaarheid van grote parkeerpleinen bij centra’s van gebouwen of detail.
Hoe dit te regelen?
Het zal in de tagcombinatie naar voren moeten komen.
Of toch *=parking parking=residential (als de weg ook residential is?)

Je wilt in je routering progje zien waar je echt kan parkeren.

Die parkeergelegenheden in residential worden hoofdzakelijk gebruikt door bewoners en bezoekers van die straat. maar verboden is het niet.

Ik had hier een P staan, een groot amenity parkeerplaats getekend.
http://www.openstreetmap.org/#map=19/52.62578/6.03041
Nu is dat verandert in vier parkeervakken met ieder zijn eigen P. Vier vakken op zich geen probleem, maar dan moet de rest ook bijgewerkt worden.
In de wiki staat dat dit samengevoegd moet worden in een relatie, zodat 1 P komt te staan.

Hier is de binnen de grote amenity kleine parkeervlakken ingetekend met hun eigen P.
http://www.openstreetmap.org/#map=19/52.62489/6.03304
Het merendeel van deze P’s zijn wat mij betreft onterecht. Waar de eigenlijke vraag over gaat hoe dit op te lossen. Welke tagcombinatie?
http://www.openstreetmap.org/#map=17/52.61898/6.03454

Voor mij horen in de toekomst de residential parkeervlakken aangeven te worden met
area:highway=parking eventueel parking=residential

als amenity=parking word gebruikt. (na melding)

1. Osmose zet hele areas vol met foutmeldingen: “Missing access to parking”.
   (Als wegen niet zijn verbonden met de parking areas).

Ook osmose zal nog een vertaalslag moeten maken als area:highway=parking meer word gebruikt.
zo ook bij area:highway=service service=parking_aisle, wegen als vlak ingetekend.

Wanneer het om aangegeven parkeerplaatsen gaat (met bord), kan het samengevoegd worden tot amenity=parking

Er is de nu in gebruikt zijnde methode;

parking:lane:right = parallel
Met alle andere varianten.
http://wiki.openstreetmap.org/wiki/Key:parking:lane
Maar hiermee kan je geen vlakken taggen, wat we steeds meer gaan doen.
Dit is een routeringslijn methode.
Nadeel van deze methode is het opknippen van de weg. Vooral bij veel wisselingen.

Een mapper bij mij in de buurt heeft dat probleem - deels - opgelost door name=bewoners te gebruiken om op de kaart bij visuele inspectie direct zichtbaar te maken dat je daar niet mag parkeren als je geen bewoner bent.
Tevens heeft hij access=private gebruikt om te voorkomen dat parkeerapps die zoeken naar beschikbare parkeerplaatsen je ernaartoe sturen.

Hier is een voorbeeld van zo’n situatie.

Strict genomen is die access tag niet juist, want er staat geen bord dat die toegang verbiedt. Bovendien is het voorbeeld hierboven ook nog eens een parkeerplaats met garageboxen en geen feitelijke openbare parkeerplaats, alhoewel er door de bewoners ook op dat plein wordt geparkeerd en iedereen er wel mag/kan komen.

@Allroads, “Maar hoe het aangeven van het residential karakter in deze residential area’s, voor mij hoort daar geen blauwe P te staan, er staan ook geen verkeersborden met een P.” Dat valt bv bij erven onder de regels, slechts daar waar een vak is Bedoel je met relaties een kader om het gehele vlak, ik kan in de Wiki niets over de onderlinge relaties vinden of is de buitenrand dan de relatie ?
Maar met het oog op alle genoemde details, “we mappen toch wat er is” dan map je toch een parkeerplaats eventueel met de restricties als private of fee. Maar ga je niet manipuleren met wat er is of niet is ? Als de bewoners klagen wordt het een Blauwe Zone of permissive met Fee.

Creatief bedacht maar dit is natuurlijk geen oplossing maar een mooi staaltje tagging for the renderer. Welke buitenlander snapt wat hier bedoeld wordt? Een name is een naam en niet anders. Als je wilt dat een renderer iets niet/anders weer zou moeten geven probeer je dat bij de renderer te regelen en niet door foute tagging in de database. Dit zou m.i. verwijderd moeten worden.

En als jij hier rond rijdt als buitenlander dan weet je het wel?

Terug naar Vught.
Buitenlanders komen op deze plek echt niet, en iedere Nederlander weet wat “bewoners” betekent.
Het gebruik van de name=* tag is in dit geval een duidelijke, creatieve oplossing, maar misschien niet helemaal volgens de regels.
Ik zal de mapper in kwestie van deze discussie op de hoogte stellen.

Das een beetje flauw Marc. Ik heb het helemaal niet over verschillen in character set (latin, chinees etc.) maar over het gegeven dat een buitenlander verwacht dat “bewoners” de naam van de parkeerplaats is. Zo zal die waarschijklijk ook gerenderd worden en te vinden zijn in zijn ofline OSM navigatie app. Ze hebben dan echt geen idee dat er hier getagd is voor de renderer om aan te geven dat het een bewonersparkeerplaats is.

Overigens biedt die name tag ook nog allerlei varianten zoals name:en die het voor mij mogelijk zouden maken om met bv Osmand in china naar de Mao-parkeerplaatst te gaan.

Maar de parkeerplaats is ook aangemerkt als “private” en ik durf te wedden dat die buitenlanders dit op hun smartphone hebben staan:

Overigens zou je ipv. de name=bewoners tag, ook kunnen taggen met description=alleen voor bewoners .

===
Edit: description idee toegevoegd.

Deze verkeerde manier van taggen is hetzelfde als onlangs passseerde: Een bochtige weg een lagere max. snelheid toekennen dan aangegeven door de verkeersborden.
Wanneer er geen parkeerverbod is - dat binnenpleintje buiten beschouwing gelaten - kan geen enkele bewoner een parkeerplaats opeisen. Hoe vervelend het ook is wanneer forensen in jouw woonwijk parkeren.
De toevoeging, naam of description “alleen voor bewoners” is echt uit den boze.

Wel ben ik het er mee eens dat niet elk parkeervak langs een weg als parkeergelegenheid aangeduid hoeft te worden.

http://www.openstreetmap.org/#map=19/52.62578/6.03041
Deze vier vakken als relatie opvoeren dan komt er, 1 P te staan.
Uit wiki.

http://wiki.openstreetmap.org/wiki/Proposed_features/parking

In Marc zijn voorbeeld zijn alle drie de tags onzin.

Maar wel als parkeervak.

Daar denkt men hier anders over:

http://wiki.openstreetmap.org/wiki/Key:description

Daar zie ik toch een heleboel vergelijkbare soorten van informatie staan.

@Marc:
Natuurlijk mag je onder description alles toevoegen.
Wat ik bedoel is dat mappers of bewoners niet uit kunnen maken waar je mag parkeren. De term “alleen voor bewoners” mist elke grondslag.

Zulke garages zijn niet bewoond, meestal worden ze verhuurd of kent eigenaren, ik ken genoeg gevallen, waarbij de huurder/eigenaren niet eens in de buurt woont. Vandaar een adres op het gebouw/garage.

Laatst nog een gesprek, iemand had een garagebox gekocht en parkeerde daar overdag zijn auto in en werkte zelf in de plaatselijke supermarkt. Na zo veel keer met lege banden te hebben gestaan, kom je met zulke oplossingen.
Vervellende ettertjes.

De tekst alleen voor bewoners slaat nergens op.

In staphorst hebben we ook meerdere P’s ik heb ze in relatie geplaats maar krijg nog geen 1 P. Kan iemand hierbij helpen. http://www.openstreetmap.org/relation/5912709

Ik heb een nieuw vlak gemaakt die de andere parkeervakken insluiten. Nu wel 1P. Geen mooie oplossing voor alle parkeer situaties. http://www.openstreetmap.org/relation/5912709

Ik tag gewoon een heel parkeerterrein als amenity=parking. Daar lopen dan de highway=service=parking_aisle doorheen (wel met een gemeenschappelijke node op de rand). Meer ga ik er niet aan doen.

Ik vind het ook niet leuk als mensen op “mijn” parkeerterrein parkeren, al weet ik wel dat ik op vrijdagavond en zondag niet terug moet komen want dan staat het hier vol vanwege het naburige kerkgebouw. Af en toe is het sneller om de bus te nemen naar mijn auto dan te lopen.

Maar ik ga het parkeerterrein niet taggen als “oprotten als je hier niet woont”, want dat is niet wat er staat, en bovendien heeft de gemeente bewust voor geen overschot aan parkeerplaatsen gekozen.

Op mijn werk is het anders: daar heb ik alle parkeerterreinen met access=private getagd omdat het terrein een bordje “verboden toegang voor onbevoegden” heeft. En daar zijn verschillende parkeervakken, omdat 1 voor bussen en de andere voor auto’s bedoeld is.

Je moet de site wel de tijd geven om iets te renderen, het duurt een paar dagen voordat iets goed zichtbaar wordt, in alle lagen.

@ gerrit, de tweede manier vindt ik niet correct, extra vlak, het is dubbel.

Ondertussen verdiepen we ons alle in de meer gedetailleerde intekening van parkeervakken, “mogelijk” (zeker is dit nog niet), wat straks uit de BGT gebruikt mag worden. Dit is een van de problematieke, waar we tegen aan gaan lopen. Zo ook ik, want zo’n gedetailleerde intekening heb ik ook nog niet gedaan.

lees wel het volgende
http://wiki.openstreetmap.org/wiki/Proposed_features/parking#Site_relation

Het zou best kunnen, dat de rendering nog niet goed werkt. Een zaak van de render, niet van ons om het anders te gaan tekenen.
Zie nog geen goede voorbeelden met 1 P, op basis van deze tag strategie, zonder amenity op node of way.
http://overpass-turbo.eu/s/e2b
Laat zien dat het nog niet veel wordt toegepast. En daar ook warrige constructies.
Relaties heeft een behoorlijke leercurve.

Nu heb ik volgens de wiki de relatie gisteren getagd, maar op de kaart is er nu niks te zien.
Je zou verwachten dat de twee vlakken geel en 1 P in het midden zou hebben. Niet dus.
Dit is een relatie met de extra tag amenity=parking, wat in principe niet nodig zou moeten zijn.
De render volgt hier niet de mogelijkheden van de wiki, wat op status approved staat.
changeset:
https://www.openstreetmap.org/changeset/36846260
relatie:
https://www.openstreetmap.org/relation/5912895
individual ways hebben geen tags.

nu een issue aangemaakt, voor betere rendering:
https://github.com/gravitystorm/openstreetmap-carto/issues/2032

en dan is het duidelijk, we moeten geduld hebben.

Dus ik laat het voorbeeld staan, want de tagging is goed.