4 ms·

You say it like it's a done deal, but virtually every book map paper and UI disagree with you. Outside of the programming bubble we're not in a world where you

by geokon 5y ago

You say it like it's a done deal, but virtually every book map paper and UI disagree with you. Outside of the programming bubble we're not in a world where you ever need to think twice about the order. I don't go to Wikipedia and think "hmm I wonder which order they wrote their coordinates". I don't need to check the publication date of a map or book. I don't see that ever changing And as I explained the benefits are kind of half-assed. If you want a more intuitive internal system than I think you can do better. You should full-ass it and re-zero it to whatever makes sense in your situation (or even change the units, or remap to go from degrees to the 0 UINT_MAX range and have your unsigned values automatically wrap around) - but keep the API in standard notation.

post-it 5y ago
> remap to go from degrees to the 0 UINT_MAX range and have your unsigned values automatically wrap around :-/
- geokon 5y ago
  It was a random thought I had today. Please tell me why it's a bad idea haha :)) A lot of weird bugs happen at the edges/meridians. In a South/East system the edges are at the poles and in the middle of the Pacific Ocean. So you already eliminate weird southern hemisphere blow ups. Using wraparound would solve the Pacific problem I guess Maybe unsigned long.. for some extra precision.. EDIT: unfortunately since I'm doing everything in Clojure unsigned math is kinda clunky :(
  - 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++.
  - post-it 5y ago
    I actually think it's a really neat idea. It gives off a hacky vibe, but as long as it's well-documented it should work well.
wiredfool 5y ago
Congratulations, you’ve just (re)invented projections.
- geokon 5y ago
  Sure. That kinda misses the point but you can think of it that way. And the mirror universe projection of lon/lat is not a great projection but you're free to choose what you want. But maybe don't expose your projection in your API?
  - wiredfool 5y ago
    Well, I need to be projection aware, as there are at least 6 that I’m using on a regular basis. (Wgs 84/espg 4326, web Mercator, itm (old and new), an equal area one, and a few local area lat Lon subsets.) None of them are more correct, they’re just more convenient.
jandrewrogers 5y ago
> or remap to go from degrees to the 0 UINT_MAX range Some systems do this internally, it has advantages beyond the wraparound. They still export standard ISO compliant data format though since that is what everyone knows.

by geokon 5y ago

post-it 5y ago

> remap to go from degrees to the 0 UINT_MAX range and have your unsigned values automatically wrap around :-/

geokon 5y ago
It was a random thought I had today. Please tell me why it's a bad idea haha :)) A lot of weird bugs happen at the edges/meridians. In a South/East system the edges are at the poles and in the middle of the Pacific Ocean. So you already eliminate weird southern hemisphere blow ups. Using wraparound would solve the Pacific problem I guess Maybe unsigned long.. for some extra precision.. EDIT: unfortunately since I'm doing everything in Clojure unsigned math is kinda clunky :(
- 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++.
- post-it 5y ago
  I actually think it's a really neat idea. It gives off a hacky vibe, but as long as it's well-documented it should work well.

wiredfool 5y ago

Congratulations, you’ve just (re)invented projections.

geokon 5y ago
Sure. That kinda misses the point but you can think of it that way. And the mirror universe projection of lon/lat is not a great projection but you're free to choose what you want. But maybe don't expose your projection in your API?
- wiredfool 5y ago
  Well, I need to be projection aware, as there are at least 6 that I’m using on a regular basis. (Wgs 84/espg 4326, web Mercator, itm (old and new), an equal area one, and a few local area lat Lon subsets.) None of them are more correct, they’re just more convenient.

jandrewrogers 5y ago

> or remap to go from degrees to the 0 UINT_MAX range Some systems do this internally, it has advantages beyond the wraparound. They still export standard ISO compliant data format though since that is what everyone knows.