Winter break is over and as mentioned last week I got started by taking off some of the rougher edges around the location-based demand (LBD) feature which - as you might remember - was implemented in little more than a week right before Christmas
As a first visible measure, I adjusted the ground network tab of airport info pages to show the connected locations rather than other airports (which would always result in an empty list in game worlds with LBD enabled). Similarly, I changed the airport maps to show the connected locations as a sort of âhot spotsâ so one can get a picture of an airportâs catchment area.
Speaking of catchment area: Once I had the above changes finished and clicked around the game to see them in action, I immediately spotted all sorts of issues with the location data. Some examples:
The airport on the German island of Heligoland had no connected locations, a problem shared by many near-shore islands.
Airports like Newark had hundreds of nearby locations that should have been clustered to a handful of places.
The populations within the location catchment areas looked off for many places.
So I dove into what turned out to be quite the rabbit hole and revisited the âlocation clustering algorithmâ that I wrote for LBD. In short, this algorithm takes hundreds of thousands of real-world locations and âclustersâ them such that only a few thousand remain. It does this in a way such that âimportantâ locations remain and the populations of the âremovedâ locations get distributed among the nearby remaining ones. It does this until it canât reduce the locations any further (because no eligible neighbors remain) or a minimum amount of locations per country has been reached.
Given the limited information this algorithm works on, the process is riddled with edge-cases. I think I caught several of them, although I had to admit defeat when it came to properly representing islands. When you look at Heligoland in Wright after the release of the upcoming maintenance patch youâll find that its ground network still makes no sense. But Iâll revisit this by itself once I get around to the respective roadmap itemâŚ
those in the same âareaâ get merged (people travel to another airport closer to them, ignoring european borders) by distance, EXCEPT they have a different âislandgroupâ
leaving: merged âareasâ, still distinct âislandsâ
next step (more complicated)
list of exclusive border travels (NK <> SK both ways)
list of âdifficultâ border travels, maybe asymetrical! (look for need of visa or others!?)
(DE <> UK)
list of âeasyâ border travels (no visa / application needed)
merge having those in mind? (maybe you need to reinstall âground networkâ for border travels to represent the amount of time needed for the border affairs? but also for island â mainland connections?)
maybe if you cluster locations, also have a look at âtravel timesâ (âgoogle mapsâ) when merging? If you have obstacles (mountains, rivers, lakes) with few connections, they should tend to get longer? Do not merge by location but by travel time? (this would solve problems like FR UK)
Another approach:
make distinct âareasâ of the world (start at municipality-level), join them, BUT have all water areas also as areas that can not be joined!
(feel free to contact me, I work with geodata occasionally, maybe you can get a group of us for some âbrainstormingâ via teams?)
The algorithm currently works on country-level. As said, Schengen, islands etc. are topics for future work with their own roadmap item (linked in OP).
The root issue isnât the logic to apply (thatâs fairly straight forward), itâs the incomplete information one needs to work with. At the moment, I do not use any actual geodata (boundaries etc.) but merely âlocationsâ that, unfortunately, come with very little hierarchical information. So I know where they belong in terms of administration, but not geographically (beyond their coordinates). As such, âislandsâ do not exist in the data (neither the external location data, nor the internal airport data). Hence, a separate topic for which I will almost certainly work with land boundary data of some sort.
OSM seems to have âadministrative boundariesâ. You could intersect those with areas of water (or other barriers) to get a complete map of the world divided into areas which are either some administrative boundary OR unpassable..
(maybe i have a look and work on it just for funâŚ)
I do have the administrative boundaries. At least sort of, because locations refer to their administrative âparentsâ. But those often do not align with physical boundaries. Case in point: Many of the German islands in the North Sea belong to counties on landâŚjust from the administrative structure you wouldnât know itâs an island.
My rough idea (without having done that thing before) is to get landmass boundaries from somewhere, then intersect those with out location/airport point coordinates and this way figure out which places belong onto which landmass. This would likely be enough for out purposesâŚbut loads of edge-cases exist, for sure.
What I forgot to say: Please feel free to have a stab at this. I am not too experienced with this and have so far shied away from using âactualâ geo data. The locations I use atm are based on https://www.geonames.org/ data, which is rather limited (at least in the freely available version).
