You're right and I often go back and forth on both controls when making experiments like this. I like the freedom to explore the scene with TrackballControls but I think you're right and the OrbitControls makes it easier to use.
* Not familiar with the data set you mention but so long as it's mostly documented it should be okay.
* I've never tackled the idea of a hierarchal map even with vectors so I don't know - with the right data, the bit I'm most concern about is the transition from one data set to the next.
* Coloring regions is straightforward
I don't have spare time to do it but am happy to help if you get stuck.
> the bit I'm most concern about is the transition from one data set to the next.
Yep. I have dabbled a tiny amount with three.js; my understanding is that there would be at least some kind of lag, as a new geometry is inserted into the pipeline. I don't know about trying to transition a mesh into another one.
> I don't have spare time to do it but am happy to help if you get stuck.
Damn, I was not expecting that you would even ponder doing it. You seem like such a nice person.
The context of my asking is a for professional project where some visualization could help in selling it. Customers love the shiny. If I go on doing it, I'll let you know!
1. Can you put two separate opacity controls for the base map and the Voronoi regions? I like the appearance of the original better than anything I could configure with this single opacity slider.
2. A lot of regions meet at the north and south poles. That's something that the original doesn't have, so I'd guess that's an artifact of numerical errors.
There is something weird I've noticed: the map appears to be above the Voronoi graph, so when you set its opacity to 1 it's impossible to see the graph. I was playing with that because I was annoyed by the graph at the antipodes and I wanted to get rid of it.
Yep, yep. I tried to create a great circle routes between the cell vertices if the line is longer than a threshold value. I might also see about filling each cell with triangles which I'll also need to make work with geodesics.
One usability issue I noticed with both this and the original inspiration is that it's hard to keep the globe in the usual north-south orientation. I feel the map would be easier to stay oriented in if the the north-south axis were restricted to the YZ plane (i.e. on screen vertical/directly toward the user normal to the screen).
One way to solve this is to at least treat dragging near the center of the screen as a simple rotation around the axis perpendicular to mouse motion. When dragging the mouse by the side of the screen (up-down near the side or left-right near the top/bottom), do the same but also gently rotate the previous rotation axis itself too. I've also noticed that the rotation does not exactly follow the mouse when the globe is zoomed in to show all the small airports in Europe.
https://i.imgur.com/izznX19.png Is this just an artifact of how the cells are rendered or some strange collection of airports off the coast of Africa. Thinking it must be the former..
Gorgeous! I did notice that the international date line is marked as a voronoi border from north to south pole. If you can do some modulo math trickery you should be able to fix this. You can find all of the cells/airports forming the border to the east of the date line and add fake airports to your data set with longitude 360 larger than the original cells. These will be used to create the correct voronoi border with the cells just to the east. Everything else will stay the same.
Thanks to the transparency of the globe I noticed this when @MereInterest pointed out the 0 0 coordinates of several airports.
By the way if you can find a way to add the airport call letters to the cell when clicked that would be amazing.
Thank you - I don't see any 0,0s in the source so I think it's something I need to take account for in the voronoi package - I'll add it to the list :)
if there aren't any 0 0 coordinate airports in the data set, maybe there are some strings that are not parsed as numbers and thus coerced to 0, a space or a non printing character (like a carriage return) can make something that looks like a number, not parse properly.
When I raise the Earth opacity to try and hide the opposite-side-of-the-globe cells, all the cells are hidden by the Earth layer, just purple dots left.
FWIW I see the same issue on the latest Chrome on MacOS. Maybe the cell boundary lines are ending up _just_ inside the globe's surface, and it's close enough that it ends up looking a little different on everybody's machine?
If that is the case, maybe a simple "tweak the radius of the Earth" dial might do the job :-)
Thanks and yep - I need to fix this. Tweaking works but introduces some other issues depending on the hardware - I have some ideas that I'll look at tonight.
Nice stuff, As a geographer who does things with spatial data I have a love/hate relationship with Voronoi maps. although they are an easy way to create territories they often look too mathematical for most people to use. Geography often matters. Although they can be useful for some purposes.
Nice fast webmap though :)
yea that sucks. Chrome and Firefox say they expect have webgpu behind a flag by end of year and if lucky shipping in stable by end of next. Apple is heavily involved but of course Apple never announces shipping plans
Nice, spherical geometry is sth. I always wanted to get into. Q: Shouldn't the lines be curved, i.e. the shortest path on a sphere is a minor arc of a great circle so shouldn't the lines in the voronoi be that as well?
They are curved hopefully. Most of them at least - when the line of a cell is longer than a certain amount, I interpolate the lat/lngs across the line and make more segments.
Make the rotation speed zoom dependent. Zooming in far shouldn’t increase the distance/sensitivity of rotation movements or velocity. Especially awkward on touch.
Most web browser maps translate my Mac's trackpad scroll events to zoom actions. Infuriating.
Only Apple's new MapKitJS does not do this.
I thought to make workaround using GreaseMonkey overrides, or whatever people do these days, but I don't do frontend stuff so would have start from scratch.
But it'd be nicer with earth's rotational axis staying in the same place.
In app.js, switching from THREE.TrackballControls to THREE.OrbitControls will make it behave like this:
https://threejs.org/examples/misc_controls_orbit.html