QGIS » QGIS Application

Distnces in latlong projections do not have much sense.

Replying to [comment:1 pcav]:

Distnces in latlong projections do not have much sense.

Distances in latlon is only a part of the report. Please read carefully.

Even if the display is wrong, data are not corrupted, and no crash happens AFAIK

For an example polygon from http://www.countyofsb.org/itd/gis/default.aspx?id=2802:

degrees: 14,848,044.089 sq.deg.
feet:    0.533 sq mile
meters:  14.848 km2

The feet and meters results are not coherent, because 1 sq mile is actually about 2.59 km2 AFAIK. And the degree result is a complete nonsense.

This IS data corruption. QGIS returns bogus values.

These are my latest observations on this annoying bug. Maybe a few of the following situations doesn't make sense at all (in these cases a warning should be issued?), maybe others are puzzling.

a) project in wgs 84, layer with a geographic system, OTFR disabled¶

*) Map Units in Degrees: map scale seems right. Measure Line and Measure Area Tools seems to return right values.

*) Map Units in Meters or Feet: map scale is wrong, as it seems to just exchange the value in degrees with the value in meters/degrees (ex: 30 degrees -> 30 meters). Measure Line and Measure Area Tools return wrong values.

b) project in wgs 84, layer with a geographic projection, OTFR enabled¶

*) Map Units in Degrees: map scale seems right. Measure Line and Measure Area Tools return wrong values (several times too big).

*) Map Units in Meters: map scale is wrong. Measure Line and Measure Area Tools seems to return right values.

*) Map Units in Feet: map scale is wrong. Measure Line and Measure Area Tools seems return wrong values (a few times less than supposed).

c) project in wgs 84, layer with a projected system, OTFR disabled¶

QGIS notice you that as the project is a G.C.S. and the layer is in a P.C.S., Measure Line and Measure Area Tools will return wrong values.

*) Map Units in Degrees: map scale is wrong. Measure Line and Measure Area Tools return wrong values (several times too big).

*) Map Units in Meters: map scale seems right. Measure Line and Measure Area Tools seems to return right values, at least they are consistent with the values returned by other tools, for example Google Earth.

*) Map Units in Feet: map scale is wrong. Measure Line and Measure Area Tools seems return wrong values (a few times less than supposed).

d) project in wgs 84, layer with a projected system, OTFR enabled¶

*) Map Units in Degrees: map scale is wrong. Measure Line and Measure Area Tools return wrong values (several times too big).

*) Map Units in Meters: map scale is wrong. Measure Line and Measure Area Tools seems to return right values.

*) Map Units in Feet: map scale is wrong. Measure Line and Measure Area Tools seems return wrong values (a few times less than supposed).

This is an important issue. Many users think the unit selector allows some kind of reprojection in the fly and feel confused.

Shouldn't we tie the units to the current CRS and take the selector away? Actually it's partially implemented: if I set the project CRS to any metric one and OTFR is enabled, the units are switched to meters automagically. But if OTFR is disabled, selecting a metric CRS doesn't switch the units. This is a bit inconsequent.

Replying to [comment:6 borysiasty]:

This is an important issue. Many users think the unit selector allows some kind of reprojection in the fly and feel confused.

I agree, this is an important issue, and once a clear plan of action in set in place, likely won't take long to fix...

Shouldn't we tie the units to the current CRS and take the selector away? Actually it's partially implemented: if I set the project CRS to any metric one and OTFR is enabled, the units are switched to meters automagically. But if OTFR is disabled, selecting a metric CRS doesn't switch the units.

I don't agree here: I don't think the user should be tied down to the units of their input layer(s). If they want to calculate distance in metres or feet, then they should be able to calculate distance in metres or feet, regardless of the projection. This means that when a geographic CRS is used, distance/area calculations need to reflect this, and return the correct results (e.g. great circle distance).

As far as I can tell, when using QgsMeasureTool, the QgsDistanceArea never has an ellipsoid set... is this correct?

Replying to [comment:7 cfarmer]:

I agree, this is an important issue, and once a clear plan of action in set in place, likely won't take long to fix...

Well, this seems really a good news for both devs and users.

Replying to [comment:7 cfarmer]:

Replying to [comment:6 borysiasty]:

This is an important issue. Many users think the unit selector allows some kind of reprojection in the fly and feel confused.

I agree, this is an important issue, and once a clear plan of action in set in place, likely won't take long to fix...

I hope so too. I think we should introduce also "unknown" units: by default when we don't know layer's CRS or when the OTF projections are turned off.

That also lead me to another idea: does it make sense not to project layers which are in different systems? I know it takes some additional rendering cost, but having OTF projections turned always on would solve several problems at once.

As far as I can tell, when using QgsMeasureTool, the QgsDistanceArea never has an ellipsoid set... is this correct?

The logic for measuring is not really good. IIRC currently when the OTF projection is turned on it calculates distance/area on a plane, with projections turned on it does the calculations on ellipsoid.

Replying to [comment:10 homann]:

I don't know how many bugs I have seen submitted on this issue.

about projections, scale and measures? many. See here

http://www.qgis.org/wiki/Bugs

actually the page is not available cause the problems with the qgis/osgeo servers.

If OTF is off, the selector sets the unit of the source layer.

This seems to me not true. If I open qgis and the load the alaska shapefile (from the qgis sample dataset), that has a projection in feet, map units do not changes from degrees. If I open a shape that has a projection in meters and set map units to meters, then close the project, open a new one and open a shape with a projection in feet, map units remain in meters, and so on... this can be puzzling for many users.

So, if you change from feet to meter, the reading should be the same.

So a)and c) is not a bug.

Actually when describing the point A) and C) I wasn't enough detailed. In fact the map scale and the measure tools are both right if the project was defined with the same unit of the layer projection, otherwise they are both wrong (but give same values). So in general it would be useful/enough to not allow selecting the "wrong" map unit in the project properties.

In b) and d), changing the map scale with OTFP enabled DOES NOT recalculare the resulting areas/distances from meters to feet.

Map scale is a plugin, so behaves differently. It might be buggy.

Also in the B) and D) cases I could have been more precise (and probably I was wrong in at least one case).

In the D) case, if the map unit is in degrees than the map scale is right but the measure tool gives wrong values.

If the map unit is in meters or feet, than the map scale is always wrong regardless the unit of the layer projection (meters or feet), and the measure tool gives right results only in meters, even if the projection unit is feet.

So it is exactly as described in B).

Other words have to be spent in the case we have layers with a projected coordinate system and we enable OTFR using a projected CRS in the project properties (for example the same CRS of the layer or at least a CRS defined with the same unit as the layer).

1) if the layer has a projected system in meters and map units are in meters, than map scale and measure tool are right. If map units are feet than map scale and measure tool are wrong.

2) if the layer has a projected system in feet and map units are in feet, than map scale is right but measure tool is wrong. If map units are meters then map scale is wrong but measure tool is right.

Simple rule: If OTFP is off, there is no relation between the data in the file and any physical size in the real world. Every distance and area is unitless, and the unit selector only slaps on the chosen unit as a friendly.

This should be documented in the user manual.

Please suggest a way how it should behave on the dev mailing list.

Hope this observations will help taking a decision about this matter.

I believe the errors have been fixed (see #1219).