Korte vragen (met hopelijk een kort antwoord)

Thx, maar dan i.c.m. amenity=social_facility, maar ik twijfel over social_facility=… (Key:social_facility - OpenStreetMap Wiki), is dat dan group_home, assisted_living of shelter?

Street side parking vast aan de weg?

Ik kom geregeld tegen dat een parking vastzit aan de weg, zoals hier:

Ik vond dat altijd vreselijk fout en heel hinderlijk, maar misschien is dat niet terecht. Immers, aanbevolen wordt om waar een weg een parking ingaat (kruist), een knoop te zetten. En de doorgaande weg, aan de kant van de street_side parking, is op dat punt tegelijk ook een parking_aisle, zeker bij haaks parkeren.
Bij parallel parkeren zou ik zeker niet vastmaken.

Ik vind dit net zo fout als bijvoorbeeld het gras van de berm vastmaken aan de weg. De parkeerplaatsen lopen tot de rand van de weg, niet tot het midden.

Je kan wel zeggen dat de parkeerplaatsen een relatie met de weg hebben, maar dat geldt net zo goed voor de berm.

2 Likes

Ik maak parkings altijd aan een way vast.

Zeker, maar parking omvat naast de parkeerplekken ook de toegang/ingang en de rijpaden. Dus losse parkeerplaatsen zeker niet aan de weg vastmaken, maar het parkeerplaatsje als geheel, niet zo vreemd eigenlijk.

In vergelijking, bermen hoef je normaal niet op te rijden, parkeerplaatsen wel.
Als je de weg als een vlak zou tekenen, dat zit het gras van de berm daar wel aan vast.

PS Voor de duidelijkheid: ik zal het zo niet mappen, maar probeer de denkwijze te begrijpen, en die is niet zonder meer fout. Dus ik ga het ook niet veranderen als het zo gemapt is. Op andere plekken heb ik het wel aangepast, met name waar het gaat om simpele parallelle parkeervakken.

Parkeren vastplakken aan wegen is net zo erg als gras of residential vastplakken aan wegen.

Een knoop zetten bij een kruising tussen een weg en een parkeerplaats is niet te vergelijken met het vastplakken van street_side parking aan een weg.

Bij het vastplakken van street_side parking aan een weg vervorm je de parking, en maak je het gebied tot wel 2 keer groter, dat is vervelend als je die grote wilt gebruiken.

Op het moment dat je parking_aisle gebruikt is het geen street_side parking meer, dan dient het volledige gebied van de parking_aisle meegenomen te worden in de parkeerplaats.

Maar op het moment dat de weg ook nog voor andere doelijnden gebruikt word dan is het street_side en dient niks van de weg meegenomen te worden.

1 Like

Ja, de Josm validator ondersteund conditionele parkeerrestricties nog niet, zie ConditionalKeys.java

Ik had nieuwe presets gemaakt voor de parking:side tags en het is wel een beetje dom als die tot foutmeldingen leiden. Het was een voortbouwing op een bestand dat ik op de Duitse server had gevonden. Ik denk echter dat de tags kloppen dus dan zal ik de presets zo laten, ook al klaagt JOSM erover.

Over heggen.
Ik kom veel heggen tegen die in de BGT Icoon-visualisatie als een groene lijn getoonde worden. Bij dikke heggen staan de lijnen vaak een één zijkant, dus niet in het midden.

Hoe trekken jullie de way van de barrier=hedge bij een dikke heg, aan een zijkant, in het midden of rondom?

Bij een dikke heg gebruik ik barrier=hedge en teken ik de omtrek of gebruik ik natural=shrubbery ook de omtrek.

Was even benieuwd, voor de ~90.000 gemapt heggen in NL zijn er ~17.300 gemapt als omtrek.

Methode om het aantal heggen gemapt als omtrek te achterhalen

> osmium tags-filter -R netherlands.pbf a/barrier=hedge -f opl | wc

Ik bedoel echt een lange heg als barrier, maar dan aan de dikke kant, zoiets:


Deze is kilometerslang.

Ik heb mijn eerdere antwoord bijgewerkt en hopelijk duidelijker gemaakt.

Wat betreft de foto, ja die zou ik als barrier=hedge mappen en, ~1 meter breed, de omtrek intekenen.

Ik zie trouwens dat je geen Road Extended heb aan staan :wink:

Ik doe altijd een enkele lijn het midden, zoals in jouw screenshot. :slight_smile:

Ik moest onverwacht naar een nieuw apparaat overstappen, heb nog niet alles weer in orde. Maar deze stijl laat bomen tenminste goed zien, dat bevalt me wel.