Re: [QGIS-Developer] Temporal controller issues
> I hear what you're saying, Nyall, I apologise if it sounded harsh, but what do you want me to say after I find out that the latest of several bugs has compromised my data and now I have to hunt down an unknown number of duplicates silently created over the last few months of work? If you empathise, do you understand how all these bugs and my data being compromised might make me feel that this feature was not done very well and that there was a lack of adequate testing? And now I just found that I have data loss as well, not just a bunch of duplicates. On Mon, Jan 4, 2021 at 2:40 PM Cory Albrecht wrote: > > Please be very wary of your language in future -- every piece of > feedback worded like this directly equates to a developer losing interest > in volunteering their time on QGIS, to the harm of all. > > I hear what you're saying, Nyall, I apologise if it sounded harsh, but > what do you want me to say after I find out that the latest of several bugs > has compromised my data and now I have to hunt down an unknown number of > duplicates silently created over the last few months of work? If you > empathise, do you understand how all these bugs and my data being > compromised might make me feel that this feature was not done very well and > that there was a lack of adequate testing? > > > As background, I implemented time handling for vector layers as a VOLUNTEER > (completely unpaid). Would you have preferred I didn't do this, and we > had no time support for vectors at all? > > As to what I would have preferred, well, I've reverted back to 3.10 to use > the old TimeManager plugin to avoid using the NTC. I would have preferred > that the feature branch you used to implement the NTC had not gotten merged > and the feature included in release versions until it had been checked to > work with and not break basic features like the selection tool. So now I > have to work under some Damoclean time limit for a couple of months until > 3.16 replaces 3.10 and I will have no choice but to move to a version with > the NTC and these bugs. > > On Sun, Jan 3, 2021 at 9:32 PM Nyall Dawson > wrote: > >> On Sat, 2 Jan 2021 at 10:23, Cory Albrecht wrote: >> > >> > Can somebody help me under the basics of how things work inside QGIS >> starting from when it loads all the features for a layer through the steps, >> and then finally drawing them on the map canvas, specifically with respect >> to the new temporal controller (NTC)? >> > >> > The issues caused by the NTC have been very frustrating for me as I >> make mostly (historical) timeline maps and I relied heavily on the old >> TimeManager (OTM) plugin by Antia Graser and group. So many tasks are now >> much more laborious or difficult because so many tools are just not >> time-aware. >> > >> > Was it not possible to add the NTC in such a way that would have still >> let all the other features work as before with the filtered feature set >> before being made time-aware, rather than confusingly operating on the >> unfiltered set? Or perhaps it shouldn't have been turned on until the >> infrastructure was there for the tools to be time-aware right away? >> > >> > Because I've just submitted yet another bug about the NTC, this time >> for the selection tool, and it has me more than a little annoyed. As a >> result of this bug I now have an unknown number of duplicate objects in >> multiple layers across multiple databases/projects that I unknowingly >> pasted into them over the past several months since the NTC was added to >> QGIS. >> > >> > I feel that the NTC was both poorly thought out and badly implemented >> as all these bugs would indicate. >> >> I can empathise with your frustration, but this is a very complex >> discussion! >> >> As background, I implemented time handling for vector layers as a >> VOLUNTEER (completely unpaid). Would you have preferred I didn't do >> this, and we had no time support for vectors at all? Please be very >> wary of your language in future -- every piece of feedback worded like >> this directly equates to a developer losing interest in volunteering >> their time on QGIS, to the harm of all. >> >> I've fixed two of your issues here >> https://github.com/qgis/QGIS/pull/40834, as an UNPAID VOLUNTEER. >> Without funding I'm just not interested in fixing the snapping related >> issues. I don't personally have any need for these, and the QGIS >> snapping code isn't something I'm motivated in getting involved with >> at all. Perhaps there's another developer interested in looking at >> this, or perhaps a developer will take a look at this during the 3.18 >> bug sprint. Or maybe someone will pay for this fix and financial gain >> will be the motivation. >> >> I like making the world a better place through volunteering my time on >> making a first-class desktop mapping application, but I'm far from >> being a slave to this, and my family, garden, and drum kit want my >> time too! >> >> Nyall >> >> >> >> >
Re: [QGIS-Developer] Temporal controller issues
> Please be very wary of your language in future -- every piece of feedback worded like this directly equates to a developer losing interest in volunteering their time on QGIS, to the harm of all. I hear what you're saying, Nyall, I apologise if it sounded harsh, but what do you want me to say after I find out that the latest of several bugs has compromised my data and now I have to hunt down an unknown number of duplicates silently created over the last few months of work? If you empathise, do you understand how all these bugs and my data being compromised might make me feel that this feature was not done very well and that there was a lack of adequate testing? > As background, I implemented time handling for vector layers as a VOLUNTEER (completely unpaid). Would you have preferred I didn't do this, and we had no time support for vectors at all? As to what I would have preferred, well, I've reverted back to 3.10 to use the old TimeManager plugin to avoid using the NTC. I would have preferred that the feature branch you used to implement the NTC had not gotten merged and the feature included in release versions until it had been checked to work with and not break basic features like the selection tool. So now I have to work under some Damoclean time limit for a couple of months until 3.16 replaces 3.10 and I will have no choice but to move to a version with the NTC and these bugs. On Sun, Jan 3, 2021 at 9:32 PM Nyall Dawson wrote: > On Sat, 2 Jan 2021 at 10:23, Cory Albrecht wrote: > > > > Can somebody help me under the basics of how things work inside QGIS > starting from when it loads all the features for a layer through the steps, > and then finally drawing them on the map canvas, specifically with respect > to the new temporal controller (NTC)? > > > > The issues caused by the NTC have been very frustrating for me as I make > mostly (historical) timeline maps and I relied heavily on the old > TimeManager (OTM) plugin by Antia Graser and group. So many tasks are now > much more laborious or difficult because so many tools are just not > time-aware. > > > > Was it not possible to add the NTC in such a way that would have still > let all the other features work as before with the filtered feature set > before being made time-aware, rather than confusingly operating on the > unfiltered set? Or perhaps it shouldn't have been turned on until the > infrastructure was there for the tools to be time-aware right away? > > > > Because I've just submitted yet another bug about the NTC, this time for > the selection tool, and it has me more than a little annoyed. As a result > of this bug I now have an unknown number of duplicate objects in multiple > layers across multiple databases/projects that I unknowingly pasted into > them over the past several months since the NTC was added to QGIS. > > > > I feel that the NTC was both poorly thought out and badly implemented as > all these bugs would indicate. > > I can empathise with your frustration, but this is a very complex > discussion! > > As background, I implemented time handling for vector layers as a > VOLUNTEER (completely unpaid). Would you have preferred I didn't do > this, and we had no time support for vectors at all? Please be very > wary of your language in future -- every piece of feedback worded like > this directly equates to a developer losing interest in volunteering > their time on QGIS, to the harm of all. > > I've fixed two of your issues here > https://github.com/qgis/QGIS/pull/40834, as an UNPAID VOLUNTEER. > Without funding I'm just not interested in fixing the snapping related > issues. I don't personally have any need for these, and the QGIS > snapping code isn't something I'm motivated in getting involved with > at all. Perhaps there's another developer interested in looking at > this, or perhaps a developer will take a look at this during the 3.18 > bug sprint. Or maybe someone will pay for this fix and financial gain > will be the motivation. > > I like making the world a better place through volunteering my time on > making a first-class desktop mapping application, but I'm far from > being a slave to this, and my family, garden, and drum kit want my > time too! > > Nyall > > > > > ___ > > QGIS-Developer mailing list > > QGIS-Developer@lists.osgeo.org > > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Convert geojson geometry to QgsGeometry in python
Hi Bo,
You can use the QgsJsonUtils.stringToFeatureList.
It adds a bit of overhead by roundtripping it through a QgsFeatureList but
works.
QgsJsonUtils.stringToFeatureList('''
{
"type": "Feature",
"geometry": {
"type": "Point",
"coordinates": [125.6, 10.1]
},
"properties": {
"name": "Dinagat Islands"
}
}
''')[0].geometry()
Matthias
On Mon, Jan 4, 2021 at 6:14 PM Bo Victor Thomsen <
bo.victor.thom...@gmail.com> wrote:
> Hi list members:
>
> The subject says it : How to convert the geometry part from a geojson
> string to a QgsGeometry
>
> Some details:
>
> How can I convert the geojson "geometry" part to a QgsGeometry ? i.e. The
> part marked in *bold* ?
>
> {
> "type": "Feature",
> *"geometry"**:* *{*
> *"type"**:* *"Point"**,*
> *"coordinates"**:* *[**125.6**,* *10.1**]*
> *}*,
> "properties": {
> "name": "Dinagat Islands"
> }}
>
> It's not the only "point" type, but all the geometry types (minus
> "geometry collection"): linestring, polygon, multipoint, multilinestring
> and multipolygon.
>
> The json text is already converted to a python dict using json.dumps().
> AFAIK, it's trivial to convert from QgsGeometry to geojson, but I can't
> find an existing method to do the opposite.
>
> --
> Med venlig hilsen / Kind regards
>
> Bo Victor Thomsen
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Convert geojson geometry to QgsGeometry in python
Hi list members:
The subject says it : How to convert the geometry part from a geojson
string to a QgsGeometry
Some details:
How can I convert the geojson "geometry" part to a QgsGeometry ? i.e.
The part marked in *bold* ?
|{"type":"Feature",*"geometry"**:{"type"**:"Point"**,"coordinates"**:[**125.6**,10.1**]}*,"properties":{"name":"Dinagat
Islands"}} |||
It's not the only "point" type, but all the geometry types (minus
"geometry collection"): linestring, polygon, multipoint, multilinestring
and multipolygon.
The json text is already converted to a python dict using json.dumps().
AFAIK, it's trivial to convert from QgsGeometry to geojson, but I can't
find an existing method to do the opposite.
--
Med venlig hilsen / Kind regards
Bo Victor Thomsen
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Call For Community Voting members ballot
Dear QGIS Community we invite you to elect your favourite community voting members. One community voting member is appointed in tandem with each new QGIS Country User Group Voting Member. This year there are 5 confirmed new country user groups. Furthermore, the AGM 2020 elected 2 Honorable Voting members, one of which was a community voting member. Since each person can have only one vote, this results in one additional community voter space up for election. This results in 6 new community voting members spaces available. Please read the instructions carefully and establish your eligibility to vote which I repeat here for your convenience: "Only community members with commit rights to an official QGIS git repository or with write access in transifex are eligible to vote nominees” Voting will close on Wednesday 17 January 2021 23:59 AoT. The voting form is here: https://forms.gle/2Js2RXDz6XaK9UM88 If you have any questions about the voting process please do not hesitate to contact me Happy new year Marco -- Marco Bernasocchi QGIS.org Chair OPENGIS.ch CEO http://berna.io ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Message to list
Hi Greg, Hannah On Mon, Jan 4, 2021 at 3:06 PM Greg Troxel wrote: > > Hannah Wait writes: > > > I work at a land surveying company and have a question on QGIS and > QField if anyone can help with. > > > > We are currently looking at uploading the 'Survaid' data with accurate > > positioning and exporting as a shapefile with the attributes in to > > QGIS. Do you know if there is a way to get the higher accuracy of > > external GPS to feed into QField on our tablet at all? > With the current stable QField (1.7) you need to use a mock application (like ntrip client) to connect an external GPS. However, the latest release 1.8 supports directly connecting to an external GPS via bluetooth. That gives you access to all the GPS data. This version is still in beta, so you have to a) either install it from the apk (available from the release page https://github.com/opengisch/QField/releases/tag/v1.8.0) b) install the qfield dev app ( https://play.google.com/store/apps/details?id=ch.opengis.qfield_dev=en=US ) c) join the "beta" on the play store app of qfield Stay tuned for a soon-to-come 1.8.1 with plenty of refinements on this front (already available in option b above) > > QField is on my list of things to try, but I haven't yet. > (Unfortunately it is not on f-droid so I'll have to build it from > source.) > Have a look at the release page link above, there are apks to download. Matthias > This query probably belongs on the QField mailinglist, but that appears > to be remarkably difficult to find. > > On Android, I can see three approaches. > > I use Vespucci, which is an openstreetmap editor. It has support for > an external NMEA source, via a TCP connection. One can put a phone in > hotspot mode and have the external device (e.g. Ardusimple WiFi NTRIP > Master with a simpleRTK2B F9P, and you are almost certainly using > something higher end!) get RTCM3 data, and have Vespucci get the RTK > solutions as high-precision NMEA. This takes you out of GIS proper > into OSM, which uses tags instead of layers, even though it's > basically the same thing. > > Modify QField to have the same sort of feature as Vespucci. You are > apparently not the first to want this: > https://github.com/opengisch/QField/issues/536 > > Use Android's "mocking" debug feature, which involves some program to > talk to the external GNSSr and inject location into the system, so > that programs see that location information. I gather people do this > with QField, from skimming their github repo. See > https://qfield.org/docs/fieldwork/gps.html > > Greg > ___ > QGIS-Developer mailing list > QGIS-Developer@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Message to list
Hannah Wait writes: > I work at a land surveying company and have a question on QGIS and QField if > anyone can help with. > > We are currently looking at uploading the 'Survaid' data with accurate > positioning and exporting as a shapefile with the attributes in to > QGIS. Do you know if there is a way to get the higher accuracy of > external GPS to feed into QField on our tablet at all? QField is on my list of things to try, but I haven't yet. (Unfortunately it is not on f-droid so I'll have to build it from source.) This query probably belongs on the QField mailinglist, but that appears to be remarkably difficult to find. On Android, I can see three approaches. I use Vespucci, which is an openstreetmap editor. It has support for an external NMEA source, via a TCP connection. One can put a phone in hotspot mode and have the external device (e.g. Ardusimple WiFi NTRIP Master with a simpleRTK2B F9P, and you are almost certainly using something higher end!) get RTCM3 data, and have Vespucci get the RTK solutions as high-precision NMEA. This takes you out of GIS proper into OSM, which uses tags instead of layers, even though it's basically the same thing. Modify QField to have the same sort of feature as Vespucci. You are apparently not the first to want this: https://github.com/opengisch/QField/issues/536 Use Android's "mocking" debug feature, which involves some program to talk to the external GNSSr and inject location into the system, so that programs see that location information. I gather people do this with QField, from skimming their github repo. See https://qfield.org/docs/fieldwork/gps.html Greg signature.asc Description: PGP signature ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Message to list
Hi, I work at a land surveying company and have a question on QGIS and QField if anyone can help with. We are currently looking at uploading the 'Survaid' data with accurate positioning and exporting as a shapefile with the attributes in to QGIS. Do you know if there is a way to get the higher accuracy of external GPS to feed into QField on our tablet at all? Kind regards, Hannah Hannah Wait GIS Technician ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Docker pull rate limit / Travis
Hi, Good move, thanks Alessandro. There was recently also a discussion about moving from travis to github workflows. In combination with this, I assume the base image could also be cached directly inside the github registry ( https://docs.github.com/en/free-pro-team@latest/packages/guides/about-github-container-registry ). This might also bring quicker builds because it's in the same network / tightly integrated with the service. Just to keep that in mind too Matthias On Mon, Jan 4, 2021 at 10:29 AM Alessandro Pasotti wrote: > On Mon, Jan 4, 2021 at 10:21 AM Alessandro Pasotti > wrote: > > > > On Mon, Jan 4, 2021 at 10:17 AM Richard Duivenvoorde > > wrote: > > > > > > Yes, I hit that too. thanks for bringing this up! > > > > > > Another idea: as the docker is actually more or less 'static' (??? or > is is pushed to hub on every build ???), can we (or Travis) not 'cache' it? > As in" place it somewhere so it can be 'created/started' fresh any time, > but not 'fetched' upon every build? > > > Or does this loose the whole purpose of this... > > > Caching could be: put the image on some webserver of somebody with > 'unlimited' bandwidth (like some universities, providers or > (unix)usergroups?). > > > > > > > I think that might work, the deps image is a base image and it doesn't > > change so often. > > > > > BUT: As QGIS is getting bigger and bigger, we have to find solutions > for this kind of 'size'-issues when using 'free' services. Same with for > example the use of OSM-tiles or Nominatim-service, Transifex etc etc... We > have to be either creative/clever, OR setup our own stuff... > > > > > > Regards, > > > > > > Richard Duivenvoorde > > > > > > > Yeah, let's just hope GitHub will remain free or we will have bigger > problems ;) > > > > In the meantime I can fill up the form > > https://www.docker.com/community/open-source/application if noone has > > already done that. > > > > > Done ^^^ let's see if that works. > > -- > Alessandro Pasotti > QCooperative: www.qcooperative.net > ItOpen: www.itopen.it > ___ > QGIS-Developer mailing list > QGIS-Developer@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] 3D View Interface Usability
Hi Jed Thanks a lot for your feedback. You have summarized it pretty well - camera controls in QGIS 3D are indeed largely based on Google Earth controls which I found relatively intuitive at the time when starting the work in 2017. We have realized over time that this kind of navigation is not enough for various use cases, including the one you have mentioned (to look at 20th floor of a building). There is definitely interest to improve it, especially with point clouds the limitations in the navigation are much easier to see. Editing vector data in 3D is near the top of the wish list for many users, so I think we will get to it sooner or later :-) Totally agreed that snapping to point clouds should be available to simplify data capturing. Probably an option to view the scene from multiple angles at once would be also useful for good quality editing (e.g. when editing vertices of a building in 3D). It looks like you already have ideas how to improve things - I would love to hear your thoughts how to make the navigation better. Please feel free to add links to videos of other software where you think the camera control behaves according to your expectations... Regards Martin On Mon, Jan 4, 2021 at 12:33 AM Jed Frechette wrote: > Happy New Year to all, > > Recently I’ve been spending time playing with the 3D view in QGIS and > I’m hoping to start a discussion about the UI and whether or not it > might make sense to consider some changes to that UI based on what the > intended uses of the 3D view are. > > Since I haven’t been directly involved in QGIS development before I’m > approaching this from a user’s perspective and thought I should start > with my observations and assumptions in case they’re radically > off-base compared to what the core developers envision for the 3D > view. > > Looking at the current state of the 3D view it seems heavily > influenced by Google Earth. In particular, it seems to be primarily > designed to simply display content that was created elsewhere. In the > context of the rest of the QGIS UI, it is much more similar to the > Print Layout view than the main 2D Map view. From a workflow > perspective, you work with your data in the main 2D Map and then > switch to the Print Layout or 3D views when you want to render that > data in a different context. > > I think now is a good time to start thinking about a potentially > bigger role for the 3D view because of the upcoming point cloud > support. I know that interactive tools are out of scope for the > current point cloud project, however, I think as soon as users can > visualize point clouds in QGIS they will want to start interacting > with them. Once the novelty wears off, simply rendering a point cloud > in 3D is pretty ugly and not terribly useful. However, being able to > digitize 3D points or lines with snapping to that point cloud is > extremely useful and that type of work will be difficult to do without > a well-designed 3D viewport. > > Even without new interactive tools, I think the more volumetric and > often unevenly distributed nature of most point cloud datasets will > make the current Google Earth style navigation less intuitive than it > is when dealing with the mostly 2D data it was designed to interact > with. For example, with the current camera controls you can’t track > along the world z-axis so you lose a degree of freedom when the camera > is horizontal. If you are looking at a street level building facade > and want to move to looking at the 20th floor you can’t just track > along the z-axis to get there. You need to tilt the camera up, try to > place it’s rotation point at the 20th floor (possibly moving the > camera backward and hoping nothing blocks your view), then tilt the > camera down (which translates the camera up) to get back to > horizontal. > > Although I spend a fair amount of time doing GIS work, my perspective > comes from spending the last 10 years working with lidar and similar > data in 3D modeling and metrology applications, where the primary mode > of interaction is a 3D viewport. As a result, I have several specific > thoughts on changes to the 3D View’s UI that would make it easier to > use, better able to eventually support more interactive tools and more > consistent with the rest of the QGIS UI. This email is already long > enough though so rather than get into that now, I’d first rather ask > what others think of the current 3D view. > > How much do people currently use the 3D view? Is the current UI > working well for how it is being used? What about down the road? Is > there a desire for more 3D tools and if so are there limitations of > the current design that should be reconsidered? > > Thanks for reading, > > -- > Jed Frechette > ___ > QGIS-Developer mailing list > QGIS-Developer@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe:
Re: [QGIS-Developer] Docker pull rate limit / Travis
On Mon, Jan 4, 2021 at 10:21 AM Alessandro Pasotti wrote: > > On Mon, Jan 4, 2021 at 10:17 AM Richard Duivenvoorde > wrote: > > > > Yes, I hit that too. thanks for bringing this up! > > > > Another idea: as the docker is actually more or less 'static' (??? or is is > > pushed to hub on every build ???), can we (or Travis) not 'cache' it? As > > in" place it somewhere so it can be 'created/started' fresh any time, but > > not 'fetched' upon every build? > > Or does this loose the whole purpose of this... > > Caching could be: put the image on some webserver of somebody with > > 'unlimited' bandwidth (like some universities, providers or > > (unix)usergroups?). > > > > I think that might work, the deps image is a base image and it doesn't > change so often. > > > BUT: As QGIS is getting bigger and bigger, we have to find solutions for > > this kind of 'size'-issues when using 'free' services. Same with for > > example the use of OSM-tiles or Nominatim-service, Transifex etc etc... We > > have to be either creative/clever, OR setup our own stuff... > > > > Regards, > > > > Richard Duivenvoorde > > > > Yeah, let's just hope GitHub will remain free or we will have bigger problems > ;) > > In the meantime I can fill up the form > https://www.docker.com/community/open-source/application if noone has > already done that. > Done ^^^ let's see if that works. -- Alessandro Pasotti QCooperative: www.qcooperative.net ItOpen: www.itopen.it ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Docker pull rate limit / Travis
On Mon, Jan 4, 2021 at 10:17 AM Richard Duivenvoorde wrote: > > Yes, I hit that too. thanks for bringing this up! > > Another idea: as the docker is actually more or less 'static' (??? or is is > pushed to hub on every build ???), can we (or Travis) not 'cache' it? As in" > place it somewhere so it can be 'created/started' fresh any time, but not > 'fetched' upon every build? > Or does this loose the whole purpose of this... > Caching could be: put the image on some webserver of somebody with > 'unlimited' bandwidth (like some universities, providers or > (unix)usergroups?). > I think that might work, the deps image is a base image and it doesn't change so often. > BUT: As QGIS is getting bigger and bigger, we have to find solutions for this > kind of 'size'-issues when using 'free' services. Same with for example the > use of OSM-tiles or Nominatim-service, Transifex etc etc... We have to be > either creative/clever, OR setup our own stuff... > > Regards, > > Richard Duivenvoorde > Yeah, let's just hope GitHub will remain free or we will have bigger problems ;) In the meantime I can fill up the form https://www.docker.com/community/open-source/application if noone has already done that. -- Alessandro Pasotti QCooperative: www.qcooperative.net ItOpen: www.itopen.it ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Docker pull rate limit / Travis
Yes, I hit that too. thanks for bringing this up! Another idea: as the docker is actually more or less 'static' (??? or is is pushed to hub on every build ???), can we (or Travis) not 'cache' it? As in" place it somewhere so it can be 'created/started' fresh any time, but not 'fetched' upon every build? Or does this loose the whole purpose of this... Caching could be: put the image on some webserver of somebody with 'unlimited' bandwidth (like some universities, providers or (unix)usergroups?). BUT: As QGIS is getting bigger and bigger, we have to find solutions for this kind of 'size'-issues when using 'free' services. Same with for example the use of OSM-tiles or Nominatim-service, Transifex etc etc... We have to be either creative/clever, OR setup our own stuff... Regards, Richard Duivenvoorde On 1/4/21 9:57 AM, pathmapper wrote: > Hi, > > due to the recently introduced docker pull rate limits there are currently > quite a lot Travis builds failing because of such a limit. > > According to this blogpost: > https://www.docker.com/blog/what-you-need-to-know-about-upcoming-docker-hub-rate-limiting/ > > "[...] non-commercial open source projects can apply for a sponsored Open > Source Docker account by filling out this application. No pull rate > restrictions will be applied to namespaces approved as non-commercial Open > Source projects." > > Don't know if such an application for a sponsored Open Source Docker account > would be something the QGIS project would be interested in or if the QGIS > Docker account is already sponsored. A sponsored Docker account might help a > little bit reaching these limits e.g. regarding pulling: > > https://hub.docker.com/r/qgis/qgis3-build-deps ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Docker pull rate limit / Travis
Hi, due to the recently introduced docker pull rate limits there are currently quite a lot Travis builds failing because of such a limit. According to this blogpost: https://www.docker.com/blog/what-you-need-to-know-about-upcoming-docker-hub-rate-limiting/ "[...] non-commercial open source projects can apply for a sponsored Open Source Docker account by filling out this application. No pull rate restrictions will be applied to namespaces approved as non-commercial Open Source projects." Don't know if such an application for a sponsored Open Source Docker account would be something the QGIS project would be interested in or if the QGIS Docker account is already sponsored. A sponsored Docker account might help a little bit reaching these limits e.g. regarding pulling: https://hub.docker.com/r/qgis/qgis3-build-deps Cheers, pathmapper ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
