Solar project boundaries: convex hulls and point-in-polygon checks
Solar sites are usually shared as a handful of corner points. Turning those into a boundary, and testing whether something lies inside it, is basic but easy to get wrong.
· 6 min read · reneGIS team
Solar sites rarely arrive as a neat polygon. What a land team hands over is a list of corner coordinates, sometimes four, sometimes forty, collected with a handheld GPS while walking the parcel. Turning that list into a boundary, and then testing whether some other asset lies inside it, is basic geometry that is nevertheless easy to get wrong.
From points to a boundary
The simplest robust boundary for a set of points is the convex hull: the smallest convex polygon that contains all of them. Picture stretching a rubber band around the pins; the shape it settles into is the hull.
The convex hull has three properties that make it a good default.
- It is unambiguous. Any set of three or more non-collinear points has exactly one.
- It is fast to compute. The standard monotone-chain algorithm sorts the points once and then walks them twice.
- It is conservative. Every point is inside or on the hull, so nothing gets left out.
Its limitation is also clear: it cannot represent concave shapes. An L-shaped parcel will get a hull that includes the notch. For screening purposes, where the question is "could this turbine be inside the solar area", a conservative boundary is the right choice. For a legal boundary, use the surveyed polygon in the order the corners were surveyed.
Point in polygon
Once there is a boundary, the next question is whether a given point lies inside it. The classic method is ray casting: draw a ray from the point in any direction and count how many times it crosses the polygon's edges. An odd count means inside, an even count means outside.
Ray casting works on any simple polygon, convex or not, and is only a few lines of code. It has two edge cases to handle deliberately: points that lie exactly on an edge, and rays that pass exactly through a vertex. Good implementations use a half-open interval test on the edge endpoints so that each vertex is counted once.
For screening, treat "on the edge" as inside. A turbine on the boundary line of a solar site is a problem either way.
Geographic coordinates and the flat-Earth shortcut
Both the hull and the point-in-polygon test are planar algorithms. Running them directly on longitude and latitude treats a degree of longitude as equal to a degree of latitude, which at 24°N is off by about 9 percent.
For the size of a solar site, a few kilometres across, this distortion does not change the answer to an inside-or-outside question except for points within metres of the boundary. It can, however, change which points form the hull when several are nearly collinear. Two defensible choices:
- Project first. Convert everything to UTM and run the algorithms in metres. Exact, and required if the boundary length or area also matters. See UTM zones in India.
- Scale longitude. Multiply longitude differences by the cosine of the latitude before running the planar algorithms. Cheap and accurate enough for screening at site scale.
What is not defensible is using the flat-Earth shortcut for anything larger than a district, or for computing areas.
Grouping points into sites
A dataset usually holds many solar projects, so the first step is deciding which points belong together. Grouping by company plus project name is simple and matches how coordinates are submitted. It fails when the same project name is reused, or when one project is split across non-adjacent parcels. In those cases a spatial clustering pass, grouping points that lie within a few hundred metres of each other, is more reliable.
A group needs at least three points to make a polygon. Groups with one or two points can only be treated as point assets.
Why this matters for wind
A wind turbine placed inside a competitor's solar boundary is the clearest kind of siting conflict: there is no spacing to argue about, the machine is on their land. Because a solar footprint is submitted as points, the conflict is invisible until someone draws the boundary. Doing that for every solar project in a region, on every revision, is exactly the kind of check that should be automated.
reneGIS Windmill Micrositing builds solar boundaries from submitted coordinates and tests every turbine against them as part of its spatial audit. For a single site, the geometry described here is enough to do the check in any GIS, and the Coordinate Converter will get the corner points into a consistent format first.