amenity=parking versus amenity=parking_space

In Tilburg worden parkeerplaatsen langs de straten sinds kort voorzien van de tag amenity=parking_space.
Dat lijkt mij volledig onjuist te zijn.
https://www.openstreetmap.org/way/594470655#map=20/51.56287/5.07275&layers=C

In de wiki wordt duidelijk dat amenity=parking_space wordt gebruikt voor een plaats voor 1 auto, die dan ook nog binnen een amenity=parking moet liggen en niet voor een aaneengesloten reeeks van parkeerplaatsen langs een straat.
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space#When_not_to_use_amenity.3Dparking_space

Wat vinden we van het gebruik van amenity=parking_space ?

Wat uitleg waarom ik dat zo gedaan heb:

Het echte probleem met de tagging is dat een perfect passende tag niet bestaat. Dat is wel vaker het geval. Dan is het gewoon kiezen wat het beste past. Zo was dat ook met groenvoorzieningen een probleem. Dat is nu getagd als natural=scrub. Ook al is er natuurlijk niks natuurlijks aan. Niet perfect, maar landuse=greenery staat er ook op om zo toch te aan te duiden dat het beheerd groen is, en geen natuurlijk struikgewas.

Naar mijn weten zijn de enige echte opties amentiy=parking, amenity=parking_space of bijvoorbeeld een zelf gekozen waarde voor area:highway.

De officiele defenitie van de gemapte parkeervlakken is “Parkeervlak: Wegdeel bestemd voor het parkeren van motorvoertuigen”. Geen van alle bovengenoemde opties komt 100% overeen met deze definitie van de geïmporteerde data.

Het gebruik van amenity=parking is praktisch gezien niet handig. Het rendert niet (blauwe P’s) en je zal ook nooit meer de dichtstbijzijnde parkeerfaciliteit kunnen vinden. De zoekopdracht “parkeerplaats in Tilburg” levert dan ook 18000 resultaten op. Ze zijn niet belangrijk genoeg om ze te beschouwen/taggen als POI waar je op kunt zoeken.

area:highway=parking zou bijvoorbeeld ook kunnen maar er is geen officiele waarde voor een parking, en komt dus in de praktijk niet voor. Zelf je eigen tagging verzinnen voor OSM werkt ook niet. OV tagging heeft laten zien dat dat ook niet werkt, er is zo nog steeds geen echte standaard manier om platformen bij haltes/stations te taggen. Verschillende tagging schemas lopen daar door elkaar.

Dan blijft amenity=parking_space over. De defenitie op de wiki komt aardig overeen met wat de vlakken eigenlijk zijn. Deze tag mag wel gebruikt worden voor aangrenzende vlakken. Er word alleen standaard aangenomen dat de capacity 1 is. Voor als dat niet is moet er een capacity=* tag op. In het geval van Tilburg zou ieder parkjeervlak dus voorzien moeten worden van capacity=unknown. Ook moet het officieel binnen een getagde parkeergelegenheid liggen. Maar ik denk niet dat het wenselijk is om dan bijvoorbeeld al het fileparkeren langs de weg in de hele stad als stroken met amentity=parking te taggen.

Stroken langs een weg voor fileparkeren als parking, hoe dan ook, te taggen lijkt me sowieso ongewenst.

Die zijn in de regel voor bewoners en hebben geen navigatiedoel…

Dit lijkt me een beetje micromappen eigenlijk - maar gezien hoe Tilburg er voor de rest al uit ziet begrijp ik het op zich wel.

Vooral voor mensen die CAD-omgevingengewoon zijn, denken alles nogal snel in ‘vlakjes’ en ‘matchen met de ruimtelijke realiteit’. Dat wordt dan ofwel te prominent gerenderd (overal blauw P’s), ofwel helemaal niet (als je parking_space) gebruikt.

Vanuit die doelstelling: waarom niet via dit werken? https://wiki.openstreetmap.org/wiki/Key:parking:lane
Laat toch ook toe te detailleren waar al dan niet geparkeerd kan worden?

