From site boundary to an approval-ready layout
A complete wind micrositing application: every turbine position checked against setbacks, spacing, habitation, forest, terrain, land and wind, the wake at each one, field verification, and the reports for approval.
The same menus you will use in the app
These are screens from WindSite with its demo project: 120 positions of a 5 MW turbine at 140 m hub height on open ground east of the Jaisalmer wind clusters, built on public data only. Click a screen to see it full size, or a thumbnail to see the next one.
Every position on one map
Your turbine positions over imagery or a map, coloured by their result, with other developers' turbines in grey. Roads, railways, EHV lines, villages, buildings, forest and protected areas sit underneath, and the administrative boundaries come live from Esri India's Living Atlas.
- Built-in layers: siting constraints, infrastructure, land and wind, ground data, wind atlas and terrain
- Reference layers read live from the Living Atlas: state, district, taluka and village boundaries, protected areas
- Draw a region on the map and run the analysis on just that part
Eight groups of checks, with the rule behind each
Limits, spacing, setbacks, habitation, forest, terrain, land and wind. Every check shows the figure it tested, the rule it comes from and, when it fails, how far the turbine has to move. Drag a pin and the checks follow it.
- The basis on every check: MNRE 2016, the 2024 amendment, Forest Act, statutory, client or project
- A failed distance says how far to move, live while the pin is dragged
- Plots: when a position fails, the best nearby plot with its land status, distance and wind
Wind at hub height, calibrated to your masts
The Global Wind Atlas at 100 m and 150 m, sheared to your hub height cell by cell, gives the speed, Weibull shape, plant load factor and wake loss at every turbine. Upload your mast logger exports and the atlas is scaled to what you measured.
- Speed, PLF and wake for every turbine, from the atlas and the turbine's power curve
- Wind masts: mean, recovery, shear, Weibull and the energy rose from a logger export
- A mast switched into the analysis scales the atlas and feeds the wake with the measured rose
Runs, review and published versions
Nothing reaches the field team or the client until it is published. A run re-checks the positions in scope, shows what changed, and every change is accepted or held before a version is published. Every version keeps its positions, results and the rule set they were tested against.
- Run on the whole project, the changed positions, a batch, villages or a region drawn on the map
- Accept or hold each change in the list or position by position on the map
- Parameters recorded on every run: turbine, rotor, hub height, setback, spacing and wind axis
From all positions to offer-ready
How many positions pass, how many need a visit, and what holds the rest back. Positions are released to the client in batches, with a client login, and the deliverables come out of the published version.
- Counts by category and by the check that fails
- Batches released to the client, with a client login that sees only what is published
- GEDA DP reports, and coordinates and results as CSV, KML and Excel
The site team is guided to each turbine
Field tasks are assigned to the site team and opened on a phone. The app guides them to the published position, takes the verification and the photos, and works without a signal from an offline pack.
- Tasks per turbine, assigned to a team, with the published position and its checks
- Guidance to the pin, verification and photos, offline
- A published move beyond the project's limit asks for the turbine to be visited again
The method and the rules, inside the app
A guide for every login: what the tool does, the roles, the siting criteria with their basis, the wind method, categories and offer, the field app, batches and reports, a FAQ and a glossary. Its criteria table is read from the project's own rule set, and sections follow the role, so a client sees no internals.
- The criteria table is live: it shows the project's own rule set
- Filtered by role, searchable, and printable as a PDF
- Kept in step with the app: when a method or a screen changes, the guide changes with it
Want the land behind every position too?
ClimeQuant Twin keeps the land register, leases and documents of each parcel on the same map, and follows the project into operation. WindSite's published layout is its starting point.
From your boundary to a published layout
1 · Your project
- Project boundary and candidate positions
- Turbine model, or its numbers
- Your client's criteria as the rule set
- Wind masts and survey parcels, when you have them
2 · The engine
- Eight groups of checks on every position
- Wind, PLF and wake at hub height
- Other developers' turbines from OpenStreetMap
- The best nearby plot when a position fails
3 · Review and publish
- Runs on the project, a batch or a region
- Every change accepted or held
- Versions frozen with their rule set
- Batches released to the client
4 · Deliverables
- GEDA DP reports
- Coordinates and results as CSV, KML and Excel
- Client login to the published layout
- Field app for the site team
Any turbine: pick a model from the list or type its numbers. Every rule is a parameter of your project, shown with its basis on each check.
Eight groups, and the rule behind each one
The figures are those of the demo project's rule set. In your project each one is a parameter you can see and change, and the basis is shown on every check in the app.
| Check group | What is checked | Basis |
|---|---|---|
| Limits | Inside the project boundary and outside the exclusion zones | Project |
| Spacing | Distance to your own turbines and to other developers', along and across the wind axis (5D × 7D in the demo) | MNRE 2024 amendment |
| Setbacks | Roads, railways, EHV lines and buildings: hub height plus half the rotor plus 5 m | MNRE 2016 guidelines |
| Habitation | Clusters of dwellings at 500 m; single dwellings and isolated buildings as the client asks | MNRE 2024 amendment · client |
| Forest | Forest land and protected areas | Forest Act · statutory |
| Terrain | Slope and elevation from the Copernicus 30 m DEM | Project |
| Land | The survey parcel under the position, its status and its owner | Project |
| Wind | Speed at hub height and the plant load factor gate | Client |
Set up, analyse, verify, deliver
Set up
Your boundary, positions and layers loaded and checked; the rule set, turbine and masts entered; the reference layers pulled in for the project area. The first run shows where the layout stands.
Analyse and review
Failing positions moved to their best plot, each move re-checked, every change accepted or held, and the first version published for the field team and the client.
Verify and deliver
Field tasks per turbine, verification from the phone, the next versions published, batches released to the client, and the GEDA DP pack and exports from the published layout.
What we need from you: project boundary (KML or shapefile) · candidate positions (CSV or KML) · turbine model, or rotor, hub height and power curve · your client's criteria, if any · wind mast data, if you have it · survey parcels, if available.
See it on your own project
Tell us about your project. An engineer will call within one working day to walk you through WindSite on the Jaisalmer demo, then set up your project: your boundary, positions and rule set, with logins for your office, field and client teams.
- Your own project, not a sample: your positions checked against your client's criteria
- Logins by role for the office, the site team and the client
- A fixed quote per project after the walk-through
Before you ask
Do we need survey parcels to start?
No. Boundary, positions and a turbine are enough for every check except land, which shows a dash until a parcel layer is loaded. The demo project runs without one.
Which turbines does it know?
A list of common models, with every number editable: rotor diameter, hub height, rated power and the cut-in, rated and cut-out speeds. Setbacks and spacing can follow the turbine automatically, so changing the model re-checks the layout.
Where does the wind data come from?
The Global Wind Atlas at 100 m and 150 m, sheared to your hub height. Your mast's logger export calibrates it: the measured speed, Weibull shape and energy rose replace the atlas values around the mast. WindSite does not do long-term correction or flow modelling between the mast and the sites; that stays with your wind consultant.
Who sees a changed position?
Only the office, until it is published. A run must cover the change, and it must be accepted, before a version is published. The field team, the client login and every report read the published version, and a position moved beyond the project's limit asks for a new field visit.
What does the site team need?
A phone. The field app installs from the browser, takes an offline pack of its tasks, guides the team to each published position, and records the verification and photos until a signal is back.
What do we get out at the end?
GEDA DP reports, the coordinates and results as CSV, KML and Excel, and a client login to the published layout and its batches. Every file names the version it came from.
How is WindSite different from ClimeQuant Twin?
WindSite sites the turbines: the checks, the wind and the approval. ClimeQuant Twin runs the project after that: land records, equipment, operations and maintenance on one map. The published layout moves from one to the other.