---
id:
aliases: []
title: 2025-12-17
tags:
  - authorship/original
  - destiny/permanent
  - status/draft
  - type/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.
