GNOME Bugzilla – Bug 769352
Tile loading is slow after the switch to mapbox provided tiles via a proxy
Last modified: 2016-08-24 11:50:20 UTC
Loading of tiles (which have not been cached before) is slow after the switch away from the MapQuest Tile Server. Mattias Bengtsson (https://bugzilla.gnome.org/show_bug.cgi?id=764841#c51) created screencasts to demonstrate the effect. It seems that the proxy server creates a significant increase in loading times: with proxy: https://www.youtube.com/watch?v=UtZM4IuWOOk without proxy: https://www.youtube.com/watch?v=Q3cgopji3qw
On note on caching: The "problem" is, that gnome-maps is so good, that I have switched away from other offers, to use it almost exclusively, e.g. also for routing. For that use case, caching of tiles is of little help, because I often go to places I have never been to before.
Relaying a suggestion from the other bug report: GNOME Maps could download a (signed) file from gnome.org that provided the details of the tile server, allowing a change in tile server without updating the client (assuming the API remains similar enough).
(In reply to Josh Triplett from comment #2) > Relaying a suggestion from the other bug report: GNOME Maps could download a > (signed) file from gnome.org that provided the details of the tile server, > allowing a change in tile server without updating the client (assuming the > API remains similar enough). (backporting technical) If that changes is contained to the new file mapSource.js then backporting all the way back to 3.14 should be trivial
Perhaps there should be the addition of a feature which allows the user to choose to download and cache all tiles at once instead of the current way it works? Or perhaps even the user should be able to select a region to download all tiles for if they want to? I don't know, but that could be a solution at least for those who wouldn't mind that, and being able to select the region for such a download would be useful too if they want that.
Please see https://bugzilla.gnome.org/show_bug.cgi?id=708799 for offline maps.
Downloading and caching map tiles doesn't solve the latency problem caused by the proxy when browsing new areas.
So yes, I like the idea of downloading a service file that tells us what the tile URIs are... Up to a point. I dislike the extra complexity of it. That it is another point of failure. But really so was the proxy. It needs some thought around the implementation, so I am happy that we released first with the proxy in place. To stop being dead in the water. And I also think the proxy should stay. And applications such as Contacts, or Shotwell or other applications that "just" want to display a map of a loction can stick with using the proxy, so that their solution is less complex, makes sense? Great work Mattias! Will you continue looking in to this service file plan? PS. Does the fact that the indirection (proxy) add _that_ much latency mean that the actual downloading of the tile is negligible?
> It needs some thought around the implementation, so I am happy that we released first with the proxy in place. To stop being dead in the water. Absolutely agreed. > And I also think the proxy should stay. And applications such as Contacts, or Shotwell or other applications that "just" want to display a map of a loction can stick with using the proxy, so that their solution is less complex, makes sense? What about having those applications contact gnome-maps via DBus and let it do the work for them? That would handle it locally, and allow those applications to use cached map tiles that gnome-maps already has.
> What about having those applications contact gnome-maps via DBus and let it do the work for them? That would handle it locally, and allow those applications to use cached map tiles that gnome-maps already has. What about if the user doesn't want to have gnome-maps installed? I'm not sure that we should create such a dependency.
Something more central could be created to download and store the tiles for these applications, and they could communicate with this central application in such a way as you have described. But it would be reliant on any one of them actually being installed. Unless I am misunderstanding you?
(In reply to Josh Triplett from comment #8) > > It needs some thought around the implementation, so I am happy that we released first with the proxy in place. To stop being dead in the water. > > Absolutely agreed. > > > And I also think the proxy should stay. And applications such as Contacts, or Shotwell or other applications that "just" want to display a map of a loction can stick with using the proxy, so that their solution is less complex, makes sense? > > What about having those applications contact gnome-maps via DBus and let it > do the work for them? That would handle it locally, and allow those > applications to use cached map tiles that gnome-maps already has. I am not sure. It would change Maps role from being an app to being infrastructure. It feels more like libchamplains role. And the cache is already shared from your XDG cache dir. So it would be used. But I am not totally against it, it would allow us to avoid doing our own map source setup that would look similar in all apps. But how would it actually work? What work would Maps do via DBus? Would we return an image somehow? That corresponds to the area we want? It would be much slower. In the end maybe it would be easier for each map to do this. Or to have Maps release a public library along with its private C library. That would have functions for setting up the URI / source. Not sure.
(In reply to cooks.go.hungry from comment #9) > What about if the user doesn't want to have gnome-maps installed? I'm not > sure that we should create such a dependency. Just for the record: GNOME Maps was recently added to GNOME core, which means GNOME applications can assume it will always be installed. It's always good to have fallback paths in place for use outside of GNOME, but not required. I'm not recommending this, just saying it's a permissible thing that can be done.
It doesn't necessarily have to be the full gnome-maps UI; it could be a backend service that gnome-maps also uses. I think it makes sense to have mapping infrastructure available. For instance, a calendar location field might offer a link to open a map, but could also show an inline preview. This may want to integrate with libchamplain, which could contact that service. If desired, it could always include a fallback for the case where it can't contact the service, but that adds complexity compared to just requiring the service.
(In reply to Jonas Danielsson from comment #7) [...] > Great work Mattias! Will you continue looking in to this service file plan? Yeah, I started looking at it today and maybe I will continue tomorrow. I might need a day or two of rest though, the last few weeks have felt hectic. > PS. Does the fact that the indirection (proxy) add _that_ much latency mean > that the actual downloading of the tile is negligible? I have no idea actually. How would you measure that?
Due to the slow loading of tiles, I see another performance "problem": Tiles loading seems to happen one after the other. Given the overhead of http, wouldn't performance increase starting a fixed number (4?) of or all tiles at the same time? HTTP pipelining or HTTP/2 might also increase performance and reduce overhead. Maybe worth of another bug report...?
(In reply to Dominik Grafenhofer from comment #15) > Due to the slow loading of tiles, I see another performance "problem": Tiles > loading seems to happen one after the other. Given the overhead of http, > wouldn't performance increase starting a fixed number (4?) of or all tiles > at the same time? HTTP pipelining or HTTP/2 might also increase performance > and reduce overhead. Maybe worth of another bug report...? Yes! We have talked about that. Please file. But against libchamplain not GNONE Maps since right now we use vanills network tile source from them! Thanks
See here for the newly filed parallel download bugreport: https://bugzilla.gnome.org/show_bug.cgi?id=769417 Thanks!
It's not a problem in libchamplain - this is because of OSM tile service policy - more here: https://bugzilla.gnome.org/show_bug.cgi?id=769417
Created attachment 332739 [details] Chromium Network Inspection for a tile download (In reply to Mattias Bengtsson from comment #14) > (In reply to Jonas Danielsson from comment #7) > [...] > > Great work Mattias! Will you continue looking in to this service file plan? > > Yeah, I started looking at it today and maybe I will continue tomorrow. I > might need a day or two of rest though, the last few weeks have felt hectic. > > > PS. Does the fact that the indirection (proxy) add _that_ much latency mean > > that the actual downloading of the tile is negligible? > > I have no idea actually. How would you measure that? Using Chromium, maybe (see attachment). Ping is anyways quite high, I guess the server is located somewhere in the U.S., that's what it looks like from Germany: florian-laptop (0.0.0.0) Thu Aug 4 18:00:30 2016 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. xxxxxxxxxxxxxx 0.0% 17 27.2 27.0 3.0 34.9 6.4 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.de 2. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.de 0.0% 17 27.9 28.3 27.4 36.5 2.1 3. xxxxxxxxxxxxxx 50.0% 17 28.0 29.3 27.8 35.4 2.6 4. xxxxxxxxxxxxxx 46.7% 16 28.8 30.0 28.4 32.1 1.4 5. xxxxxxxxxxxxxx 0.0% 16 28.9 29.8 27.8 32.0 1.1 6. xxxxxxxxxxxxxx 0.0% 16 31.0 31.0 30.6 31.5 0.0 7. xe-1-2-0.mpr1.fra4.de.above.net 0.0% 16 32.0 31.3 30.4 32.6 0.3 8. ae27.cs1.fra9.de.eth.zayo.com 0.0% 16 163.5 163.1 162.6 163.6 0.0 9. ae0.cs1.fra6.de.eth.zayo.com 0.0% 16 163.0 163.4 162.1 166.6 0.9 10. ae2.cs1.ams17.nl.eth.zayo.com 0.0% 16 163.5 167.5 162.9 208.3 11.3 11. ae0.cs1.ams10.nl.eth.zayo.com 0.0% 16 166.8 166.5 165.8 169.5 0.7 12. ae2.cs1.lhr15.uk.eth.zayo.com 0.0% 16 166.4 166.8 165.9 167.6 0.0 13. ae5.cs1.dca2.us.eth.zayo.com 0.0% 16 169.6 176.3 168.9 204.1 13.1 14. ae0.cs2.dca2.us.eth.zayo.com 0.0% 16 169.6 180.8 167.4 229.2 18.0 15. ae3.cs2.iah1.us.eth.zayo.com 0.0% 16 181.2 170.8 164.8 200.6 9.5 16. ae27.cr2.iah1.us.zip.zayo.com 0.0% 16 139.0 140.0 138.8 145.1 1.3 17. ae6.mpr4.phx2.us.zip.zayo.com 0.0% 16 166.1 167.3 166.1 172.5 1.7 18. ae4.mpr3.phx2.us.zip.zayo.com 0.0% 16 166.5 166.2 165.7 166.8 0.0 19. 208.184.108.38.IPYX-072053-007-ZYO.above.net 0.0% 16 166.6 166.5 165.1 167.3 0.4 20. border1.po1-bbnet1.phx004.pnap.net 0.0% 16 170.1 171.6 169.7 188.0 4.3 21. redhat-2.border1.phx004.pnap.net 0.0% 16 210.1 212.1 207.1 230.1 6.0 22. tx-160-181-132-209.redhat.com 0.0% 16 209.5 204.7 203.6 209.5 1.4 23. transit-28-180-132-209.redhat.com 0.0% 16 209.3 204.2 202.5 209.3 1.4 24. proxy01.gnome.org 0.0% 16 204.0 203.8 201.6 204.7 0.8 Using gnome-maps has become really painful (on non-American continents at least).
Yeah, I understand that. We're working on a solution. Not sure if it can be backported though. :/ Shipping software on Linux, really sucks. I hope flatpak will be the norm for application distribution in a year or two.
Does the proxy cache tiles? If so, how long does it keep them before checking for updated copies from the parent tile server? Thank you.
It does not cache.
Just an idea but wouldn't it be possible to query the gnome server only once at the beginning and then have direct connection to the mapbox server until the user ends the Maps application? The initial query to the gnome server would retrieve the tile URL template such as https://a.tiles.mapbox.com/v4/mapbox.streets/#Z#/#X#/#Y#.png?access_token=my_token and use it to initialize the network tile source. This way you'd still have the flexibility of changing the map source in the future but also avoid the delays caused by the proxy in the middle.
(In reply to Jiri Techet from comment #24) > Just an idea but wouldn't it be possible to query the gnome server only once > at the beginning and then have direct connection to the mapbox server until > the user ends the Maps application? The initial query to the gnome server > would retrieve the tile URL template such as > > https://a.tiles.mapbox.com/v4/mapbox.streets/#Z#/#X#/#Y#. > png?access_token=my_token > > and use it to initialize the network tile source. This way you'd still have > the flexibility of changing the map source in the future but also avoid the > delays caused by the proxy in the middle. Yes. I think this is the plan. But also get license. Name (for cache) and base64 attribution logo and max http conns and so.
(In reply to Mattias Bengtsson from comment #23) > It does not cache. But we do cache locally via libchamplain.
(In reply to Jonas Danielsson from comment #27) > (In reply to Mattias Bengtsson from comment #23) > > It does not cache. > > But we do cache locally via libchamplain. I meant at the proxy level.
*** Bug 769770 has been marked as a duplicate of this bug. ***
Created attachment 333438 [details] [review] mapSource: Get tile server information from service.json Attempt to download a service.json file from gnome.org. The file will define all information needed to create a libchamplain source. This will help us to change the tile-server without needing to update the application. If the call to gnome.org fails. Fallback to a default service.json.
Created attachment 333439 [details] [review] Add print tile service Use the print style from the service.json file for the print source. Right now it is same as street style. But gives us the possibility of having a special print style later.
I think I also want to make the logo a GtkClutterActor so that we get transparency. We already have explicit and implicit dependencies on Clutter and GtkClutter.
Created attachment 333484 [details] [review] Use GtkClutter for attribution logo
Created attachment 333485 [details] [review] Use GtkClutter for attribution logo
Created attachment 333487 [details] [review] mapSource: Get tile server information from service.json Attempt to download a service.json file from gnome.org. The file will define all information needed to create a libchamplain source. This will help us to change the tile-server without needing to update the application. If the call to gnome.org fails. Fallback to a default service.json.
Created attachment 333488 [details] [review] Add print tile service Use the print style from the service.json file for the print source. Right now it is same as street style. But gives us the possibility of having a special print style later.
Created attachment 333489 [details] [review] Use GtkClutter for attribution logo
Created attachment 333537 [details] [review] mapSource: Get tile server information from service.json Attempt to download a service.json file from gnome.org. The file will define all information needed to create a libchamplain source. This will help us to change the tile-server without needing to update the application. If the call to gnome.org fails. Fallback to a default service.json.
Created attachment 333538 [details] [review] Add print tile service Use the print style from the service.json file for the print source. Right now it is same as street style. But gives us the possibility of having a special print style later.
Created attachment 333539 [details] [review] Use GtkClutter for attribution logo
Created attachment 333580 [details] [review] mapSource: Get tile server information from service.json Attempt to download a service.json file from gnome.org. The file will define all information needed to create a libchamplain source. This will help us to change the tile-server without needing to update the application. If the call to gnome.org fails. Fallback to a default service.json.
Created attachment 333581 [details] [review] Add print tile service Use the print style from the service.json file for the print source. Right now it is same as street style. But gives us the possibility of having a special print style later.
Created attachment 333582 [details] [review] Use GtkClutter for attribution logo
Created attachment 333584 [details] [review] mapSource: Get tile server information from service.json Attempt to download a service.json file from gnome.org. The file will define all information needed to create a libchamplain source. This will help us to change the tile-server without needing to update the application. If the call to gnome.org fails. Fallback to a default service.json.
Created attachment 333585 [details] [review] Add print tile service Use the print style from the service.json file for the print source. Right now it is same as street style. But gives us the possibility of having a special print style later.
Created attachment 333586 [details] [review] Use GtkClutter for attribution logo
Review of attachment 333584 [details] [review]: ::: src/mapSource.js @@ +72,3 @@ +function _getTileService() { + if (_tileService) + return _tileService; Not sure if I've missed something here, but isn't it the case that _tileService is never assigned, so this will never be triggered and the service file is re-download the service file?
Review of attachment 333585 [details] [review]: LGTM
One general comment is that I really want the --service-definition or w/e flag back as a means to test a service definition before deploying it.
Review of attachment 333584 [details] [review]: I'll look at this more thorughly tomorrow. ::: data/maps-service.json @@ +8,3 @@ + "max_zoom_level": 19, + "tile_size": 256, + "uri": "https://a.tiles.mapbox.com/v4/mapbox.streets/#Z#/#X#/#Y#.png?access_token=pk.eyJ1IjoiZ25vbWUtbWFwcyIsImEiOiJjaXF3a3lwbXkwMDJwaTBubmZlaGk4cDZ6In0.8aukTfgjzeqATA8eNItPJA&", Let this be uri_format to be consistent with Champlain. @@ +37,3 @@ + "attribution_logo": "PHN2ZyB4bWxuczpkYz0iaHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8iIHhtbG5zOmNjPSJodHRwOi8vY3JlYXRpdmVjb21tb25zLm9yZy9ucyMiIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyIgeG1sbnM6c3ZnPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB2ZXJzaW9uPSIxLjEiIHdpZHRoPSI2NSIgaGVpZ2h0PSIyMCI+PGRlZnMvPjxtZXRhZGF0YT48cmRmOlJERj48Y2M6V29yayByZGY6YWJvdXQ9IiI+PGRjOmZvcm1hdD5pbWFnZS9zdmcreG1sPC9kYzpmb3JtYXQ+PGRjOnR5cGUgcmRmOnJlc291cmNlPSJodHRwOi8vcHVybC5vcmcvZGMvZGNtaXR5cGUvU3RpbGxJbWFnZSIvPjxkYzp0aXRsZS8+PC9jYzpXb3JrPjwvcmRmOlJERj48L21ldGFkYXRhPjxnIHRyYW5zZm9ybT0idHJhbnNsYXRlKC0yNjEuODQ4MywtOTguNTAzOTUpIj48ZyB0cmFuc2Zvcm09Im1hdHJpeCgwLjE3NDQxODM2LDAsMCwwLjE3NDQxODM2LDIyMC41MjI4MiwyOS4yMjkzNDIpIiBzdHlsZT0ib3BhY2l0eTowLjI1O2ZpbGw6I2ZmZmZmZjtzdHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MTcuMjAwMDIzNjU7c3Ryb2tlLWxpbmVjYXA6cm91bmQ7c3Ryb2tlLWxpbmVqb2luOnJvdW5kO3N0cm9rZS1taXRlcmxpbWl0OjQ7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtZGFzaGFycmF5Om5vbmUiPjxwYXRoIGQ9Ik0gNS4yOCAxLjUgQyA0LjU0IDEuNTYgMy45IDIuMjUgMy45MSAzIGwgMCAxMS44OCBjIDAuMDIgMC43NyAwLjcyIDEuNDcgMS41IDEuNDcgbCAxLjc1IDAgYyAwLjc4IDAgMS40OCAtMC42OSAxLjUgLTEuNDcgbCAwIC00LjI4IDAuNzIgMS4xOSBjIDAuNTMgMC44NyAyLjAzIDAuODcgMi41NiAwIGwgMC43MiAtMS4xOSAwIDQuMjggYyAwLjAyIDAuNzYgMC43IDEuNDUgMS40NyAxLjQ3IGwgMS43NSAwIGMgMC43OCAwIDEuNDggLTAuNjkgMS41IC0xLjQ3IGwgMCAtMC4xNiBjIDEuMDIgMS4xMiAyLjQ2IDEuODEgNC4wOSAxLjgxIGwgNC4wOSAwIDAgMS40NyBjIC0wIDAuNzggMC42OSAxLjQ4IDEuNDcgMS41IGwgMS43NSAwIGMgMC43OSAtMCAxLjUgLTAuNzEgMS41IC0xLjUgbCAwLjAyIC0xLjQ3IGMgMS43MiAwIDMuMDggLTAuNjQgNC4xNCAtMS42OSBsIDAgMC4xOSBjIDAgMC4zOSAwLjE2IDAuNzkgMC40NCAxLjA2IDAuMjggMC4yOCAwLjY3IDAuNDQgMS4wNiAwLjQ0IGwgMy4zMSAwIGMgMi4wMyAwIDMuODUgLTEuMDYgNC45MSAtMi42OSAxLjA1IDEuNjEgMi44NCAyLjY5IDQuODggMi42OSAxLjAzIDAgMS45OCAtMC4yNyAyLjgxIC0wLjc1IDAuMjggMC4zNSAwLjczIDAuNTcgMS4xOSAwLjU2IGwgMi4xMiAwIGMgMC40OCAwLjAxIDAuOTcgLTAuMjMgMS4yNSAtMC42MiBsIDAuOTEgLTEuMjggMC45MSAxLjI4IGMgMC4yOCAwLjM5IDAuNzQgMC42MyAxLjIyIDAuNjIgbCAyLjE2IDAgQyA2Mi42NyAxNi4zMyA2My40MiAxNC44OSA2Mi44MSAxNCBMIDYwLjIyIDEwLjM4IDYyLjYyIDcgQyA2My4yNiA2LjExIDYyLjUgNC42MiA2MS40MSA0LjYyIGwgLTIuMTYgMCBDIDU4Ljc4IDQuNjIgNTguMzEgNC44NiA1OC4wMyA1LjI1IEwgNTcuMzEgNi4yOCA1Ni41NiA1LjI1IEMgNTYuMjkgNC44NiA1NS44MiA0LjYyIDU1LjM0IDQuNjIgbCAtMi4xNiAwIGMgLTAuNDkgLTAgLTAuOTcgMC4yNSAtMS4yNSAwLjY2IC0wLjg2IC0wLjUxIC0xLjg0IC0wLjgxIC0yLjkxIC0wLjgxIC0yLjAzIDAgLTMuODMgMS4wOCAtNC44OCAyLjY5IEMgNDMuMSA1LjUzIDQxLjI3IDQuNDcgMzkuMTkgNC40NyBMIDM5LjE5IDMgQyAzOS4xOSAyLjYxIDM5LjAzIDIuMjEgMzguNzUgMS45NCAzOC40NyAxLjY2IDM4LjA4IDEuNSAzNy42OSAxLjUgbCAtMS43NSAwIGMgLTAuNzEgMCAtMS41IDAuODMgLTEuNSAxLjUgbCAwIDMuMTYgQyAzMy4zOCA1LjEgMzEuOTYgNC40NyAzMC4zOCA0LjQ3IGwgLTMuMzQgMCBjIC0wLjc3IDAuMDIgLTEuNDcgMC43MiAtMS40NyAxLjUgbCAwIDAuMzEgYyAtMS4wMiAtMS4xMiAtMi40NiAtMS44MSAtNC4wOSAtMS44MSAtMS42MyAwIC0zLjA3IDAuNyAtNC4wOSAxLjgxIEwgMTcuMzggMyBjIC0wIC0wLjc5IC0wLjcxIC0xLjUgLTEuNSAtMS41IEwgMTQuNSAxLjUgQyAxMy41NSAxLjUgMTIuMjggMS44NyAxMS42NiAyLjk0IGwgLTEgMS42OSAtMSAtMS42OSBDIDkuMDMgMS44NyA3Ljc3IDEuNSA2LjgxIDEuNSBsIC0xLjQxIDAgQyA1LjM2IDEuNSA1LjMyIDEuNSA1LjI4IDEuNSB6IG0gMTYuMTkgNy43MiBjIDAuNTMgMCAwLjk0IDAuMzUgMC45NCAxLjI4IGwgMCAxLjI4IC0wLjk0IDAgYyAtMC41MiAwIC0wLjk0IC0wLjM4IC0wLjk0IC0xLjI4IC0wIC0wLjkgMC40MiAtMS4yOCAwLjk0IC0xLjI4IHogbSA4LjgxIDAgYyAwLjgzIDAgMS4xOCAwLjY4IDEuMTkgMS4yOCAwLjAxIDAuOTQgLTAuNjIgMS4yOCAtMS4xOSAxLjI4IHogbSA4LjcyIDAgYyAwLjcyIDAgMS4zNyAwLjYgMS4zNyAxLjI4IDAgMC43NyAtMC41MSAxLjI4IC0xLjM3IDEuMjggeiBtIDEwLjAzIDAgYyAwLjU4IDAgMS4wOSAwLjUgMS4wOSAxLjI4IDAgMC43OCAtMC41MSAxLjI4IC0xLjA5IDEuMjggLTAuNTggMCAtMS4xMiAtMC41IC0xLjEyIC0xLjI4IDAgLTAuNzggMC41NCAtMS4yOCAxLjEyIC0xLjI4IHoiIHRyYW5zZm9ybT0ibWF0cml4KDUuNzMzMzQxNCwwLDAsNS43MzMzNDE0LDIzNi45MzMwOCwzOTcuMTc0OTgpIiBzdHlsZT0iZm9udC1zaXplOm1lZGl1bTtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmb250LXN0cmV0Y2g6bm9ybWFsO3RleHQtaW5kZW50OjA7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWRlY29yYXRpb246bm9uZTtsaW5lLWhlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3dvcmQtc3BhY2luZzpub3JtYWw7dGV4dC10cmFuc2Zvcm06bm9uZTtkaXJlY3Rpb246bHRyO2Jsb2NrLXByb2dyZXNzaW9uOnRiO3dyaXRpbmctbW9kZTpsci10Yjt0ZXh0LWFuY2hvcjpzdGFydDtiYXNlbGluZS1zaGlmdDpiYXNlbGluZTtjb2xvcjojMDAwMDAwO2ZpbGw6IzAwMDAwMDtmaWxsLW9wYWNpdHk6MTtmaWxsLXJ1bGU6bm9uemVybztzdHJva2U6bm9uZTtzdHJva2Utd2lkdGg6MTcuMjAwMDIzNjU7bWFya2VyOm5vbmU7dmlzaWJpbGl0eTp2aXNpYmxlO2Rpc3BsYXk6aW5saW5lO292ZXJmbG93OnZpc2libGU7ZW5hYmxlLWJhY2tncm91bmQ6YWNjdW11bGF0ZTtmb250LWZhbWlseTpTYW5zOy1pbmtzY2FwZS1mb250LXNwZWNpZmljYXRpb246U2FucyIvPjwvZz48ZyB0cmFuc2Zvcm09Im1hdHJpeCgwLjE3NDQxODM2LDAsMCwwLjE3NDQxODM2LDIyMC41MjI4MiwyOS4yMjkzNDIpIiBzdHlsZT0iZmlsbDojZmZmZmZmIj48cGF0aCBkPSJtIDUuNDEgMyAwIDEyIDEuNzUgMCAwIC05LjkxIDMuNSA1Ljk0IDMuNDcgLTUuOTQgMCA5LjkxIDEuNzUgMCAwIC0xMiBMIDE0LjUgMyBDIDEzLjggMyAxMy4yNSAzLjE2IDEyLjk0IDMuNjkgTCAxMC42NiA3LjU5IDguMzggMy42OSBDIDguMDcgMy4xNiA3LjUxIDMgNi44MSAzIHogTSAzNiAzIGwgMCAxMi4wMyAzLjI1IDAgYyAyLjQ0IDAgNC4zOCAtMS45MSA0LjM4IC00LjUzIDAgLTIuNjIgLTEuOTMgLTQuNDcgLTQuMzggLTQuNDcgQyAzOC43IDYuMDMgMzguMzIgNiAzNy43NSA2IGwgMCAtMyB6IE0gMjEuNDcgNS45NyBjIC0yLjQ0IDAgLTQuMTkgMS45MSAtNC4xOSA0LjUzIDAgMi42MiAxLjc1IDQuNTMgNC4xOSA0LjUzIGwgNC4xOSAwIDAgLTQuNTMgYyAwIC0yLjYyIC0xLjc1IC00LjUzIC00LjE5IC00LjUzIHogbSAyNy41NiAwIGMgLTIuNDEgMCAtNC4zOCAyLjAzIC00LjM4IDQuNTMgMCAyLjUgMS45NyA0LjUzIDQuMzggNC41MyAyLjQxIDAgNC4zNCAtMi4wMyA0LjM0IC00LjUzIDAgLTIuNSAtMS45NCAtNC41MyAtNC4zNCAtNC41MyB6IG0gLTIyIDAuMDMgMCAxMiAxLjc1IDAgMCAtMi45NyBjIDAuNTcgMCAxLjA0IC0wIDEuNTkgMCAyLjQ0IDAgNC4zNCAtMS45MSA0LjM0IC00LjUzIDAgLTIuNjIgLTEuOSAtNC41IC00LjM0IC00LjUgeiBtIDI2LjE2IDAgMy4wMyA0LjM4IC0zLjE5IDQuNjIgMi4xMiAwIEwgNTcuMzEgMTEuOTEgNTkuNDQgMTUgNjEuNTkgMTUgNTguMzggMTAuMzggNjEuNDEgNiA1OS4yNSA2IDU3LjMxIDguODEgNTUuMzQgNiB6IE0gMjEuNDcgNy43MiBjIDEuNCAwIDIuNDQgMS4xOSAyLjQ0IDIuNzggbCAwIDIuNzggLTIuNDQgMCBjIC0xLjQgMCAtMi40NCAtMS4yMSAtMi40NCAtMi43OCAtMCAtMS41NyAxLjA0IC0yLjc4IDIuNDQgLTIuNzggeiBtIDI3LjU2IDAgYyAxLjQ0IDAgMi41OSAxLjI0IDIuNTkgMi43OCAwIDEuNTQgLTEuMTUgMi43OCAtMi41OSAyLjc4IC0xLjQ0IDAgLTIuNjIgLTEuMjQgLTIuNjIgLTIuNzggMCAtMS41NCAxLjE4IC0yLjc4IDIuNjIgLTIuNzggeiBtIC0yMC4yNSAwLjAzIDEuNTkgMCBjIDEuNTkgMCAyLjU5IDEuMjggMi41OSAyLjc1IDAgMS40NyAtMS4xMyAyLjc4IC0yLjU5IDIuNzggbCAtMS41OSAwIHogbSA4Ljk3IDAgMS41IDAgYyAxLjQ3IDAgMi42MiAxLjI4IDIuNjIgMi43NSAwIDEuNDcgLTEuMDQgMi43OCAtMi42MiAyLjc4IGwgLTEuNSAwIHoiIHRyYW5zZm9ybT0ibWF0cml4KDUuNzMzMzQxNCwwLDAsNS43MzMzNDE0LDIzNi45MzMwOCwzOTcuMTc0OTgpIiBzdHlsZT0iZmlsbDojZmZmZmZmO2ZpbGwtb3BhY2l0eToxO2ZpbGwtcnVsZTpub256ZXJvO3N0cm9rZTpub25lIi8+PC9nPjwvZz48L3N2Zz4=", + "max_connections": 12 + } I'd wrap these objects inside a tiles-object, like this (unless it's a hassle): { "tiles": { "street": { ... }, "aerial": { ... }, ... } } This is since we want to add more services here than tiles soon. ::: src/mapSource.js @@ +33,1 @@ +const _TILE_SERVICE_URL = 'http://threetimestwo.org/service.json'; I'm still a bit afraid that the choice to not go with the flexibility of using the full version in the URI will bite us later in some way, but I need to think more about when a problem could actually come up. (What I mean is that the file would be something like services-3.20.1.json or so). @@ +70,3 @@ +} + +function _getTileService() { Not totally fond of the idea of loading the service definition in this file. I would love to see an extra module for this and that the service definition was resolved in application.js and that the endpoints then were fed to the different services from somewhere in application.js But I understand if this comment doesn't help from a backporting perspective so I'm totally fine with doing it like this now, I can refactor master later.
Review of attachment 333585 [details] [review]: Awesome sauce!
Review of attachment 333586 [details] [review]: This made the logo look so much better. Double check that it works without a logo set. Both with empty string, null and no key.
Review of attachment 333584 [details] [review]: Thank you! ::: data/maps-service.json @@ +8,3 @@ + "max_zoom_level": 19, + "tile_size": 256, + "uri": "https://a.tiles.mapbox.com/v4/mapbox.streets/#Z#/#X#/#Y#.png?access_token=pk.eyJ1IjoiZ25vbWUtbWFwcyIsImEiOiJjaXF3a3lwbXkwMDJwaTBubmZlaGk4cDZ6In0.8aukTfgjzeqATA8eNItPJA&", ok! @@ +37,3 @@ + "attribution_logo": "PHN2ZyB4bWxuczpkYz0iaHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8iIHhtbG5zOmNjPSJodHRwOi8vY3JlYXRpdmVjb21tb25zLm9yZy9ucyMiIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyIgeG1sbnM6c3ZnPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB2ZXJzaW9uPSIxLjEiIHdpZHRoPSI2NSIgaGVpZ2h0PSIyMCI+PGRlZnMvPjxtZXRhZGF0YT48cmRmOlJERj48Y2M6V29yayByZGY6YWJvdXQ9IiI+PGRjOmZvcm1hdD5pbWFnZS9zdmcreG1sPC9kYzpmb3JtYXQ+PGRjOnR5cGUgcmRmOnJlc291cmNlPSJodHRwOi8vcHVybC5vcmcvZGMvZGNtaXR5cGUvU3RpbGxJbWFnZSIvPjxkYzp0aXRsZS8+PC9jYzpXb3JrPjwvcmRmOlJERj48L21ldGFkYXRhPjxnIHRyYW5zZm9ybT0idHJhbnNsYXRlKC0yNjEuODQ4MywtOTguNTAzOTUpIj48ZyB0cmFuc2Zvcm09Im1hdHJpeCgwLjE3NDQxODM2LDAsMCwwLjE3NDQxODM2LDIyMC41MjI4MiwyOS4yMjkzNDIpIiBzdHlsZT0ib3BhY2l0eTowLjI1O2ZpbGw6I2ZmZmZmZjtzdHJva2U6IzAwMDAwMDtzdHJva2Utd2lkdGg6MTcuMjAwMDIzNjU7c3Ryb2tlLWxpbmVjYXA6cm91bmQ7c3Ryb2tlLWxpbmVqb2luOnJvdW5kO3N0cm9rZS1taXRlcmxpbWl0OjQ7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtZGFzaGFycmF5Om5vbmUiPjxwYXRoIGQ9Ik0gNS4yOCAxLjUgQyA0LjU0IDEuNTYgMy45IDIuMjUgMy45MSAzIGwgMCAxMS44OCBjIDAuMDIgMC43NyAwLjcyIDEuNDcgMS41IDEuNDcgbCAxLjc1IDAgYyAwLjc4IDAgMS40OCAtMC42OSAxLjUgLTEuNDcgbCAwIC00LjI4IDAuNzIgMS4xOSBjIDAuNTMgMC44NyAyLjAzIDAuODcgMi41NiAwIGwgMC43MiAtMS4xOSAwIDQuMjggYyAwLjAyIDAuNzYgMC43IDEuNDUgMS40NyAxLjQ3IGwgMS43NSAwIGMgMC43OCAwIDEuNDggLTAuNjkgMS41IC0xLjQ3IGwgMCAtMC4xNiBjIDEuMDIgMS4xMiAyLjQ2IDEuODEgNC4wOSAxLjgxIGwgNC4wOSAwIDAgMS40NyBjIC0wIDAuNzggMC42OSAxLjQ4IDEuNDcgMS41IGwgMS43NSAwIGMgMC43OSAtMCAxLjUgLTAuNzEgMS41IC0xLjUgbCAwLjAyIC0xLjQ3IGMgMS43MiAwIDMuMDggLTAuNjQgNC4xNCAtMS42OSBsIDAgMC4xOSBjIDAgMC4zOSAwLjE2IDAuNzkgMC40NCAxLjA2IDAuMjggMC4yOCAwLjY3IDAuNDQgMS4wNiAwLjQ0IGwgMy4zMSAwIGMgMi4wMyAwIDMuODUgLTEuMDYgNC45MSAtMi42OSAxLjA1IDEuNjEgMi44NCAyLjY5IDQuODggMi42OSAxLjAzIDAgMS45OCAtMC4yNyAyLjgxIC0wLjc1IDAuMjggMC4zNSAwLjczIDAuNTcgMS4xOSAwLjU2IGwgMi4xMiAwIGMgMC40OCAwLjAxIDAuOTcgLTAuMjMgMS4yNSAtMC42MiBsIDAuOTEgLTEuMjggMC45MSAxLjI4IGMgMC4yOCAwLjM5IDAuNzQgMC42MyAxLjIyIDAuNjIgbCAyLjE2IDAgQyA2Mi42NyAxNi4zMyA2My40MiAxNC44OSA2Mi44MSAxNCBMIDYwLjIyIDEwLjM4IDYyLjYyIDcgQyA2My4yNiA2LjExIDYyLjUgNC42MiA2MS40MSA0LjYyIGwgLTIuMTYgMCBDIDU4Ljc4IDQuNjIgNTguMzEgNC44NiA1OC4wMyA1LjI1IEwgNTcuMzEgNi4yOCA1Ni41NiA1LjI1IEMgNTYuMjkgNC44NiA1NS44MiA0LjYyIDU1LjM0IDQuNjIgbCAtMi4xNiAwIGMgLTAuNDkgLTAgLTAuOTcgMC4yNSAtMS4yNSAwLjY2IC0wLjg2IC0wLjUxIC0xLjg0IC0wLjgxIC0yLjkxIC0wLjgxIC0yLjAzIDAgLTMuODMgMS4wOCAtNC44OCAyLjY5IEMgNDMuMSA1LjUzIDQxLjI3IDQuNDcgMzkuMTkgNC40NyBMIDM5LjE5IDMgQyAzOS4xOSAyLjYxIDM5LjAzIDIuMjEgMzguNzUgMS45NCAzOC40NyAxLjY2IDM4LjA4IDEuNSAzNy42OSAxLjUgbCAtMS43NSAwIGMgLTAuNzEgMCAtMS41IDAuODMgLTEuNSAxLjUgbCAwIDMuMTYgQyAzMy4zOCA1LjEgMzEuOTYgNC40NyAzMC4zOCA0LjQ3IGwgLTMuMzQgMCBjIC0wLjc3IDAuMDIgLTEuNDcgMC43MiAtMS40NyAxLjUgbCAwIDAuMzEgYyAtMS4wMiAtMS4xMiAtMi40NiAtMS44MSAtNC4wOSAtMS44MSAtMS42MyAwIC0zLjA3IDAuNyAtNC4wOSAxLjgxIEwgMTcuMzggMyBjIC0wIC0wLjc5IC0wLjcxIC0xLjUgLTEuNSAtMS41IEwgMTQuNSAxLjUgQyAxMy41NSAxLjUgMTIuMjggMS44NyAxMS42NiAyLjk0IGwgLTEgMS42OSAtMSAtMS42OSBDIDkuMDMgMS44NyA3Ljc3IDEuNSA2LjgxIDEuNSBsIC0xLjQxIDAgQyA1LjM2IDEuNSA1LjMyIDEuNSA1LjI4IDEuNSB6IG0gMTYuMTkgNy43MiBjIDAuNTMgMCAwLjk0IDAuMzUgMC45NCAxLjI4IGwgMCAxLjI4IC0wLjk0IDAgYyAtMC41MiAwIC0wLjk0IC0wLjM4IC0wLjk0IC0xLjI4IC0wIC0wLjkgMC40MiAtMS4yOCAwLjk0IC0xLjI4IHogbSA4LjgxIDAgYyAwLjgzIDAgMS4xOCAwLjY4IDEuMTkgMS4yOCAwLjAxIDAuOTQgLTAuNjIgMS4yOCAtMS4xOSAxLjI4IHogbSA4LjcyIDAgYyAwLjcyIDAgMS4zNyAwLjYgMS4zNyAxLjI4IDAgMC43NyAtMC41MSAxLjI4IC0xLjM3IDEuMjggeiBtIDEwLjAzIDAgYyAwLjU4IDAgMS4wOSAwLjUgMS4wOSAxLjI4IDAgMC43OCAtMC41MSAxLjI4IC0xLjA5IDEuMjggLTAuNTggMCAtMS4xMiAtMC41IC0xLjEyIC0xLjI4IDAgLTAuNzggMC41NCAtMS4yOCAxLjEyIC0xLjI4IHoiIHRyYW5zZm9ybT0ibWF0cml4KDUuNzMzMzQxNCwwLDAsNS43MzMzNDE0LDIzNi45MzMwOCwzOTcuMTc0OTgpIiBzdHlsZT0iZm9udC1zaXplOm1lZGl1bTtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQ6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmb250LXN0cmV0Y2g6bm9ybWFsO3RleHQtaW5kZW50OjA7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWRlY29yYXRpb246bm9uZTtsaW5lLWhlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3dvcmQtc3BhY2luZzpub3JtYWw7dGV4dC10cmFuc2Zvcm06bm9uZTtkaXJlY3Rpb246bHRyO2Jsb2NrLXByb2dyZXNzaW9uOnRiO3dyaXRpbmctbW9kZTpsci10Yjt0ZXh0LWFuY2hvcjpzdGFydDtiYXNlbGluZS1zaGlmdDpiYXNlbGluZTtjb2xvcjojMDAwMDAwO2ZpbGw6IzAwMDAwMDtmaWxsLW9wYWNpdHk6MTtmaWxsLXJ1bGU6bm9uemVybztzdHJva2U6bm9uZTtzdHJva2Utd2lkdGg6MTcuMjAwMDIzNjU7bWFya2VyOm5vbmU7dmlzaWJpbGl0eTp2aXNpYmxlO2Rpc3BsYXk6aW5saW5lO292ZXJmbG93OnZpc2libGU7ZW5hYmxlLWJhY2tncm91bmQ6YWNjdW11bGF0ZTtmb250LWZhbWlseTpTYW5zOy1pbmtzY2FwZS1mb250LXNwZWNpZmljYXRpb246U2FucyIvPjwvZz48ZyB0cmFuc2Zvcm09Im1hdHJpeCgwLjE3NDQxODM2LDAsMCwwLjE3NDQxODM2LDIyMC41MjI4MiwyOS4yMjkzNDIpIiBzdHlsZT0iZmlsbDojZmZmZmZmIj48cGF0aCBkPSJtIDUuNDEgMyAwIDEyIDEuNzUgMCAwIC05LjkxIDMuNSA1Ljk0IDMuNDcgLTUuOTQgMCA5LjkxIDEuNzUgMCAwIC0xMiBMIDE0LjUgMyBDIDEzLjggMyAxMy4yNSAzLjE2IDEyLjk0IDMuNjkgTCAxMC42NiA3LjU5IDguMzggMy42OSBDIDguMDcgMy4xNiA3LjUxIDMgNi44MSAzIHogTSAzNiAzIGwgMCAxMi4wMyAzLjI1IDAgYyAyLjQ0IDAgNC4zOCAtMS45MSA0LjM4IC00LjUzIDAgLTIuNjIgLTEuOTMgLTQuNDcgLTQuMzggLTQuNDcgQyAzOC43IDYuMDMgMzguMzIgNiAzNy43NSA2IGwgMCAtMyB6IE0gMjEuNDcgNS45NyBjIC0yLjQ0IDAgLTQuMTkgMS45MSAtNC4xOSA0LjUzIDAgMi42MiAxLjc1IDQuNTMgNC4xOSA0LjUzIGwgNC4xOSAwIDAgLTQuNTMgYyAwIC0yLjYyIC0xLjc1IC00LjUzIC00LjE5IC00LjUzIHogbSAyNy41NiAwIGMgLTIuNDEgMCAtNC4zOCAyLjAzIC00LjM4IDQuNTMgMCAyLjUgMS45NyA0LjUzIDQuMzggNC41MyAyLjQxIDAgNC4zNCAtMi4wMyA0LjM0IC00LjUzIDAgLTIuNSAtMS45NCAtNC41MyAtNC4zNCAtNC41MyB6IG0gLTIyIDAuMDMgMCAxMiAxLjc1IDAgMCAtMi45NyBjIDAuNTcgMCAxLjA0IC0wIDEuNTkgMCAyLjQ0IDAgNC4zNCAtMS45MSA0LjM0IC00LjUzIDAgLTIuNjIgLTEuOSAtNC41IC00LjM0IC00LjUgeiBtIDI2LjE2IDAgMy4wMyA0LjM4IC0zLjE5IDQuNjIgMi4xMiAwIEwgNTcuMzEgMTEuOTEgNTkuNDQgMTUgNjEuNTkgMTUgNTguMzggMTAuMzggNjEuNDEgNiA1OS4yNSA2IDU3LjMxIDguODEgNTUuMzQgNiB6IE0gMjEuNDcgNy43MiBjIDEuNCAwIDIuNDQgMS4xOSAyLjQ0IDIuNzggbCAwIDIuNzggLTIuNDQgMCBjIC0xLjQgMCAtMi40NCAtMS4yMSAtMi40NCAtMi43OCAtMCAtMS41NyAxLjA0IC0yLjc4IDIuNDQgLTIuNzggeiBtIDI3LjU2IDAgYyAxLjQ0IDAgMi41OSAxLjI0IDIuNTkgMi43OCAwIDEuNTQgLTEuMTUgMi43OCAtMi41OSAyLjc4IC0xLjQ0IDAgLTIuNjIgLTEuMjQgLTIuNjIgLTIuNzggMCAtMS41NCAxLjE4IC0yLjc4IDIuNjIgLTIuNzggeiBtIC0yMC4yNSAwLjAzIDEuNTkgMCBjIDEuNTkgMCAyLjU5IDEuMjggMi41OSAyLjc1IDAgMS40NyAtMS4xMyAyLjc4IC0yLjU5IDIuNzggbCAtMS41OSAwIHogbSA4Ljk3IDAgMS41IDAgYyAxLjQ3IDAgMi42MiAxLjI4IDIuNjIgMi43NSAwIDEuNDcgLTEuMDQgMi43OCAtMi42MiAyLjc4IGwgLTEuNSAwIHoiIHRyYW5zZm9ybT0ibWF0cml4KDUuNzMzMzQxNCwwLDAsNS43MzMzNDE0LDIzNi45MzMwOCwzOTcuMTc0OTgpIiBzdHlsZT0iZmlsbDojZmZmZmZmO2ZpbGwtb3BhY2l0eToxO2ZpbGwtcnVsZTpub256ZXJvO3N0cm9rZTpub25lIi8+PC9nPjwvZz48L3N2Zz4=", + "max_connections": 12 + } Allrajt! ::: src/mapSource.js @@ +33,1 @@ +const _TILE_SERVICE_URL = 'http://threetimestwo.org/service.json'; I will go with https://gis.gnome.org/services/v1/service.json @@ +70,3 @@ +} + +function _getTileService() { Yes, exactly. And agreed. A debug option to test new service definition would be nice on master. But not something we need to backport. @@ +72,3 @@ +function _getTileService() { + if (_tileService) + return JSON.parse(data); Seems like a rebase accident, yes, will fix.
Created attachment 333608 [details] [review] mapSource: Get tile server information from service.json Attempt to download a service.json file from gnome.org. The file will define all information needed to create a libchamplain source. This will help us to change the tile-server without needing to update the application. If the call to gnome.org fails. Fallback to a default service.json.
Created attachment 333609 [details] [review] Add print tile service Use the print style from the service.json file for the print source. Right now it is same as street style. But gives us the possibility of having a special print style later.
Created attachment 333610 [details] [review] Use GtkClutter for attribution logo
I just did a build from wip/jonasdn/service branch. Massive speed improvement. This is much faster than the old MapQuest too. Mapbox appears to be using a CDN so people all over the globe will benefit from this :)
Attachment 333608 [details] pushed as 6a6a17e - mapSource: Get tile server information from service.json Attachment 333609 [details] pushed as acc7020 - Add print tile service Attachment 333610 [details] pushed as 2574925 - Use GtkClutter for attribution logo
Tested git version. Not it is fast and usable. Great work. Thanks much !!
Not -> Now :)