Open ElisabethKloren opened 1 year ago
Eigenlijk wel, de rotatiehoek verkleind het oopervlak van een verkeersbord en maakt het daardoor minder zichtbaar. De invalshoek van licht bepaald ook de mate van reflectie en daarmee de zichtbaarheid. de zichtbaarheid van verkeersborden is opgenomen in o.a. de EN12899, DIN67520 en EN3381 in dit specifieke voorbeeld gaat het dan om de invalshoek. In geval van parkeren kan, zowel met als zonder een onderbord, haaks op de rijrichting staan.
De vraag is, wat we moeten toestaan qua input. In George kan nu dus een hoek van 0 - 360 worden opgegeven lijkt het, dat is realistisch (het kan allemaal voorkomen als je de situatie buiten meet, inclusief verdraaide en aangereden borden), of moet je hier de gewenste/geplande richting aanduiden? Dan is het of parallel of haaks op de rijrichting? > dit moet ik nog checken bij vakinhoudelijke collega's
In het datamodel van de verkeersborden is recent (vanaf api v3) ook een kolom toegevoegd met de driving_direction'. Deze gaat de waardes Heen, Terug of Loodrecht `bevatten. Heen en Terug verwijst naar de richting van het wvk_id waar het betrekking op heeft. Deze kolom wordt binnenkort gevuld.
Daarnaast is er in v3 ook een kolom 'nenTurningDirection' opgenomen.
Zowel de hoek als de richting worden opgenomen in het informatiemodel.
Heropen, dit moet wel nog worden verwerkt, lijkt me dat driving_direction' met de waardes Heen, Terug of Loodrecht een aspect moet zijn van de netwerk locatie fysieke plaat, checken bij informatiemodelleur
Moet de hoek van het verkeersbord tov het wegvak worden aangeduid? Normaal is het haaks op de rijrichting, maar het E4 bord kan ook parallel staan zodat je vanaf de andere rijrichting ook kan zien dat je niet mag parkeren
In George zag ik volgens mij meer een kijkrichting in 360 graden, maar is dat wenselijk?)
& Check in Datex?