Parkeerplek voor je deur is toch geen parkeerplaats?

In een deel van Harderwijk heeft iemand iedere vrije plek waar een auto kan staan met amenity=parking getagd.
Is dat de bedoeling?
Zo nee, wat doen we er dan mee?

http://www.openstreetmap.org/#map=18/52.32669/5.60933

Het dateert al van een aantal jaren geleden.

Marc,

Ik weet niet wie het gedaan heeft, alhoewel ik een vermoeden heb.

In Staphorst en omgeving had de inmiddels geblokte Gerrit Dankelman ook bijna alle individuele parkeerplaatsen en -stroken als P gemapt. Deze heb ik grotendeels met hulp van anderen verwijderd.
Wellicht is hij ook in Harderwijk actief geweest.

Zo niet: dan verwijderen met een note aan de auteur, zou mijn voorstel zijn.

Martin

Mijn voorstel is laten staan. Waarom zou je bijvoorbeeld een boom wel op de kaart zetten en een (kleine) parkeerplaats niet?

Is het werk van Parie, is al eens eerder opgemerkt zie https://forum.openstreetmap.org/viewtopic.php?id=11197
Sorry, zie dat het een andere mapper uit Harderwijk is, ene Klaas :wink:

We mappen zeker niet iedere individuele boom, zeker in een bos niet, maar meer ‘markante’ bomen. Met natuurlijk een wat vrije definitie van ‘markant’.

Als we iedere parkeerplaats gaan mappen wordt het beeld overspoeld met blauwe P’s. Bovendien geven deze individuele P’s ook geen informatie aan lokaal onbekenden, zoals een grotere parkeerplaats dat wel doet.

Uiteraard mijn persoonlijke mening; anderen denken wellicht anders over micromapping (ik noem als voorbeeld het tekenen van trottoirs in stedelijke gebieden als apart voetpad parallel aan de straat).

…maar ik kan het mis hebben.

Misschien is dit een betere tag voor parkeervakken:
http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space

Had ooit in het m’n dorp ook veel parkeerplaatsen getagd met amenity=parking.

Inmiddels heb ik sommige straten omgezet naar parking:lane omdat het nauwkeuriger is (en minder prominent op de kaart staat wat een aardige bijkomstigheid is). Zolang er geen bord met grote P staat bij een groter terrein, lijkt die parking:lane me vaak meer op z’n plek.

http://overpass-turbo.eu/s/l1C
Zo te zien heb ik nog een paar locaties gemist waar dit ook beter zou zijn, maar het is nogal wat werk om al die tags goed te zetten :frowning:

Toevallig ben ik net min of meer klaar met deze parkeerplaats.

Daar staan ook nogal wat P’s. Eén niveau uitzoomen en er staan er nog maar twee. Als het beter kan dan laat maar weten.
Misschien kan iemand naar de stukken snelweg kijken die terug de snelweg op voeren, of daar nog destination tags op moeten.

Er zijn altijd anders denkenden, maar dit voorbeeld heb je zelf gemaakt.
Het hoort 1 grote parkeerplaats te zijn en niet zoals jij het hebt gedaan.

Ik vind dit:

http://wiki.openstreetmap.org/wiki/NL:Tag:amenity%3Dparking

vrij duidelijk.

@Kogacarlo, petje af voor die parkeerplaats, hoe lang ben je daar mee bezig geweest? Maar inderdaad wat marczoutendijk zegt, dat lijkt me een simpelere oplossing, daarbij scheelt het je nog een hoop tijd ook. Ziet er (naar mijn mening) ook net iets overzichtelijker uit.

Maar om even terug te komen op het onderwerp…

Mee eens, maar om nu, zoals de wiki beschrijft, elk parkeervak op een parkeerterrein te gaan tekenen lijkt mij wel een beetje over-the-top, gelukkig is het een ‘addition’ ;).