Een perfecte oplossing! Wist hem ook, door de snelheid was ik vergeten hem mee te nemen in mijn bericht. Dank!

Deze fraaie oplossing vind ik niet terug op:
https://wiki.openstreetmap.org/wiki/Template:NL:How_to_map_a:P => Parkeerplaats.
Ook parking_space is daar niet vermeld.

Misschien dat iemand met Wiki-ervaring dat bij kan werken?
Alvast bedankt voor de moeite.

Het is zeker een vorm van micro-mapping. Het nut van de aanduiding parking_space is op z’n minst twijfelachtig.
Het niet renderen van de blauwe P is een voordeel, want anders kleurt zo een stad helemaal blauw.
Zoals zoveel laat OSM het dus wel toe.
Ook JOSM validatie geeft geen foutmelding.
Volgens taginfo is het al meer dan 400.000 keer gebruikt.

Uiteindelijk komt het er dus op neer dat we het niet actief gaan bestrijden. :frowning:

Het laat in principe wel toe te registeren/documenteren hoe groot het aanbod aan parkeerplaatsen is, maar dan moet je het echt vak per vak gaan intekenen, consequent, en niet een ‘strookje’ van een paar met de keer.

Uit nieuwsgierigheid: is de ‘import’ waarvan sprake ergens gedocumenteerd?

Ik heb er ooit een wiki pagina over aan gemaakt, alleen helemaal up-to-date is het niet meer:
https://wiki.openstreetmap.org/wiki/Kernregistratie_Topografie_Tilburg_/_Landuse_import

Heh. Import voltooid voor de documentatie af is… ook niet helemaal koosjer.
Nu ja, soms leunt de structuur voor documentatie imports een beetje aan tegen wat men wel eens ‘regelneverij’ pleegt te noemen…

Het verschil tussen “parkeergelegenheden”
bord E4 en alle E varianten en “parkeerhaven” of “parkeerstrook” is niet duidelijk in Nederland. ( Men gaat ook steeds meer E borden gebruiken om havens/stroken te kunnen regelen. )

Kijk je nu in Nederland, wie in de wijken de parkeerstroken/havens mapt, dan kom je vele verschillende namen tegen, van nieuwelingen tot en met mappers met meer changesets achter hun naam.
Men mapt dan ook de parkeerstroken/havens en zet daar vooral amenity=parking op, er is dus behoefte aan om het zo uit te beelden, als vlak. Men mist het op de kaart. Geen onderscheid makend. Wat eigenlijk wel zou moeten. Daar moeten we nog een slag maken, om een goede tagcombinatie te gebruiken.

De wayline methode is dan wel uitgewerkt, in een tijd dat men alles aan de wayline hangt. (Ontwikkeling OSM)
Maar hoe ga je dat uitbeelden op een kaart, met alle varianten, zo dat het ook nog snel te begrijpen is. Met kleurtjes, lijntjes aan de weg, met icoontjes.
Daarnaast, hoe maak je het controleerbaar, inzichtelijk, JOSM mappaintstyle, laten we het maar niet hebben over ID en de andere.
Er hangt al zoveel aan de wayline “road”, allemaal knippen.
Ik heb dan wel een gedeeltelijke parking mappaintstyle gemaakt en kan je zeggen, dat het moeilijk inzichtelijk te maken is.

Wat geldt voor een wayline mappaintstyle, geldt ook voor een wayline vlakke kaart visualisatie.

**Dan is gebruik van een vlak een veel betere methode!. **

Belangrijk, “een los element”, met tags er op, die als afzonderlijk element een identiteit gegeven kan worden. Zo ook gevisualiseerd.
De ruimte is er op de kaart, vult een leeg topografisch gat op.

Wanneer je vlak visualisatie in een kaart bekijkt, zie je gelijk dat er elementen in de straat zijn om te parkeren, het is niet voor niets dat vele mapppers de parkeerhavens/stroken intekenen. Ze missen het, als belangrijk item in hun kaart.

