Page MenuHomePhabricator

Replacements for,, not available
Closed, ResolvedPublic


I had noticed that (dewp's) Geohack's preview OSM map has stopped working, and @Strainu reported the failure of the, eh, pop-up-able OSM map at the top of wiki articles as well. This is due to the Toolforge project's tool "wiwosm" referring to, and which have stopped working as well. I'm not sure since when this does no longer work (cf. T85165).

I don't know what the difference between the three hosts was/is and why lists no instances for the Maps project while individual instance pages as for example seem to exist, but as that OSM plug-in currently just shows a blank canvas, it should be fixed really soon. This could either be done by setting up the redirects (again?) or patching the "wiwosm" tool.

Event Timeline

scfc created this task.Jun 21 2015, 5:05 PM
scfc raised the priority of this task from to High.
scfc updated the task description. (Show Details)
scfc added projects: Cloud-Services, Maps.
scfc added subscribers: scfc, Kolossos, Strainu.
Restricted Application added a project: Discovery. · View Herald TranscriptJun 21 2015, 5:05 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
scfc added a comment.Jun 21 2015, 6:01 PM

If I understood correctly, the Maps project is shut down until the NFS recovery is complete. So if & Co. are served by the Maps project, this task is effectively blocked by that circumstance.

MaxSem added a subscriber: MaxSem.Jun 21 2015, 6:12 PM

Note tht reinstating these domains have ceased making sense after all wikis were made HTTPS-only. As a result of that, a single subdomain would work faster - not only because TLS handshakes make multiple domains slower but also because SPDY/HTTP 2.0 make multiple requests to the same domain actually faster over HTTPS. So, instead of bringing the subdomains back, links to them should be eliminated instead.

If I understood correctly, the Maps project is shut down until the NFS recovery is complete. So if & Co. are served by the Maps project, this task is effectively blocked by that circumstance.

Can't we use the OSM tile servers as a temporary replacement? I remember some Wikimania talk in Gdansk about Wikimedia sites bringing too much traffic to those servers, but OSM has already upgraded their hardware several times in the last few years.

scfc added a comment.Jun 21 2015, 11:18 PM

AFAIUI, explicitly prohibits switching to OSM tile servers without their prior approval. And says:

It's upgrade time! OpenStreetMap is growing, servers are projected to hit capacity by mid 2015. […]

so the timing is bad :-).

Is there an ETA for the Maps project coming back online? This week?

(Assuming that the WMF tile server indeed is part of the Maps project.)

cmarqu added a subscriber: cmarqu.Jul 1 2015, 11:03 AM

I switch the standard tiles to

With only 100 Tile request/s we will be no problem for OSM. They have more datacenter than Wikimedia:

Kghbln added a comment.EditedJul 2 2015, 8:37 PM

I switch the standard tiles to

Does this mean that all the services relying on // such as the MapSources extension (T103073) will start working again after the switch was done? If yes this will be great!

Kolossos added a comment.EditedJul 3 2015, 5:41 AM

No I change only the scripts we have in production inside Wikipedia and Commons.
This doesn't also help maps that base on hikebikemap-tiles or blackwhite-map.

Krinkle added a subscriber: Krinkle.EditedSep 11 2015, 1:41 AM

This is causing SSL certificate warnings on production wikis at three levels:
-> "Kaart" (Map)

