Beste,
Zijn er in de specificaties van het AHN3 eisen gesteld aan de timestamp zoals deze in de ruwe puntenwolken is opgeslagen?
Zoals ook al aangestipt in dit topic wordt in de AHN3 data soms gebruik gemaakt van de zgn. GPS Week Time, maar zonder dat de GPS week ook is opgeslagen. Dit resulteert in nanoseconden sinds een onbekende zondag 00:00. In andere bestanden wordt echter Adjusted Standard GPS Time gebruikt, die wel om te zetten is naar een absolute datumtijd. Welke vorm wordt gebruikt is aangegeven door een specifieke bit in de header (ASPRS specs).
Het lijkt me wenselijk dat er zoveel mogelijk gebruik wordt gemaakt van de Adjusted Standard GPS Time, zodat men gebruik kan maken van dit attribuut.
In sommige tiles waar er overlap bestaat tussen inwin gebieden, zoals bv tile C_52AZ2.LAZ, komen timestamps in allebei de vormen voor door het mergen van verschillende datasets, wat het .laz bestand ongeldig maakt. Dit is te zien met bv lasinfo:
gps_time min: 46376.834950 max: 203337302.207474
De minimum waarde is een week time (waarde lager dan het aantal seconden in een week, 604800), terwijl de hoogste waarde standard gps time is. Er zijn ongetwijfeld meer tiles waar dit probleem voorkomt.
Bij voorbaat dank,
Maarten Pronk
PS Ik bekijk nu de mogelijkheden om adhv de flightlines alsnog een GPS Week time te kunnen corrigeren.