Tagging maxheight onder viaducten en in tunnels .. hoe en wat?

Nee, >4,2m geeft geen info.

Een voertuig van 3,8 meter? Goed, die kan er onderdoor.
Een voertuig van 4,5 meter? Die weet nog altijd niet of hij er wel of niet onderdoor kan.
Het enige is dat je zeker weet dat je met voertuigen lager dan 4,2 meter er zeker onderdoor kan, maar je weet niet of je met voertuigen hoger dan 4,2 meter er onderdoor kan.

Wat kan een router met deze informatie? Die moet beslissen of een voertuig van 4,5 meter wel of niet past bij een hoogte van 4,2 meter. Als je zegt “past niet”, dan heb je hele slechte informatie toegevoegd, want misschien past het wel. Als je zegt “past wel”, dan heeft > 4,2m geen toegevoegde waarde.
Een router kan voor dat voertuig hoger dan 4,2 meter dus niets doen, of je moet als default strategie invoeren dat je er dan niet onderdoor kan. En dat is onjuist.

Bijgevolg maakt het niet uit of je geen hoogteinformatie zet of >4,2m.
Dus ga dit alsjeblieft niet zo taggen. Het is onzin.

Geen idee of het dezelfde mapper is onder een ander account. Grote schade door onbedoelde verschuivingen. Schuiven met de kaart in editmodus met editot iD.
De hoogte wordt overigens als maxheight=default ingevuld.

Vooralsnog geen reactie. Even in de gaten houden. De eerste changeset heb ik teruggedraaid. Ondoenlijk om te repareren.
https://www.openstreetmap.org/changeset/74025939

en hier

https://overpass-api.de/achavi/?changeset=74025939

edit… Inmiddels PB contact
edit correctie height moet zijn maxheight

Die maxheight = default was me ook opgevallen. Wat daar nu het nut van is?
Er zijn al diverse routes gewond geraakt in de strijd om de maximale hoogte

Heren,
De maxheight=default waarde komt voort uit de wiki lijkt me;
https://wiki.openstreetmap.org/wiki/Key:maxheight
en is vrij vaak gebruikt (10% over de hele wereld);
https://taginfo.openstreetmap.org/keys/maxheight#values

Cf gewonde relaties begrijp ik dat er momenteel geen enkele editor is die het correct kan doen?
Lees; knippen met behoud van relaties?

Beide mappers heb ik nogmaals uitgenodigd op het forum gezien de grote hoeveelheid edits in korte tijd en de evt. gevolgen.

edit: Ik vermoed dat de bijdragen uit de hoek van Rijkswaterstaat komen.

edit2… Mijn advies is gezien de onzekerheid bij splitsen met iD om over te stappen naar JOSM.

Ik heb gemerkt dat het inladen van een (klein) stuk weg in JOSM niet altijd alle relaties meeneemt.
Als je hierop bedacht bent, dan valt het makkelijk op te lossen door bijvoorbeeld een groter gebied in te laden. Voor snelwegen kun je ook de relaties krijgen door één van de grotere busstations in de omgeving in te laden.

Hoi E de Wit,
Bedankt voor het antwoord!
Ik sta in contact met de mappers, en met deze input kunnen we wat! waarvoor dank!
Ik vraag hen over te stappen op JOSM, om op basis daarvan te werken.
Uiteraard willen we met zn allen naar een zo goed mogelijke kaart toewerken, zonder fouten!
Mochten er nog zaken foutlopen hoor ik het bijgevolg graag, we doen van onze kant ons best echter om het feilloos te laten verlopen nu :slight_smile:

Dat helpt zeker, maar de langere wandel- en fietsroutes worden toch nog steeds vaak gemist. JOSM kan alleen maar bijwerken wat-ie gedownload heeft, maar dat is meestal meer dan wat ID heeft. Het is in JOSM wel veel makkelijker om extra gebied erbij te pakken bv door de relaties die aan een wegdeel zitten gewoon te openen en het knopje “alle leden ophalen” te klikken.

In JOSM als je een stuk weg gaat bewerken (verlengen, knippen, rondsluiten, “rechttrekken”) is het zaak om te kijken in welke relaties die way zit, en die dan allemaal open te klikken en bij voorkeur ook alle leden op te halen. Daarna pas de bewerking doen en dan al die relaties bijwerken met het bijwerkknopje.

De meeste zijn dan klaar, maar sommige niet, en die moet je dan handmatig goed maken en weer opslaan.

Gedoe? Zeker, maar het voorkomt nog veel meer gedoe waar ook anderen last van hebben.

In https://drive.google.com/open?id=1uJZXMtgszE9KaTxBvrRQjnTnh9ZJSkGv3OBfHhMtELs staat mijn beginnershandleiding voor JOSM voor wandelmappers. Misschien heb je daar iets aan?

(Nou krijg ik vast een hoop kommentaar dat het niet goed is… des te beter, hoe meer tips hoe beter!)

