95 lines
3.3 KiB
Markdown
95 lines
3.3 KiB
Markdown
---
|
|
id:
|
|
aliases: []
|
|
title: 2025-12-17
|
|
tags:
|
|
- authorship/original
|
|
- destiny/permanent
|
|
- status/draft
|
|
- type/periodic/daily
|
|
dg-publish: true
|
|
---
|
|
# 2025-12-17
|
|
|
|
## 2025-12-17 05:39:??
|
|
|
|
One aspect of estimating that I find most interesting,
|
|
but that is criminally understudied,
|
|
is the effect of building dimensions
|
|
(footprint shape, floor area, stories, height)
|
|
on total cost.
|
|
|
|
Unfortunately, lack of interest in the subject extends beyond estimating.
|
|
Discourse on spatial data seems to fall into one of two bins:
|
|
* civil engineering
|
|
* n-dimensional mathematics[^1]
|
|
neither are readily applicable to building construction.
|
|
|
|
[^1]: worse still, the "space" studied in such disciplines is
|
|
[vector space](https://en.wikipedia.org/wiki/Vector_space)
|
|
where "distance" is a measure of similarity
|
|
and physical geometry is rarely considered.
|
|
|
|
Of the two, pure math would be be preferred---
|
|
being generally more rigorous---
|
|
but the first bin far outweighs the second.
|
|
See the difference in content from
|
|
[geostatistics](https://en.wikipedia.org/wiki/Geostatistics)
|
|
to the conceivably far more broad
|
|
[spatial statistics](https://en.wikipedia.org/wiki/Spatial_statistics).
|
|
|
|
> [!quote] [Geographic data and information](https://en.wikipedia.org/wiki/Geographic_data_and_information)
|
|
> **Spatial data** or **spatial information** is broader class of data
|
|
> whose geometry is relevant
|
|
> but it is not necessarily [georeferenced](https://en.wikipedia.org/wiki/Georeferenced "Georeferenced"),
|
|
> such as in computer-aided design (CAD),
|
|
> see [geometric modeling](https://en.wikipedia.org/wiki/Geometric_modeling "Geometric modeling").
|
|
|
|
### Ambiguity
|
|
|
|
New Note: [[ambiguity]]
|
|
|
|
## 2025-12-17 12:32
|
|
|
|
#topic/ambiguity
|
|
|
|
A while ago I heard a minor coding influencer lament
|
|
that frameworks, packages, and tools
|
|
often have ridiculous sounding names[^2]
|
|
when, he suggests, they ought to just be called what they do.
|
|
|
|
[^2]: `bubble-tea` and `ratatui`
|
|
(libraries for creating CLI's) come to my mind
|
|
|
|
Unfortunately some people and organizations agree with him,
|
|
giving us terms which mean both something very general
|
|
and something very specific.[^3]
|
|
|
|
[^3]: [[project-management-tm|"Project Management"]]
|
|
was my go to example, but weak
|
|
because it's difficult for me to articulate
|
|
the difference from construction project management
|
|
especially to someone unfamiliar with the specifics of either.
|
|
|
|
For lack of a better term I've been thinking of this as an SEO problem,
|
|
but the bigger problem is that it invites [[ambiguity#Category Mistake|Category Mistake]],
|
|
whereby the ignorant listener associates traits unique to the example
|
|
to all things that the name could describe.
|
|
|
|
I thought to finally write about this problem
|
|
while researching [[lighting-controls#Protocols|lighting control protocols]].
|
|
The two most dominant examples:
|
|
|
|
* [[lighting-controls#^dali|"Digital Addressable Lighting Interface (DALI)"]]
|
|
* [[lighting-controls#^dmx|"Digital Multiplex (DMX)"]]
|
|
|
|
while notably different in topology,
|
|
could both be described accurately with the other's name.
|
|
|
|
> It is possible to avoid this problem
|
|
> without the effort necessary to come up with a clever name.
|
|
> Just stick an arbitrary, but reasonably unique word
|
|
> in front of the generic description.
|
|
> A person's name ("John's Digital Addressable Lighting Interface (JDALI)")
|
|
> or your favorite animal ("Heron Digital Multiplex (HDMX)") are good options.
|