How to Check Plot Shape, Brahmasthan and Entrance Vastu Programmatically

The first three things clients ask about a property are usually the shape of the plot, the centre of the house and the direction of the main door. All three can be checked from coordinates. This article shows how the VedIntel™ Vastu API does each check, what it reports, and where it deliberately says nothing.

1. Plot shape and proportion

Every geometry response includes the plot's area, bounding_box and aspect_ratio. In rules version 1.0.0, a length-to-width ratio between 1.0 and 2.0 fires plot-aspect-ratio-positive, a moderate-confidence rule attributed to the Manasara tradition. The 20 × 10 test plot has a ratio of exactly 2.00, so it qualifies.

Real plots are often not rectangles. The Brahmasthan block of the response reports plot_regularity (regular or irregular) and bbox_coverage_ratio, the plot area divided by its bounding-box area. That ratio is 1.0 for a rectangle and lower for L-shapes, triangles or a rectangle drawn at an angle. When a plot is irregular, the response adds an irregularity_warning, because classical texts such as Mayamata and Manasara describe the Mandala for regular plots.

2. The Brahmasthan

The API projects a 9 × 9 grid over the bounding box of the north-rotated plot. The Brahmasthan is the central 3 × 3 block, rows and columns 4–6, which is one ninth of the bounding-box area. POST /api/v1/vastu/brahmasthan returns that cell and checks each room against it.

• A room counts as an obstruction when it covers more than 5% of the Brahmasthan cell. Each room appears in room_obstructions with its overlap_pct.
• brahmasthan_fraction_in_plot says how much of the cell lies inside the actual plot. is_fully_in_plot is true only when all of it does.
• The positive finding brahmasthan-clear-positive fires only when the cell is unobstructed and fully inside the plot.
• If part of the cell falls outside an irregular plot, the API does not give a positive or negative verdict. It emits the informational finding brahmasthan-not-fully-within-plot instead.
• Both the bounding-box centre_point and the area-weighted centroid_xy are returned. No classical text says which one to use for irregular plots, so the API reports both and the grid uses the bounding-box centre.

3. The main entrance

Send the bearing the main door faces, 0–360° clockwise. With north_angle 0 that is a True North bearing. If your plan is rotated, see the note on north_angle in the directions article.

POST /api/v1/vastu/entrance
{"entrance": {"bearing_deg": 45}, "north_angle": 0,
 "plot": [{"x":0,"y":0},{"x":20,"y":0},{"x":20,"y":10},{"x":0,"y":10}]}

"calculation": { "entrance": { "direction_8": "NE", "direction_4": "E", "bearing_deg": 45,
                               "deity": "Ishana (Shiva)", "label_en": "North-East" } },
"rule_evaluation": { "findings": [ {
  "rule_id": "entrance-ne-positive",
  "outcome": "positive",
  "severity": "minor",
  "source_type": "consensus",
  "source_text": null,
  "source_verification_status": "consensus_only",
  "interpretive_confidence": "moderate",
  "trigger": "Main entrance faces NE"
} ], "positive_count": 1, "negative_count": 0, ... }

This finding is a good example of why the source fields matter. A north-east entrance is widely recommended in modern practice, but the rule is consensus with consensus_only verification and moderate confidence. It is not a rule tied to one classical text. Present it that way.

4. Compare options with /vastu/findings

Before a door is built, you often want to compare candidates. POST /api/v1/vastu/findings runs the rule engine on semantic input, with no polygons: room zones, the entrance direction, whether the Brahmasthan is obstructed, and the plot aspect ratio. That makes what-if tests cheap to write:

// Compare candidate entrance directions without any geometry (one API call each).
const DIRS = ['N', 'NE', 'E', 'SE', 'S', 'SW', 'W', 'NW']

async function compareEntrances(apiKey) {
  const rows = []
  for (const dir of DIRS) {
    const res = await fetch('https://vedintelastroapi.com/api/v1/vastu/findings', {
      method: 'POST',
      headers: { 'X-API-Key': apiKey, 'Content-Type': 'application/json' },
      body: JSON.stringify({
        rooms: [{ name: 'Kitchen', zone_8: 'SE' }],
        entrance_direction_8: dir,
        brahmasthan_is_obstructed: false,
        plot_aspect_ratio: 2,
      }),
    })
    const json = await res.json()
    if (json.status !== 200) throw new Error(json.error + ': ' + json.message)
    const ev = json.response.rule_evaluation
    const entrance = ev.findings.filter(f => f.category === 'entrance')
    rows.push({ dir, positive: ev.positive_count, negative: ev.negative_count, entrance })
  }
  return rows
}

For a kitchen in SE, a NE entrance, a clear Brahmasthan and a ratio of 2, the live engine returns four positive findings: kitchen-se-positive, brahmasthan-clear-positive, entrance-ne-positive and plot-aspect-ratio-positive. Each candidate costs one API call, so eight directions cost eight calls.

5. Validation errors are specific

Bad input returns HTTP 400 with error: "INVALID_INPUT", the failing field and a readable message. Show the message to the user instead of a generic error:

HTTP 400
{ "status": 400, "error": "INVALID_INPUT", "field": "entrance",
  "message": "Entrance bearing_deg must be 0–360" }

HTTP 400
{ "status": 400, "error": "INVALID_INPUT", "field": "rooms.0.zone_8",
  "message": "zone_8 must be one of: N, NE, E, SE, S, SW, W, NW" }

HTTP 400
{ "status": 400, "error": "INVALID_INPUT", "field": "plot",
  "message": "'plot' must have at least 3 vertices" }

6. Timing the move: griha pravesh muhurta

POST /api/v1/vastu/muhurta with event_type: "griha_pravesh" checks one date at one place, using Swiss Ephemeris positions and rules from Muhurta Chintamani. Here is a live result for Bengaluru:

curl -X POST https://vedintelastroapi.com/api/v1/vastu/muhurta \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"event_type":"griha_pravesh","date":"15/01/2027","lat":12.9716,"lon":77.5946,"tz":5.5}'

"muhurta": {
  "date": "15/01/2027",
  "suitable": false,
  "score": "4/4",
  "tithi": "Saptami", "nakshatra": "Revati", "yoga": "Shiva", "vara": "Friday", "paksha": "Shukla Paksha",
  "sunrise": { "utc": "01:15:37", "unix": 1799975737 },
  "muhurta_windows": [],
  "blockers": ["Lunar month Pausha not prescribed - MC 13.1-13.2"],
  "day_blockers": ["Lunar month Pausha not prescribed - MC 13.1-13.2", "Movable lagna - MC 13.4", "Nakshatra not prescribed"],
  "evaluation": "best_moment_no_window",
  "rules_source": "Muhurta Chintamani 13.1-13.2 (months; soft and fixed nakshatras), 13.4 (...), 1.46-1.47 (...)",
  "recommendation": "15/01/2027 is not recommended for Griha Pravesh. No muhurta window in the Hindu day ..."
}

Note that the score is 4/4 but the day is still not suitable. The score covers tithi, nakshatra, yoga and weekday. Blockers such as the lunar month (Pausha is not prescribed) or a movable lagna can still rule a day out. Show suitable, the blockers and the recommendation together. The sunrise is in UTC: 01:15:37 UTC is 06:45:37 IST. bhoomi_puja, griha_arambha, vastu_puja and griha_pravesh_renovation return HTTP 501 for now.

Related