Re: [Qgis-user] Report Layout strange behaviour with photos
On Tue, 15 Sep 2020 at 19:17, Bernd Vogelgesang wrote: > > Hi Andreas, > > hope I did not sound too negative. For sure I would like to help in some > way. I give money in nearly every crowdfunding project, though I even > don't need most functionalities there. > Around the report function, there is quite a sounding silence in the > lists and the web, so I assume that few people use it, or feel too > stupid to ask cause they don't get it to work properly. > > What I already tried, was to collect issues on github for the Report > But already there the problems begin: There is not a label for it (only > a general "Print Layout") and report is a very common word) > This may be intended as the reporting seems to be the younger brother of > the Atlas, but makes it not easier ;) There's now https://github.com/qgis/QGIS/issues?q=is%3Aopen+is%3Aissue+label%3AReports, and I've trawled through and tagged everything I could find (I may have missed some though!) There's a wishlist Google docs which has been a WIP collaborative effort for a while detailing possible future enhancements to reports (and layouts). Here's a quick summary of the current contents: **General layout improvements** - Show print margins for pages - Coloured and named snapping guides - Better guide snapping feedback (following the Illustrator approach) so that it's easier to see exactly what a smart guide is snapping features to - Add a wizard for automatic guide setup (e.g. for easy creation of grid based designs) - Allow negative guide placements to create guides which are aligned at “right edge - value” (e.g. -5 = 5mm from right side of page, regardless of page size) - Switch all the remaining items to use QgsTextRenderer for text - allowing buffers, shadows, background shapes. (Remaining items are legends and label items) - Make more layout item size settings unit aware, and add user-facing setting for setting the default layout unit - “Smart shapes”, e.g. annotation style “balloons” - Support icons in rows for attribute tables (i.e. show the conditional formatting icons in attribute tables when they are activated) - Double click resize handles to auto size items (e.g. expand/shrink a label item to fit the text. Double clicking the right handle would expand the item to the right, double clicking the left would expand it to the left, etc...) - Expand Processing layout tools to add extra algorithms for working with layouts -- e.g. create layout from template, export report, etc - Easier dynamic text insertion into layouts for beginners -- e.g. drag and drop dynamic page number, file path, author labels to the layout - Ability to drag and drop atlas fields to the page to auto-create an appropriate layout item. E.g. a layout label showing the field value, or a picture item populated by the field (if the atlas layer's form setup is set to use a file reference widget) ** Reports ** - Expression based filters for sections - Expression based custom sort order for field groups - Relation based sections (repeat section for all related features) - Support “aggregated” geometries for headers/footers in sections - Support for non-full page repeating sections - Support for "expanding" content (.e.g label items which grow to fit the available text, causing the section's size to vary feature-by-feature) (this one continues on from the previous point) - Reorder report sections via drag and drop - Add user-defined notes to sections describing the logic (not included in the outputs, only visible while designing the report) - Copy/paste groups and sections between different reports (or for duplicating within the same report) Feel free to add further ones :) At this stage it's just a wishlist, which would be culled down to a package of works at a later stage... Nyall > > Before I would be able to create a QEP, I would need someone to explain > me the parts in Report that I maybe simply do not understand. > > So, count me in (at least a bit ;) ) > > Bernd > > > On 15.09.20 08:30, Andreas Neumann wrote: > > Hi Bernd, > > The report functionality definitely needs some love. There is a great > > base now, but it needs to improve. > > Would you volunteer to collect missing things regarding reports in a QEP > > and then help organize a crowd-funding? Even if you can't fund this > > yourself, it would help a lot to come up with a sound proposal / > > specification, that some interested developer can submit a quote and we > > can look around for funders. > > There are quite a few successful examples in the past where someone who > > missed a functionality in QGIS but couln't finance it came up with a > > sound proposal and then we could find a developer and funders based on > > that initiative. > > Or you could organize this as a joint effort - e.g. through the german > > QGIS user group. > > Greetings, > > Andreas > > On 2020-09-14 23:09, Bernd Vogelgesang wrote: > > > >> On 14.09.20 22:30, Håvard Tveite wrote: > >>> Including photos / images in reports is
Re: [Qgis-user] GeoJSON coordinate precision
Unbelievable how I could not recognise this setting in the export window. Again a great example that the human in front of the pc is mostly the main problem :) Thank you, Werner, for your help. Christoph > Am 15.09.2020 um 13:57 schrieb Werner Macho : > > Hi Christoph, > back in front of my PC there is room for further explanation ;) > > if you right click on the layer to export and go to "Export" -> "Save > Features As" the Export window opens .. > If you scroll down a bit there are "Layer Options" - and within the > Layer Options (depending to which format you want to export, but you > said GeoJSON - and within GeoJSON I just checked that the option is > really there) there is the "COORDINATE_PRECISION" Option in the first > line (followed by RFC7946 and WRITE_BBOX). > Default should be 15 as precision .. > > Hope this helps > > regards > Werner > >> On Tue, Sep 15, 2020 at 1:51 PM Christoph Jung wrote: >> >> Hello Werner, >> >> Thank you for your response. I looked for a parameter like >> coordinate_precision, but I could not find anything similar in the export >> dialogue (for GeoJSON), in the application options also not. >> >> Christoph >> Am 15.09.2020 um 11:40 schrieb Werner Macho : >>> ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] Relation (1-N) Unpredictable Result (with default options)
Hi Jeffrey, Ah - this sounds familiar. I am cc'ing Denis Rouzaud who fixed this on master. See https://github.com/qgis/QGIS/issues/37266 @Denis - was this ever backported to 3.10? From https://github.com/qgis/QGIS/pull/37286 I can't tell. If this isn't fixed in 3.10 yet, I strongly suggest to do so. Thanks for a clarification, Denis, Andreas Am 15.09.20 um 17:50 schrieb Jeffrey Durrence: Andreas, Thank you for your interest in my reported problem. I have worked with this some today in hopes of opening an issue on GitHub. Unfortunately, the problem seems even more mysterious to me after further testing. I have 2 data data tables generated extracted from a fulcrumapp.com app. These 2 tables have a foreign key relationship by design, so they should work well in QGIS using the relation feature. After today's testing, I can tell you that they actually do work fine so long as I use a very small subset of the actual data. This is the mysterious part. For example, if I limit the parent table to only 10 records and then limit the child table to those records linked to the 10 parents, QGIS performs as expected. If I use all of the data (around 4000 parent records and 9000 child records), then I get an incorrect parent-to-child assignment for new child records that I try to create. With this being the case, I don't feel confident posting an issue on GitHub. I would have to anonymize the data to post on GitHub, and that would require further work on my end. If I have more time today or tomorrow, I will try to further investigate the problem to see if I can learn more about the behavior. -Jeffrey -- Jeffrey Durrence jeffrey.durre...@mcleanengineering.com McLean Engineering Company 815 South Main Street Moultrie, GA 31768 1.229.985.1148 (Voice) 1.229.985.2248 (FAX) 1.229.798.0480 (Mobile) *From: *"Andreas Neumann" *To: *"Jeffrey Durrence" *Cc: *"qgis-user" *Sent: *Tuesday, September 15, 2020 2:12:12 AM *Subject: *Re: [Qgis-user] Relation (1-N) Unpredictable Result (with default options) Hi Jeffrey, Can you please open an issue on Github (https://github.com/qgis/QGIS/issues) and include your DDL SQL statements you used for these tests - including all pkey/fkey and other constraints you used and a simple QGIS project file demonstrating the issue. It is easier to discuss such issues on Github. Maybe it is related to the fact that Comboboxes aren't properly initialized with NULL values, for cases that don't allow NULL values. This is important to investigate - as it is unacceptable that corrupt data is collected. Thanks, Andreas On 2020-09-15 04:32, Jeffrey Durrence wrote: Today I was trying to set up an edit form for a spatial table with a related, non-spatial table. I have done this many times in the past, but it's been a while. After using Project Properties to set up my relation, I made several attempts to add a new record in the "child" table. Each time I tried, the new record did not get the correct value for the field which relates the two tables. Existing records were displayed as expected and could be edited, but I could not add new features. I went to the docs to see if something had changed that might be affecting me. I downloaded sample shapefile data and used that to demonstrate that related records could be created with that data. I set up a clean database and QGIS project file and made several attempts with my PostGIS data. I did observe that some new options were available to me under the widget area of the child table. What had me confused was that with the default options selected (the way I used to do it), the "reference field" values generated for the "new" child records were real values -- just not at all the correct values. I tried several things with the PostGIS data, but what finally fixed the behavior for me was to make one change in the default Widget settings for the "reference field" in the child table properties. In my case, enabling the option to "Use a read-only line edit instead of a combobox" resolved the issue. When that is enabled, new child records get the correct value for the reference field. I don't completely understand what determined the inserted values when this option was not enabled, but I would think that enabling this by default would save a lot of confusion for users like me. I was quite surprised that I could not find folks talking about this in the usual places. Could be that there is something local to my environment, but I thought it worth mentioning should someone else stumble upon it. Using QGIS LTS (3.10.5) on Ubuntu 20.4 and Windows 10 64-Bit with PostGIS backend (observed same behavior with Postgres 10.14 / PostGIS 2.4.4 and Postgres 12.4 / PostGIS 3.0.0) -- Jeffrey
Re: [Qgis-user] Relation (1-N) Unpredictable Result (with default options)
Andreas, Thank you for your interest in my reported problem. I have worked with this some today in hopes of opening an issue on GitHub. Unfortunately, the problem seems even more mysterious to me after further testing. I have 2 data data tables generated extracted from a fulcrumapp.com app. These 2 tables have a foreign key relationship by design, so they should work well in QGIS using the relation feature. After today's testing, I can tell you that they actually do work fine so long as I use a very small subset of the actual data. This is the mysterious part. For example, if I limit the parent table to only 10 records and then limit the child table to those records linked to the 10 parents, QGIS performs as expected. If I use all of the data (around 4000 parent records and 9000 child records), then I get an incorrect parent-to-child assignment for new child records that I try to create. With this being the case, I don't feel confident posting an issue on GitHub. I would have to anonymize the data to post on GitHub, and that would require further work on my end. If I have more time today or tomorrow, I will try to further investigate the problem to see if I can learn more about the behavior. -Jeffrey -- Jeffrey Durrence jeffrey.durre...@mcleanengineering.com McLean Engineering Company 815 South Main Street Moultrie, GA 31768 1.229.985.1148 (Voice) 1.229.985.2248 (FAX) 1.229.798.0480 (Mobile) From: "Andreas Neumann" To: "Jeffrey Durrence" Cc: "qgis-user" Sent: Tuesday, September 15, 2020 2:12:12 AM Subject: Re: [Qgis-user] Relation (1-N) Unpredictable Result (with default options) Hi Jeffrey, Can you please open an issue on Github ( [ https://github.com/qgis/QGIS/issues | https://github.com/qgis/QGIS/issues ] ) and include your DDL SQL statements you used for these tests - including all pkey/fkey and other constraints you used and a simple QGIS project file demonstrating the issue. It is easier to discuss such issues on Github. Maybe it is related to the fact that Comboboxes aren't properly initialized with NULL values, for cases that don't allow NULL values. This is important to investigate - as it is unacceptable that corrupt data is collected. Thanks, Andreas On 2020-09-15 04:32, Jeffrey Durrence wrote: Today I was trying to set up an edit form for a spatial table with a related, non-spatial table. I have done this many times in the past, but it's been a while. After using Project Properties to set up my relation, I made several attempts to add a new record in the "child" table. Each time I tried, the new record did not get the correct value for the field which relates the two tables. Existing records were displayed as expected and could be edited, but I could not add new features. I went to the docs to see if something had changed that might be affecting me. I downloaded sample shapefile data and used that to demonstrate that related records could be created with that data. I set up a clean database and QGIS project file and made several attempts with my PostGIS data. I did observe that some new options were available to me under the widget area of the child table. What had me confused was that with the default options selected (the way I used to do it), the "reference field" values generated for the "new" child records were real values -- just not at all the correct values. I tried several things with the PostGIS data, but what finally fixed the behavior for me was to make one change in the default Widget settings for the "reference field" in the child table properties. In my case, enabling the option to "Use a read-only line edit instead of a combobox" resolved the issue. When that is enabled, new child records get the correct value for the reference field. I don't completely understand what determined the inserted values when this option was not enabled, but I would think that enabling this by default would save a lot of confusion for users like me. I was quite surprised that I could not find folks talking about this in the usual places. Could be that there is something local to my environment, but I thought it worth mentioning should someone else stumble upon it. Using QGIS LTS (3.10.5) on Ubuntu 20.4 and Windows 10 64-Bit with PostGIS backend (observed same behavior with Postgres 10.14 / PostGIS 2.4.4 and Postgres 12.4 / PostGIS 3.0.0) -- Jeffrey Durrence jeffrey.durre...@mcleanengineering.com McLean Engineering Company 815 South Main Street Moultrie, GA 31768 ___ Qgis-user mailing list [ mailto:Qgis-user@lists.osgeo.org | Qgis-user@lists.osgeo.org ] List info: [ https://lists.osgeo.org/mailman/listinfo/qgis-user | https://lists.osgeo.org/mailman/listinfo/qgis-user ] Unsubscribe: [ https://lists.osgeo.org/mailman/listinfo/qgis-user | https://lists.osgeo.org/mailman/listinfo/qgis-user ] ___
Re: [Qgis-user] GeoJSON coordinate precision
Hi Christoph, back in front of my PC there is room for further explanation ;) if you right click on the layer to export and go to "Export" -> "Save Features As" the Export window opens .. If you scroll down a bit there are "Layer Options" - and within the Layer Options (depending to which format you want to export, but you said GeoJSON - and within GeoJSON I just checked that the option is really there) there is the "COORDINATE_PRECISION" Option in the first line (followed by RFC7946 and WRITE_BBOX). Default should be 15 as precision .. Hope this helps regards Werner On Tue, Sep 15, 2020 at 1:51 PM Christoph Jung wrote: > > Hello Werner, > > Thank you for your response. I looked for a parameter like > coordinate_precision, but I could not find anything similar in the export > dialogue (for GeoJSON), in the application options also not. > > Christoph > > > Am 15.09.2020 um 11:40 schrieb Werner Macho : > > ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] GeoJSON coordinate precision
Hello Werner, Thank you for your response. I looked for a parameter like coordinate_precision, but I could not find anything similar in the export dialogue (for GeoJSON), in the application options also not. Christoph > Am 15.09.2020 um 11:40 schrieb Werner Macho : > ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [QGIS-it-user] sito qgis.it - sezione blog
Ciao Salvatore, sì, sarebbe utile. Ci vorrebbe poi qualcuno che aggiorni il blog con nuovi contenuti. Aggiungo, per migliorare il sito, di tradurre in italiano (o di eliminare se non necessario) il banner dell'informativa sui cookies (sono necessari? vengono utilizzati?) https://github.com/qgis-it/qgis-it.github.io/issues/19 Inoltre il sito è fornito solo di accesso HTTP:// e non anche di quello HTTPS://. Sarebbe utile aggiungere un certificato ssl/tls magari tramite https://letsencrypt.org/. A presto. Andrea -- Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Italian-User-f5250612.html ___ QGIS-it-user mailing list QGIS-it-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/qgis-it-user
Re: [Qgis-user] Report Layout strange behaviour with photos
Hi, The documentation can also be used to identify problems. Some things are explained in much detail, and that suggests that there is room for improvements in the report GUI / workflow. Håvard (who revised/wrote the report documentation) On 15.09.2020 11:17, Bernd Vogelgesang wrote: > Hi Andreas, > > hope I did not sound too negative. For sure I would like to help in some > way. I give money in nearly every crowdfunding project, though I even > don't need most functionalities there. > Around the report function, there is quite a sounding silence in the > lists and the web, so I assume that few people use it, or feel too > stupid to ask cause they don't get it to work properly. > > What I already tried, was to collect issues on github for the Report > But already there the problems begin: There is not a label for it (only > a general "Print Layout") and report is a very common word) > This may be intended as the reporting seems to be the younger brother of > the Atlas, but makes it not easier ;) > > Before I would be able to create a QEP, I would need someone to explain > me the parts in Report that I maybe simply do not understand. > > So, count me in (at least a bit ;) ) > > Bernd > > > On 15.09.20 08:30, Andreas Neumann wrote: >> Hi Bernd, >> The report functionality definitely needs some love. There is a great >> base now, but it needs to improve. >> Would you volunteer to collect missing things regarding reports in a QEP >> and then help organize a crowd-funding? Even if you can't fund this >> yourself, it would help a lot to come up with a sound proposal / >> specification, that some interested developer can submit a quote and we >> can look around for funders. >> There are quite a few successful examples in the past where someone who >> missed a functionality in QGIS but couln't finance it came up with a >> sound proposal and then we could find a developer and funders based on >> that initiative. >> Or you could organize this as a joint effort - e.g. through the german >> QGIS user group. >> Greetings, >> Andreas >> On 2020-09-14 23:09, Bernd Vogelgesang wrote: >> >>> On 14.09.20 22:30, Håvard Tveite wrote: Including photos / images in reports is covered by the documentation. See: https://docs.qgis.org/testing/en/docs/user_manual/print_composer/create_reports.html#including-pictures-in-a-report It worked for me. It should now also be possible to use images stored in a BLOB field. Håvard >>> >>> Thanx for answering. Indeed there is something about adding photos, but >>> actually this version of the doc is somehow not showing up in google >>> searches: >>> >>> Furthermore, I did not have the problem of having to construct a path to >>> the image. The full path is already in the data (from the nice toolbox >>> function for geotagged images). The report just did't eat the path. >>> After dozend and dozends of attemps, QGIS somehow seemed to give up on >>> refusing them, and now miraculously is accepting the path. >>> >>> The problem, that all images where repeatedly showing in all section got >>> solved too. In the level up for the subplots, I had to use the field >>> unique for each subplot and not that for the plot, as I wrongly assumed. >>> Having it set wrongly didn't influence the correct print of the plots >>> and then their subplots, but had influence on the follwing photos. Pfuh, >>> the logic behind, how the report "knows "what to print in lower levels >>> is actually not really obvious, It seems to figure this out on its own. >>> >>> So, seems I get it working. >>> >>> Major flaws: >>> There is only the possibility to select an existing field for a layer in >>> report groups. So the data has to be prepared for each and every >>> possible usage beforehand. Having the possibilty to use expressions here >>> would be phantastic. So now, when you find out that you had not the >>> right variables for your job in the data, you have to stop working on >>> the report and fumble the stuff into the attributes. I worked around >>> this problem by setting up a nice model to prepare my data, but not >>> everyone has the knowledge to do so. >>> >>> Found no way to add sections within the "tree" or to move anything. Once >>> you laid out a design and forgot a title page or mid-sections, you seem >>> to have to restart from scratch. No way to manipulate it later. >>> >>> Found no way so far to add page numbers. >>> >>> All in all. Spent 2 days now on this 30 page report and I hope I will >>> remember next time how to glue things together. >>> This could be a really powerful tool for lazy people having to do boring >>> reports frequently. So far, no time was gained, and I had to use extra >>> doses of alcohol not to give up.;) >>> Hopefully developers will give it a little more love some day to make it >>> a bit smoother, then it will really rock! >>> >>> On 14.09.2020 18:20, Bernd Vogelgesang wrote: Hi there, >>> >>> I'm really eager to finally
Re: [Qgis-user] GeoJSON coordinate precision
Hi, only on mobile now, so not tested, but I think you can use the COORDINATE_PRECISION option to specify the number of decimals when exporting. regards werner ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] Report Layout strange behaviour with photos
Hi Bernd, The best intro to QGIS reports (that I know) can be found at Nyall Dawsons website: https://north-road.com/2018/01/23/exploring-reports-in-qgis-3-0-the-ultimate-guide/ Nyall is also the developer who worked on the reports. The reports in QGIS did not get a lot of attention yet - Tim Sutton presented reports and his reults at FOSS4G in Bucharest - and like you, he ran into a lot of limitations and hidden things you need to do with expressions and such. There is definitely room for improvements. Collecting feature requests at Github is great, but it would be very good to collect (reference) all of these in a QGIS QEP and then we could find a dev (most likely Nyall) and come up with funding. I am pretty sure that Tim Sutton would join your effort - and myself as well ;-) If this effort is backed by a convincing collection of useful improvements, I am confident that we can find organizations funding it. We could also schedule a meeting with Tim, Nyall and yourself - and other interested users to discuss further improvements. But collecting missing things upfront to such a meeting would make the discussion much more productive. Hope this helps, Andreas On 2020-09-15 11:17, Bernd Vogelgesang wrote: Hi Andreas, hope I did not sound too negative. For sure I would like to help in some way. I give money in nearly every crowdfunding project, though I even don't need most functionalities there. Around the report function, there is quite a sounding silence in the lists and the web, so I assume that few people use it, or feel too stupid to ask cause they don't get it to work properly. What I already tried, was to collect issues on github for the Report But already there the problems begin: There is not a label for it (only a general "Print Layout") and report is a very common word) This may be intended as the reporting seems to be the younger brother of the Atlas, but makes it not easier ;) Before I would be able to create a QEP, I would need someone to explain me the parts in Report that I maybe simply do not understand. So, count me in (at least a bit ;) ) Bernd On 15.09.20 08:30, Andreas Neumann wrote: Hi Bernd, The report functionality definitely needs some love. There is a great base now, but it needs to improve. Would you volunteer to collect missing things regarding reports in a QEP and then help organize a crowd-funding? Even if you can't fund this yourself, it would help a lot to come up with a sound proposal / specification, that some interested developer can submit a quote and we can look around for funders. There are quite a few successful examples in the past where someone who missed a functionality in QGIS but couln't finance it came up with a sound proposal and then we could find a developer and funders based on that initiative. Or you could organize this as a joint effort - e.g. through the german QGIS user group. Greetings, Andreas On 2020-09-14 23:09, Bernd Vogelgesang wrote: On 14.09.20 22:30, Håvard Tveite wrote: Including photos / images in reports is covered by the documentation. See: https://docs.qgis.org/testing/en/docs/user_manual/print_composer/create_reports.html#including-pictures-in-a-report It worked for me. It should now also be possible to use images stored in a BLOB field. Håvard Thanx for answering. Indeed there is something about adding photos, but actually this version of the doc is somehow not showing up in google searches: Furthermore, I did not have the problem of having to construct a path to the image. The full path is already in the data (from the nice toolbox function for geotagged images). The report just did't eat the path. After dozend and dozends of attemps, QGIS somehow seemed to give up on refusing them, and now miraculously is accepting the path. The problem, that all images where repeatedly showing in all section got solved too. In the level up for the subplots, I had to use the field unique for each subplot and not that for the plot, as I wrongly assumed. Having it set wrongly didn't influence the correct print of the plots and then their subplots, but had influence on the follwing photos. Pfuh, the logic behind, how the report "knows "what to print in lower levels is actually not really obvious, It seems to figure this out on its own. So, seems I get it working. Major flaws: There is only the possibility to select an existing field for a layer in report groups. So the data has to be prepared for each and every possible usage beforehand. Having the possibilty to use expressions here would be phantastic. So now, when you find out that you had not the right variables for your job in the data, you have to stop working on the report and fumble the stuff into the attributes. I worked around this problem by setting up a nice model to prepare my data, but not everyone has the knowledge to do so. Found no way to add sections within the "tree" or to move anything. Once you laid out a design and forgot a title page or
[Qgis-user] GeoJSON coordinate precision
Hello everyone, I have polygons on both sides of the date line. I checked and corrected all vertices to avoid coordinates bigger 180 and less -180 degrees. I used the vertices tool and there were only 5 numbers after the comma of the coordinates. But after exporting the data to GeoJSON, the coordinates have now several numbers more behind the comma with the problem, that some coordinates are bigger 180 and less -180 degrees. Is there any place to control the precision of the coordinates during the export to GeoJSON or is the precision of the numbers in the vertices tool controllable? Sincerely, Christoph ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] Report Layout strange behaviour with photos
Hi Andreas, hope I did not sound too negative. For sure I would like to help in some way. I give money in nearly every crowdfunding project, though I even don't need most functionalities there. Around the report function, there is quite a sounding silence in the lists and the web, so I assume that few people use it, or feel too stupid to ask cause they don't get it to work properly. What I already tried, was to collect issues on github for the Report But already there the problems begin: There is not a label for it (only a general "Print Layout") and report is a very common word) This may be intended as the reporting seems to be the younger brother of the Atlas, but makes it not easier ;) Before I would be able to create a QEP, I would need someone to explain me the parts in Report that I maybe simply do not understand. So, count me in (at least a bit ;) ) Bernd On 15.09.20 08:30, Andreas Neumann wrote: Hi Bernd, The report functionality definitely needs some love. There is a great base now, but it needs to improve. Would you volunteer to collect missing things regarding reports in a QEP and then help organize a crowd-funding? Even if you can't fund this yourself, it would help a lot to come up with a sound proposal / specification, that some interested developer can submit a quote and we can look around for funders. There are quite a few successful examples in the past where someone who missed a functionality in QGIS but couln't finance it came up with a sound proposal and then we could find a developer and funders based on that initiative. Or you could organize this as a joint effort - e.g. through the german QGIS user group. Greetings, Andreas On 2020-09-14 23:09, Bernd Vogelgesang wrote: On 14.09.20 22:30, Håvard Tveite wrote: Including photos / images in reports is covered by the documentation. See: https://docs.qgis.org/testing/en/docs/user_manual/print_composer/create_reports.html#including-pictures-in-a-report It worked for me. It should now also be possible to use images stored in a BLOB field. Håvard Thanx for answering. Indeed there is something about adding photos, but actually this version of the doc is somehow not showing up in google searches: Furthermore, I did not have the problem of having to construct a path to the image. The full path is already in the data (from the nice toolbox function for geotagged images). The report just did't eat the path. After dozend and dozends of attemps, QGIS somehow seemed to give up on refusing them, and now miraculously is accepting the path. The problem, that all images where repeatedly showing in all section got solved too. In the level up for the subplots, I had to use the field unique for each subplot and not that for the plot, as I wrongly assumed. Having it set wrongly didn't influence the correct print of the plots and then their subplots, but had influence on the follwing photos. Pfuh, the logic behind, how the report "knows "what to print in lower levels is actually not really obvious, It seems to figure this out on its own. So, seems I get it working. Major flaws: There is only the possibility to select an existing field for a layer in report groups. So the data has to be prepared for each and every possible usage beforehand. Having the possibilty to use expressions here would be phantastic. So now, when you find out that you had not the right variables for your job in the data, you have to stop working on the report and fumble the stuff into the attributes. I worked around this problem by setting up a nice model to prepare my data, but not everyone has the knowledge to do so. Found no way to add sections within the "tree" or to move anything. Once you laid out a design and forgot a title page or mid-sections, you seem to have to restart from scratch. No way to manipulate it later. Found no way so far to add page numbers. All in all. Spent 2 days now on this 30 page report and I hope I will remember next time how to glue things together. This could be a really powerful tool for lazy people having to do boring reports frequently. So far, no time was gained, and I had to use extra doses of alcohol not to give up.;) Hopefully developers will give it a little more love some day to make it a bit smoother, then it will really rock! On 14.09.2020 18:20, Bernd Vogelgesang wrote: Hi there, I'm really eager to finally figure out how to create a photo documentation with QGIS. Everything needed is prepared and in place. I have overview coverages of plots with sub-plot over an aerial image. The maps are nicely produced to a report as groups. On each overview, the belonging sub-plots follow as individual maps. Now I would like to show pictures taken on the sub-plots. First issue: I add a new group photo-points and as field I select the referencing field for the sub-plot. Edit body, add picture frame. When setting the full file path for the images (stored as field "photo" in the point file, generated with "Import geotagged
Re: [QGIS-it-user] sito qgis.it - sezione blog
per aggiornamenti sul sito sulle traduzioni, forko, updato e pullo la requesta o passo direttamente il file ? :-D s. Il giorno mar 15 set 2020 alle ore 09:38 Federico Gianoli < gianoli.feder...@gmail.com> ha scritto: > Ciao a tutti, > sì sono d'accordo anche io con il blog, devo capire come farlo girare > sullo spazio github dove abbiamo il sito (e da qui deriva il problema > dell'http che non ho ancora avuto tempo di mettermi per risolverlo). > I cookie vengono utilizzati ed il banner è obbligatorio. tradurlo è un > attimo lo si può fare. > > Fede > > Il giorno mar 15 set 2020 alle ore 09:14 Andrea Giudiceandrea < > andreaer...@libero.it> ha scritto: > >> Ciao Salvatore, >> sì, sarebbe utile. Ci vorrebbe poi qualcuno che aggiorni il blog con nuovi >> contenuti. >> >> Aggiungo, per migliorare il sito, di tradurre in italiano (o di eliminare >> se >> non necessario) il banner dell'informativa sui cookies (sono necessari? >> vengono utilizzati?) >> https://github.com/qgis-it/qgis-it.github.io/issues/19 >> >> Inoltre il sito è fornito solo di accesso HTTP:// e non anche di quello >> HTTPS://. Sarebbe utile aggiungere un certificato ssl/tls magari tramite >> https://letsencrypt.org/. >> >> A presto. >> >> Andrea >> >> >> >> -- >> Sent from: >> http://osgeo-org.1560.x6.nabble.com/QGIS-Italian-User-f5250612.html >> ___ >> QGIS-it-user mailing list >> QGIS-it-user@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/qgis-it-user >> > ___ > QGIS-it-user mailing list > QGIS-it-user@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/qgis-it-user > ___ QGIS-it-user mailing list QGIS-it-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/qgis-it-user
Re: [QGIS-it-user] sito qgis.it - sezione blog
Ciao a tutti, sì sono d'accordo anche io con il blog, devo capire come farlo girare sullo spazio github dove abbiamo il sito (e da qui deriva il problema dell'http che non ho ancora avuto tempo di mettermi per risolverlo). I cookie vengono utilizzati ed il banner è obbligatorio. tradurlo è un attimo lo si può fare. Fede Il giorno mar 15 set 2020 alle ore 09:14 Andrea Giudiceandrea < andreaer...@libero.it> ha scritto: > Ciao Salvatore, > sì, sarebbe utile. Ci vorrebbe poi qualcuno che aggiorni il blog con nuovi > contenuti. > > Aggiungo, per migliorare il sito, di tradurre in italiano (o di eliminare > se > non necessario) il banner dell'informativa sui cookies (sono necessari? > vengono utilizzati?) > https://github.com/qgis-it/qgis-it.github.io/issues/19 > > Inoltre il sito è fornito solo di accesso HTTP:// e non anche di quello > HTTPS://. Sarebbe utile aggiungere un certificato ssl/tls magari tramite > https://letsencrypt.org/. > > A presto. > > Andrea > > > > -- > Sent from: > http://osgeo-org.1560.x6.nabble.com/QGIS-Italian-User-f5250612.html > ___ > QGIS-it-user mailing list > QGIS-it-user@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/qgis-it-user > ___ QGIS-it-user mailing list QGIS-it-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/qgis-it-user
Re: [Qgis-user] Report Layout strange behaviour with photos
Hi Bernd, The report functionality definitely needs some love. There is a great base now, but it needs to improve. Would you volunteer to collect missing things regarding reports in a QEP and then help organize a crowd-funding? Even if you can't fund this yourself, it would help a lot to come up with a sound proposal / specification, that some interested developer can submit a quote and we can look around for funders. There are quite a few successful examples in the past where someone who missed a functionality in QGIS but couln't finance it came up with a sound proposal and then we could find a developer and funders based on that initiative. Or you could organize this as a joint effort - e.g. through the german QGIS user group. Greetings, Andreas On 2020-09-14 23:09, Bernd Vogelgesang wrote: On 14.09.20 22:30, Håvard Tveite wrote: Including photos / images in reports is covered by the documentation. See: https://docs.qgis.org/testing/en/docs/user_manual/print_composer/create_reports.html#including-pictures-in-a-report It worked for me. It should now also be possible to use images stored in a BLOB field. Håvard Thanx for answering. Indeed there is something about adding photos, but actually this version of the doc is somehow not showing up in google searches: Furthermore, I did not have the problem of having to construct a path to the image. The full path is already in the data (from the nice toolbox function for geotagged images). The report just did't eat the path. After dozend and dozends of attemps, QGIS somehow seemed to give up on refusing them, and now miraculously is accepting the path. The problem, that all images where repeatedly showing in all section got solved too. In the level up for the subplots, I had to use the field unique for each subplot and not that for the plot, as I wrongly assumed. Having it set wrongly didn't influence the correct print of the plots and then their subplots, but had influence on the follwing photos. Pfuh, the logic behind, how the report "knows "what to print in lower levels is actually not really obvious, It seems to figure this out on its own. So, seems I get it working. Major flaws: There is only the possibility to select an existing field for a layer in report groups. So the data has to be prepared for each and every possible usage beforehand. Having the possibilty to use expressions here would be phantastic. So now, when you find out that you had not the right variables for your job in the data, you have to stop working on the report and fumble the stuff into the attributes. I worked around this problem by setting up a nice model to prepare my data, but not everyone has the knowledge to do so. Found no way to add sections within the "tree" or to move anything. Once you laid out a design and forgot a title page or mid-sections, you seem to have to restart from scratch. No way to manipulate it later. Found no way so far to add page numbers. All in all. Spent 2 days now on this 30 page report and I hope I will remember next time how to glue things together. This could be a really powerful tool for lazy people having to do boring reports frequently. So far, no time was gained, and I had to use extra doses of alcohol not to give up.;) Hopefully developers will give it a little more love some day to make it a bit smoother, then it will really rock! On 14.09.2020 18:20, Bernd Vogelgesang wrote: Hi there, I'm really eager to finally figure out how to create a photo documentation with QGIS. Everything needed is prepared and in place. I have overview coverages of plots with sub-plot over an aerial image. The maps are nicely produced to a report as groups. On each overview, the belonging sub-plots follow as individual maps. Now I would like to show pictures taken on the sub-plots. First issue: I add a new group photo-points and as field I select the referencing field for the sub-plot. Edit body, add picture frame. When setting the full file path for the images (stored as field "photo" in the point file, generated with "Import geotagged photos") there is only a red cross shown, and the selection in the dialog jumps from raster to svg. On export as pdf, there is a warning "Picture source is missing or corrupt". I redid this several times, to no avail, but once in a sudden, a preview image was shown, though I did not change the slightest thing in the settings. I swear! Second issue: Now that it finally accepted the path, exporting the report now produced a page for each picture under each sub-plot, instead of filtering those which actually fit there (and how it does with the sub-plots within the plots!) Has anyone an idea what might be wrong here. Documentation on this matter or examples are unfortunatly nonexistent. Linux Mint, 3.14.1 Cheers, Bernd ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe:
Re: [Qgis-user] Relation (1-N) Unpredictable Result (with default options)
Hi Jeffrey, Can you please open an issue on Github (https://github.com/qgis/QGIS/issues) and include your DDL SQL statements you used for these tests - including all pkey/fkey and other constraints you used and a simple QGIS project file demonstrating the issue. It is easier to discuss such issues on Github. Maybe it is related to the fact that Comboboxes aren't properly initialized with NULL values, for cases that don't allow NULL values. This is important to investigate - as it is unacceptable that corrupt data is collected. Thanks, Andreas On 2020-09-15 04:32, Jeffrey Durrence wrote: Today I was trying to set up an edit form for a spatial table with a related, non-spatial table. I have done this many times in the past, but it's been a while. After using Project Properties to set up my relation, I made several attempts to add a new record in the "child" table. Each time I tried, the new record did not get the correct value for the field which relates the two tables. Existing records were displayed as expected and could be edited, but I could not add new features. I went to the docs to see if something had changed that might be affecting me. I downloaded sample shapefile data and used that to demonstrate that related records could be created with that data. I set up a clean database and QGIS project file and made several attempts with my PostGIS data. I did observe that some new options were available to me under the widget area of the child table. What had me confused was that with the default options selected (the way I used to do it), the "reference field" values generated for the "new" child records were real values -- just not at all the correct values. I tried several things with the PostGIS data, but what finally fixed the behavior for me was to make one change in the default Widget settings for the "reference field" in the child table properties. In my case, enabling the option to "Use a read-only line edit instead of a combobox" resolved the issue. When that is enabled, new child records get the correct value for the reference field. I don't completely understand what determined the inserted values when this option was not enabled, but I would think that enabling this by default would save a lot of confusion for users like me. I was quite surprised that I could not find folks talking about this in the usual places. Could be that there is something local to my environment, but I thought it worth mentioning should someone else stumble upon it. Using QGIS LTS (3.10.5) on Ubuntu 20.4 and Windows 10 64-Bit with PostGIS backend (observed same behavior with Postgres 10.14 / PostGIS 2.4.4 and Postgres 12.4 / PostGIS 3.0.0) -- Jeffrey Durrence jeffrey.durre...@mcleanengineering.com McLean Engineering Company 815 South Main Street Moultrie, GA 31768 ___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user___ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
