Planar polygon perimeter
Corners at easting 500000 to 500100 and northing 4649776 to 4649876 give a perimeter of 400, with four edges of 100, in the same units as your grid. It is the straight-line edge sum on the map plane, not a great-circle length. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Surveyors, GIS analysts, and field engineers often hold parcel corners, construction footprints, and inventory polygons already projected into a local or national grid — easting and northing in meters rather than raw latitude and longitude. On that projected plane the fence length around a closed figure is the sum of Euclidean straight-line distances between consecutive vertices, including the final return to the start. Use it when you deliberately want planar map-unit perimeter, not a spherical great-circle length on WGS84.
Why projected planar perimeter is not a great-circle length
Latitude and longitude describe positions on a curved Earth; summing degree differences or treating them as Cartesian x and y produces lengths that stretch and shrink with latitude and projection choice. Once coordinates are transformed into a projected coordinate reference system — UTM zones, national grids, local site grids — easting and northing become linear map units (usually meters) on a plane chosen so that distances inside a limited region stay accurate enough for fencing, paving, and inventory.
The planar polygon perimeter is then simply the closed path length of the ordered ring in those map units: each edge is the hypotenuse of the easting and northing differences between consecutive corners, and the last corner connects back to the first. That definition matches how survey notes, CAD site plans, and many desktop GIS measure tools report boundary length after projection. It is intentionally different from spherical haversine perimeter on lat/lon rings, which is the right tool when you only have geographic degrees and no shared projected CRS.
Choosing the planar path avoids under- or over-estimating short site boundaries when a great-circle model is applied naively to already-projected meter coordinates, and it keeps results comparable to tape measures and total-station traverses that already live in the same grid.
Input contract: easting, northing, and closed rings
At least three vertices are required so the figure is a genuine polygon rather than a digon or a single point. If the first and last points already coincide within a tiny epsilon — the GeoJSON-style closed ring pattern — the duplicate closing vertex is dropped before measuring so the final edge is not counted twice. Otherwise the service always adds the closing segment from the last remaining vertex back to the first.
Classic check: a one-hundred by one-hundred meter axis-aligned rectangle in any UTM-like offset yields perimeter four hundred with four equal edges of one hundred. Wire the free browser form for interactive site checks, then call the identical contract from scripts when validating cadastral imports or estimating fence runs without reimplementing the closed-ring walk.
Where planar easting-northing perimeter shows up in practice
Municipal GIS and land-administration pipelines export parcel rings already in a national projected CRS; computing planar perimeter from those eastings and northings gives a fence or wall estimate that matches the map grid used for legal plans, without pulling a full desktop GIS for every batch. Construction and civil engineering teams store building footprints and site limits as projected polylines in CAD; a shared edge-sum oracle keeps material takeoffs aligned between office scripts, web review tools, and mobile field apps.
Environmental and agricultural projects often digitize plot boundaries on a basemap that is already projected; the planar perimeter feeds buffer costs, perimeter fencing for livestock, and quality checks that reject degenerate rings with fewer than three corners. If you later need spherical great-circle length on lat/lon, area via shoelace on the same plane, or open polyline path length without closing, treat those as separate intents rather than overloading this planar-polygon-perimeter landing.
What you can do with it
Projected parcel fence estimates
From cadastral easting/northing corners in a national grid, recover planar perimeter before ordering fence or wall materials.
CAD and site-plan takeoffs
Turn ordered projected building-footprint vertices into a closed perimeter that matches the site CRS used in drawings.
GIS import quality checks
Validate that imported projected rings have plausible planar perimeters and at least three distinct corners before loading them into production layers.
FAQ
How is the planar polygon perimeter calculated?
Each consecutive pair of projected vertices is measured with Euclidean distance (Math.hypot on easting and northing differences). The ordered ring is closed automatically, and segment lengths are summed.
How many vertices do I need?
At least three. After dropping a duplicate closing point (when first equals last), the ring must still have three or more corners.
Does the input ring need to be closed already?
No. If the first and last coordinates already match within a tiny epsilon, the duplicate is not counted twice. If they differ, the service adds the closing segment from the last vertex back to the first.
Is this the same as great-circle geographic perimeter?
No. This tool assumes coordinates are already projected into a planar CRS (easting/northing map units). For latitude/longitude great-circle ring length, use the geographic polygon perimeter capability instead.
What does it cost?
The browser tool is free and runs locally.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/geo/polygon-perimeter-planar \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"vertices":[{"easting":500000,"northing":4649776},{"easting":500100,"northing":4649776},{"easting":500100,"northing":4649876},{"easting":500000,"northing":4649876}]}'const res = await fetch("https://api.kit.forhosting.com/geo/polygon-perimeter-planar", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"vertices": [
{
"easting": 500000,
"northing": 4649776
},
{
"easting": 500100,
"northing": 4649776
},
{
"easting": 500100,
"northing": 4649876
},
{
"easting": 500000,
"northing": 4649876
}
]
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/geo/polygon-perimeter-planar",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"vertices": [
{
"easting": 500000,
"northing": 4649776
},
{
"easting": 500100,
"northing": 4649776
},
{
"easting": 500100,
"northing": 4649876
},
{
"easting": 500000,
"northing": 4649876
}
]
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/geo/polygon-perimeter-planar", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"vertices":[{"easting":500000,"northing":4649776},{"easting":500100,"northing":4649776},{"easting":500100,"northing":4649876},{"easting":500000,"northing":4649876}]}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"vertices":[{"easting":500000,"northing":4649776},{"easting":500100,"northing":4649776},{"easting":500100,"northing":4649876},{"easting":500000,"northing":4649876}]}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/geo/polygon-perimeter-planar", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"vertices": [
{
"easting": 500000,
"northing": 4649776
},
{
"easting": 500100,
"northing": 4649776
},
{
"easting": 500100,
"northing": 4649876
},
{
"easting": 500000,
"northing": 4649876
}
]
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "geo.polygon_perimeter_planar",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
This capability accepts an ordered list of projected vertices, validates that at least three finite corners define a ring, closes the polygon automatically when the first and last points differ, and returns a deterministic perimeter with per-edge lengths and a method tag of planar_edge_sum. The same pure module powers the free browser tool and the prepaid API path, so interactive checks and batch scripts never disagree on the edge-sum contract.
Why projected planar perimeter is not a great-circle length
This endpoint fixes the algorithm to a pure edge sum so every language and runtime reproduces the same number for the same vertex list.
Input contract: easting, northing, and closed rings
Send vertices as a required array of objects with easting and northing (aliases e, x, east for the first component and n, y, north for the second; each vertex may also be a two-element array). Values must be finite numbers; missing fields, empty strings, NaN, and Infinity fail with invalid_input naming the bad field and are not charged. On success the JSON body returns perimeter rounded for stable serialization, n as the ring vertex count after close-dedup, vertex_count as the original input length, segments as the number of edges (equal to n), closed_input as a boolean flag, vertices as the normalized easting/northing list used for the walk, edges as the ordered per-edge lengths including the closing edge last, and method set to planar_edge_sum. API pricing is the published base of $0.002 per successful item.