Tim, -1 to use OSM-based XYZ tile server that doesn't update its dataset on a regular basis (+/- weekly). While there are nicer styles that OSM's default one, one of the fundamental dynamic of OSM is the ability to update / add spatial data and see those updates reflected on tiles immediately. We should both respect and benefit from that :)
For e.g., the beautiful style on the link you provided uses a 10-month old OSM dataset. It's a significant data gap. Math On Wed, Mar 22, 2017 at 2:29 AM, Tim Sutton <[email protected]> wrote: > Hi > > Its really great to see this Paolo. I think the OSM requests all sound > reasonable and if we do start representing a high load on their servers we > could consider adding a caching proxy between QGIS clients and OSM tile > server so that we don't hit their servers too hard. > > One thing that I would suggest is that we do not use the default tile > renders for OSM - it would be much nicer to provide something 'consumer' > orientated rather than the OSM renders which are great for visualizing a > broad range of OSM feature types but not IMHO very nice looking > cartography. Reaching out to the folks at http://giscience.uni-hd.de to > see if we can use their tile renders might provide a nicer out of the box > experience for our users. Of course we would still acknowledge OSM as the > source of the data and giscience as source of the renders. Here is an > example of their render: > > *http://korona.geog.uni-heidelberg.de > <http://korona.geog.uni-heidelberg.de>* > > Regards > > Tim > > > > > > On 21 Mar 2017, at 4:58 PM, Jorge Gustavo Rocha <[email protected]> wrote: > > Hi Paolo, > > I can help on this. > > 1. The UserAgent is already a configurable feature in QGIS (under > Options/Network). Any user can change it, but we can propose another > default value. > > 2. The QGIS community is very much aware of OpenStreetMap. If we really > need to make our users more aware, does it make sense to add a new > button to QGIS to report map errors? (context dependent, when the > OpenStreetMap layer is shown) It would have the same functionality of > the notes in OpenStreetMap web interface. > > 3.1 On the "add layer" dialog, we can show the OpenStreetMap url (which > might change over time) and licenses (for data and tiles) taken from > settings or an (external) resource. We can make this not hard coded, to > be modified easily, without upgrading QGIS. We can also check if the > service is enabled for us, before allow users to add that layer (related > with 4.). > > 3.2 When the tiles are used in the composer or on the web client, we can > not enforce an attribution string. We might add or suggest it, but users > should be free the create and edit the attributions. It the > responsibility of the user, not a QGIS responsibility. > > 4. We have to handle when tiles are not loading, either because there > are network problems, server busy, etc. We can customize the user's > feedback regarding the load of the default OpenStreetMap tiles. But we > definitely need to know formally when they shut our access down. This is > related with 3.1 issue. If the access is disabled, we can also disable > adding default OpenStreetMap tiles option. > > Regards, > > Jorge Gustavo > > Às 09:52 de 21-03-2017, Paolo Cavallini escreveu: > > Hi all, > we have been exploring the possibility of adding default XYZ maps to > QGIS, so to make life far easier for users. > The good news is that the OSM board is quite positive about this. > The not-so-good news is that their (I believe reasonable) requirements > imply some more development from our side. > Is anyone interested in taking this? > Requirements below. > All the best. > === > > 1. You seem to be using an user agent of "Mozilla/5.0 QGIS/2.18.3". We > strongly recommend that you don't pretend to be a browser by adding the > "Mozilla" bit. OpenStreetMap sees increasing traffic from "fake" user > agents, and it is likely that we will penalise user agents like that at > some point in the future - meaning tiles will still be served, but > slower than to "honest" user agents that don't pretend to be a browser > when they are not. We understand that this is difficult terrain and that > other data sources might actually *require* that you pretend to be a > browser - perhaps per-datasource overrides of the user agent are a > possibility. > > 2. As you know, OpenStreetMap thrives on contributions by mappers, and > one of the main reasons we make our tiles freely available is the hope > of attracting new contributors. It would be nice if QGIS could do its > part to help us here, by making their users aware that OSM is open for > everyone to contribute. Perhaps a link to > http://www.openstreetmap.org/fixthemap can be placed somewhere in the > layer description or something. > > 3. Our data is licensed under ODbL 1.0, and our map tiles are CC-BY-SA > 2.0. The latter could change at any time; the former is > relatively constant. > > The legal consequences of this situation for your users are: > > * If they publish an image in which our tiles are visible, they must > attribute OpenStreetMap as the source, and specify that the map image is > CC-BY-SA 2.0, and specify that the data behind it is ODbL 1.0. All these > requirements can be fulfilled in one go by linking to > www.openstreetmap.org/copyright but there is no legal requirement to > link to that page. > > * Everyone is allowed to create derivatives of OpenStreetMap data - for > example by tracing features on the OSM tiles - and freely distribute > them. Such derived datasets, unless they are "insubstantial" > (https://wiki.osmfoundation.org/wiki/Licence/Community_ > Guidelines/Substantial_-_Guideline) > inherit the ODbL license and must, when publicly used, on request be > made available under ODbL. > > 4. If the load coming from QGIS should be unexpectedly high and impact > our service performance, there might come a time where we'd have to > throttle or even switch off this access. You should have some mechanism > or plan that deals with that to avoid frustration among your user base - > maybe a mechanism where QGIS installations request updated tile sources > from a central service so you could notify them of the OSM tiles not > being available (or being available elsewhere) should the need arise. > > > J. Gustavo > -- > Jorge Gustavo Rocha > Departamento de Informática > Universidade do Minho > 4710-057 Braga > Tel: +351 253604480 <+351%20253%20604%20480> > Fax: +351 253604471 <+351%20253%20604%20471> > Móvel: +351 910333888 <+351%20910%20333%20888> > skype: nabocudnosor > _______________________________________________ > Qgis-developer mailing list > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > > — > > > > > > > > > > *Tim Sutton* > > *Co-founder:* Kartoza > *Project chair:* QGIS.org > > Visit http://kartoza.com to find out about open source: > > Desktop GIS programming services > Geospatial web development > GIS Training > Consulting Services > > *Skype*: timlinux > *IRC:* timlinux on #qgis at freenode.net > > Kartoza is a merger between Linfiniti and Afrispatial > > > _______________________________________________ > Qgis-developer mailing list > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >
_______________________________________________ Qgis-developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
