Area is wrong in QGIS master (again) #17707
Comments
|
Author Name: Giovanni Manghi (@gioman) the slowness of the attribute table has been reported in another (blocking) issue.
|
|
Author Name: Matthias Kuhn (@m-kuhn) I just checked and could not reproduce (yet). OTF turned on: Can you add a project file to the zip? |
|
Author Name: Rhenriques Henriques (Rhenriques Henriques) See attached project and files. See the two PNG images included. One shows how the area is predicted in the calculation window (the value is right) and the other one shows how it appear in the table (wrong value - area_1). The column "area" as the expected value. This value comes from ArcGIS 10. Parallel to this there's another annoying issue - QGIS cannot remember the framed objects and zoom from the last session. We have to select a layer and do "zoom to layer extension" to frame the objects again.
|
|
Author Name: Rhenriques Henriques (Rhenriques Henriques) Problem finally solved in QGIS nightly build 55f8606! |
|
Author Name: Giovanni Manghi (@gioman)
|
|
Author Name: Rhenriques Henriques (Rhenriques Henriques) Sorry Giovanni, but the bug surfaced again in nightly build 30900e9!! It has exactly the same symptoms it had before. Strange... |
|
Author Name: Giovanni Manghi (@gioman) Rhenriques Henriques wrote:
maybe the issue was never fixed and it surfaces only in specific conditions?
|
|
Author Name: Alvaro Huarte (@ahuarte47) Hi, I have found that the change in the calculated value of the area is due to the configuration of the project. It has assigned an ellipsoid transformation for measure calculations. !MeasureCalcTransformed.jpg! I you change the 'ellipsoid' to 'none/planimetric', it give me ok. Or you can disable 'on the fly' CRS transformation in CRS panel.
|
|
Author Name: Rhenriques Henriques (Rhenriques Henriques) Hi Alvaro You are right! Maybe the none/planimetric option should be selected as "default" for every new project. |
|
Author Name: Alvaro Huarte (@ahuarte47) Hi Rhenriques, then this issue can be closed? |
|
Author Name: Rhenriques Henriques (Rhenriques Henriques) Hi Alvaro I suppose so. I've tested in several projects and values are always correctly calculated if 'none/planimetric' option is used, as expected. |
|
Author Name: Giovanni Manghi (@gioman) Alvaro Huarte wrote:
Hi Alvaro and Rui, Do older qgis releases computed the area right even with 'wgs84'? If yes then this must be fixed anyway, unless the old behavior/option was misleading. Please raise this issue in the dev mailing list.
|
|
Author Name: Nyall Dawson (@nyalldawson) There is a side-effect of setting the ellipsoid to "None/planimetric":
There's some relevant discussion in issue #16402. |
|
Author Name: Rhenriques Henriques (Rhenriques Henriques) Nyall is right! I've only tested in projects with projected units. The settings are not even stable. Sometimes things change (units; ellipsoid) each time we open the Project Settings dialog (NB). |
|
Author Name: Alvaro Huarte (@ahuarte47) Hi, I release a new pull request (#1071) it attempts to correct this error. Can you test it ? Alvaro
|
|
Author Name: Giovanni Manghi (@gioman) Rhenriques Henriques wrote:
but then the issue is now about the measure tool, and not the field calculator results? right? As it is now it seems that the area/length are computed correctly with or without otfr, right? Alvaro your patch fixes the measure tools problem and the inconsistency when setting project properties > canvas units? If yes this ticket should be closed and a new one open, or at least change title, category and description.
|
|
Author Name: Alvaro Huarte (@ahuarte47) Hi, this patch fix the ellipsoid and units selection in the project properties dialog. The current settings are preserved when the dialog is showed and fix a bug to select the related ellipsoid of the current CRS (https://github.com/qgis/QGIS/pull/1071/files#diff-b335df9eb7a06c67dc9347624b7c3b53L1027). I have not tested the measure tool, I guess it works fine for one so mature application ;-), but I tested the example of Rhenriques and It seems ok. Best regards |
|
Author Name: Giovanni Manghi (@gioman) Alvaro Huarte wrote:
Rui, can you confirm then that the original issue is solved? Thanks
|
|
Author Name: Giovanni Manghi (@gioman) This seems really fixed to me. Please reopen if necessary.
|
|
Author Name: Alvaro Huarte (@ahuarte47) Hi Giovanni, the pull request '#1071' has not yet been merged. Best Regards |
|
Author Name: Giovanni Manghi (@gioman) Alvaro Huarte wrote:
it seems to me that master is returning right values as it is now, but I would really appreciate if you can give a look. Also it would e important to have the feedback of the original reporter. |
|
Author Name: Alvaro Huarte (@ahuarte47) Giovanni Manghi wrote:
I think that 'ahuarte47@e0342dc' fixes as least a bug searching the ellipsoid related to one CRS |
|
Author Name: Rhenriques Henriques (Rhenriques Henriques) Just tested in NB, code revision "d26831b" and is not right yet. If the original shape CRS is used in the project definition, the area is right. As soon as we change the project CRS to WGS84, the area calculation gets wrong. Same as before unfortunately. |
|
Author Name: Paolo Cavallini (@pcav)
|
|
Author Name: Giovanni Manghi (@gioman) Rhenriques Henriques wrote:
Ok, so for what I can see now qgis master computes wrong the area of a polygon if this has (for example) a projected CRS and OTFR is ON and set to a geographic CRS (or a different projected CRS), unless in the project properties the ellipsoid is set to "none/planimetric". In the same conditions QGIS 1.8 computed the are always correctly (the ellipsoid was only configurable in the general options). Correct?
|
|
Author Name: Rhenriques Henriques (Rhenriques Henriques) Correct! |
|
Author Name: Bo Victor Thomsen (Bo Victor Thomsen) IMHO, the correct solution would be that both the measurement tools and the field calculation functions should obey the same global set-up value regarding the ellipsoid choice. And the default ellipsoid should be the one used in the project default CRS. The use of planimetric measurement is a leftover from the days where you had to use a planimeter (http://en.wikipedia.org/wiki/Planimeter) to calculate areas on a paper map. Would it be possible to the following choices ?: "Use ellipsoid from default project CRS" Although the main point is to have the different tools to report the same area/length measurements Regards |
|
Author Name: Martin Dobias (@wonder-sk) I am getting quite confused by the discussion as there have been various issues mentioned. Can you please clearly describe (with the help of attached QUAD project) in what case things get wrong and what is the expected outcome?
The only issue I can see right now is with OTF projections on, project CRS: wgs84, ellipsoid: none. As a bonus, with these settings above, after opening the project properties dialog, the measurement ellipsoid says WGS 84 which is wrong (planimetric is being used). Is this the problem or are there more cases to fix? |
|
Author Name: Martin Dobias (@wonder-sk)
|
|
Author Name: Giovanni Manghi (@gioman)
Hi Martin, I resume here what we discussed in private. Anyway it seems to me that if the issue of the completely wrong computed values is solved then the actual implementation make sense, and this introduce a different behavior since 1.8. In the future the approach used in the "add/export geometry columns" tool in the vector menu may be used. Giovanni: take as input a 10x10km square in a projected CRS Hi Martin, I resume here what we discussed privately. qgis 1.8: the ellipsoid for measurements option was defined in the qgis general now add your square, otfr off, compute area with field calculator -> 100sqkm otfr on, project CRS same as layer CRS, compute area with field otfr on, project CRS different from the layer CRS (geographic or qgis master: the ellipsoid for measurements option is defined in the project now add your square, otfr off, compute area with field calculator -> 100sqkm otfr on, project CRS same as layer CRS, compute area with field otfr on, project CRS different from the layer CRS (geographic or If the user changes the ellipsoid for measurements to "planar/none" Martin: This is expected - or at least for me... instead of measuring the area But maybe not what the users want? Giovanni: I agree, but this change was undocumented and probably unexpected by the feedback I have is that most users expect to have the area/length But I also agree that the actual behaviour of qgis make sense (for the maybe the approach that can be used (as option in the project/general Martin: This looks like a good option for the future - should be relatively clear. It seems that planimetric computation in layer's CRS is the usual |
|
Author Name: Giovanni Manghi (@gioman) Martin Dobias wrote:
Hi Martin, does your fix apply also to the field calculator? cheers! |
|
Author Name: Martin Dobias (@wonder-sk) No, it fixes only wrong value in identify tool. I am not aware of any issue in field calculator. |
|
Author Name: Alvaro Huarte (@ahuarte47) Hi Martin, there is an issue commented in #17707 (comment) that I think fixed in #1071 Cheers!!! |
|
Author Name: Martin Dobias (@wonder-sk)
|
|
Author Name: Giovanni Manghi (@gioman) Martin Dobias wrote:
I'm afraid also the FC is affected. |
|
Author Name: Rhenriques Henriques (Rhenriques Henriques) I'm paying attention to every single NB about this issue. Changes are not committed yet in the NB: f06457b. Changing flags in the project settings, about units and projection, are not honoured yet too. This happens under circumstances that are not easy to replicate sometimes, but mainly are related with turning on or off the OTFR. If we change to meters and planimetric, for instance, things change again the next time we open the project dialogue settings to default. |
|
Author Name: Alvaro Huarte (@ahuarte47) Hi Rhenriques, this pull (#1071) (not merged) attempts to correct that behavior that are not respected previous settings. Can you test it ? |
|
Author Name: Martin Dobias (@wonder-sk) I do not feel confident merging the proposed PR this close before the release as there are several non-trivial changes where I cannot foresee their impact. It needs more testing to see if various possible cases are covered. |
|
Author Name: Alvaro Huarte (@ahuarte47) Martin Dobias wrote:
ok, then there are two minor changes: |
|
Author Name: Martin Dobias (@wonder-sk) Merged the two commits from Alvaro (35791aa and c784c0) |
|
Author Name: Martin Dobias (@wonder-sk) The real issue with the project properties and setting of on-the-fly reprojection flag, CRS, map units, ellipsoid is that it is poorly designed and the user has no clue which settings are forced by QGIS and which of them are recommended with the possibility to override them. |
|
Author Name: Giovanni Manghi (@gioman) Martin Dobias wrote:
Hi Martin, I just tested master with a code revision prior of your last commit. This is what I see using the field calculator. The input is a 1x1km grid in a projected CRS (tested 3763)
the Field Calculator preview always show 1000000 Maybe 3) makes sense, but 2) does not seems to. |
|
Author Name: Rhenriques Henriques (Rhenriques Henriques) The behaviour that Giovanni described is exactly what I am obtaining too. As I told before, and as Giovanni wrote, the strange thing is that field calculator always show the correct value in the preview. Cheers |
|
Author Name: Martin Dobias (@wonder-sk) Giovanni Manghi wrote:
For 2) and 3), if you did not use "none / planimetric" ellipsoid for measuring, the result makes sense because the measurements are done on ellipsoid. Only with "none / planimetric" ellipsoid it will give you 1000000. I am not saying this logic is optimal, it is simply the behavior that someone has defined previously. Btw. interesting that you can see preview in field calculator - for me the preview for "$area" is always empty. |
|
Author Name: Giovanni Manghi (@gioman)
as discussed previously this is of course right, and makes sense for power users, but if wgs84 is the defaut ellispoid (as it is) this can be confusing for most of the users, especially because it is change since 1.8. I'm really not sure what would be the best option at this point.
:) |
|
Author Name: Martin Dobias (@wonder-sk) Giovanni Manghi wrote:
Me neither - but it does not make sense to do any radical changes right now. It is clear that for future versions we need to rethink how we will deal will measuring settings, map units and related things to clean the mess we have right now - a solution with sensible defaults and logic where one gets expected results all the time. |
|
Author Name: Paolo Cavallini (@pcav) I confirm, the $area preview shows the result |
|
Author Name: Martin Dobias (@wonder-sk) Another fix (d92a0e) - make sure to show preview of "$area" + make the preview consistent with field calculator results |
|
Author Name: Antonio Locandro (Antonio Locandro) Here are my thoughts on this The measure tool dialog for me for selecting Ellipsoid is superfluous in the General Tab, units should be selected directly on the Measure tool that way I can go from m to km to NM to ft if I wanted.
In this scenario if I have a layer in WGS UTM a) If project is set to use UTM then I will can measure in m, ft, etc Field calculator should work similar |
|
Author Name: Giovanni Manghi (@gioman) Antonio Locandro wrote:
Hi Antonio, please send your notes also the dev mailing list, we need to figure out a way to solve this issues. |
|
Author Name: Giovanni Manghi (@gioman) I'm closing this because as far as I can see now (in master) the area computations are right in both field calculator and identify tool ("derived") and when reprojection is ON the values are ok depending the ellipsoid set in project properties. The real issue seems this #18809 and, as said many times in this ticket, the whole logic that need to be reviewed, see Antonio's comment #17707 (comment) for example
|
qgib
added
Bug
Author Name: Rhenriques Henriques (Rhenriques Henriques)
Original Redmine Issue: 9060
Affected QGIS version: master
Redmine category:vectors
Qgis 2.1 DEV has a ressurgence of the "area calculation bug" with OTFR. For instance the NB e890e14 cannot calculate correctly the area. If we use "info" and check the geometry properties, the area is just right. We try to get it to a field, by using $area and results are awkward. The 0 ID geometry from the attached file should have 2520002 m2 and is giving 2523339 m2. This bug is not corrected. Use attached .shp to check.
Another thing is that, while opening an attribute table with several thousands of objects (about 400 000 points in my case), QGIS is extremely slow and some tables do not load beyond a few 1000 or 2000 objects. This is getting worse each NB. In QGIS 2.0.1 the table open is super fast.
Cheers
Related issue(s): #18809 (relates)
Redmine related issue(s): 10392
The text was updated successfully, but these errors were encountered: