Hi Tom and Mathieu
Ok good responses....I'll withdraw my suggestion for now.... Regards Tim Sutton Co-founder of Kartoza QGIS project chairman > On 22 Mar 2017, at 5:11 AM, Mathieu Pellerin <[email protected]> wrote: > > 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 >> >> 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 >>> Fax: +351 253604471 >>> Móvel: +351 910333888 >>> 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
