- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
minus three hundret fifth nitnth!
Admin
The problem with rotations is actually much worse than you make it out to be.
They are not bounded per se. At least not the longitude. A standard representation is bounded by convention, but generally any rotation by multiples of 360 degrees is the same rotation. Unless you're talking about a rotational distance, in which case they are not.
Rotations are a mess to work with.
Case in point: When first reading the start of the article, I thought that the issue would be that a line from -179 to +179 would span 358 instead of the intended 2 degrees of latitude.
Which I suppose was the reason the fix wasn't easy in this case. Probably easy enough to normalize the data to the default ranges, but then there would be no way to distinguish a 178 degrees latitude line from a -182 degrees latitude line.
Admin
I remember when this article was first published (hey, this is the Best of 2023 series). The points must show directions. You point out that a line from -179 (179 W) to 179 (179 E) could span either 2 degrees or 358 degrees.
I guess I would fix this by normalizing the first point of the bounding shape to be within the range of -180 to 180 for longitude and -90 to 90 for latitude. All other points in the polygon should be shifted by the same number of degrees as that first point. If the next point's longitude is less than the current point's, it means to draw to the west; if it's greater, draw to the east. Same concept for latitude. There will be math involved in determining which line fragments show up in the view port. It is possible to do a spiral which spans the globe multiple times which makes it such a tricky task.
Admin
I think this belongs right up there with "myths programmers believe about Dates, Names, Timezones" and now "geography".
Admin
Around the world in a daze
Admin
The proper fix is to set the first point in an absolute coordinate system that can be sanitized for bounds, and then store every following point relative to that base mark. No more confusion.
Bonus points if the data types can clearly differentiate between an absolute coordinate and a relative one.
Admin
Data types? Data types?? We don't use no steenkin' data types. Everything about coding is so much more convenient when written in typeless languages. When storing stuff or transporting stuff the best possible is JSON blobs, exceeded only by opaque XMLblobs stored in string fields in databases.
Data types? What do you think this is, the 1990s?
Admin
Amen. I really should have more to say about this subject other than I paid close attention to it. For the last few weeks, I've spent untold hours doing map annotations including things like "add a map pin 10m to the right and perpendicular to this line on the map."
Admin
I'm sorry, but the correct shape of data is base64-encoded JSON embedded in zipped XML. I can't imagine anything better, unless you embed the zipped XML in YAML. Each layer of the onion should also have some metadata that's vital to using something in a different layer, too.