-
Notifications
You must be signed in to change notification settings - Fork 348
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
coast: limit decimals when dumping GSHHG/DCW #8516
Comments
This is controlled by the
|
It's not documented, so we should improve the documentation. PR is welcomed. |
Yes, it is, but I imagine most people don't think about this, hence it may be hardcoded. Mentioning this in the docs is a good solution - will make a PR, probably. |
The source data for dcw has only 5 digits, e.g. :
Still, dumping the polygon gives 10 decimals, the 5 latter not being 0:
How can this be? |
Single precision for floating-point numbers? |
Well, it is documented in the sense that But I noticed something that is worse. Although these data is does not have a high precision in localization, we are degrading it in about ~20 m. A consequence of the binning/scaling algorithm but something to have in mind for future. |
If you look into the |
Ok, so this is an explainable artifact then, I assume, based on your answer. (I've read that numbers become complicated with all kind of strange rounding effects once you go into the float/long/etc. world, so won't go into that hole right now) |
The point here is that we are saving floating point data (4 bytes floats are enough) in 2 bytes ints and with that we obviously loose precision. While the situation is not that bad in GSHHG because it uses a binning schema where by knowing the bin we already know the integer part of the bin corner orgin and the 2 bytes (0-65535) can be used to store only the decimal part, the situation in DCW is different. Here we want to store the data as polygons so we cannot use the binning and as a consequence the 2 bytes can provide only a precision of ~0.001 degrees (1 / 65535 = ~1.5e-5; 1.5e-5 * 180 ~= 0.0027...) |
Thanks, interesting. So just 4 decimals are basically enough? |
Not sure I understand the question. We cannot choose the number of significant decimals. We have what we have, and if I'm right the precision decreases as we move way from Greenwich and the Equator. |
Alright, thanks. I might make a PR just noting that one may consider setting |
This is the script that creates the DCW file.
|
And from what I understand by looking at lines 116 to 150 of the script, I think the 2 byte range is set for each longitude and latitude range of each polygon. In practice this means that larger polygons have lower accuracy. Explore the file and extract the scales used (dcw-scales.txt)
That is, the worst accuracies are for the longitude values of the polygons of Antarctica (AQ), United States, Russia and Canada. For the longitude of Germany we have a precision of 0.0001. For the latitude of Iceland we have 0.00005. |
I made these two maps to compare the original data (from the Full script
|
Now I made a zoom and add the GSHHG data set. Conclusion. I think DCW should be left as it is.
|
No, GSHHG cannot be assumed as the truth. We have permanent complains on hows the coast coastlines do not align with other data or satellite images. GSHHG is very old and suffers from using a different datum than modern data. All our effort on coastlines/borders front should be concentrated in creating a new |
Dealt with in #8524. |
coast will use 10 decimals when dumping coastlines or country polygons.
Using 5 decimals, you're at a resolution of ~1.11 meter, so we're talking millimeter/sub-millimeter-scale.
Would it be an idea to hardcode dumping of GSSHG/DCW to at most 5 decimals?
Disk space is ample these days, but no need to waste it.
PS! Minor issue, I just wanted to vent.
The text was updated successfully, but these errors were encountered: