3

I can get accurate lengths of line features and areas of polygon features using the "Measuring Tool" in a QGIS project. However, when I attempt to generate length or area data in Attribute Tables using the "Field Calculator" I get values that are outrageously incorrect (too large by a factor of 1000 or more). A surprising aspect is that the values that pop up as "Output Preview" in the Field Calculator appear to be accurate/correct values. Has anyone else encountered this ? Can anybody tell me where I am going wrong ? Thanks

  • 2
    It is propberly a projection issue. When you use the Measuring Tool your data is projected on the fly to whatever it is set. If you use the field calculator, the projection of the file itself is used. What is the projection of your file? What is the projection of your dataframe (right corner, EPSG:..., next to the globe symbole) – ustroetz Nov 7 '13 at 23:28
  • Thanks @Ustroetz.The projection shown on the bottom right corner is the same for all layers (ESPG 29903). I have since noticed that the Field Calculator works OK when converting values that are already in an Attribute Table (e.g. converting from meters to yards or hectares to acres). It also works OK for populating an Attribute Table with values for X or Y coordinates of features in point vectors. I am baffled but I am a newbie. – Edward Nov 8 '13 at 12:18
  • related: gis.stackexchange.com/questions/76083/… – underdark Nov 8 '13 at 13:16
6

I had a similar problem but this seems to be a usable workaround: Instead of using the table calculator, use "Vector -> Geometry Tools -> Export/Add Geometry Columns...". In this dialog box, use the option to Calculate using "Layer CRS" or "Project CRS", and you will get the correct area. If you use "Ellipsoid" you will get errors similar to the column calculator. This is strange, because the column calculator supposedly uses the Layer CRS, not the ellipsoid.

(After experimenting a little more, I found another workaround: If I use the column calculator on a layer with a lat/lon coordinate system instead of UTM, that also seems to work fine. So, strangely enough, my example below works fine if I use the column calculator to get the area before changing the projection to UTM.)

As background: I am using QGIS 2.14.3. I have a polygon layer that was originally in a lat/lon coordinate system (EPSG:4269, NAD83). I right-clicked on the layer and used "Save As..." to save it in a UTM coordinate system (EPSG:26904 - NAD83 / UTM Zone 4N). Then I created a new project, set it to the same UTM coordinate system and loaded the UTM version of this layer into it. The layer and project dialog boxes and the bottom right corner of the main window all show EPSG:26904.

Then I used the column calculator to calculate area using $area. This gives the right value for about 1/3 of the polygons. But the other 2/3 of the polygons have areas that are too high by a seemingly random factor between 17.9 and 230981.2. This is strange, because a few days ago I performed a similar calculation on a similar layer and had no problem (I think). That may have been done in a slightly different projection or in QGIS 2.12 though. Anyway, the workaround above seems to calculate the right area for all the polygons.

2

The projection shown in the bottom right corner is your dataframe projection. This is the projection being used to calculate distance/area when using the measure tool, as ustroetz states. It is set at the project level and will be consistent across layers.

The projection of the file is different and can vary between layers. Right click the layer you are interested in in the Layer tree, select "Properties", and go to the "General" tab. Your file projection will display under "Coordinate Reference System".

If the coordinate reference system differs from your data frame it could be the cause of the discrepancy. If this is the case you can save your layer in a different projection by right clicking the layer --> Save As --> select the correct CRS.

  • Thanks tshiffle. I will check that out and let you know the outcome – Edward Nov 15 '13 at 0:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.