This isn't a novel thing, as far as I can tell. A decade ago when I was working on routing of over-the-road trucking, our maps provider moved the entire United States a couple meters and it broke all our road restrictions.
The problem for us -- and likely for those in Australia now -- is that converting physical address descriptions and lat/long becomes a little more fraught. We described road restrictions as being "on the road that is found between X1,Y1 and X2,Y2." A separate layer would snap those X,Y coordinates to the road network and find the road between them. Before the move, that meant converting to "Highway 6 Southbound from milemarker 16 to milemarker 28"
But when you moved the world, X1,Y1 no longer landed on Highway 6, and instead snapped over to the frontage road. Your restriction now read as "Highway 6 Southbound, down to exit 21, around the corner to the frontage road, then down the frontage road". And your restriction that used to say "stay off this one section of road" now says "stay off the highway, the frontage road, and don't use this exit."
While the problem isn't novel, that's probably not what happened with what you're describing, for a number of reasons.
Most local datums are anchored to the local geology. So in the US, if you're using nad27 or nad83, the reference system is "moving" along with the continent (nad83 = North American Datum 1983), based on some weighted benchmark vectors and a lot of math. It's one reason why different datums with defined epochs exist. Some are static, but some are actually dynamic with time (eg ITRF).
But most people don't grok any of that and just stick with defaults, or guess-and-check during map setup and go with whatever looks "close enough".
In your case, chances are the map provider switched datums with the update, from nad27 to nad83, and your software wasn't told about the change. Or it was, but your road restriction data was drawn in the old projection, and not converted / transformed to the new one.
Or, you could have had data that initially was mislabeled, recorded with GPS (wgs84) and entered using one of the many datums that's similar, but not the same. Or maybe collected using one of the many state plane coordinate systems (which people tend to like because it's more or less Cartesian- east,north) which are themselves built in top of one of the datums. You can pick the right coordinate zone, but wrong underlying datum.
If any data provider or aggregator or if your company GIS guru ever selected the wrong projection (choices often are dozens of coded options that look nearly identical), or left it blank (undefined) because they weren't sure...
A instant "shift" would happen as soon as you "corrected" the error, (or upgraded software, or any other number of situations).
This is where a good GIS guru earns their keep, because conversions between projections and datums are just math, and data can often be corrected in seconds by running it through a manual "inverse" conversion, assuming one can recognize what happened.
Back to Australia: if people used GPS coordinates (wgs84) and didn't convert to a Australian centric datum (which is the default option for most collectors), the data would "stay still" while the continent moves. Which is one of many reasons why selecting an appropriate datum/ projection is so important.
For the US: While there is some intra-datum movement between nad27 and nad83, most of the differences are do to improvements in the quality and accuracy of surveys over half a century. So the differences between the two datums tend to grow as you get further from the beginning points of the surveys.
Which means some areas, like a lot of the East coast, have minimal differences, and areas out West have larger deltas, but it varies.
A couple of meters would be better explained by a bad datum transformation than by drift, which is likely an order of magnitude smaller at even the worst locations for the US.
The ADA requires 'paratransit' service for persons whose disabilities prevent them from using accessible, non-commuter, fixed route bus service. In many cities paratransit is handed off to taxi services.
>When your router receives a non-static DHCP assigned IP address from your ISP there is a pre-defined time limit built into the assignment, this time limit is called a DHCP Lease. The typical lease time for ISP’s in the United States is roughly 7 days. However in most instances your router will renegotiate this lease prior to its expiration. During the lease renegotiation, it is very common for the same IP to be reassigned to your router. In fact our research has discovered many homes that have theoretically dynamic IP’s, but have held the same IP for multiple years. Because of this recursive reassignment the typical location targeted by El Toro has held the same IP address for 7 months.
It seems a typical location has the same ip address for around 7 months and can indeed have the same address for far longer if your service isn't interrupted, you don't change or reboot networking hardware, and you don't try to connect to the game from your laptop at your friends house.
My current ISP in the UK and my previous one in France are changing IPs every few weeks or so in practice, or when the box is rebooted, or when the connection is lost for a while between the box and the ISP.
The game server would prevent many (most?) players by whitelisting IPs, but I bet they couldn't care less about blocking players or they wouldn't require whitelisting in the first place.
I assume you can't log in using a user/pass in that server, that's why they use IP addresses. But you could have a web interface where you can log in, and that would communicate with the game server to add your current IP to the whitelist.
I've had the same v4 address with ATT for over a year. It's technically possible for a dhcp server to deny a renew and have the client initiate a discover to be given a different IP but in practice that would break everyone's active connections each time so ISPs just let DHCP renew until you stop asking.
For something with the user population of a community game server you could also allow the full subnet and probably never run into a user collision.
Would be cool to just accept a DNS instead. Servers could poll it at a fixed interval to update whitelists and clients can run a DNS updater, i.e no-ip.
Merely that a coating that retains total choice in colours is more flexible than one that limits the range of colours possible.
And presumably that's part of the contribution here - a nonstick toilet that doesn't look like the ones you get on planes and trains already.
Also, the current fashion in my country is for white toilets - you go to a bathroom showroom, ~95% of what's on display will be white. A design that doesn't require a change in fashions is simpler than one that needs tastes to change.
I've been pondering the same economics on car-, bike- and scooter- shares. I'd love to know if Car2Go's ridiculous little SMART cars were treated better or worse than their Benz replacements. I wonder if Lime's electric bikes get shoved off the pier less than Ofo's cheapest ones.
What you saw as a positive feature, I saw as the death of Friendster. My friend added "The Burning Man" as her friend, and I suddenly had thousands of friends neither of us had ever actually met. The activity of this pool completely swamped the output of any of the 'friends' I would actually meet up with. I had a HUGE network, but no friends on Friendster.
This wasn't entirely bad to meet up with people outside of your circles, but you needed some way to control the firehose. And, you know, I think that's still not a solved problem. I think I would be more keen on social networks filtering me feed if I had more control over those filters.
Or worse, if you accidentally find this feature, will you know what you just did? Or will you suddenly be dumped into somewhere that looks like it is still a web browser but has suddenly stopped responding like one.
It reminds me of all the old Windows users accidentally dragging their start-bar and covering the whole screen.
The problem for us -- and likely for those in Australia now -- is that converting physical address descriptions and lat/long becomes a little more fraught. We described road restrictions as being "on the road that is found between X1,Y1 and X2,Y2." A separate layer would snap those X,Y coordinates to the road network and find the road between them. Before the move, that meant converting to "Highway 6 Southbound from milemarker 16 to milemarker 28"
But when you moved the world, X1,Y1 no longer landed on Highway 6, and instead snapped over to the frontage road. Your restriction now read as "Highway 6 Southbound, down to exit 21, around the corner to the frontage road, then down the frontage road". And your restriction that used to say "stay off this one section of road" now says "stay off the highway, the frontage road, and don't use this exit."