vault backup: 2025-10-28 17:01:24
This commit is contained in:
@@ -15,34 +15,6 @@ title: Optimal Estimating Patterns
|
||||
[[construction-estimating-software]] consistently fails to innovate
|
||||
on the stale patterns developed for marginally similar applications decades ago.
|
||||
|
||||
## Flaws of Traditional Patterns
|
||||
|
||||
### Required Hyper-Specificity
|
||||
|
||||
The reason that it's such a big deal to change between 1-hole straps and and unistrut straps
|
||||
is because it takes so long to do.
|
||||
If it was as simple as it is to visualize,
|
||||
which it could be if you were drawing these things and it was being interpreted,
|
||||
rather than having to explicitly specify every aspect of what you wanted.
|
||||
Then that would make a huge difference.
|
||||
|
||||
In the (granted, limited) market segment that we've worked in,
|
||||
I use ~10 assemblies on a regular basis.
|
||||
That makes up 99% of the work.
|
||||
Why are there hundreds in in our database?
|
||||
They just need to be better.
|
||||
You could probably get away with hard coding some of this,
|
||||
even if that irks me,
|
||||
if they were good.
|
||||
It's just that it doesn't seem to be a goal
|
||||
that Trimble or anybody else has.
|
||||
|
||||
### Assumed Finality
|
||||
|
||||
While they may support a multitude of creative methods to create takeoffs,
|
||||
traditional methods are rarely as convenient when it comes to modify those takeoffs,
|
||||
as is frequently necessary as in the case of mistakes and revisions.
|
||||
|
||||
## More Optimal Patterns
|
||||
|
||||
> [!note]
|
||||
@@ -74,18 +46,43 @@ in terms of what existing estimators may be willing to accept
|
||||
#### Compared to Existing Frameworks
|
||||
|
||||
Traditional methods interact with an existing database.
|
||||
EaC builds a static database at runtime.
|
||||
EaC builds a static database at runtime,
|
||||
allowing flexibility of input.
|
||||
|
||||
* define variables
|
||||
* search and replace
|
||||
* undo
|
||||
|
||||
#### Project Structure
|
||||
|
||||
Organizational info (items, assemblies) as submodules.
|
||||
Solves database conflicts by pinning estimates to a commit.
|
||||
|
||||
[[breakdown-objects]]
|
||||
[[assembly-objects]]
|
||||
#### Related Notes
|
||||
|
||||
* [[breakdown-objects]]
|
||||
* [[assembly-objects]]
|
||||
* [[functional-labor-factoring]]
|
||||
|
||||
### Bayesian Takeoff
|
||||
|
||||
#### User Story
|
||||
|
||||
Frank is estimating a 20-story high rise
|
||||
and notices that their are roughly, but not exactly,
|
||||
the same number of receptacles in the corridors of levels 2 to 19.
|
||||
Frank starts a new takeoff for duplex receptacles,
|
||||
typical of levels 2 to 19.
|
||||
He counts and inputs quantities for 3 levels,
|
||||
each adjusts the prior to calculate the expected quantity for all 18 levels.
|
||||
|
||||
### Sketch-Based Lookup
|
||||
|
||||
<!-- TODO:
|
||||
This section is a transcription of a dictation.
|
||||
To be condensed.
|
||||
-->
|
||||
|
||||
A better use for computer vision in estimating
|
||||
is sketch based assembly lookup.
|
||||
Probably the the biggest hang-up in the workflow
|
||||
|
||||
Reference in New Issue
Block a user