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 
Ik doe altijd een enkele lijn het midden, zoals in jouw screenshot. 
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.
ik hoop dat ik niet de thread breek door een ander topic aan te snijden maar de titel van deze thread vraagt erom
Hi ik ben nog een beginnende OSMér.
Ik wilde wat laadstations hier in onze buurt opvoeren.
Ik heb deze 2 links gelezen:
Waarbij er dus een 3-letter code van de leverancier moet komen.
Het zijn Vattenfall laadstations, maar ik kan helaas nergens de code van Vattenfall vinden. Zelfs op beursnoteringen gezocht maar ook niet gevonden.
Zijn er elders voorbeelden met complete mapping? Dan haal ik info daar uit maar ik kon niets bestaands vinden.
Ik heb momenteel staan:
ref:EU:EVSE=NL*VTF*VS3621*1; NL*VTF*DB2372*2
dus ‘VTF’ gebruikt. VS3621 en DB2372 zijn de unieke codes van deze paal.
Let erop dat (in dit geval) elke laadpaal 2 aansluitingen heeft, met eigen unieke codes.
Ik hoopte zelfs de opzoek-URL erin te krijgen, dat is in dit format:
https://app.goincharge.com/charging?visualId=VS3621 voor de VS3621 kant.
Het gaat om (bijv) object met id 12864355592
Wijzigingenset: 166845139
Grtx, en thx, Ben
Hoi Ben, goede thread gevonden ;-), welkom.
Het is geen enkel probleem een tag weg te laten als je niet weet wat de waarde moet zijn en als die waarde misschien zelfs niet bestaat.
Zijn er elders voorbeelden met complete mapping?
Niet direct een voorbeeld maar wel aantallen via taginfo:
- wat is er in NL getagd in combinatie met
amenity=charging_station, link, geenref:EU:EVSEmaar dit laat alleen de meest gebruikte tags zien - Hoe vaak is
ref:EU:EVSEgebruikt in NL, link, 146 keer, (nog) niet dat vaak. - Hoe vaak is
ref:EU:EVSEgebruikt in de EU, link
Als je toch echt een voorbeeld wil hebben, dit zijn er enige:
ref:EU:EVSE=NLALLEGO004173
ref:EU:EVSE=NLALLEGO004174
ref:EU:EVSE=NLFASE3111201
ref:EU:EVSE=NLALLEGO011746
ref:EU:EVSE=NL*EFL*EV*8374845
ref:EU:EVSE=NL*EFL*EV*2983302
ref:EU:EVSE=NLTMMEGL31*1*0242
ref:EU:EVSE=NL*SGM*E11719273
ref:EU:EVSE=PP004077-1
ref:EU:EVSE=TNLP007646-1
ref:EU:EVSE=NLRBCE0002973
Op Key:ref:EU:EVSE kan je onder Format zien hoe het er hoort uit te zien, het gebruik van een sterretje (‘*’) wordt aanbevolen voor de leesbaarheid.
Tenslotte, je kan met Overpass turbo zoeken naar ref:EU:EVSE.
1 Like
Thanks!
Dankzij die query heb ik in Nijmegen enkele goede voorbeelden gevonden…
Vattenvall heeft Nuon overgekocht (of andersom?weet ik het )
Nijmegen ,Edisonstraat 50:
ref:EU:EVSE NL*NUO*EALF*0017751*1;NL*NUO*EALF*0017751*2
Oplaadpunt Vattenfall InCharge Nijmegen
dus ik ga mijn tags ongeveer gelijktrekken met die !
Bij het Bakkerijmuseum in Hattem zijn de wikidata verwijderd van een museum onder vermelding van “osmose issue.” Aangezien ik met zowel wikidata als osmose onbekend ben vroeg ik me af of dit terecht is verwijderd. De oude wikidata blijken namelijk nog steeds correct naar wikipedia te verwijzen.
Het probleem met het Bakkerijmuseum is wat ingewikkelder, via de wijzigingset set kan je vinden dat er twee nodes zijn gewijzigd en als je op de kaart kijk zie ik twee musea’s en een horeacagelegenheid met dezelfde naam. Het “andere” museum heeft de wikidata tag.
Eigenlijk zou het museum als omtrek ingetekend moeten worden en de tags daarnaar verplaatst worden, ik weet echter niet wat er allemaal bij hoort.
En de horeca gelegenheid heeft ook de tag museum=technology. Nogal apart.
En dat lijkt me ook lastig omdat de beide nodes aan weerszijden van een openbare weg lijken te liggen.
En ondanks dat osmose klaagt zou ik, denk ik de wikidata tag gewoon op allebei de nodes laten. Het lijkt mij hetzelfde museum te zijn verdeelt over meerdere gebouwen.