LinkedIn
Twitter
@Matthew_Brown
Unless you can’t ensure that the points are taken in strict order/direction (i.e. clockwise or counter-clockwise direction), you won’t be able to get an accurate calculation even with a 3rd party service. Provided you can maintain that data collection order, than it’s a very easy match calculation to do even without using a 3rd party service.
Assume 4 points as [PT1] to [PT4] and points taken in clockwise direction:
SQ FT CALCULATION
IFS(
DISTANCE([PT2],[PT1]) = DISTANCE([PT4],[PT3]),
IFS(
DISTANCE([PT3],[PT2]) < DISTANCE([PT4],[PT1]),
((DISTANCE([PT2],[PT1]) * DISTANCE([PT3],[PT2])) + (DISTANCE([PT2],[PT1]) * (DISTANCE([PT4],[PT1]) - DISTANCE([PT3],[PT2]))) / 2) * 10763910.0000,
DISTANCE([PT3],[PT2]) > DISTANCE([PT4],[PT1]),
((DISTANCE([PT2],[PT1]) * DISTANCE([PT3],[PT2])) + (DISTANCE([PT2],[PT1]) * (DISTANCE([PT3],[PT2]) - DISTANCE([PT4],[PT1]))) / 2) * 10763910.0000,
TRUE,
DISTANCE([PT2],[PT1]) * DISTANCE([PT3],[PT2]) * 10763910.0000
),
DISTANCE([PT2],[PT1]) > DISTANCE([PT4],[PT3]),
((DISTANCE([PT4],[PT3]) * DISTANCE([PT3],[PT2])) + (DISTANCE([PT3],[PT2]) * (DISTANCE([PT2],[PT1]) - DISTANCE([PT4],[PT3]))) / 2) * 10763910.0000,
TRUE,
((DISTANCE([PT2],[PT1]) * DISTANCE([PT3],[PT2])) + (DISTANCE([PT3],[PT2]) * (DISTANCE([PT4],[PT3]) - DISTANCE([PT2],[PT1]))) / 2) * 10763910.0000
)
ACRES CALCULATION
IFS(
DISTANCE([PT2],[PT1]) = DISTANCE([PT4],[PT3]),
IFS(
DISTANCE([PT3],[PT2]) < DISTANCE([PT4],[PT1]),
((DISTANCE([PT2],[PT1]) * DISTANCE([PT3],[PT2])) + (DISTANCE([PT2],[PT1]) * (DISTANCE([PT4],[PT1]) - DISTANCE([PT3],[PT2]))) / 2) * 247.1054,
DISTANCE([PT3],[PT2]) > DISTANCE([PT4],[PT1]),
((DISTANCE([PT2],[PT1]) * DISTANCE([PT3],[PT2])) + (DISTANCE([PT2],[PT1]) * (DISTANCE([PT3],[PT2]) - DISTANCE([PT4],[PT1]))) / 2) * 247.1054,
TRUE,
DISTANCE([PT2],[PT1]) * DISTANCE([PT3],[PT2]) * 247.1054
),
DISTANCE([PT2],[PT1]) > DISTANCE([PT4],[PT3]),
((DISTANCE([PT4],[PT3]) * DISTANCE([PT3],[PT2])) + (DISTANCE([PT3],[PT2]) * (DISTANCE([PT2],[PT1]) - DISTANCE([PT4],[PT3]))) / 2) * 247.1054,
TRUE,
((DISTANCE([PT2],[PT1]) * DISTANCE([PT3],[PT2])) + (DISTANCE([PT3],[PT2]) * (DISTANCE([PT4],[PT3]) - DISTANCE([PT2],[PT1]))) / 2) * 247.1054
)
Of course this approach disregards the area to be a parallelogram shape rather than a perfect rectangle. However, if you consider Martin’s Law of Skewness, the area of a parallelogram (a rectangle which is shewed with an angle of alpha), the area can be interpreted as:
and provided the Skewness angle of the both opposite sides are equal than the area of that parallelogram is same than the perfect rectangle as the trigonometric limit approaches to 1
The latter case; provided the Skewness angle of the opposite sides are not equal than (which we call Obstructed Polygon) you will need an Eigen Vector to correct the vector calculation of the so called area, which will need a GPS Total Station and I’m afraid in this case even a 3rd party service can’t help you for that calculation.
Far more important, may be remind you that, the precision/accuracy of any GPS calculation strongly relies on the accuracy of the GPS accelerometer of the mobile device where it should be perfectly and appropriately calibrated.
@GreenFlux
I’m a Construction Director in essence and we do a lot of topographic surveys on site. In general we only give the WCS benchmark coordinates to the surveyors and the plot’s map. The surveyors bind the GPS total station to that polygon point only once and it’s totally their choice to pick-up measuring points according how much the site have ease of access. So there is no way to know in what order they might have picked-up the points and in fact in terms of topography it’s totally irrelevant because at the end of the day, they import the coordinates to their AGIS software and draw the boundary poly-lines as per the map they have and the job is done.
So I believe here @Matthew_Brown does not have any chance to know in which order the guys pick the points unless and explicitly they are instructed to do so. Provided -/+ 15-20% errata is not important for the work he wants to accomplish, there is no big deal. However, on the contrary, provided he wants a good accuracy (i.e. -/+ 3-5%) than believe me this is not a good method in many ways. In our current construction site which have a 25M sq.ft. land, we are using TOPCON GPS Total Station which is far away number 1 instrument and it’s errata is around -/+ 1-2%. And this device is machine calibrated every 3 months 
In general we’ve seen pretty poor GPS accuracy from the API that AppSheet uses to calculate the coordinates. For example, in the image below all of the points are clustered around one side of the rectangle; green edits show where the other side of the rectangle should be.
Has anyone had better accuracy on the GPS points? No use on plugging these points into another service for land area if the accuracy is so poor.
