QGIS » QGIS Application

Note: This also affects Scalebar in Print Composer.

I agree, another option would be to have in the measurement tool the possibility to select units like in other softwares. I feel a few more units would be good to be added such as miles and Nautical Miles which I use in aviation. With this option the map units could be in meters for example but I could measure in NM, miles, feet or whatever unit is available. This gives a little more flexibility

This is quite confusing -

I think this is caused by QGIS defaulting to "None / planimetric" for the ellipsoid for new projects. In 1.8 QGIS defaulted to WGS84. The correct behaviour should be to restore this as the default setting.

However -- I'm having lots of trouble understanding how this is supposed to work. The option to choose a canvas unit for the project is under the "Canvas units (CRS transformation: OFF)" group. If you hover over an option the tooltip states "Used when CRS transformation is turned off". I'm pretty sure this tooltip is wrong -- since the choice DOES apply even if CRS transformation is turned on. HOWEVER, the choice is reset when the project properties window is opened UNLESS CRS transformation is off.... very confusing!!

To add to the confusion there's 2 "WGS84" ellipsoids listed - one is "WGS84" and one is "WGS 84". Choosing "WGS84" actually results in "Clarke 1986" being saved for the project!

My gut feeling is that:
- Ellipsoid should default to "WGS 84"
- "WGS84" needs to be removed
- The tooltip for canvas units needs to be fixed/reworded
- The choice of canvas unit should save even if CRS transformation is enabled

I'd like a second opinion on this though, since there may have been discussion around this behaviour which I'm not aware of.

Hi Nyall,

I don't have the time to do so, but a review of my vertical tab GUI update to the Project Properties dialog may be in order: commit 5b7c895 ("on gituhub":commit:5b7c895)

I found the measurement settings confusing as well and tried to bring more clarity to the situation (e.g. added the "(CRS transformation: OFF/ON)" notices). Before, reading the tool tip and bouncing back-forth to the OTF tab was required to understand the temporal state of the setting.

It may be I introduced a bug with my updates; but, when working on it, I noticed some issues that I thought were not related to the GUI, but did not investigate further, because I saw this issue (commit and issue were created on the same day).

Why is this closed?

Bug fixed thanks to fundings from Agence de l'Eau Adour-Garonne.

I opened the project, an it appears that you did not enable 'on the fly' CRS transformations in your project properties.

You really need that to do the degree->meter conversion, therefore qgis continues to give degrees instead of the chosen meters.

Note: I guess it would be useful to disallow the selection of meter/feet in the measure tool options if the projection is not enabled, maybe with a comment "enable on the fly CRS in project properties" to change measurement units. It was not the object of this bug (the OTF projection was on). Is it necessary to do that for closing ?

The same project opened in 1.8 (Same setting as in 2.0: No "default OTF reprojection" in Settings=>Options) measures in meters.
Was there something wrong with the old approach?

Graying out will probably not be easy because they are an application setting and OTF reprojection can be a project setting, so they are on different levels.

Nyall Dawson wrote:

- Ellipsoid should default to "WGS 84"
- "WGS84" needs to be removed

Removing WGS84 doesn't seem to be a good idea, it refers to the acronym IGNF:ELG053 and the parameters are ok (in srs.db). The fact that its saved as "Clarke 1986" may be another issue, this one seems confused enough as it is.

If the Ellipsoid defaults to anything but None/Planimetric, why is the choice only possible with OTF projection is checked ?

To me a reasonable fix would be to enable OTF CRS transfo by default for new projects.

To me a reasonable fix would be to enable OTF CRS transfo by default for new projects.

The user can set this in the general options -> crs, but in general I would say that many users would still like to work in whatever CRS, no OTF enabled and measure in meters/feet/degrees. I think that this was possible in 1.8, but I can't remember now.

The tool tip over the Ellipsoid dropdown list in Project Options -> General says 'Can only use ellipsoidal calculations when CRS transformation is enabled'. That makes the design intend pretty clear: no OTF, no ellipsoid, no meters/feet in measure tool.

