Bug report #1969
Measure tools and scale give wrong readings with OTFR disabled
| 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.
History
#1
Updated by Paolo Cavallini about 15 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 15 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 15 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 15 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 15 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 15 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 15 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 15 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 15 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 13 years ago
- Target version changed from Version 1.7.0 to Version 1.7.4
#11
Updated by Paolo Cavallini over 12 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 about 12 years ago
- File measure_result.pdf added
- File tenunitswide.dbf added
- Pull Request or Patch supplied set to No
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 12 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 12 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.