-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change of Datum values #9
Comments
From a quick research in our data: There are also some objects referring to a local datum (VERDAT = 24), which will be available in S-101, too. I am not sure I understand your concern correctly. I see two possible problems that could arise from the need to change the VERDAT entry.
I agree with the first issue. This will cause a lot of work, but it is unavoidable or the data will be ruined. The second issue is no problem in my opinion, as attributes refer either to M_VDAT or M_SDAT and therefore are independent from each other. The tricky part is to separate the two groups. The definitions in the DCEG for M_VDAT and M_SDAT are confusing, as they both mention ‚datum for sounding reduction‘. For reference (DCEG Vers. 1.0.1): 3.8 Sounding Datum 3.9 Vertical Datum Maybe the definition of vertical datum can be changed to not include 'datum for sounding reduction' to avoid confusion? Conclusion: As long as the connected attributes are adjusted according to changes in M_VDAT (or M_SDAT) there should be no problem with attributes referring to the datum definition (besides the effort needed to deal with the amount of objects). If the amount of objects affected by the changes is too high, maybe ‚Local datum‘ (24) could serve as (temporary) wildcard until all objects can be adjusted to fit with the new ‚real‘ vertical datum. |
In the attached file, elements on possible issues when changing a Datum value, but not the data underneath).
Further investigation is needed.
Issue #9 - Datums.pdf
Datums.xlsx
The text was updated successfully, but these errors were encountered: