QGIS » QGIS Application

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

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.

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.

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.

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.

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! :-)

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.

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.

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.

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.

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

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

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

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.

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)"

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

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

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!