• Industrial Automation Engineer (unregistered)

    you would think the underlying arithmetic is a simple problem, but it is not. consider a windvane, giving you the wind direction between 0-360 degrees. to compensate for fluttering winds, you apply a low-pass filter. then the wind changes from N-sightlyW to N-slightlyE. those are fun times.

  • ochrist (unregistered)

    Couldn't they just get Superman to rotate a few times and get back to a time when the code wasn't such a mess?

  • Yazeran (unregistered) in reply to Industrial Automation Engineer

    Yea as it turns out getting an average of a number of directions is a surprisingly complex (pun intended) operation.

    It basically boils down to converting the directions to unit-vectors in the complex place, and then taking the sum of those complex numbers and divide the sun with the number of vectors (that step is just normal averaging, but using complex addition instead of normal arithmetic addition)

    The downside is that you may end up with a result vector with length 0 - in which case the average direction is undefined even though all the inputs ARE defined! (consider taking the average of true N, true W, true S and true E).

    Fun stuff (that may end up jumping up and saying 'Gotcha' if you are not careful)

    Yazeran

  • (author) in reply to Industrial Automation Engineer

    It's funny you bring that up, because Sandra included some commentary in her submission which didn't end up in the article. The basic rule for handling geographic information that crosses the domain boundary is "don't": split it up into two different segments, on each side of the boundary.

  • Barry Margolin (github) in reply to Yazeran

    Averages are weird things. As you suggest, the average wind velocity in a tornado is probably close to 0, but try telling that to the towns it destroys. And when Bill Gates walks into a bar, the "average patron" suddenly becomes a multimillionaire.

  • PMF (unregistered) in reply to Remy Porter

    The basic rule for handling geographic information that crosses the domain boundary is "don't": split it up into two different segments, on each side of the boundary.

    No, that won't work. Because if you draw a polygon that consists of points to the left and to the right of the 180° border, it does matter whether you want it to be drawn the "short" or the "long" way. You have to know, and adjust coordinates accordingly (depending on the capabilities of the rendering engine)

  • cellocgw (unregistered)

    This is mathematically correct, as a previous answer suggested: angles greater than 2*pi ARE different in complex space, which is why we have things like "branch cuts" and "principle branch" to begin with. So for this case, just explain to the users that zero to 360 (longitude) is "right now," while -0 to -360 is yesterday, and 361 to 722 is tomorrow.

  • (nodebb)

    And to make things more complex, what happens when you have a shape that crosses the 180 degree line? You have wildly different coordinates that are actually next to each other. (And, yes, I've seen a real world example, admittedly when distances were limited to a handful of miles. I tripped it with bad data but there are a couple of bits of land that are actually hit by the 180 degree line, not to mention Antarctica.)

  • Fizzlecist (unregistered) in reply to ochrist

    Do you think there was ever such a time? I admire your optimism :-)

  • #D-B (unregistered)

    As a New Zealander, I'm just happy that a) we got mentioned on TDWTF and b) are occasionally included on maps.

    Seriously, people keep leaving us off them. Or are somehow convicted we don't exist. Or even worse, are part of Australia. Ugh.

  • Oliver Jones (unregistered)

    Zingers, these wild coordinates are called.

    You should have seen the e-maps for the south side of Chicago for the 1980 Census. The cross streets were all someplace in DuPage County to the west.

  • Oliver Jones (unregistered)

    Zingers, these wild coordinates are called.

    You should have seen the e-maps for the south side of Chicago for the 1980 Census. The cross streets were all someplace in DuPage County to the west.

  • MaxiTB (unregistered)

    % 180 bzw %90 is your friend in this case.

  • Steve Bennett (unregistered)

    It's a pretty subtle problem with no perfect solution. If you constantly constrain longitudes to between -180 and 180, then you always have problems on the antemeridian: a polygon that you think crosses the 180 line actually doesn't, it goes the long way around.

    The solution described here is actually pretty reasonable: allow coordinates to be greater than 180 or less than -180, so that for any individual shape, there are no discontinuities. But then you need to consider what happens when you pan around the world, and whether you need to make multiple copies of each object.

    (Source: I specialise in web-based maps).

  • (nodebb) in reply to Steve Bennett

    How about using something like unit-quaternions or rotors for internal representation?

    When two values are almost equivalent, but have wildly different representation, it is usually also an issue of the representation. Longitude and latitude are useful for human readers, but they aren't great for doing computations.

  • (nodebb) in reply to Yazeran

    It basically boils down to converting the directions to unit-vectors in the complex place, and then taking the sum of those complex numbers and divide the sun with the number of vectors (that step is just normal averaging, but using complex addition instead of normal arithmetic addition)

    Probably better to work with them as vectors rather than complex numbers. The math is almost the same, except that instead of averaging, you sum the vectors and normalize (if you need to). It also has the advantage of being trivial to extend into 3D if you need it.

  • Graham (unregistered) in reply to LorenPechtel

    I’ve had to solve the problem of shapes crossing the antimeridian in my mapping package CartoType. One example is drawing a map of Fiji. It is surprisingly hard to get right. Parts of my code allow out-of-range longitude values then normalise later.

  • Sandra (unregistered) in reply to Steve Bennett

    In our domain that's not a concern - there's very little agricultural activity near the antimeridian, since not many people grow crops in Siberia, Antarctica, or Fiji.

  • (nodebb) in reply to dkf

    instead of averaging, you sum the vectors and normalize

    Or you could still take the average i.e. divide the components of the sum by the number of vectors. Then the direction of your resultant vector gives you the mean direction and the magnitude will give you some idea of the distribution.

  • T (unregistered)

    Stereographic coordinates aren't bounded.

  • (nodebb)

    Clearly there are some people who are thinking beyond present dimensions.

  • (nodebb)

    Maybe I'm missing, but to draw a polygon on a sphere, couldn't it be done be recording each point (coordinates), and the heading to the next one, to be able to replay the drawing the user made when it comes time to render it?

  • Alex Vincent (unregistered)

    I'm not sure how many punks there were at Sandra's place, but they sure were daft...

  • MaybeHelpful (unregistered) in reply to Steve Bennett

    Maybe it makes sense to store points as Latitude+Longitude, but arcs/lines as start+offset, this way all points would be represented exactly once (NZ after zero and ten rotations would be the same Latitude+Longitude), but now lines/arcs can even go around the world multiple times.

Leave a comment on “Around the World (Around the World)”

Log In or post as a guest

Replying to comment #603104:

« Return to Article