GNOME Bugzilla – Bug 764841
Stop Using MapQuest Tile Server
Last modified: 2016-08-21 12:24:34 UTC
MapQuest has changed their tile usage policy and will only allow tile access through one of their sdk's in near future. We should start searching for the alternatives
There are 2 ways to handle the problem 1.) We can start using some other tile server
There are 2 ways to handle the problem 1.) We can start using some other tile server Map Quest tile server was the only tile server which had english labels. We can always revert back to using mapnik tile server but it contains a bit too much information. One alternative is to use wikimedia tile server though it is in experimental stage now but the map style seems good and contains enough information 2.) the other solution is to create our own tile server. This seems a good option. It will allow us to customize maps according to our needs and will also the tile access time due to less traffic. The second option seems a better choice now I will explore the possiblities of creating our own tile server and will keep on posting it on this bug
(In reply to Nayan Deshmukh from comment #2) Thanks for filing this! Now this is serious. If mapquest changes its terms of service and stops working for us that means gnome-maps stops working. That means gnome-maps 3.12 stops working. That means gnome-maps 3.14 stops working. That means gnome-maps 3.16 stops working That means gnome-maps 3.18 stops working and that means gnome-maps 3.20 stops working. Solving it would mean updating stable versions back to a reasonable time. And this is really why I do not like relying on third party services. Especially when we are a desktop-app. A webabb can roll-out a new version to all users very easily. Not so for us. I would like confirmation that we can not continue using Mapquest. The post you did on a forum did not mention Maps at all right? Could you find an official mail address to MapQuest? Maybe the GNOME engangement team could ask them if Maps will be cut off from the street tiles service? Sri, could engement help out? > There are 2 ways to handle the problem > > 1.) We can start using some other tile server > Map Quest tile server was the only tile server which had english labels. > We can always revert back to using mapnik tile server but it contains a > bit > too much information. One alternative is to use wikimedia tile server > though > it is in experimental stage now but the map style seems good and > contains > enough information If we are to use any server that is not our own I would say that the openstreetmap server might the most reliable. > > 2.) the other solution is to create our own tile server. This seems a good > option. > It will allow us to customize maps according to our needs and will also > the > tile access time due to less traffic. > > The second option seems a better choice now I will explore the possiblities > of creating our own tile server and will keep on posting it on this bug We are already looking into this. I have added Cosimo to cc. We want to create tiles.gnome.org. Cosmio: Have you gotten anywhere in looking into this? Having our own server is _not easy_. Right now we get by with gnome-maps using the toolkints. Not doing that much complex stuff. We have no-one paid doing this and the ones developing does not have much time. We are not set up to mainting infrastructure, We need help with it. From the GNOME foundation or a sponsoring company. So. Yeah. We need confirmation. And we need alternatives. I've added some people to CC. What are your opinions?
> I would like confirmation that we can not continue using Mapquest. The post > you did on a forum did not mention Maps at all right? I did not mention maps specifically. > Could you find an official mail address to MapQuest? Maybe the GNOME > engangement team could ask them if Maps will be cut off from the street > tiles service? The only mail I was able to find was sales@mapquest.com. I have also filled their contact us form and asked about the issue(mentioning gnome-maps) and also if they can give us a date for the terms and conditions to come into effect. > > There are 2 ways to handle the problem > > > > 1.) We can start using some other tile server > > Map Quest tile server was the only tile server which had english labels. > > We can always revert back to using mapnik tile server but it contains a > > bit > > too much information. One alternative is to use wikimedia tile server > > though > > it is in experimental stage now but the map style seems good and > > contains > > enough information > > If we are to use any server that is not our own I would say that the > openstreetmap server might the most reliable. openstreetmap server is the most reliable server, but the lack of english might be a problem > > > > 2.) the other solution is to create our own tile server. This seems a good > > option. > > It will allow us to customize maps according to our needs and will also > > the > > tile access time due to less traffic. > > > > The second option seems a better choice now I will explore the possiblities > > of creating our own tile server and will keep on posting it on this bug > > We are already looking into this. I have added Cosimo to cc. We want to > create tiles.gnome.org. > > Cosmio: Have you gotten anywhere in looking into this? > > Having our own server is _not easy_. Right now we get by with gnome-maps > using the toolkints. Not doing that much complex stuff. We have no-one paid > doing this and the ones developing does not have much time. We are not set > up to mainting infrastructure, We need help with it. From the GNOME > foundation or a sponsoring company. > > So. Yeah. We need confirmation. And we need alternatives. I've added some > people to CC. What are your opinions? setting and maintaining our own server will be difficult we will also need to keep it updated regularly with the diff from OSM, but it will also reduce our dependence on third party services. If it is possible I would like to go with our own server. If not then OSM server is there and very reliable than any other servers
(In reply to Nayan Deshmukh from comment #4) > > > > If we are to use any server that is not our own I would say that the > > openstreetmap server might the most reliable. > > openstreetmap server is the most reliable server, but the lack of english > might be a problem > I do not understand what you mean? What lack of english? In the tiles? Here?: http://www.openstreetmap.org/ > > > > > > 2.) the other solution is to create our own tile server. This seems a good > > > option. > > > It will allow us to customize maps according to our needs and will also > > > the > > > tile access time due to less traffic. > > > > > > The second option seems a better choice now I will explore the possiblities > > > of creating our own tile server and will keep on posting it on this bug > > > > We are already looking into this. I have added Cosimo to cc. We want to > > create tiles.gnome.org. > > > > Cosmio: Have you gotten anywhere in looking into this? > > > > Having our own server is _not easy_. Right now we get by with gnome-maps > > using the toolkints. Not doing that much complex stuff. We have no-one paid > > doing this and the ones developing does not have much time. We are not set > > up to mainting infrastructure, We need help with it. From the GNOME > > foundation or a sponsoring company. > > > > So. Yeah. We need confirmation. And we need alternatives. I've added some > > people to CC. What are your opinions? > > setting and maintaining our own server will be difficult we will also need > to keep it updated regularly with the diff from OSM, but it will also reduce > our dependence on third party services. > > If it is possible I would like to go with our own server. If not then OSM > server is there and very reliable than any other servers Yes, we want our own server. We know how to do it and what technologies to use. What we need is money, and time and someone to administrate. Before that we might want to create tiles.gnome.org and use it as a proxy, and point it top mapquest or openstreetmap, and we can repoint it at need and later one use it as our own server.
> I do not understand what you mean? What lack of english? In the tiles? > Here?: http://www.openstreetmap.org/ Sorry for the ambiguity I meant English labels as openstreetmaps display labels in local language as compared to mapquest which has english labels. > The only mail I was able to find was sales@mapquest.com. I have also filled their > contact us form and asked about the issue(mentioning gnome-maps) and also if they > can give us a date for the terms and conditions to come into effect. They diverted me to their forums for such questions. > Yes, we want our own server. We know how to do it and what technologies to use. > What we need is money, and time and someone to administrate. Before that we might > want to create tiles.gnome.org and use it as a proxy, and point it top mapquest > or openstreetmap, and we can repoint it at need and later one use it as our own > server. For now we need to conform with mapquest about the use of their tiles, and may be shift to openstreetmaps in case they no longer provide service.
One issue I think with changing tile provider that we might need to take into account is the champlain cache. I guess there is a risk of getting inconsistent looks if, let's say we switch to using the default mapnik style tiles as supplied by osm.org, and there's some cached tiles locally and some tiles needing to be fetched for a particular viewport, we could end up with a mix that might look strange. So, we might need to take this into account and invalidate old cached tiles at first run when using a new version with changed tile sources. (on the other hand, that is an issue that would self-heal in at most 7 days, so maybe it's not worth considering).
(In reply to Marcus Lundblad from comment #7) > One issue I think with changing tile provider that we might need to take > into account is the champlain cache. > I guess there is a risk of getting inconsistent looks if, let's say we > switch to using the default mapnik style tiles as supplied by osm.org, and > there's some cached tiles locally and some tiles needing to be fetched for a > particular viewport, we could end up with a mix that might look strange. > So, we might need to take this into account and invalidate old cached tiles > at first run when using a new version with changed tile sources. > (on the other hand, that is an issue that would self-heal in at most 7 days, > so maybe it's not worth considering). I checked that libchamplain has different cache for different sources so it won't be a problem
(In reply to Jonas Danielsson from comment #3) > We are already looking into this. I have added Cosimo to cc. We want to > create tiles.gnome.org. > > Cosmio: Have you gotten anywhere in looking into this? > > Having our own server is _not easy_. Right now we get by with gnome-maps > using the toolkints. Not doing that much complex stuff. We have no-one paid > doing this and the ones developing does not have much time. We are not set > up to mainting infrastructure, We need help with it. From the GNOME > foundation or a sponsoring company. > > So. Yeah. We need confirmation. And we need alternatives. I've added some > people to CC. What are your opinions? Jonas, thanks for copying me on this issue. Unfortunately I have not been able to make much progress on this front yet. It looks like it became somewhat more urgent now and not just a nice new feature to have... I'll see if there's anything I can do to get it moving again in the short term.
(In reply to Marcus Lundblad from comment #7) > One issue I think with changing tile provider that we might need to take > into account is the champlain cache. > I guess there is a risk of getting inconsistent looks if, let's say we > switch to using the default mapnik style tiles as supplied by osm.org, and > there's some cached tiles locally and some tiles needing to be fetched for a > particular viewport, we could end up with a mix that might look strange. > So, we might need to take this into account and invalidate old cached tiles > at first run when using a new version with changed tile sources. > (on the other hand, that is an issue that would self-heal in at most 7 days, > so maybe it's not worth considering). Yesterday, I tried to manually change the tile source to "OSM_MAPNIK" in mapView.js and can confirm now that things works as indented. I.e. old cached tiles from the MQ tile provider are not shown, and new tiles using the updated style are downloaded as needed.
Also the aerial tiles will stop working, I guess, since these are also using a MapQeust tile source. So I think we might need to disable the ability to switch between street and aerial view (at least for the time being).
Created attachment 330218 [details] [review] mapView: Stop using MapQuest tiles Revert to using the standard OSM Mapnik tiles instead of MapQuest's tiles, as MapQuest will cease providing free tiles.
Created attachment 330219 [details] [review] layerPopover: Remove ability to switch b/w street and aerial As the aerial tiles currently are provided by MapQuest, the switcher buttons is not needed currently. Keeps the ability to load custom map layers.
I've attached two patches, One that changes the default "street" tiles to use OSM Mapnik tiles. And one that removes the street/aerial switch buttons in the layers popover, as the aerial tiles are also provided by MapQuest. I'm still a bit uncertain if the openstreetmap.org tile server is allowed to be used like this. Also, the tiles aren't as clean as the MapQuest ones, but better than nothing at all I guess…
(In reply to Marcus Lundblad from comment #14) > I've attached two patches, > One that changes the default "street" tiles to use OSM Mapnik tiles. > And one that removes the street/aerial switch buttons in the layers popover, > as the aerial tiles are also provided by MapQuest. > I'm still a bit uncertain if the openstreetmap.org tile server is allowed to > be used like this. > Also, the tiles aren't as clean as the MapQuest ones, but better than > nothing at all I guess… The Mapnik tiles don't have english labels and are a bit cluttered but they will do for now. I have tested the patches and they are working fine.
The second patch should apply on the 3.20 branch as well, but probably not on 3.18 and earlier (as it didn't have the "Load layer" stuff), but on those the layers button should perhaps be disabled altogether.
Note the Monday July 11 deadline: http://devblog.mapquest.com/2016/06/15/modernization-of-mapquest-results-in-changes-to-open-tile-access/
FWIW, I tried contacting[1] MapQuest, trying to get some estimate on how many requests per month we're using: 1: https://twitter.com/mattias_jcb/status/750853099875598336
(In reply to Mattias Bengtsson from comment #18) > FWIW, I tried contacting[1] MapQuest, trying to get some estimate on how > many requests per month we're using: > > 1: https://twitter.com/mattias_jcb/status/750853099875598336 Great! That could be useful if we decide to set up our own server.
As of today, this has happened. The threatened cut-off of MapQuest tile service has been enacted and now Maps (all versions) do not work. They just show a dummy tile explaining with a link to a page describing the new policy.
Bumping severity and priority.
Unfortunately using the standard OSM tile server directly is forbidden without explicitely asking for permission. So using the patches above might possibly result in libchaplain getting banned from tile access.
I've just sent an email to operations@osmfundation.org requesting an authorisation to use OSM's tiles servers. It may be helpful. Subsequent communications will be added to this bug report for clarity ;) Here is the content of that email: Hello OSM Foundation, [Gnome Maps](https://wiki.gnome.org/Apps/Maps) is a Linux Desktop application part of the Gnome Desktop. It uses MapQuest as a tile server. However, Gnome Maps is currently experiencing a service issue, as MapQuest has stop serving tiles. Due to the architecture of the application, this appears to brake all delivered versions of Gnome Maps to date. [A bug report is tracking this](https://bugzilla.gnome.org/show_bug.cgi?id=764841), and a patch to use OSM tile server is being worked on. However, we would like to ask for the permission to use OSM tile servers. This could be a temporary solution if need be. I visited the [Tile Policy page](https://wiki.openstreetmap.org/wiki/Tile_usage_policy), so here are some answers to the requirements: 1. Heavy use I don't have access to usage statistics yet. 2. Clearly display licence attribution. This should be sorted out in the patch itself. 3. Do not actively or passively encourage copyright infringement Gnome Maps is a GPLv2 application, and this is never encourage in any way. 4. Calls to /cgi-bin/export may only be triggered by direct end-user action Export is not possible through the application itself. 5. Highly Recommended: Do not hardcode any URL at tile.openstreetmap.org into an app The application architecture has hardcoded URL, thus this issue :D If you could participate to the bug report directly, it would be great. Otherwise, I will make sure the bug report has all of our conversation about this issue. Kindly Yours, Jiehong
We might also consider talking to the GNOME foundation board so as some contribution could be given to the OSM fundation for the additional bandwidth.
@Claude Paroz: Sounds like a good idea. I've decided to forward them the email I sent to the OSM foundation, and also but them in copy. Here is the email I sent to board@gnome.com: Hello Gnome Foundation Board, Gnome Maps is currently experiencing a service issue, as MapQuest has stop serving tiles. Due to the architecture of the application, this appears to brake all delivered versions of Gnome Maps to date. [A bug report is tracking this](https://bugzilla.gnome.org/show_bug.cgi?id=764841), and a patch to use OSM tile server is being worked on. However, this requires the authorisation of the OSM foundation. I've just sent an email to operations@osmfundation.org requesting an authorisation to use OSM's tiles servers. The content of the email I sent is present in the bug report, and is forwarded to you for reference. Perhaps the Gnome Foundation could provide some form of contribution to OpenStreetMap in exchange of the use of their tile server. The community would greatly appreciate if any meaningful action could come up from this on-going issue. Kindly yours, Jiehong Yet, it seems that I got a failure from sending emails to operations@osmfundation.org, so I sent it to: Chairperson – Kate Chapman: chairman@osmfoundation.org Secretary – Paul Norman: secretary@osmfoundation.org Treasurer – Frederik Ramm treasurer@osmfoundation.org
(In reply to ma.jiehong from comment #25) > I've decided to forward them the email I sent to the OSM foundation, and > also but them in copy. Here is the email I sent to board@gnome.com: The board never received it. The address is board@gnome.org > I've just sent an email to operations@osmfundation.org requesting an > authorisation to use OSM's tiles servers. Should be @osmfoundation.org
Sent it to operations@osmfoundation.org (fortunately this typo was only in the bug report), but I really made a mistake for the Gnome Board. Thanks Alexandra Franke for this notification. I've corrected this. I feel a bit dumb on that one ;)
Hello guys, First, thanks for the awesome work. I have to double check with my team, but I would be glad to help the Gnome community with some Openstreetmap tiles on the house, with a community Api-Key. How can we help? What can we do? Loïc
PS: Metrics would help.
Hi Loïc! Thanks a lot for reaching out to us! Unfortunately we don't have any metrics as MapQuest didn't have the data to produce any. :/ We've gotten a couple of offers for the interim period and I'm currently evaluating them, but more offers are certainly interesting! Some questions: - How many requests / month do you think you could offer? - For how long do you think we could use jawg.io? - Do you have any demo page where I could see your base maps in action? Regards and lots of thanks, Mattias
Also, do you provide Satellite maps?
Hi Mattias, sad to hear there are no metrics. No, we do not provide satellite maps, and we mostly provide "streets" styles, with a 7-day diff update, which may not be exactly what you need. If I understand it well, you need an OpenStreetMap style with instant updates... Am I right? In what we could Offer, I guess we could just open up for 6 months, monitor your activity and take it from there. Without metrics, it is tough to really know what to expect. Main styles Demo: http://demo.jawg.io?mode=fullscreen Otherwise, have you managed to reach the OSM Community? Best wishes, Loïc
(In reply to Loïc Ortola from comment #32) > Hi Mattias, > > sad to hear there are no metrics. > No, we do not provide satellite maps, and we mostly provide "streets" > styles, with a 7-day diff update, which may not be exactly what you need. If > I understand it well, you need an OpenStreetMap style with instant > updates... Am I right? > In what we could Offer, I guess we could just open up for 6 months, monitor > your activity and take it from there. Without metrics, it is tough to really > know what to expect. > > Main styles Demo: > http://demo.jawg.io?mode=fullscreen > > Otherwise, have you managed to reach the OSM Community? > > Best wishes, > Loïc Thanks for the offer Loĩc! I think your style looks nice! Out of curiosity, do you use the Mapnik renderer, and if so, is your style available (or could be made available) using a free/libre license? In case we would like to use this style when/if transitioning to our own hosted tile server.
I see Gnome-maps is considering switching to openstreetmap-carto tiles (which are the tiles you call OSM_MAPNIK). I'm one of the maintainers of openstreetmap-carto. Openstreetmap-carto is itself an Open Source project (unlike Mapquest Open, which uses open data but closed rendering rules). I see that many of you cite lack of English as a problem with the rendering. I'm a bit surprised by this. Why should a Chinese user of Gnome-maps see his places be written in English? Wouldn't it be weirder for a Chinese user to see the names of his provinces written in English than it would be for an English speaker to see Chinese province names in Chinese? Does English have a special position within Gnome? As far as we're concerned, no language has a special status, as we have no way of knowing the user's language. Of course, multilingual maps would be great, but we don't have currently the server capacity to implemeht this. Some of you describe the rendering as busy and cluttered. This is something I agree with, although it might be partially unavoidable for a map that tries to be general purpose (as opposed to a road-centered map). Also the fact that the map is used as an important feedback mechanism for mappers poses some constraints about what we need to display. In any case, any suggestions on how to make the map look less cluttered, preferable in the form of pull requests, are very welcome. Please let me know if you have any further questions. If you need any help with setting up an own tile server, I'd be happy to help you in the right direction as well. Note that the openstreetmap.org tile servers use our rendering rules but are not controlled by us, so I'm not able to help you with the tile usage policy. This is our project home: https://github.com/gravitystorm/openstreetmap-carto We can always use more contributors, so if any of you would like to help us in making the tiles look better, you're very welcome.
(In reply to info from comment #34) > I see Gnome-maps is considering switching to openstreetmap-carto tiles > (which are the tiles you call OSM_MAPNIK). > > I'm one of the maintainers of openstreetmap-carto. Openstreetmap-carto is > itself an Open Source project (unlike Mapquest Open, which uses open data > but closed rendering rules). > > I see that many of you cite lack of English as a problem with the rendering. > I'm a bit surprised by this. Why should a Chinese user of Gnome-maps see his > places be written in English? Wouldn't it be weirder for a Chinese user to > see the names of his provinces written in English than it would be for an > English speaker to see Chinese province names in Chinese? Does English have > a special position within Gnome? As far as we're concerned, no language has > a special status, as we have no way of knowing the user's language. Of > course, multilingual maps would be great, but we don't have currently the > server capacity to implemeht this. I think the issue is not that place names are localised as per user's locale but that they are localised for the location of the place. E.g I can't read any place names when I load map of Russia or China, cause they are in Russian and Chinese.
i would propose to switch to vector tiles [0] (maybe not as a hotfix..) i'm not sure if you are familiar with it but the main advantages of vector tiles is that they * contain all vector data instead of just pixels * use _much_ less space on the server (56GB) * are _rendered on_ the client [1] - according to style rules defined _on_ the client. i see it as a main advantage that you can take control about the rendering aspect on your own and for example * increase text size when the user has selected "Large text" from the assistence menu. * show language specific names This would be huge a step forward for visually impaired people! The processing power on the server is almost nonexistent if you use the prerendered vector tiles from [0]. i have no idea about the traffic though.. [0] http://osm2vectortiles.org/ [1] https://github.com/mapbox/mapbox-gl-native
@aatdark vector tiles is definitely on our radar. There are many advantages of using vector tiles, but I may say I hadn't thought about those two points you mentioned. Thanks for bringing it up! We're currently working on moving over to raster tiles provided by mapbox, there will be a more thorough announcement soon!
Created attachment 332374 [details] [review] Add MapSource module with Mapbox URIs Add mapSource.js which contains functions for creating cached Champlain MapSources using Mapbox URI.
Created attachment 332375 [details] [review] Use MapSource module to set map source
Cast of using Mapbox tiles: https://www.youtube.com/watch?v=3p1eCz8HCM8&feature=youtu.be
Created attachment 332376 [details] [review] Add MapSource module with Mapbox URIs Add mapSource.js which contains functions for creating cached Champlain MapSources using Mapbox URI.
Created attachment 332377 [details] [review] Use MapSource module to set map source
Created attachment 332378 [details] [review] Add MapSource module with Mapbox URIs Add mapSource.js which contains functions for creating cached Champlain MapSources using Mapbox URI.
Created attachment 332379 [details] [review] Use MapSource module to set map source
Created attachment 332384 [details] [review] Add MapSource module with Mapbox URIs Add mapSource.js which contains functions for creating cached Champlain MapSources using Mapbox URI.
Created attachment 332385 [details] [review] Use MapSource module to set map source
Created attachment 332386 [details] [review] Add Mapbox attribution logo
Created attachment 332390 [details] [review] Add MapSource module with Mapbox URIs Add mapSource.js which contains functions for creating cached Champlain MapSources using Mapbox URI.
Created attachment 332391 [details] [review] Use MapSource module to set map source
Created attachment 332392 [details] [review] Add Mapbox attribution logo
Great work Jonas! Thanks a lot for this! One thing I've been thinking about since we got the proxy up is what to do with the added latency we get. Here's two screen casts as comparison: with proxy: https://www.youtube.com/watch?v=UtZM4IuWOOk without proxy: https://www.youtube.com/watch?v=Q3cgopji3qw (my computer is lagging a bit at the end here) The difference is quite staggering. One thing I've been discussing with Andrea is whether we could just drop a gis.services file somewhere which would be a json document to all our service endpoints. That way we would have the possibility to quickly change tileservers when / if this happens again while not having to take a huge latency hit y going through gnome proxies. I could start looking at this on Sunday if it's interesting?
The latency is unfortunate. It can not be avoided? Or reduced at least? There are other benefits of having a GNOME proxy, stats for one thing, and one common entry point. And not having to have the access key locally on client side. I have pushed releases for 3.22, 3.20, 3.18 and 3.16: wip/jonasdn/mapbox-3-22 wip/jonasdn/mapbox-3-20 wip/jonasdn/mapbox-3-18 wip/jonasdn/mapbox-3-16 So when we want to make Maps working again with proxy I can push these to master/stable branches and make tar balls.
(3.16.0 release was March 2015)
Review of attachment 332392 [details] [review]: Pushed a version of this
Review of attachment 332391 [details] [review]: Pushed a version of this
Review of attachment 332390 [details] [review]: Pushed a version of this
Review of attachment 330219 [details] [review]: Obsolete
Review of attachment 330218 [details] [review]: Obsolete
This solution have been pushed to 3.16, 3.18, 3.20 and to master and tar balls have been sent out. Thank you all.
I am using the updated version on fedora 23 (see https://bugzilla.redhat.com/show_bug.cgi?id=1356484). It works again. Thanks a lot! Unfortunately, I can confirm the high latency, which makes working with gnome maps rather unpleasant. Should I file a new bug report for this?
(In reply to Dominik Grafenhofer from comment #60) > I am using the updated version on fedora 23 (see > https://bugzilla.redhat.com/show_bug.cgi?id=1356484). It works again. Thanks > a lot! > > Unfortunately, I can confirm the high latency, which makes working with > gnome maps rather unpleasant. Should I file a new bug report for this? Yes pls! Thanks! Keep in mind you probably had a lot of tiles cached before of old tiles. That needs to be recached now!
Done: https://bugzilla.gnome.org/show_bug.cgi?id=769352
Please provide a solution for GNOME Contacts too. It still tries to use map tiles provided by MapQuest: https://git.gnome.org/browse/gnome-contacts/tree/src/contacts-address-map.vala#n54
3.20 update is going out to Fedora users. The 3.18 update reportedly prevents Maps from launching at all: (org.gnome.Maps:8212): Gjs-WARNING **: JS ERROR: Error: No property 'projection' in property list (or its value was undefined) [...]
Better report: (org.gnome.Maps:8212): Gjs-WARNING **: JS ERROR: Error: No property 'projection' in property list (or its value was undefined) _createTileSource@resource:///org/gnome/Maps/js/mapSource.js:55 _createCachedSource@resource:///org/gnome/Maps/js/mapSource.js:70 createStreetSource@resource:///org/gnome/Maps/js/mapSource.js:105 MapView<.setMapType@resource:///org/gnome/Maps/js/mapView.js:160 wrapper@resource:///org/gnome/gjs/modules/lang.js:169 MapView<._init@resource:///org/gnome/Maps/js/mapView.js:84 wrapper@resource:///org/gnome/gjs/modules/lang.js:169 MainWindow<._init@resource:///org/gnome/Maps/js/mainWindow.js:76 wrapper@resource:///org/gnome/gjs/modules/lang.js:169 Application<._createWindow@resource:///org/gnome/Maps/js/application.js:236 wrapper@resource:///org/gnome/gjs/modules/lang.js:169 Application<.vfunc_activate@resource:///org/gnome/Maps/js/application.js:250 wrapper@resource:///org/gnome/gjs/modules/lang.js:169 main@resource:///org/gnome/Maps/js/main.js:47 run@resource:///org/gnome/gjs/modules/package.js:192 start@resource:///org/gnome/gjs/modules/package.js:176 @/usr/bin/gnome-maps:5
(In reply to Michael Catanzaro from comment #66) > Better report: > > (org.gnome.Maps:8212): Gjs-WARNING **: JS ERROR: Error: No property > 'projection' in property list (or its value was undefined) > _createTileSource@resource:///org/gnome/Maps/js/mapSource.js:55 > _createCachedSource@resource:///org/gnome/Maps/js/mapSource.js:70 > createStreetSource@resource:///org/gnome/Maps/js/mapSource.js:105 > MapView<.setMapType@resource:///org/gnome/Maps/js/mapView.js:160 > wrapper@resource:///org/gnome/gjs/modules/lang.js:169 > MapView<._init@resource:///org/gnome/Maps/js/mapView.js:84 > wrapper@resource:///org/gnome/gjs/modules/lang.js:169 > MainWindow<._init@resource:///org/gnome/Maps/js/mainWindow.js:76 > wrapper@resource:///org/gnome/gjs/modules/lang.js:169 > Application<._createWindow@resource:///org/gnome/Maps/js/application.js:236 > wrapper@resource:///org/gnome/gjs/modules/lang.js:169 > Application<.vfunc_activate@resource:///org/gnome/Maps/js/application.js:250 > wrapper@resource:///org/gnome/gjs/modules/lang.js:169 > main@resource:///org/gnome/Maps/js/main.js:47 > run@resource:///org/gnome/gjs/modules/package.js:192 > start@resource:///org/gnome/gjs/modules/package.js:176 > @/usr/bin/gnome-maps:5 Ah. Right. I built with latest champlain here. I think champlain had a bug with making its enums introspectsble at some point.
And Mercator is default it seems so can be omitted. Can do new releases tomorrow. I guess.
That'd be good, since we just told distros to upgrade to something that doesn't work!
(In reply to György Balló from comment #64) > Please provide a solution for GNOME Contacts too. It still tries to use map > tiles provided by MapQuest: > https://git.gnome.org/browse/gnome-contacts/tree/src/contacts-address-map. > vala#n54 https://bugzilla.gnome.org/show_bug.cgi?id=769372
I really don't like the new map source. The street names in Arabic are displayed from right to left when it should be from left to right. This makes them difficult to read.
Oops. I meant left to right when it should be right to left.
(In reply to Hussam Al-Tayeb from comment #72) > I really don't like the new map source. The street names in Arabic are > displayed from right to left when it should be from left to right. This > makes them difficult to read. This is an issue with the tile generation, so I think this issue should be raised to Mapbox' awareness.
Amisha: MapBox bug in comments #72 and #73.
(In reply to Hussam Al-Tayeb from comment #72) > I really don't like the new map source. The street names in Arabic are > displayed from right to left when it should be from left to right. This > makes them difficult to read. Yeah that's an open issue and is currently being worked upon.
(In reply to amisha from comment #76) > (In reply to Hussam Al-Tayeb from comment #72) > > I really don't like the new map source. The street names in Arabic are > > displayed from right to left when it should be from left to right. This > > makes them difficult to read. > > Yeah that's an open issue and is currently being worked upon. This appears to fixed now. Thank you very much :)