Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Area is wrong in QGIS master (again) #17707

Closed
qgib opened this issue Nov 13, 2013 · 54 comments

Comments

@qgib
Copy link
Contributor

commented Nov 13, 2013

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


@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Nov 13, 2013

Author Name: Giovanni Manghi (@gioman)


the slowness of the attribute table has been reported in another (blocking) issue.


  • subject was changed from Table issues to Area is wrong in QGIS master (again)
  • category_id removed Browser
  • version was changed from 2.0.1 to master
@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Nov 15, 2013

Author Name: Matthias Kuhn (@m-kuhn)


I just checked and could not reproduce (yet).

OTF turned on:
With project CRS set to 4326 I get 2523339 in the identify dialog and the field calculator (opened from the attribute table)
With project CRS set to 20790 I get 2520002 in the identify dialog and the field calculator (opened from the attribute table)

Can you add a project file to the zip?

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Nov 15, 2013

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.
Cheers


  • 6471 was configured as QUAD.zip

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Nov 26, 2013

Author Name: Rhenriques Henriques (Rhenriques Henriques)


Problem finally solved in QGIS nightly build 55f8606!
Cheers

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Nov 26, 2013

Author Name: Giovanni Manghi (@gioman)


  • resolution was changed from to fixed/implemented
  • status_id was changed from Open to Closed
@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Nov 27, 2013

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...
Cheers

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Nov 28, 2013

Author Name: Giovanni Manghi (@gioman)


Rhenriques Henriques wrote:

Sorry Giovanni, but the bug surfaced again in NB 30900e9!! It has exactly the same symptoms it had before. Strange...
Cheers

maybe the issue was never fixed and it surfaces only in specific conditions?


  • resolution was changed from fixed/implemented to
  • status_id was changed from Closed to Feedback
@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Dec 27, 2013

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.
Best Regards


  • 6603 was configured as MeasureCalcTransformed.jpg

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Dec 27, 2013

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.
Cheers

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Dec 28, 2013

Author Name: Alvaro Huarte (@ahuarte47)


Hi Rhenriques, then this issue can be closed?
Best regards

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Dec 28, 2013

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.
Please ensure that this option is set as default in the next versions. No one wants miscalculated areas or any other wrong measurements in their tables!
Cheers and thank you.

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Dec 29, 2013

Author Name: Giovanni Manghi (@gioman)


Alvaro Huarte wrote:

Hi Rhenriques, then this issue can be closed?
Best regards

Hi Alvaro and Rui,
what are the (other) consequences of eventyally making 'none/planimetric' default?

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.


  • status_id was changed from Feedback to Open
@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Dec 29, 2013

Author Name: Nyall Dawson (@nyalldawson)


There is a side-effect of setting the ellipsoid to "None/planimetric":

  • Set the otf projection to a non-projected crs, eg wgs84 (epsg:4326)
  • In the general tab set the canvas units to "meters"
  • Try to measure a distance on the map - the distance is shown in degrees, not metres

There's some relevant discussion in issue #16402.

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Dec 29, 2013

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).
This issue must be changed to blocker due to the major implications it represents. You can have the best GIS software but if it's unable to calculate correctly, in a stable basis, a distance or an area, it becomes useless in real world projects. Strange because it all seem much more stable in 1.8. Another strange thing is that the 'preview value' of the 'field calculator' is mostly right. How is this possible?
Cheers

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Jan 17, 2014

Author Name: Alvaro Huarte (@ahuarte47)


Hi, I release a new pull request (#1071) it attempts to correct this error.

Can you test it ?
Thank you very much

Alvaro


  • pull_request_patch_supplied was changed from 0 to 1
@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Jan 26, 2014

Author Name: Giovanni Manghi (@gioman)


Rhenriques Henriques wrote:

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).
This issue must be changed to blocker due to the major implications it represents. You can have the best GIS software but if it's unable to calculate correctly, in a stable basis, a distance or an area, it becomes useless in real world projects. Strange because it all seem much more stable in 1.8. Another strange thing is that the 'preview value' of the 'field calculator' is mostly right. How is this possible?
Cheers

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.


  • status_id was changed from Open to Feedback
@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Jan 26, 2014

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

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Jan 27, 2014

Author Name: Giovanni Manghi (@gioman)


Alvaro Huarte wrote:

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

Rui, can you confirm then that the original issue is solved? Thanks


  • category_id was configured as Vectors
@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 8, 2014

Author Name: Giovanni Manghi (@gioman)