So this is more a change in design than a bug fix here.

It seems easy enough to allow ellipsoid choice without OTF transfo, and to change the default, the question here is: does it break the design ?

From a user perspective it just seems odd. And I would see it as a bug fix because in 1.8 it used to work the expected way and I haven't seen any explanation for a design change so far.

IF there are good architectural reasons (a tooltip is obviously not to be treated as such) at least there needs to be an indication of why it is not working as expected and where to change what in order to get it working as expected.

Agreed with Matthias: if the user chooses meters, this unit should be used anyway

There was a discussion started on qgs-dev list Sep 6 2012 by Magnus Homann. You can have a look there https://groups.google.com/forum/#!topic/qgis-developer-remote/ULACvru_LFQ (groups.google because in the ML archive the thread is difficult to follow).

From what I understand, the measure tool has always been using CRS OTF transfo code, even if it wasn't activated.

Now the measuring tool does only use it when CRS OTF transfo is enabled.

With the provided patch, the only thing you have to do is enable the CRS OTF transfo and the ellipsoid for the measurement tool should be fine.

So to solve this I propose:
- either to enable CRS OTF transfo by default (quick, small change to the code),
- or to move the ellipsoid choice to the measure tools options, and to use the CRS transfo code there with the chosen ellipsoid defaulted to "WGS 84" as it used to be (long, possibly a lot of changes).

With the risk that this is going to be judged a stupid question: What is the reason for turning off OTF transformation?

Matthias Kuhn wrote:

With the risk that this is going to be judged a stupid question: What is the reason for turning off OTF transformation?

From a user point of view? I would say that if I work with a big projects and all layers are in the same CRS and enabling OTF does not add any rendering overhead, then it is ok to have always OTF on.

From a user point of view? I would say that if I work with a big projects and all layers are in the same CRS and enabling OTF does not add any rendering overhead, then it is ok to have always OTF on.

Well... I forgot to mention that from a user point of view there are also good reasons to want OTF off, even with layers in different CRS, for example it is handy to understand what can be the CRS of a layer, ie when a .prj file is missing in a shape or o tiff + world file, and no metadata is provided.

Hi,
agreed with Giovanni, OTF off is really needed.

Testing joined project, I found an odd behaviour:
1 open the project, OTF = OFF, measure in degrees : OK
2 set OTF = true > measure come in meters : OK
3 set OTF = true and crs = 2154 > measure in meter ok
4 set OTF = false. CRS gets back to WGS84 automatically. But measure give meter response, and false measures (I get millimeters where I had meters and kilometers before..)

Any idea?

The PR (20 days ago) has not been accepted nor rejected, is someone taking care of it ?

From the explanations above, there seem to be valid reasons to turn off OTF, but it should only be disabled for special use-cases.

Vincent, would it be easy to add a message to the measurement dialog, in case OTF is turned off, so somebody who accidentally turned it off gets an idea about the unexpected behavior?

I hope it's okay to introduce this string addition still.

(OTF on/off) has been added to the title of the measurement dialog in PR778.

Hi Vincent,
I tested PR778, but I can still reproduce the behavior Régis described.

1. Open attached project(mapunits.zip)
2. Turn on OTF and change CRS to 2145, OK => Map canvas turns white
3. Turn off OTF and zoom to layer extent, OK
4. Mesure: In meters and city is just a couple of CMs in diameter

I can reproduce.

Apparently, when switching to 2154 (Regis initial choice), the canvas units (in project->prop->general) switch to meter.

Can you confirm that selecting the degree radio button after step 3. solves the problem ?

Yes, that fixes it.
Does it make sense to leave the option "meters" allowed in a case like this?

I've been testing/using version 1.9 and wanted to provide some additional results for this 
bug in regards to the derived values that are displayed when using the Identify Features 
button. My concern is not what is being displayed depending on the settings as that 
discussion is already under way, but the unit of measures that are being displayed with the 
results. It seems there are mismatches occuring between values and labels where degrees are 
being displayed where kms or meters should be displayed, or the wrong values are showing 
based on the unit of measure.

