Bij parkeervakken kun je / word je geacht capaciteit op (te) geven.
Dat kan zelfs handig zijn voor gebruikers, al kan ik me nauwelijks voorstellen dat daarvoor de kaart wordt gebruikt ipv. visueel naar dat ene vrije plekje te speuren.
Probleem zijn de uitzonderingen: gereserveerd voor gehandicapten, gereserveerd voor EV.
Ik heb geen afspraken kunnen vinden, hoe die in te vullen.
Voorbeeld uit de buurt:
1 strook met parkeervakken parallel. 6 vakken totaal. 1 vak daarvan voor gehandicaptenparkeerplaats op kenteken. Dat zou ik dan aangeven als 5 vakken totaal, maar waarvan 1 vak gehandicapten algemeen.
Moet ik dat dan aangeven als 4 vakken + 1 vak gereserveerd? (de boetes vóórdat de auto wordt weggesleept zijn niet mals).
Volgende blok, een parkeerhaven met 3 plekken. Maar ook een laadpaal voor twee daarvan. Is dat dus capacity=1 capacity:charging=2 of moet ik die EV-plekjes van het totaal aftrekken?
Het totaal aantal vakken verandert vrijwel nooit, maar de hoeveelheid laadpalen verandert aan de lopende band.
Constant het verschil aanpassen leidt dus tot dubbele administratie; het totaal aanhouden leidt tot een vertekend beeld van de beschikbare parkeercapaciteit.
Individuele parkeerplaatsen hoef je geen capacity te geven, want dat is doorgaans 1, maar je bedoelt parkeerhavens en parkeerstroken en zo. (Parkeervak is een beetje ambigu als term.)
Voor het taggen van amenity=parking geldt:
capacity is het totale aantal parkeerplaatsen, dus inclusief gehandicaptenparkeerplaatsen.
capacity:KLASSE is het aantal parkeerplaatsen voor categorie KLASSE, dus bij één gehandicaptenparkeerplaats is dat 1.
Dus bij je laadpalenvoorbeeld is het capacity=3 en capacity:charging=2, wat betekent dat er maar één parkeerplaats is voor niet-elektrische auto’s.
Netjes om in te tekenen natuurlijk, maar ik beperk mezelf tot generieke gehandicaptenparkeerplaatsen omdat de op kenteken gestelde parkeerplaatsen niet constant zijn. Ze veranderen sneller dan de generieke gehandicaptenparkeerplaatsen die meestal ook breder zijn of een verlaagde stoep eromheen hebben.
Wat je ook nog kan doen trouwens, is alleen de totale capacity taggen, en dan capacity:charging=yes. Daarmee geef je enkel dat er parkeerplaatsen speciaal voor opladen zijn, maar niet hoeveel. Het totale aantal parkeerplaatsen verandert doorgaans eens in de dertig jaar of zo.
Een vervolgvraag hierbij:
Een lange ventweg, vrijwel het volledige stuk parkeervakken links, deels langs, het vervolgdeel dwars.
De rechterzijde zijn incidenteel haventjes aangelegd, dan weer 6 vakken parallel, dan weer 3 of 2.
Is het handig om elke situatie te compartimenteren (maar dan krijg je links een niet realistische verbrokkeling in aantallen ) of het totaal links en rechts aan te geven?
Waarom is dat onrealistisch? Uiteindelijk maakt het voor data consumers niet zoveel uit of je vijf parkeerhavens van elk acht parkeerplaatsen tagged of één lange van 40. Of je een reeks parkeerhavens als één of los intekent is een persoonlijke voorkeur natuurlijk; los is nauwkeuriger.
Zoiets? (Al die blauwe P’s zijn wellicht storend, maar dat komt omdat de renderer nog niet rekening houdt met het relatief nieuwe parking=street_side).
Natuurlijk kun je er ook voor kiezen om ze helemaal niet in te tekenen en met parking:lane te werken. Dan tag je de informatie (en de capacitieit) op de weg zelf. Dat gaat dan wel ten koste van de details. Ik gebruik parking:lane zelf voornamelijk wanneer er geen parkeerhavens zijn.
Het beeld is (nog) wat druk misschien, maar het is wel een mooie oplossing met parking=street_side (kende ik inderdaad nog niet).
Eigenlijk de oplossing die ik met parking:lane ook probeerde te bereiken.
Het beeld zal alleen wat minder strak worden dan in jouw voorbeeld, door de onregelmatigheid van de parkeerhavens rechts.
Op de onderste foto in de wiki zouden met veel fantasie nog weggesleten vakstrepen op het wegdek te bedenken zijn. Ook wanneer ze duidelijk zijn, zoals in mijn omgeving, begrijp ik, dat er voor dat stukje parking:lane:left:parallel=on_street zou moeten worden gebruikt. Dan is compartimentering vanzelfsprekend.
Mijn keuze om aan OSM mee te gaan werken is om naast correctie van aperte fouten júíst de ontbrekende details aan te brengen, in een beperkt gebied.
Dat lijkt me meer een bug voor de gemeente om het netter aan te leggen.
Bij parking:lane:left:parallel=on_street dan heb je als het goed is een straat waar men kan parkeren links op de straat zelf. Er is dan geen als zodanig herkenbare parkeerhaven aan die kant, klopt dat?
Je kan parking:lane en amenity=parking met parking=street_side trouwens goed mixen. Je kan dan met parking:lane:=separate aangeven dat aan die kant er expliciet ingetekende parkeerhavens zijn.
In JOSM is het handig om de Parking lanes Map Paint Style daar voor aan te zetten:
Dan zie je snel of en hoe parking:lane is ingesteld. In dit voorbeeld gaat het om een blauwe zone, dus alleen parkeren in de aangegeven parkeervakken: dat tagt wel lekker makkelijk.
Werkt super, voor zo’n gebied met veel kleinschalige parkeeroplossingen véél en véél gemakkelijker dan het gehannes met met lane.
Alleen een probleem met een laad-/losplaats https://www.openstreetmap.org/way/908825511 met beperkte tijdsduur
** capacity:conditional:delivery=1 @ (Mo-Fr 09:00-18:00; Sa 09:00-17:00)** in een parkeerhaven met 6 (-2 en -1) plekjes
Waarschuwing mbt syntaxis, maar ik zou niet weten hoe ik dit anders zou moeten aanpakken, de wiki helpt me in ieder geval niet beter op weg. capacity:delivery:conditional geprobeerd, zelfde resultaat.