Als ik zelf in een vreemde wijk kom, dan kijk je vaak even, waar is er mogelijkheid om te parkeren.
Dat moet je eigenlijk gelijk op een kaart kunnen zien. Herkenbaar vlak naast de rijbaan.

Het is een vooruitgang om de vlakken inzichtelijk te maken.

Past meer bij wat mensen verwachten.

Een meer passende tagcombinatie is gewenst om het verschil aan te geven tussen E4 en de havens/stroken.

Wat zou een goede tagcombinatie zijn?

Hier geldt hetzelfde als trottoir. Overal domweg iets intekenen geeft een heleboel extra data waar niemand wat mee kan.

Dus wat is de toegevoegde waarde? Ik kan me voorstellen dat als er een wijk is zonder parkeergelegenheid langs de weg het zin heeft om aan te geven waar wel geparkeerd kan worden.

Waar ik zelf wel gecharmeerd van ben is: wie kan er parkeren en hoeveel kost het.

Probleem met micromappen blijft: wie gaat het onderhouden. Hoe zie je dat iets verkeerd gemapt is of verouderd is?

Om een voorbeeld te geven, in Amsterdam heeft een groep mensen van bijna alle fietspaden het materiaal van het wegdek getagd (en ook de breedte). Soms merk ik dat het verouderd is, maar ik hou dat in het veld niet bij. Dus meer en meer klopt het niet. Wat heb je er dan nog aan?

Als je parkeervakken in gaat tekenen en de weg wordt opnieuw ingedeeld, dan heb je ook kans dat de verouderde situatie op de kaart blijft staan.

Zoals Allroads zegt:

Hij heeft er wel wat aan!

Het komt een discussie niet ten goede als men geen begrip kan tonen voor elkaars standpunt. Domweg iets dom of overbodig noemen, lokt alleen maar tegenreacties uit; het brengt geen oplossing.

Het onderhouden van een kaart geeft veel werk. Vergeleken bij parkeertarieven, bus en treinlijnen, wandel- en fietsroutes, flitspalen, straatmeubilair, enz. enz. lijkt me verandering van plaveisel of parkeerplaatsen niet echt een groot probleem, maar dit terzijde :slight_smile:

Trouwens het tot stand komen van een richtlijn lijkt me voor de bedreven mappers niet echt iets waar ze op zitten te wachten (ze trekken zich er toch niet veel van aan :wink: geloof ik) dus hoeft men zich daar niet zo druk over te maken.
Voor beginners is het echter wel handig een duidelijke richtlijn te hebben waarin iedereen zich vinden kan.

Ik vind dat er nogal een verschil is tussen parkeren op de straat en parkeren op speciaal daarvoor gemaakte parkeerhavens naast diezelfde straat.
Om dan de parkeerfunctie van het parkeervak aan de highway te hangen lijkt me juist micromapping omdat je alleen t.h.v. het parkeervak de extra tag aan de highway toevoegt.
Bij de amenity=parking lees ik: “Use amenity=parking to tag a facility used by the public, customers, or other authorised users for parking motor vehicles” en bij key:parking:lane “For parking in designated areas, see amenity=parking.”
Hieruit maak ik op dat een gebied, uitsluitend bedoelt voor parkeren getagged moet worden als amenity=parking.

Het is nog erger.

Het is niet de bedoeling dat een weg wordt opgeknipt wanneer de parking:lane wordt toegevoegd. Maar het is wel de bedoeling dat de capaciteit wordt ingevuld.

Dat leidt echter tot een probleem zodra de weg in tweeën moet worden geknipt en iemand niet precies weet hoeveel parkeerplaatsen zich aan iedere kant bevinden. Het resultaat zal zijn dat deze informatie verloren gaat of onbetrouwbaar wordt.

Het probleem is het gebrek aan onderhoud. Uiteindelijk geeft een kaart weinig vertrouwen als blijkt dat veel informatie gewoon verouderd is.