This seems really fixed to me. Please reopen if necessary.


  • resolution was changed from to fixed/implemented
  • status_id was changed from Feedback to Closed
@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 8, 2014

Author Name: Alvaro Huarte (@ahuarte47)


Hi Giovanni, the pull request '#1071' has not yet been merged.
Do you think that it is not necessary to fix this issue ?

Best Regards
Alvaro

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 8, 2014

Author Name: Giovanni Manghi (@gioman)


Alvaro Huarte wrote:

Hi Giovanni, the pull request '#1071' has not yet been merged.
Do you think that it is not necessary to fix this issue ?

Best Regards
Alvaro

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.

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 8, 2014

Author Name: Alvaro Huarte (@ahuarte47)


Giovanni Manghi wrote:

Alvaro Huarte wrote:

Hi Giovanni, the pull request '#1071' has not yet been merged.
Do you think that it is not necessary to fix this issue ?

Best Regards
Alvaro

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.

I think that 'ahuarte47@e0342dc' fixes as least a bug searching the ellipsoid related to one CRS

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 8, 2014

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.
Cheers

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 8, 2014

Author Name: Paolo Cavallini (@pcav)


  • status_id was changed from Closed to Feedback
@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 16, 2014

Author Name: Giovanni Manghi (@gioman)


Rhenriques Henriques wrote:

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.
Cheers

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?


  • fixed_version_id was changed from Future Release - High Priority to Version 2.2
  • resolution was changed from fixed/implemented to
  • status_id was changed from Feedback to Open
@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 16, 2014

Author Name: Rhenriques Henriques (Rhenriques Henriques)


Correct!

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 18, 2014

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"
"Use specific ellipsoid" (together with a "ellipsoid chooser" dialogue)
"Use planimetric calculations"

Although the main point is to have the different tools to report the same area/length measurements

Regards
Bo Victor Thomsen
Aestas-GIS
Denmark

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 18, 2014

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?

  • on-the-fly projections on/off
  • project CRS
  • project measurement ellipsoid
  • tool used (measure tool / identify tool / field calculator / all)
  • anything else that affects calculation?

The only issue I can see right now is with OTF projections on, project CRS: wgs84, ellipsoid: none.
The identify tool says the area is 31 227 946 258,332 km² which is completely off.

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?

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 19, 2014

Author Name: Martin Dobias (@wonder-sk)


  • status_id was changed from Open to Feedback
@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 19, 2014

Author Name: Giovanni Manghi (@gioman)


Is this the problem or are there more cases to fix?

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
options, wgs84 by default

now add your square, otfr off, compute area with field calculator -> 100sqkm

otfr on, project CRS same as layer CRS, compute area with field
calculator -> 100sqkm

otfr on, project CRS different from the layer CRS (geographic or
projected does not matter), compute area with field calculator ->
100sqkm

qgis master:

the ellipsoid for measurements option is defined in the project
options, wgs84 by default

now add your square, otfr off, compute area with field calculator -> 100sqkm

otfr on, project CRS same as layer CRS, compute area with field
calculator -> 100sqkm

otfr on, project CRS different from the layer CRS (geographic or
projected does not matter), compute area with field calculator ->
NOT 100sqkm... but a close value (as expected?). Problem is that
sometimes the result is a completely wrong value (not even close).

If the user changes the ellipsoid for measurements to "planar/none"
that the results are equals to the ones in qgis 1.8


Martin:

This is expected - or at least for me... instead of measuring the area
in layer's coordinate system, it will reproject it to lat/lon coords
on ellipsoid and calculate the area on ellipsoid - a relatively small
difference is understandable.

But maybe not what the users want?


Giovanni:

I agree, but this change was undocumented and probably unexpected by
many users, so
is leading to confusions.

the feedback I have is that most users expect to have the area/length
of layers in a projected CRS to be always
computed in the layers CRS.

But I also agree that the actual behaviour of qgis make sense (for the
more experienced user), so the above could
eventually be added as an option in general or project properties.

maybe the approach that can be used (as option in the project/general
options) is the one already available in the
"add/export geometry columns" tool in the vector menu.


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
assumption. Then there are people with unprojected data (e.g. from
GPS) trying to measure something, for them it makes more sense to have
area computed on ellipsoid rather than area in squared degrees :-)
.... all the other cases are probably "advanced" and the user should
have a choice to decide how to do the measuring.

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 19, 2014

Author Name: Giovanni Manghi (@gioman)


Martin Dobias wrote:

In case of any further issues please open a new bug as all the comments in this issue make it hard to follow.