Daar heb ik wat uren aan gespendeerd, op de plek zelf en achter de pc. Ik poog toch min of meer de werkelijkheid op de kaart te zetten en de werkelijkheid is dat niet het gehele terrein parkeerplaats is maar het zijn allemaal eilanden. Om het gehele gebied dan als parkeerplaats aan te duiden lijkt me niet correct. Mijn achtergrond als landmeter heeft er misschien mee te maken.
Ik las ooit (correct me if i’m wrong) dat een parkeerplaats niet gevonden wordt door navigatiesystemen als er niet een node aan de wegen vastzit. Daarom zit bij zowel het vrachtwagengedeelte als het personenautogedeelte bovenin wel een P-eiland aan het wegennet vast. Ook zit het roze gebied highway=rest_area (dat is wél de complete parkeerplaats) aan de weg vast.
Ik vind het trouwens wel overzichtelijk. :slight_smile:

Volgens mij is dat fout, anders zou je naar geen enkel adres of POI kunnen navigeren, die liggen allemaal los naast de straten. Een navigatie systeem is perfect in staat om je tot vlakbij een punt te brengen dat naast de weg ligt.

En die zou je nu allemaal samen in een relatie moeten stoppen want ze vormen feitelijk 1 geheel, niet ?
Zie https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking sectie “Site Relation Proposal”

Dit maakt het (volgens mij) alleen complexer.

Wat doe je dan voor gemeenschappelijke attributen zoals naam, operator, price, enz. ? herhalen per stuk ? dat is ook niet de waarheid, bv. het geheel heeft een naam, ieder individueel stukje.

Anders moet je 1 parking vlak tekenen rond het geheel en met parking_space(s) werken.
amenity=parking zijn niet enkel de parkeerplaatsen, maar ook de wegen ertussen, de ingang, de betaalautomaat enz.
Er is maar 1 parking met meerdere parkeerzones in het gegeven voorbeeld. Die "zones’ moet je met parking_space mappen.

Of via een site relatie mappen om alles bij elkaar te houden

Hoe meer ik erover denk, hoe meer ik de gekozen oplossing verkeerd vind. Wat niet wil zeggen dat ik zo’n situatie zou hermappen.

Over de tags kun je altijd twisten, maar het is wel op de kaart gezet zoals het er op de grond er uit ziet.
Het is dan aan de renderaar om de details weg te laten die voor de toepassing overbodig zijn.

Voor een autokaart is het aantal details overdreven.
Maar voor een gedetailleerde topografische kaart zijn de details weer nodig.

In Duitsland lijken ze het eerder highway=rest_area of highway=services voor de groe vlakken te gebruiken dan amenity=parking

Een soortgelijk voorbeeld bij onze oosterburen staat hieronder.

http://www.openstreetmap.org/#map=17/50.44034/7.22431

Dit hadden mijn woorden kunnen zijn.
Helemaal mee eens.
Hopelijk komt Kogacarlo ook tot dit inzicht, anders denkend vind ik niet verkeerds aan mits we tot dezelfde doelstelling komen.
Hiervoor zijn de wikiafspraken bedoeld, dit alles om OpenStreetMap bruikbaar te houden.

Maar ook een toponym zou een bruikbare oplossing geweest zijn…

amenity=parking_space is bedoeld voor enkele vakken.
amentiy=parking zou bedoelt moeten zijn voor het geheel. Je kan ook een node gebruiken. Het vlak tekenen is meer gewenst/gevraagd.

Dan is er de lijn tagging, ontstaan in een vroeger stadium parking:lane
moeilijk te renderen/te controleren, terwijl de mensen op een kaart de vakken willen zien.
Maar wel te gebruiken in een straat zonder vakken, om parkeerverbod en betaald parkeren aan te geven.

Gegevens, die wel van belang zijn.

We missen dus een variant om parkeervakken te taggen.
Of dit nu langs de staat is of een terrein.

Deze moeten we uit gaan werken.

Wat is de benaming van een groep parking spaces?
Is dit een plot?

Of moeten we verder werken aan de variant area:highway voor vakken
iets van:
area:highway=service
service=parking
parking=
en dan nog een tag dat de vakken het meest door residential mensen of veelal door residential bezoekers gebruikt wordt.
als ik naar een onbekende plaats ga kijk ik toch even op de luchtfoto om te zien waar de auto ergens kan staan.
=residential

Als ik naar een onbekende plaats ga, kijk ik toch even op de luchtfoto om te zien, waar de auto ergens kan staan.
Dan als de vakken zichtbaar zijn. is dit zeer gewenst.