3 ms·

Sub-cm resolution everywhere with only 32 bits. > Using wraparound would solve the Pacific problem I guess I worked with such a coordinate system years ago, a

by rsaxvc 5y ago

Sub-cm resolution everywhere with only 32 bits. > Using wraparound would solve the Pacific problem I guess I worked with such a coordinate system years ago, and there's definitely some advantages (fixed resolution, speed on some processors, memory usage) and some disadvantages ( not all software is wraparound aware and needs ported, debugging outside of decimal degrees is harder for me but I know some mathematicians who are more used to radians than anything else - perhaps you get used to it).

geokon 5y ago
Thanks for the sanity check! Yeah, my napkin math was showing a very high resolution without any floats needed. I'm happy to hear it's been done before. It's going to ultimately come together as a GUI (it's a set of scripts so far) so fortunately I don't need to interface with any other software. The debugging aspect may be a bit annoying I'll admit. Before printing you'd need to constantly convert your u_ints to degrees to make sense of them. The main problems I'm seeing so far is that lon spans 360 and wraps around cleanly, but lat spans 180.. and when you go past the pole you don't actually wrap anywhere (you don't wanna jump to the other pole :)). What actually happens is that you end up on a different longitude. I'm not sure how to work around that. But then maybe you don't need to b/c that scenario shouldn't come up - while crossing the pacific will. At the moment I'm primarily shooting to select rectangular regions and then extract data (like elevation or precipitation) in those regions. Such a region could cross a meridian/equator - but it wouldn't make sense for it to go past the pole On the JVM unsigned code is going to be a lot clunkier to write, but I'm hoping in the end it'll save me a ton of time debugging edge cases
- rsaxvc 5y ago
  I've seen lat being half as large as long done two ways. 1) Double the lat resolution and use two different scaling factors for converting each axis to degrees(less fun to debug, but hey, free 2x resolution or repurpose the LSB for something else) 2) Allow intermediate results on latitudes to temporarily enter the no-mans land between 90-180(and southern equivalent), then manually wrap back. > On the JVM unsigned code is going to be a lot clunkier to write Wikipedia has a comparison: https://en.m.wikipedia.org/wiki/Binary_angular_measurement https://en.m.wikipedia.org/wiki/Binary_angular_measurement Having x-y=5 and y-x=-5 can be quite handy, but there's also some concerns about integer overflow in C/C++.

by rsaxvc 5y ago

geokon 5y ago

Thanks for the sanity check! Yeah, my napkin math was showing a very high resolution without any floats needed. I'm happy to hear it's been done before. It's going to ultimately come together as a GUI (it's a set of scripts so far) so fortunately I don't need to interface with any other software. The debugging aspect may be a bit annoying I'll admit. Before printing you'd need to constantly convert your u_ints to degrees to make sense of them. The main problems I'm seeing so far is that lon spans 360 and wraps around cleanly, but lat spans 180.. and when you go past the pole you don't actually wrap anywhere (you don't wanna jump to the other pole :)). What actually happens is that you end up on a different longitude. I'm not sure how to work around that. But then maybe you don't need to b/c that scenario shouldn't come up - while crossing the pacific will. At the moment I'm primarily shooting to select rectangular regions and then extract data (like elevation or precipitation) in those regions. Such a region could cross a meridian/equator - but it wouldn't make sense for it to go past the pole On the JVM unsigned code is going to be a lot clunkier to write, but I'm hoping in the end it'll save me a ton of time debugging edge cases

rsaxvc 5y ago
I've seen lat being half as large as long done two ways. 1) Double the lat resolution and use two different scaling factors for converting each axis to degrees(less fun to debug, but hey, free 2x resolution or repurpose the LSB for something else) 2) Allow intermediate results on latitudes to temporarily enter the no-mans land between 90-180(and southern equivalent), then manually wrap back. > On the JVM unsigned code is going to be a lot clunkier to write Wikipedia has a comparison: https://en.m.wikipedia.org/wiki/Binary_angular_measurement https://en.m.wikipedia.org/wiki/Binary_angular_measurement Having x-y=5 and y-x=-5 can be quite handy, but there's also some concerns about integer overflow in C/C++.