Feature #1219

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

Added by Steven Mizuno over 5 years ago. Updated over 4 years ago.

Status:Closed Start Date:
Priority:Low Due date:
Assigned to:Magnus Homann % Done:

0%

Category:Projection Support
Target version:Version 1.2.0
Platform:All Resolution:fixed
Platform version: Patch supplied:
Status info:0 Tag:

Description

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

test_files.zip - shapefiles - lines and polygons (1.9 kB) Steven Mizuno, 09/01/2008 07:23 am

Associated revisions

Revision c0a247e7c4c7dc5abbfd126a8c5f72b3db8df02b
Added by Magnus Homann over 4 years ago

A stab at improving the measurement system. Added a new selector in Options for converting the result, and grayed out the layer units when OTFP is on. Should fix #1219, I hope.

git-svn-id: http://svn.osgeo.org/qgis/trunk@11340 c8812cc2-4d05-0410-92ff-de0c093fc19c

Revision 3c6a232ec711e8be1e048350fc8e66371265f191
Added by Magnus Homann over 4 years ago

A stab at improving the measurement system. Added a new selector in Options for converting the result, and grayed out the layer units when OTFP is on. Should fix #1219, I hope.

git-svn-id: http://svn.osgeo.org/qgis/trunk/qgis@11340 c8812cc2-4d05-0410-92ff-de0c093fc19c

History

Updated by Steven Mizuno over 5 years ago

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

Updated by Maciej Sieczka - over 5 years ago

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.

Updated by Steven Mizuno over 5 years ago

Replying to [comment:2 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.

Updated by Maciej Sieczka - over 5 years ago

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.

Updated by Steven Mizuno over 5 years ago

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.

Updated by Magnus Homann over 5 years ago

  • Status changed from Open to In Progress

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

Updated by Magnus Homann over 4 years ago

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 c0a247e7 (SVN r11341). I expect bug reports! :-)

Updated by Giovanni Manghi over 4 years ago

Replying to [comment:9 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 c0a247e7 (SVN r11341). 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.

Updated by Giovanni Manghi over 4 years ago

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.

Updated by Magnus Homann over 4 years ago

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.

Updated by Giovanni Manghi over 4 years ago

Hi

Replying to [comment:12 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.

Updated by Giovanni Manghi over 4 years ago

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

Updated by Magnus Homann over 4 years ago

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

Updated by Magnus Homann over 4 years ago

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

Updated by Giovanni Manghi over 4 years ago

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.

Updated by Giovanni Manghi over 4 years ago

Replying to [comment:12 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)"

Updated by Magnus Homann over 4 years ago

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

Updated by Giovanni Manghi over 4 years ago

Replying to [comment:19 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".

Updated by Magnus Homann over 4 years ago

  • Status changed from In Progress to Closed
  • Resolution set to fixed

Okay, try 6bea923d (SVN r11540). Worksforme now. Closing this bug, now it's just a matter of documenting what's going on.

Updated by Giovanni Manghi over 4 years ago

Replying to [comment:21 homann]:

Okay, try 6bea923d (SVN r11540). Worksforme now. Closing this bug, now it's just a matter of documenting what's going on.

works for me too.

Thanks!

Also available in: Atom PDF