Using the following build of QGIS on Kubuntu 12.04: 1.9.0+git20130828+fa135f0~precise-ubuntugis1
I created a simple 100 sq.km polygon using the following XYs referenced to CRS 32612

id,x,y
1,505000,6010000
1,505000,6000000
1,495000,6000000
1,495000,6010000
1,505000,6010000

Once I had this polygon created referenced to CRS 32612, I saved it referenced to CRS 4326 as well.
The results below are the derived values as displayed in the Identify Results.
The layer refers to the CRS code of the polygon.

Start QGIS 
OTF is on.
Canvas CRS set to 4326.
Measure Tool Ellipsoid set to WGS 84
Canvas Units set to Degree
Load layers.

Layer    Area        Perimeter
32612    99.657 sq.km    0.485 m
4326    99.657 sq.km    40.016 km

Change Canvas Units to Meters

Layer    Area        Perimeter
32612    99.657 sq.km    0.485 m
4326    99.657 sq.km    40.016 km

Change Canvas CRS to 32612

Layer    Area        Perimeter
32612    99.657 sq.km    0.485 m
4326    99.657 sq.km    40.016 km

Change Measure Tool Ellipsoid to None/Planimetric

Layer    Area        Perimeter
32612    100.000 sq.km    40.000 km
4326    0.014 sq.m    0.486 m

Change Canvas CRS to 4326
Measure Tool Ellipsoid set to None/Planimetric
Canvas Units set to Degree

Layer    Area            Perimeter
32612    100,000,000.000 sq.deg    40,000.000 degrees
4326    0.014 sq.deg        0.486 degrees

Matthias: I'm not sure about the utility of this canvas unit selection. My best guess is that it allows the user to override/specify units when not readilly available in the data source. If it's the case, overriding with something wrong will lead to wrong results.

Neil:

Thanks a lot for the test, I see a couple of "normal" things happening:

- The canvas units are used when the Ellipsoid is set to none/plaeimetric (the tooltip seems to be wrong there). So the two first should be equal, and they are.
- "Canvas CRS" is the CRS to project to with OTF, so changing it should not change the measurements, just the coordinates displayed at the bottom of the window. Thus, it's normal that nothing changes in the third case (apart from displayed coord).
- In the two last case (Ellipsoid=noe/paneimetric), you override the CRS units and tell qgis "the units are that!". So there again, no surprise: qgis does the math and gives you what you asked for (interpreting degrees as meters in one case, meters as degrees in the second).

I only see one oddity (bug) there: it's the perimeter value of 0.485m in the 3 first cases for layer 32612. Could you please post your test cases (.shp) here so I can reproduce and fix that ?

@Vincent,

Sorry, I'm a bit confused. I was under the impression, that your pull request fixes the behavior Régis observed, but this behavior was still taking place in my experiments with your pull request, as explained in comment #7441-31.

I hope you can help me to understand.

Is it possible to fix this behavior (#7441-31)?
What exactly is PR 778 fixing?

Matthias: can you my PR and try switching to 2154 instead of 2145?

That was unintended, indeed. I just tried with 2154, but it still gives me a city diameter of 2.5 cm, when switching back to turned-off OTF and I need to adjust the units manually.

Tim is going to branch for release today, any chance to have at least a temporary solution committed?

On it, doing my best to have something in early afternoon.

Matthias, I updated the PR 778 and it fixes both what Regis observed and what you observed. Can you plz try it and confirm ?

I'm working on the issue of the perimeter value, but this is another one, and maybe should be filed as a different ticket, I let you juge of that.

Thank you very much for this fix, Vincent

Bug fixed thanks to fundings from Agence de l'Eau Adour-Garonne.

I am unable to change the canvas unit from degrees to metres in the project properties (qgis2.2).
CRS Transformation is On.

I select metres, clicks apply and ok, and when I check the properties again, its gone back to degrees. Is this a bug?