Ook daar is weer mijn opmerking op van toepassing: het heeft geen toegevoegde waarde. Een voertuig dat 5 meter hoog is weet dan nog altijd niet of hij wel of niet onder het object door kan. Een router zal zeggen dat hij dat niet kan want die zal 4,2m (of wat het maximum voor Nederland is) kiezen, maar de praktijk kan anders zijn.

En dan wordt het ook nog eens gebruikt waar (volgens mij) geen reden is: https://www.openstreetmap.org/way/584348102

Default = wettelijk geldende hoogtebeperking voor dat land imo.
Het lijkt me dus zaak dat die router (of alternatieven) default omzet naar 4.2 voor NL - wat beter is dan geen tag, dan kan de router uberhaupt niets gaan omzetten en in rekening nemen…

Nee, want geen bord betekent niet dat de doorrijhoogte “maar” 4,2 meter is. Dat kan ook betekenen dat die 5 meter is. Dus het heeft geen enkele informatie, behalve dan misschien dat er zich een object boven de weg bevind.
Een router moet dus ook weer de keuze maken, doe ik er niets mee of zet ik er een (waarschijnlijk onterechte) maximum doorrijhoogte van 4,2 meter op.

Hoi Maarten,
afgaand op de discussie hiervoor (zie vorige posts) durf ik stellen dat, indien de hoogte hoger is dan 4.2m het L01-verkeersbord dient geplaatst te worden.
Groet,
B.

Ik zie dat er ook op autosnelwegen en autowegen geknipt wordt rond het viaduct, zoals hier en hier.

Aangezien je niet mag keren en stoppen op auto(snel)wegen, geldt de hoogterestrictie volgens mij tussen de vorige en volgende uitwisselingsmogelijkheden en niet alleen onder het viaduct. Knippen is dan onnodig.

Dan kunnen we hetzelfde betoog maken (zoals enkele posts terug) cf hoge kraanwagen die bij een ongeval moet geraken, en dus info nodig heeft betreffende de brug-hoogtes :wink:

In dat speciale gevallen wordt een maatwerk oplossing bedacht iom de wegbeheerder. Langs op/afritten sturen en eventueel de verkeerslichten demonteren.

Een tijdje geleden hadden we in de buurt een zwaar en lang transport dat de afslag gemist had. Ze hebben daar een tijdelijke “weg” voor aangelegd om het transport te laten keren. Dat had de voorkeur boven snelweg afsluiten en een paar km achteruit rijden.

Dit soort geintjes kost een paar centen en normaliter zal de voorbereiding een paar weken/maanden langer duren, maar nav een schouw door experts en de diverse vergunningverleners is er altijd wel een mouw aan te passen voor een transport.
En dus ook buiten de in OSM ingetekende wegen aangezien in OSM de mogelijkheden voor tijdelijke wegen, pontonbruggen, binnenvaart en dergelijke er ook niet in staan.

Eggie, zijn je vermoedens dat de edits van Rijkswaterstaat komen bevestigd? En weet je inmiddels meer over de beweegredenen?
Als ik de wiki mag geloven dan zegt de default waarde niks als deze niet gekoppeld wordt met de in het land geldende hoogte. Het geeft ook enkel aan wat de hoogte minimaal is en niet de werkelijke hoogte.

Er wordt overigens actief doorgegaan met het toevoegen van de ‘maxheight=default’.

Heren,
Graag even in PM contact met me opnemen.
Het gaat NIET om Rijkswaterstaat.
Wel willen wij de OSM-data verbeteren, en durven stellen dat we hier toch redelijk hard op de vingers getikt worden, terwijl we de beste bedoelingen hebben. (zie ook 10% maxheight=default tags in de gehele wereld).
Alternatief is dat we bijgevolg niets attribueren op OSM, maar dit op een andere manier gaan verwerken, zonder “meerwaarde” voor OSM.
Dit laatste proberen we uiteraard ten allen tijde te vermijden

De tag maxheight=default staat beschreven in de wiki als ‘non-numerical value’. ‘default’ is dus een waarde die je kan gebruiken voor de tag ‘maxheight’. Er kan m.b.v. de boundary-relations worden bepaald in welk land de weg ligt*, waardoor de weg dus wel gekoppeld is met het land en dus indirect met de geldende hoogte.

De tag ‘maxheight=default’ wordt ruim 14000 keer gebruikt. De tag is dus zowel beschreven als algemeen in gebruik. Een discussie over de wenselijkheid van de tag lijkt me daarom niet aan de orde. Een kracht van OSM is juist dat iedereen informatie kan toevoegen en de gebruiker zelf kan bepalen welke informatie hij wil gebruiken.

  • Deze manier wordt ook voor andere plaatsbepalingen in OSM gebruikt, waardoor bijvoorbeeld de tag ‘is_in’ overbodig is geworden.

Het was niet mijn bedoeling de indruk te wekken dat ik weerstand heb tegen de toevoeging van deze tag. (Het tegendeel zelfs)
Ik proefde op het forum weerstand en vond het nodig dit toch even aan te stippen.

Ik ben me er bewust van dat de default tag algemeen gebruikt wordt en functioneel is.