Hi Martin, does your fix apply also to the field calculator?

cheers!

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 19, 2014

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.

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 19, 2014

Author Name: Alvaro Huarte (@ahuarte47)


Hi Martin, there is an issue commented in #17707 (comment) that I think fixed in #1071

Cheers!!!

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 19, 2014

Author Name: Martin Dobias (@wonder-sk)


  • status_id was changed from Closed to Reopened
@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 19, 2014

Author Name: Giovanni Manghi (@gioman)


Martin Dobias wrote:

No, it fixes only wrong value in identify tool. I am not aware of any issue in field calculator.

I'm afraid also the FC is affected.

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 19, 2014

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.
While using the 2.01 version, in projects with a high degree of responsibility, I use a shape with a perfect 1 sq km that I copy to every polygon shape, to ensure that I got the areas right in the field calculator. Very annoying...
Cheers

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 19, 2014

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 ?

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 20, 2014

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.

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 20, 2014

Author Name: Alvaro Huarte (@ahuarte47)


Martin Dobias wrote:

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.

ok, then there are two minor changes:

ahuarte47@4b352c3
#1054

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 20, 2014

Author Name: Martin Dobias (@wonder-sk)


Merged the two commits from Alvaro (35791aa and c784c0)

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 20, 2014

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.

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 20, 2014

Author Name: Giovanni Manghi (@gioman)


Martin Dobias wrote:

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.

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)

  1. otfr off area = 1000000
  2. otfr on, project CRS same as layer area = 1002464.5100 - 1002535.8531
  3. otfr on, project CRS different from layer CRS (projected or geographic) area = 1002464.5100 - 1002535.8531

the Field Calculator preview always show 1000000

Maybe 3) makes sense, but 2) does not seems to.

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 20, 2014

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

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 20, 2014

Author Name: Martin Dobias (@wonder-sk)


Giovanni Manghi wrote:

The input is a 1x1km grid in a projected CRS (tested 3763)

  1. otfr off area = 1000000
  2. otfr on, project CRS same as layer area = 1002464.5100 - 1002535.8531
  3. otfr on, project CRS different from layer CRS (projected or geographic) area = 1002464.5100 - 1002535.8531

the Field Calculator preview always show 1000000

Maybe 3) makes sense, but 2) does not seems to.

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.

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 20, 2014

Author Name: Giovanni Manghi (@gioman)


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.

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.

Btw. interesting that you can see preview in field calculator - for me the preview for "$area" is always empty.

:)

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 20, 2014

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.

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.

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.

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 20, 2014

Author Name: Paolo Cavallini (@pcav)


I confirm, the $area preview shows the result

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Feb 20, 2014

Author Name: Martin Dobias (@wonder-sk)


Another fix (d92a0e) - make sure to show preview of "$area" + make the preview consistent with field calculator results

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented May 29, 2014

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.

  • If project uses a Projected coordinate system then the measure tool should give me the measurements using that PCS by default in the units I have previously selected, only meters, ft and NM should be shown as options (BTW miles should be added as its used in the USA) no degrees options here as it doesn't make sense

  • If the project is set to using a Geographic coordinate system then measurements should be used by selecting the ellipsoid from the definition, if OTF is off then only degrees should be shown as option if OTF is on only m,ft, NM should be shown. It makes absolutely no sense to have the QGIS project use Airy 1830 for measure calculations if WGS 84 is used for the project

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
b) If project is in WGS then I can get geodetic distance in m, ft, etc

Field calculator should work similar

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented May 30, 2014

Author Name: Giovanni Manghi (@gioman)


Antonio Locandro wrote:

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.

  • If project uses a Projected coordinate system then the measure tool should give me the measurements using that PCS by default in the units I have previously selected, only meters, ft and NM should be shown as options (BTW miles should be added as its used in the USA) no degrees options here as it doesn't make sense

  • If the project is set to using a Geographic coordinate system then measurements should be used by selecting the ellipsoid from the definition, if OTF is off then only degrees should be shown as option if OTF is on only m,ft, NM should be shown. It makes absolutely no sense to have the QGIS project use Airy 1830 for measure calculations if WGS 84 is used for the project

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
b) If project is in WGS then I can get geodetic distance in m, ft, etc

Field calculator should work similar

Hi Antonio, please send your notes also the dev mailing list, we need to figure out a way to solve this issues.

@qgib

This comment has been minimized.

Copy link
Contributor Author

commented Jun 12, 2014

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


  • resolution was changed from to fixed/implemented
  • status_id was changed from Reopened to Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.