-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OTFT on, layer's and project's CRS the same: measure tools and Identify Features return impossible measurments #11279
Comments
Author Name: Steven Mizuno (Steven Mizuno) On further investigation I find that line length is also incorrect with OTF on. |
Author Name: Maciej Sieczka - (Maciej Sieczka -) 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. |
Author Name: Steven Mizuno (Steven Mizuno) Replying to [comment:2 msieczka]:
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 With OTF enabled the squares measure 0.004 m2 and 1.046 ha 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. |
Author Name: Maciej Sieczka - (Maciej Sieczka -) Ahh, now I understand what's the problem. Summary for Folks if anybody was missing the point like I did:
Quite a bug. |
Author Name: Steven Mizuno (Steven Mizuno) After a day away from all of this and more testing, I realized two things:
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. |
Author Name: Magnus Homann (@homann) 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
|
Author Name: Giovanni Manghi (@gioman) Replying to [comment:9 homann]:
Hi, 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. |
Author Name: Giovanni Manghi (@gioman) 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. |
Author Name: Magnus Homann (@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. 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. |
Author Name: Giovanni Manghi (@gioman) Hi Replying to [comment:12 homann]:
I used the (Alaska) qgis sample dataset. It is available on the site.
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. |
Author Name: Giovanni Manghi (@gioman) Once this is fixed I guess we will have to discuss what to do with scale bars and measures tool when OTFR is disabled. |
Author Name: Magnus Homann (@homann) What projections did you switch between to see the difference in meters and feet? |
Author Name: Magnus Homann (@homann) Please provide detailed steps to reproduce the problem. I have tried without understanding what you do. |
Author Name: Giovanni Manghi (@gioman) 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. |
Author Name: Giovanni Manghi (@gioman) Replying to [comment:12 homann]:
I just used the qgis sample dataset. From the qgis site: "The dataset is projected as Alaska Equal Area with unit feet (EPSG 2964)" |
Author Name: Magnus Homann (@homann) How did you see that scale bar was right, and measurements were wrong? |
Author Name: Giovanni Manghi (@gioman) Replying to [comment:19 homann]:
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". |
Author Name: Steven Mizuno (Steven Mizuno)
Original Redmine Issue: 1219
Redmine category:projection_support
Assignee: Magnus Homann
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
The text was updated successfully, but these errors were encountered: