#carpentry

Railing and baluster layout maths as an API, computed locally and deterministically — the baluster-count, spacing and post numbers a deck builder, fabricator or balustrade designer sets a guardrail out with. The baluster-count endpoint gives the smallest number of balusters that keeps every gap within the safety limit: between two posts n balusters leave n+1 gaps, so the count = ceil((rail length − max gap) ÷ (baluster width + max gap)). The usual guardrail limit is a 100 mm (4-inch) sphere — a child-safety rule — so a 2000 mm rail with 40 mm balusters needs 14 of them at even 96 mm gaps; round up, because one fewer opens the gaps past the limit. The layout endpoint sets out a known count evenly: the gap = (rail length − total baluster width) ÷ (count + 1), the centre-to-centre pitch = baluster width + gap, and the first baluster's centre sits one gap plus half a baluster from the post face, so you mark the first centre and step off the pitch with the last gap landing equal to the first. The post-count endpoint sizes the frame: a run needs one more post than spans, spans = ceil(run ÷ max post spacing), posts = spans + 1, even spacing = run ÷ spans — a 6 m run at a 1.8 m max takes 4 spans and 5 posts at a tidy 1.5 m. Everything is computed locally and deterministically, so it is instant and private. Ideal for deck and balustrade design tools, fabrication and estimating apps, and building calculators. Pure local computation — no key, no third-party service, instant. Uses the common 100 mm infill rule — confirm your local code. 3 compute endpoints. For stair rise and run use a stair API; for fence pickets a fence API.

api.oanor.com/handrail-api

Cut-list maths for woodworking and material cutting as an API, computed locally and deterministically. The cuts endpoint computes how many pieces of a target length come from one stock length once the saw kerf — the width of material each cut removes — is accounted for, using pieces = floor((stock + kerf)/(piece + kerf)) since the final cut leaves no kerf, and returns the used length, the leftover offcut, the waste percentage and the total kerf loss; a 2400 mm board cut into 300 mm pieces with a 3 mm kerf yields 7 pieces with a 282 mm offcut, not the 8 you would expect ignoring the blade. The boards endpoint works out how many stock lengths a job of a given quantity needs and how many spare pieces are left over. The yield endpoint reports the overall material efficiency — total piece length divided by total stock length — for a whole cutting job. All lengths share one consistent unit (mm, cm or inches). Everything is computed locally and deterministically, so it is instant and private. Ideal for woodworking, carpentry, metal-fabrication, contractor, maker and shop-software developers, cut-list and offcut calculators, and material-ordering tools. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is single-length (1D) cut optimisation; for loose-material volume use a mulch/volume API.

api.oanor.com/kerf-api

Lumber and framing material-estimation maths as an API, computed locally and deterministically. The boardfeet endpoint computes board feet — the standard volume unit for sawn timber, (thickness_in × width_in × length_ft) ÷ 12 — for a quantity of boards, with the total board feet and linear feet. The studs endpoint frames a wall: the number of vertical studs, ceil(wall length ÷ spacing) + 1 (16-inch ≈ 0.4064 m or 24-inch ≈ 0.6096 m centres), with two extra studs per opening, plus the plate boards for the top and bottom plates. The cost endpoint totals the lumber either by board foot (board feet × price per board foot) or by piece (pieces × price per piece). Everything is computed locally and deterministically, so it is instant and private. Ideal for construction, carpentry and DIY app developers, framing and material take-off tools, and lumberyard and builder calculators. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is lumber and framing estimation; for drywall sheets use a drywall API and for concrete use a concrete API.

api.oanor.com/lumber-api

Staircase geometry as an API, computed locally and deterministically. The calc endpoint takes the total rise (floor-to-floor height) and works out the number of steps, the exact riser height, the tread depth, the total run, the stringer (hypotenuse) length and the stair angle, and checks the result against building-code limits and the Blondel comfort rule (2 × riser + tread ≈ 24–25 in). The check endpoint validates a given riser and tread against typical US IRC limits — maximum riser 7.75 in, minimum tread 10 in — and reports the angle and comfort. The stringer endpoint returns the stringer length and angle from a total rise and total run. Dimensions are handled internally in inches but accept inches, centimetres, millimetres and metres. Everything is computed locally and deterministically, so it is instant and private. Code limits are typical US IRC values — always confirm your local building code. Ideal for construction and carpentry tools, deck and home-improvement apps, and architecture and CAD software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is staircase geometry; for paint, tile and concrete quantities use a construction-calculator API and for roof pitch use a roofing API.

api.oanor.com/stair-api