nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Measurement tool vs shape area field

Royce_Simpson

I know this has been discussed extensively in the past, but I wanted to start another thread on the topic because I'm still struggling to understand why this is happening.

I've created a polygon hosted feature layer in AGOL, and I sketch an area in Pro, Web Editor, or Field Maps. The shape-area comes back as abc square meters, but when I use a measure tool in either an instant app or in Pro, and trace over that area, the result is xyz square meters. In other words, the results are different.

I've read numerous posts stating that the issue is that the data/map is in Web Mercator, and therefore, the measure tool utilizes the distorted effect from the projection.

What is the scoop on this, and how can I get these things to line up, especially in Field Maps, where my field workers are seeing that default acres number when they select a feature, at odds with the actual shape-area value converted to acres?

Find more posts tagged with

Accepted answers

All comments

CardiniaShire

This is very helpful - thank you. I was wondering if you are aware of where the default measurement appears on Field Maps app for the polygon. When my workers create a polygon, the system displays its area measurement in the popup under the title (see attached). This measurement is different to arcade calculated area I have configured in the form, Area($feature, 'hectares').

My workers are getting confused by the system created measurement. Do you know how I can switch it off and use my calculated value only?

Ha.jpg

ClintOffutt1

I've basically come to the point where I tell my end users that Esri web products (web maps, ExB apps) can NOT be used to take measurements. There is no way for me to develop apps where the measurements are accurate and the tools provided are so primative, there is no way to log or label individual segments in a multi segment linear measurement. We can not trust the Measure widget or the Draw widget with measurements (I have never used the basic measure tool in the map window, but doubt it works either) regardless of whether we set a native coordinate system (in my case state plane) that the data was created/edited in or use the default web mercator. This is unfortunate for people who use the mapping products for management of cadastral data, such as land surveys, deeds, metes and bounds descriptions and or other cogo geometry. These online systems are only viewer grade, I tell them, not for anayltical purposes (in this case, taking measurements). The problem I have is Esri has forced us to use their online, subscribtion based services instead of creating a desktop view product to replace ArcReader and such product is horrible at complex labeling and doesn't even have basic GIS measuring capabilities. My users work in courthouses, legal offices, and engineering firms and do not need web based systems at all. They would value a desktop reader only software that isn't reliant upon internet connections and do/redo type "developments" if that is what you can call the revisions of the current Esri AGOL products.

ChristopherCounsell

Three things to consider:

Coordinate system used
Method (geodesic or planar)
When is it calculated/stored (i.e. attribute calculations to non-system fields

How these things play out depends on your data, context and configuration. It will be different across the platform and it's important to understand it in the context.

To show feature area in field maps I would:

Identify the coordinate system you want to use. Local, projected, area preserving
Publish your layer in this service. ArcGIS Pro will publish and project to match the map coordinate system.
Now the shape geometry attributes should reflect the coordinate system and units, however I would:
Create an attribute field e.g. area_acres
Calculate the geometry of this field. In ArcGIS Pro use the field calculator and set your coordinate system.
In field maps, use arcade to calculate it dynamically. More on that here:
https://support.esri.com/en-us/knowledge-base/faq-is-it-possible-to-calculate-area-in-arcgis-online-000019847
Configure the form and pop-ups to show the area_acres field over the system geometry. This is easier and more tangible for end users, especially if exporting to CSV. You can use the field to show units and calculate them (instead of users not knowing if it's showing sqm or square ft)
Having a different source coordinate system to the map will project your data on the fly....

Now for the measurement widgets you'll need to read up on them e.g.

ArcGIS Pro uses the map frame properties, or the tool may allow for configuration
ArcGIS online typically defaults to the web map coordinate system. This is set by the base map. ESRI base map services are web mercator. You can use a custom base map with a different coordinate system to change it. However, some tools might not support it, or other limitations may apply e.g. all base map layers need to be same reference

Web mercator is a necessary evil. It's not accurate. But we can't know what coordinate system you want to use. You'll have to configure it via the above.

Hope that helps get you started. Don't forget to check the above points for each context. E.g. field maps measure, experience builder measure, arcade area function, pro tools, system geometry...

ClintOffutt1

Hi, I have had measurement issues even when using coordinate systems other than the default web Mercator 84 or whatever AGOL uses by default. In may case, I use the local state plane coordinate system with feet for the units. If I use the tool tips constraints on the Draw widget and create an easily measureable polygon, for example 100'x100', the "label" that pops up is NOT 10,000sq ft. WHY?!! Then, to make it better, if I go and use the Measurement widget to interactively measure that constrained drawing, it's not the same either.

I have noticed when I try to measure exact, surveyed online feature layer (hosted) that have been created with accuracy and precision in ArcMap or ArcGIS pro, the measurements are not the exact same regardless if I use the matching coordinate system or the default web mercator that the AGOL web maps defaults to.

danretired

That is correct. A big flashing warning would be a minimum. Better still, measurement tools should be disabled if measurements will lead to erroneous values, or they are "corrected" behind the scenes to appropriate geodesic/planar values using a projection appropriate for the area where it is being used (a minimum for field workers for sure).

Royce_Simpson

I saw that article and it didn't really tell me anything actionable. For example, how can I actually create a hosted feature layer in AGOL and have it in a web map with standard esri basemap and get all this to work properly. If I can't, then this is an imposed limitation and it seems incumbent on ESRI to somehow let the end user (Field Maps mobile workers, for example) know that measurements in Field Maps, AGOL map viewer, ArcGIS Pro, and default area values that are being calculated on the fly in Field Maps, are wrong.

danretired

If the measure tools aren't projecting/calculating in an appropriate coordinate system, but relying on web mercator data, then

FAQ: Why Are My Map, Distance and Area Measurements Wrong When Using WGS 1984 Web Mercator

It is useless for area and distance measurements. So the reference should get you started and the basic properties of the projection and its associated coordinate system is not really the problem, it is that the tools for onscreen measurement don't reproject to a location appropriate conformal/area preserving/distance preserving coordinate system

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.