The widget makes requests to using protocol-relative urls (which expands to HTTPS now).


  1. This is responded to with the wrong certificate. instead of *
  1. It then redirects to insecure HTTP:

  1. The HTTPS variant of this uses an invalid certificate (* does not cover * Presumably this should use something like

Affirmative. The tiles are gone, e.g. on WikiVoyage.

Yurik added a subscriber: Yurik.Dec 21 2015, 6:46 PM

Would it make sense to switch dewiki to the new maps server, just like it-wiki, ru-wiki, en-wikivoyage and ru-wikivoyage did? Italian Wiki switch documented here (example). Russian wiki geohack looks like this, and their changes documented here.
P.S. I am not exactly sure who is maintaining the *

Would it make sense to switch dewiki

Perhaps it would. But what about all the other wikis out there not run by WMF?

Yurik added a subscriber: BBlack.Dec 21 2015, 8:27 PM

Perhaps it would. But what about all the other wikis out there not run by WMF?

I think we should enable access to the WMF maps tiles to the world as soon as we get more production servers in place, but we should have a separate discussion about that. @BBlack is looking at that.

scfc added a comment.Dec 22 2015, 2:37 AM

IMHO all maps should use the new maps server. Personally I'm more interested in the in-article-pop-up-thingy (i. e. the frame for example for as it is very useful to get an immediate feeling for where the subject of an article is located.

Yurik added a comment.Dec 22 2015, 2:53 AM

@scfc - I'm working on that as part of the Kartographer extension. See demo here. (it can be made into a popup fairly easily later)

There are services other than Wikis that are using some of these tiles (I can only speak for the hikebike and hillshading tiles), like KDE Marble, and web pages like - they were in contact with previous admins and got told it wouldn't be a problem to deliver these tiles through them. Actually, there was even extra work done to accommodate these services during the switchover to wmflabs.
While this probably wasn't a proper service level agreement, I'm kinda surprised to see the toolserver replacement go so soon.

I'm kinda surprised to see the toolserver replacement go so soon.

This implies that there were plans form the start to cease this service. I there any spot were somebody not following this topic on a daily basis can read about this. Was there some kind of announcement. I feel like having had a migration time without being told about it. In June the status was that this service will be move to and that's it. This seems to be a very desagrable situation. I am pretty saddened to tell the truth.

Yurik added a comment.Dec 22 2015, 1:49 PM

I don't think this was intentional--at least I haven't heard of these boxes being scheduled to go down. I would think it's a bug somewhere, and simply needs someone who knows about this service to look at it.

I attempted to log into the main instance for this, but it just timed out. Are any maintainers able to log in?

NB: strictly speaking, WMF Labs run on donated money, so third parties shouldn't make any demands as whatever traffic/hardware they're utilizing is paid for with money donated for the upkeep of Wikimedia projects.

I 've rebooted the instance that serves those tiles, seems like it suffered a partial freeze due to an NFS outage earlier this week which cause the instance to be mostly unresponsive (could not login via ssh, obviously HTTP requests would not work etc). Seems like it is serving tiles fine again. Tested with

Thanks very much! That seems to also have triggered the process that is re-rendering the tiles when requesting so (i.e. with /dirty at the end of a single tile's URL).
I'm not sure whether we ever had an automatic tile expiration process set up or if that was just ideas floating around on the mailing list... I'll try to keep an eye on it, but maybe I should rather port over the hikebikemap style to work with the "new setup".

Yurik added a comment.Jan 26 2016, 9:51 AM

@cmarqu, Italian and Russian wikis have already switched GeoHack to the much more stable, and English should be switched soon as well (demo) - have you considered switching DE wiki?

  • GeoTemplate (you can try it in a sandbox first)
  • GeoHack.js -- IT & RU wiki's javascript code is more up to date than EN
Kghbln added a comment.EditedJan 26 2016, 10:04 AM

@Yurik WikiVoyage is using the MapSources extension which in turn depends on this service via the slippymap tag. What should WikiVoyage do?

@Kghbln, en & ru wikivoyage has already switched to the new maps (example). If MapSources/slippymap uses leaflet or openlayers to get tiles, it should be fairly trivial to retarget them to the new service. Btw, I am not saying we should kill all maps experimentation in labs -- au contraire -- labs is what feeds new development. But labs are by their nature much less stable and prone to issues, thus projects should migrate to production as soon as they are ready.

apache was not working for some reason. Fixed, I am investigating what happened

@Yurik , @Kolossos , the main reason I prefer to keep the way they are now on ro.wp is the lack of other points except the current one on the map, like for kml-on-ol.php Do you have any examples on how to do that or, can you move that service to serve tiles from maps.Wikimedia.Org?

@Strainu, the only offers tile service, just like the (a|b|c), so swapping one for another should not change the functionality like pushpins and extra layers added by kml-on-ol. For example, you can see it by switching between different backgrounds of the wiwosm kml tool by clicking the little "+" sign in the top right, and switching to "maps.wikimedia".

@Yurik Thanks for your insight.

If MapSources/slippymap uses leaflet or openlayers to get tiles

Yeah the slippymap tag uses openlayers to get the tiles. Probably it will be a good idea to create a task for it so that the tiles are picked up from the new location at Keeping fingers crossed.

Yurik moved this task from All map-related tasks to Related on the Maps board.Feb 7 2016, 10:23 PM
Deskana moved this task from Needs triage to Maps on the Discovery board.Feb 26 2016, 7:02 PM
scfc added a comment.Mar 19 2016, 2:19 AM

@scfc - I'm working on that as part of the Kartographer extension. See demo here. (it can be made into a popup fairly easily later)

I suppose that would be the <maplink> tag? Is there an existing task that tracks converting the current gadget(s) to use Kartographer or should I create one?

Dzahn added a subscriber: Dzahn.May 16 2016, 10:44 PM

I just noticed there are still a lot of hits for these on the toolserver-legacy instance, there are requests for a.toolserver, b.toolserver c.toolserver from a 3rd party Android app *User agent: Dalvik".

apache was not working for some reason. Fixed, I am investigating what happened

Could you please give it a kick again? (Yesterday, after some time of outage, it started working again, but today, it seems to be more prolonged.)

@madhuvishy Probably an aftermath of the migration ? Is it done (and the only thing required is a VM reboot)? Or not yet ?

@akosiaris The migration is all done

Works gain, thanks.

I 've restarted maps-tiles3 VM on the maps project for what is worth.

Krinkle removed a subscriber: Krinkle.
Yurik moved this task from Related to Tracking on the Maps board.Dec 6 2016, 3:33 PM
MaxSem closed this task as Resolved.Nov 29 2018, 1:40 AM
MaxSem claimed this task.

There is a tileserver now at at, so in that regard this ticket is done. If providing back-compat for DNS records is also wanted, that stopped working over 3 years ago so fixing it doesn't make much sense.