Btw, so far i understand you can still do work for editing the database and prepare your uploads (e.g. using the iD-editor: OpenStreetMap)
Save your finished changeset before uploading in different osmchange-files (bottom left corner by “Download osmChange file”-function and upload it later by using JOSM.
It would be nice if uploading an osmChange file would be also supported by the iD editor, perhaps this break could be used to implement the (long pending) corresponding issue, see:
Ah okay, otherwise I’d ask if you’ve thought of setting up a tunnel that connects Dublin to Amsterdam over the 4G link and let it carry out its automatic replication that way, which would (as far as I understand it) eliminate the finicky data-loss-prone manual intervention.
It seems a very sensible decision had been made to have dual-redundant links to the ISP.
However the ISP basically then shafted us by making both those links go to a single point of failure (which then failed).
The general way to mitigate risks like this is to have a robust due diligence process for checking out third-party suppliers and good lawyers for checking their T&Cs. But robust due diligence is time consuming and good lawyers are expensive.
If you’re referring to edits that mappers would’ve made in the moment but later forgot about or lost the motivation to perform, there are some offline editors for OSM, though it can be dicey if you happen to edit in a popular area where you might get edit conflicts. Maybe a good reason to try mapping a region where there’s only sparse coverage. Like pick a place that has no landuse coverage and have a field day offline. Alternatively, OpenHistoricalMap could serve as a staging ground for more time-sensitive edits you don’t want to lose track of, or a way to scratch your mapping itch if you’re mourning your editing streak.
For completeness, you’ll also be also to upload an OSC or osmChange file in Level0 once the database is writable again.
potential new editors that will not be able to register for OpenStreetMap due to new registrations being disabled during read-only mode, and thus might decide to forego joining the project altogether (Can you even log on right now? If not, that presents an even bigger hurdle if you don’t happen to have an OAuth2 token saved in JOSM)
some mappers (like me) who have decided to stop surveying as long as the project is in this state with not even an ETA on when editing will be available again, and also being unwilling to let changes sit on the hard drive for days or (potentially) weeks. Especially in the case of relations, which tend to get edited a lot and are a guarantee for edit conflicts even on a live map, saving your edits locally is not a good workaround.
Keep your feet still and enjoy the temporary digital detox… Gather your thoughts for the next, really important tasks. All in all, I don’t think this unintentional forced break is such a bad thing.
The admins will do their very best… (within the scope of their possibilities)… The learning effect will benefit us all… Let’s enjoy the pre-Christmas period!
I wonder, with such a long outage what’s gonna happen when the floodgates finally open. Will there be overloads? Or massive conflicts due to simultaneous uploads? Who knows.
There have been some other multi-day disruptions in the past. I don’t recall hearing about any major technical problems, though there might be some local logistical challenges in places where mappers already tend to get edit conflicts.
By the way, I’ve heard of some mappers keeping an iD browser tab open for a few days. I would recommend exporting the osmChange file as a backup, so you aren’t totally dependent on browser session restoration and iD’s merge conflict resolver.
We should have all service back by the European evening tomorrow (Tuesday). We are switching to the new ISP.
(Minor matter of me having to get new ISP setup working on our routers with some virtual networking required for simultaneous upstream ISPs, and some special VRRP setup required for the new ISP redundancy setup)
I don’t think this is possible at the moment. The sessions were closed and it is not possible to log in OSM iD. Once the problem is solved, all that remains is to cross your fingers and log back in and wait for the OSM iD notice= “You want to restore unsaved changes from the previous session”
OSM iD development mirrors work but also do not allow login.
So ultimately, if OSM iD is not working at this time there will be no way to access the OSC file export menu which requires a login beforehand.
That being said, thanks Vespucci for handling offline mapping well and allowing us multiple options to support our edits.
If editing with the JOSM Editor, a good practice if you kept the data offline for a while is to select Menu option File / Update modified before uploading the changeset to the server.
When you download specific features like waterways, you need some Sanitation practices to avoid conflicts. After the download of specific objecs, you should selet the menu Option File / Download parent ways/relations. This avoids frustration moving to the sky when conflicts management where for example a node is shared by many objects.
Thanx for the hard work. i have been in the situation that trusted parties did not honour their water tight contracts with penalty clauses; instead they rather paid the fines because that was cheaper than total redundancy.
Thanx for the JOSM advice. I have a considerable ‘forward log’, I hope to get it uploaded soon!
It should not be a problem for data you did not update. When you want to reduce the OSM file size after you downloaded data, you should use the Menu option Edit / Purge (and not delete ) to remove some selected data from the file.
Pssst: We have working IPv4 routing in Amsterdam with new ISP.
Basic config applied to router and single host so far.
IPv6 is broken, reported already to new ISP. Looks like they forgot to allocate a subnet. IPv6 router subnet works, but missing the “public” IPv6 subnet.
I’m off to bed, and will add missing VRRP bits and improve config tomorrow.
) to remove some selected data from the file.