OTFT on, layer's and project's CRS the same: measure tools and Identify Features return impossible measurments

[smizuno]

Occurs on Windows and Linux - don't know about Mac.

Project CRS set to epsg:32615 or 26915 (haven't tried others), measures in meters; PostGIS layer in same CRS. Ellipsoid for distance measurements is WGS84.

I created two squares, 1 meter and 100 meters on a side, and located at 500000, 5000000.

With OTF turned OFF Identify reports derived area of 1.000 m2, 10000.000 m2 respectively. These are the expected values. Using the Measure Area tool to measure the squares gives reasonable values (variation due to drawing accuracy).

Linux: With OTF turned ON Identify reports derived area of 5.740 ha, 1.046 ha respectively. These are incorrect, especially for the 1m square.

Windows: With OTF turned ON Identify reports derived area of 0.004 m2, 1.046 ha respectively. These are incorrect, especially for the 1m square.

With OTF turned ON, the area reported using the Measure Area tool drawing on the squares are similar, with the 1m showing wildly varying values - very small to quite large (several ha) depending on how the area was drawn. The area reported also varies with the location the squares are positioned at.

I have tested with actual dataset (a Minnesota county set) and find that the discrepancies are present but fairly small as the objects get larger.

Mandriva Linux x86_64: r9037, GEOS 3.0.0, PROJ 4.6.0 Windows XP: r9044, GEOS 3.0.0, PROJ 4.6.0

[smizuno]

On further investigation I find that line length is also incorrect with OTF on.

[msieczka]

Can you reproduce that with shapefiles? If so, please attach a sample Shapefile. Also please tell what target CRS should be defined when OTFR is enabled.

[smizuno]

shapefiles - lines and polygons

[smizuno]

Replying to msieczka:

Can you reproduce that with shapefiles? If so, please attach a sample Shapefile. Also please tell what target CRS should be defined when OTFR is enabled.

Shapefiles also show the problem. see attached file

The source files are in EPSG:26915 (UTM zone 15 NAD83)

1m_100m_lines.shp - 4 lines: 2 of 1M length, 1 at diagonal (1.414M length), 1 of 100M length

1m_100m_squares.shp - 2 squares: 1 of 1M on a side, 1 of 100M on a side

The test uses EPSG:26915 as the map CRS, so there should be no difference in the length, area measurements.

using Identify:

Without OTF the squares measure (in Derived item) 1.000 m2 and 10,000.000 m2 Without OTF the lines measure (in Derived item) 1.000 m, 1.414 m (the diagonal) and 100.000 m

With OTF enabled the squares measure 0.004 m2 and 1.046 ha Without OTF the lines measure 1.002 m, 1.417 m (the diagonal) and 100.208 m

Using the measure tools and trying to trace exactly the various shapes gets within a very small fraction of the expected values when OTF is off; there are significant differences with OTF on.

I have also tried GRS80 as the ellipsoid for distance calculations, no difference.

[msieczka]

Ahh, now I understand what's the problem. Summary for Folks if anybody was missing the point like I did:

1. Download the attached Shapefiles.

2. Load them in QGIS. They are in EPSG:26915 - set you project's CRS the same *and enable "On The Fly transformation"*.

3. You'll start getting weird, huge measurment results with OTFT enabled. Such as:

Area of the smaller square:

                    OTFT off    OTFT on

Identify Features   1 m2        104600 m2 (sic!)
Measure Area        1 m2        various weird values of 5 - 10 000 m2

Quite a bug.

[smizuno]

After a day away from all of this and more testing, I realized two things:

1. that Identify and the Measure Distance/Area tools are using plane calculations when OTFT is off. When OTFT is on they use calculations on an ellipsoid. (confirmed by looking in QgsDistanceArea) This is not indicated in the User Guide (0.9.1 release) which mentions only choosing an ellipsoid for measurements. I am aware that ellipsoid calculations may have gross errors on very small angles (and 1m is a really small angle) unless designed for such use.

2. when OTFT is enabled the ONLY valid measure for Identify and Measure tools is meters. I have tried this with UTM, long/lat, and a TMERC projection in feet. Measuring lines or polygons with any of these CRSs as the map canvas CRS would yield reasonable values only when the Measurement units is set to Meters.

In addition, the Scale bar is correct only when the Measurement units is set for units matching the map canvas CRS.

These make for a very confusing user interface.

I recommend that the Identify, Measure tools and the Scale bar should show measurements in either meters or feet (scaling as necessary) that are calculated on an ellipsoid, regardless of the CRS or OTFT. Note that Degree measurement are generally of little use. Also note, scale bar units in feet or meters don't have much meaning if the map canvas CRS is long/lat. Perhaps there could be a switch to use plane calculations, but this might complicate things too much.

I believe this would be much more useful to most users.

The User Guide should mention any limitations in measurements, such as may be present on very small distances or areas.

[homann]

The UI is confusing, no doubt about it.

When OTF proj is off, we don't use the CRS at all. All layer poits are unitless. So there is no way of telling if your square (0,0) - (10,10) is 100 square meter, 100 square feet or 100 square parsec. That's why the unit selection exists in the first place.

When OTF is on, we figure out the unit from the canvas projection. If a geocs such as WGS84, the unit is set to degrees, else if it is UTM it is set to meter.

An idea is to grey out the unit selection possibility when OTF proj is on, might make it less confusing.

It is not ideal, but we should figure out how to do it once and for all and write it down. The I can fix it. I'll leave this as an ehancement

[homann]

I changed the way it works a bit. The layer units are grayed out when OTFP is on, and there is a separate selector for displaying as feet or meter (only converts from meters and feet).

It's in r11340. I expect bug reports! :-)

[lutra]

Replying to homann:

I changed the way it works a bit. The layer units are grayed out when OTFP is on, and there is a separate selector for displaying as feet or meter (only converts from meters and feet).

It's in r11340. I expect bug reports! :-)

Hi, thanks for working on this matter, it is a much needed thing.

These are my observation.

*) load a layer with a projection in meters and enable OTFR. Scale bar is right, measure line tools is right for both meters and feet. Measure area tool is right for square meters but *wrong* for square feet (seems to not make the transformation from square meters).

