Bug report #1969

Measure tools and scale give wrong readings with OTFR disabled

Added by vince - about 10 years ago. Updated about 7 years ago.

Status:Closed
Priority:Low
Assignee:Magnus Homann
Category:Projection Support
Affected QGIS version:master Regression?:No
Operating System:All Easy fix?:No
Pull Request or Patch supplied:Yes Resolution:fixed
Crashes QGIS or corrupts data:No Copied to github as #:12029

Description

In 1.3.0, the area measurement tool sometimes goes daft. Proof on the attached screenshot.

measure_result.pdf (39.2 KB) Magnus Homann, 2012-08-18 01:13 PM

tenunitswide.dbf (76 Bytes) Magnus Homann, 2012-08-18 01:13 PM

History

#1 Updated by Paolo Cavallini about 10 years ago

Not replicable here. Can you check in which condition does this happen? Only with particular data or projections maybe? If so, sample data would be useful to attach to the ticket

#2 Updated by vince - about 10 years ago

You're right, it does only happen for a single layer and a single projection. Bad luck, the layer is not free so I cannot post it here (it is anyhow too big: 36000 polygons representing France 36000 cities). Bad luck again, I tried to clip the layer, but the resulting intersection does not present the same symptom. I'll try to dig a bit further.

#3 Updated by Giovanni Manghi about 10 years ago

I found a way to easy replicate the behaviour. I guess.

Open a new project, in my case by default it opens in wgs84, then add the "alaska" (epsg 2964, projected CRS) shapefile from the qgis sample dataset. With OTFR not enabled, the measure area results are wrong.

Enable OTFR and you'll see now that the tool give right results. Disable OTFR and again is all ok.

#4 Updated by Giovanni Manghi about 10 years ago

Replying to [comment:4 vince]:

You're right, it does only happen for a single layer and a single projection. Bad luck, the layer is not free so I cannot post it here (it is anyhow too big: 36000 polygons representing France 36000 cities). Bad luck again, I tried to clip the layer, but the resulting intersection does not present the same symptom. I'll try to dig a bit further.

Hi,

did you made any further test?

Can you relate your problem with the behaviour I described?

#5 Updated by vince - about 10 years ago

Replying to [comment:6 lutra]:

Hi,
did you made any further test?
Can you relate your problem with the behaviour I described?

Oops sorry. I'll try, but meanwhile I stumbled on another bug I'm a bit investigating. I'll be back tomorrow on this one :)

#6 Updated by vince - about 10 years ago

The bug affects the linear ruler too. It seems to be triggered by the 'on the fly' projection conversion option.

#7 Updated by Giovanni Manghi about 10 years ago

Replying to [comment:8 vince]:

The bug affects the linear ruler too. It seems to be triggered by the 'on the fly' projection conversion option.

can you be more specific (maybe posting a sample of your data)?

This is my observation:

- open a new project and check in the options that the "preferred measurement unit" is meters and that otfr is disabled

- add a layer with a projected CRS: if the "layer unit" option (in the "general" tab of the "project properties" menu) is defined accordingly with the layer CRS unit, then all "measure area", "measure line" and scalebar do give right values

- if by mistake you have a layer with a CRS unit defined in meters BUT the "layer unit" defined in feet or degrees, you'll read wrong values despite having "preferred measurement unit" in meters.

Lewt me know if this make sense to you.

#8 Updated by Giovanni Manghi almost 10 years ago

I believe this is really the behaviour of qgis right now: if otfr is not enabled then layer units must be defined accordingly to crs units (in project properties), otherwise the scalebar will be wrong and measure tools will work accordingly with the bar.

With otfr enabled things seems really to work as expected.

#9 Updated by Paolo Cavallini almost 10 years ago

I confirm the observations by lutra, on current trunk (1.5). While understandable, the behaviour is incorrect, and should be fixed.

#10 Updated by Giovanni Manghi almost 8 years ago

  • Target version changed from Version 1.7.0 to Version 1.7.4

#11 Updated by Paolo Cavallini over 7 years ago

  • Target version changed from Version 1.7.4 to Version 1.8.0
  • Crashes QGIS or corrupts data set to No
  • Affected QGIS version set to master

#12 Updated by Magnus Homann over 7 years ago

This is tricky. If we consider that the OTF is OFF, the layer CRS does not matter to QGIS when measuring. There are many settings that determine what the physical length of a segment is. I have created a shape file that is a line from (0,0) to (10,0). Depending on different settings (see PDF), the physical length is different as seen by measurment tool.

Sometimes the measuremnet tool and the scale bar differs, I don't think scale bar cares about preferred units. Lets look into that later, first concentrate on the measurement tool.

#13 Updated by Magnus Homann about 7 years ago

  • Resolution set to fixed
  • Pull Request or Patch supplied changed from No to Yes
  • Target version changed from Version 1.8.0 to Version 2.0.0
  • % Done changed from 0 to 100

I fixed this in https://github.com/qgis/Quantum-GIS/pull/208

Waiting for merge to master.

#14 Updated by Giovanni Manghi about 7 years ago

  • Status changed from Open to Closed

Magnus Homann wrote:

I fixed this in https://github.com/qgis/Quantum-GIS/pull/208

Waiting for merge to master.

Hi Magnus, brillant, thanks for your effort.

Also available in: Atom PDF