Ik probeer het woud aan parkeerregels & tarieven die Haarlem opgesteld heeft te verwerken in OSM.
Na het te hebben toegepast op: Zijlweg Haarlem kom ik erachter dat de keys: parking:both:charge,
parking:both:charge:conditional & parking:both:orientation niet bestaan ?
Dit terwijl ik deze keys toegepast heb via OSM wiki pagina: Street parking
Heb ik zelf semantische of syntaxische fouten gemaakt of staat er iets nu op deze wiki-pagina beschreven wat niet (meer) opgeslagen wordt in OSM ?
Ik zie zelf even, door zowel Haarlemse parkeer als OSM’s regels, door de bomen het bos niet meer.
Wie kan verheldering geven ?
N.B. er zit nog een fout in Zijlweg Haarlem m.b.t. fietsgebruikers maar dat is voor later zorg.
De door jou gebruikte 0.65 EUR/hour is nog niet door taginfo verwerkt.
Wat bedoel je met “opgeslagen in OSM”?
Alle keys die je gebruikt worden opgeslagen in OSM.
Dus parking:paard-en-wagen:inclusief-wortel-voor-paard=gratis
kun je gewoon gebruiken, het wordt opgeslagen maar er is geen rendering voor beschikbaar en het zal zonder verdere bekendmaking in een wiki ook niet (veel) gebruikt worden.
Om die reden is voor het deel charge:conditional ook nog geen wiki beschikbaar. Want: weinig gebruikt en weinig behoefte om te gebruiken.
Het zou kunnen zijn, bedacht ik me, dat het een oude wiki pagina is met key optie’s die niet meer gebruikt worden en nog niet als obsolete verklaart waren.
Deze keys stel ik zelf niet voor die staan gedocumenteerd in de wikipagina: Street_parking.
Daarom was ik verbaast dat ze (in ID) niet blauw maar zwart ten teken van niet renderbare keys weergeven worden.
Edit: Laatst vermeldde quote en mijn antwoord daarop
Ik ben geïndexeerde relationele databases gewend zodat 1 verandering mits goed gedefinieerd meteen voor een bepaald gebied geldt bijvoorbeeld.
OSM blijft nog steeds wennen voor me zeker als je dat moet vullen via ID.
Wikipagina’s staan niet in de OSM database
Wikiwijzigingen worden niet automatsch doorgevoerd
Tagwijzigingen worden in OSM niet automatisch doorgevoerd
Taginfo is je vriend. Behoorlijk actuele Taginfo wordt wel automagisch getoond in de infobox op de wikipagina.
Dat is helemaal duidelijk maar je raadpleegt wikipagina’s juist om zoveel mogelijk uit te sluiten dat je niet renderbare keys gebruikt…
In mijn geval niet omdat ik die tarifering nou zo heeeeeel belangrijk vind maar meer omdat ik zeker wil weten dat door het niet kunnen renderen van de parkeerinfo het hele item geskipt wordt omdat er op dat stuk ook nog een paar relatie’s lopen op dat stuk weg.
90% van de bestaande keys wordt niet gerenderd om de simpele reden dat een kaart dan volledig onleesbaar wordt. Je kunt nu eenmaal niet al die informatie kwijt op het scherm (of op een paperen kaart).
Er zal dus iemand moeten opstaan die een kaart maakt waarop alle informatie betreffende parkeren is te zien.
En bedenk ook dit: de wiki is niet hoe het moet, maar hoe het - tot nu toe - is gedaan. Over 5 jaar is alles weer anders.
Dus eigenlijk is het beter een url m.b.t. tarieven & conditie’s op te nemen in OSM ?
Voordeel daarvan: wijzigingen (kwa tarief & conditie’s) staan actueler op die website & voorkomt te ingewikkelde constructie’s die niet te renderen vallen ?
Als dat een betere oplossing is: weet iemand een mooie veel gebruikte url/website verwijzing anders dan de algemene key: website= (aannemend en in de praktijk ziende dat tarievering in garages, op straat maar ook op pontjes) in eerste instantie niet op de homepagina te vinden is van de ondernemer.
Immers op de homepagina staat vaak algemenere info.
Dan kan ik de blijkbaar (bron: Taginfo) nauwelijks gebruikte keys weg halen.
Als parkeerregels en tarieven voor alle parkeervoorzieningen redelijk eenvormig te krijgen zijn zou het mogelijk een meerwaarde hebben om ze als aparte voorziening in OSM op te nemen.
Anders krijg je vooral veel data die na verloop van tijd steeds onbruikbaarder wordt.
Een url naar een algemene website van een object kan je zowizo in de website key zetten, dat is dan niet beperkt tot parkeerregels.
Als je zou willen dat OSM-based toepassingen bij aanklikken van een POI de parkeerregels/kosten kunnen tonen, dan moet die toepassing op een uniforme manier de regels en tarieven via de url kunnen extraheren uit de site.
Als je zou willen dat je uit de OSM database met een query alle parkeervoorzieningen voor (op dat moment) minder dan 3 euro per uur kan opvragen, dan worden de vereisten nog een tikkie strenger.
Het zou MI al lastig genoeg zijn om te mappen en bij te houden waar je uberhaupt mag parkeren en waar niet, maar dat is in ieder geval wel met standaardborden geregeld.
De parkeerregels zijn zoals je al zei goed te doen in OSM immers je wijst terecht op bebording (maar volgens mij bestaat er ook stoeprand en parkeervak aanduid-uitsluiting om het compleet te maken).
Grootste uitdaging ligt inderdaad in het eenduidig definiëren van parkeertarieven.
Tarifering lijkt in eerste instantie niet belangrijk omdat het kwa routering verkeerstechnisch geen drempels op werpt, maar kan WEL een gebruikerscriterium zijn die de verkeersgebruiker doet beslissen een ander vervoermiddel te (willen) kiezen en in dat opzicht wel degelijk van belang omdat een ander vervoermiddel weer invloed kan hebben op de routering…
Zou je het hele parkeertarievenstelsel van Nederland in kaart willen brengen dan kan je dat mijn inziens het beste doen middels een geïndexeerd relationele database maar dat is een te groot project om te behappen in 1 keer laat staan uit te testen…
Een betere aanpak is om eerst 1 kleine gemeente met simpele parkeertarieven kwa database te definiëren maar omdat ik niet in zo’n gemeente woon wordt het voor mij lastig te controleren of het model correct gaat worden of niet…
Een aantal vragen:
Weet iemand een gemeente met eenvoudige parkeertarieven om een database model mee te kunnen opbouwen ?
Weet iemand sowieso al bestaande opensource projecten die het parkeertarieven vraagstuk inzichtelijk probeer(t/de) te maken ?