*) load a layer with a projection in feet and enable OTFR. Scale bar is right, measure line tools is *wrong* for both meters and feet. Measure area tools is *wrong* for both meters and feet.

I would like to see the "display units" to change automatically (when OTFR is enabled), together with the scale bar units, accordingly to the projection selected in the project properties. Now it doesn't behave this way, and the measure tools are always in meters by default and the map scale is fixed to the project projection unit.

I am seeing that you just committed a code for fixing area measures. I'll give a try and then report back.

[lutra]

I updated to rev 11342 and it fixed the measure area tool in square feet when the projection is in meters.

Still issues, when the projection is in feet.

[homann]

OK, I haven't tested with projection in feet, so no surprise there. Can you describe what projection and what method you use to test, then I'l be able to debug it quickly.

The point with display units is that they are for the measurement only, and in what unit the user wants to see, and not the format the data is in. I personally think they SHOULDN'T change automatically.

The scale bar doesn't use the display units at all, it is only for measurement tool.

[lutra]

Hi

Replying to homann:

OK, I haven't tested with projection in feet, so no surprise there. Can you describe what projection and what method you use to test, then I'l be able to debug it quickly.

I used the (Alaska) qgis sample dataset. It is available on the site.

The point with display units is that they are for the measurement only, and in what unit the user wants to see, and not the format the data is in. I personally think they SHOULDN'T change automatically.

The scale bar doesn't use the display units at all, it is only for measurement tool.

Ok, for many (who uses projections in meters) would be not a big deal as they will have scale bars in meters and measure tools in meters by default. But who uses primarily projections in feet will have scale bars in feet and then measure tools in meters by default, so they will have to go to the options and change the unit manually.

[lutra]

Once this is fixed I guess we will have to discuss what to do with scale bars and measures tool when OTFR is disabled.

[homann]

What projections did you switch between to see the difference in meters and feet?

[homann]

Please provide detailed steps to reproduce the problem. I have tried without understanding what you do.

[lutra]

Hi,

sorry for the late answer. Do you mean that measuring tools works fine for you when using projections in feet? If so it could be a problem with the data I tested.

[lutra]

Replying to homann:

OK, I haven't tested with projection in feet, so no surprise there. Can you describe what projection and what method you use to test, then I'l be able to debug it quickly.

I just used the qgis sample dataset. From the qgis site: "The dataset is projected as Alaska Equal Area with unit feet (EPSG 2964)"

[homann]

How did you see that scale bar was right, and measurements were wrong?

[lutra]

Replying to homann:

How did you see that scale bar was right, and measurements were wrong?

Well,

the truth is that I'm not sure that the scale bar is totally right, but what you can read on the scale bar make sense with the underlying data, where the measure tool don't.

Where the scale bar reads (example for a certain segment) "568 miles", the measure tool reads "173 miles".

[homann]

Okay, try r11539. Worksforme now. Closing this bug, now it's just a matter of documenting what's going on.

[lutra]

Replying to homann:

Okay, try r11539. Worksforme now. Closing this bug, now it's just a matter of documenting what's going on.

works for me too.

Thanks!