Analyzing Locating Systems: Objects, Spaces, References, Dimensions, Units, and Representations

Last lesson separated the everyday meanings packed into “where”: place, position, location, address, identity, reference, context, boundary, and region. We saw that a city name, a map coordinate, and a room number may all be useful locators while answering different questions.

Now we make the hidden structure of a locating system explicit. The central claim of this lesson is simple: a coordinate, path, or label becomes meaningful only as part of a system that specifies what is being located, in what space, relative to what reference, along which dimensions, in which units, and in what representation.

---

From a number to a locating system

Suppose someone writes:

$$(10,20)$$

This is not yet a location. It is a pair of values. To turn it into a usable location claim, we need to supply a system.

A compact model is:

$$\mathcal{L}=(O,S,R,D,U,\rho )$$

where:

Component	Question	Typical examples
$O$: object	What is being located?	A cursor tip, survey marker, file, book, person, event
$S$: space	What set of possible positions does it occupy?	A plane, Earth’s surface, a filesystem tree, a graph
$R$: reference	What anchors or conventions make positions interpretable?	Origin, axes, datum, map projection, root directory
$D$: dimensions	What independent components describe a position?	$x,y$; latitude, longitude, height; directory components
$U$: units	What scale or measurement convention applies?	Metres, centimetres, degrees, pixels, seconds
$\rho$: representation	How is the location encoded or expressed?	Ordered tuple, map grid, text path, database fields

A fuller statement distinguishes the object’s position in a space from the encoding used to communicate that position. Let $\ell (o)$ denote the position of object $o$ in space $S$, and let $r_R$ be a representation rule determined by reference system $R$. A recorded coordinate is then:

$$c=r_R(\ell (o))$$

The important point is that $c$, the coordinate record, is not identical to the object and is not even identical to its position. It is a representation of that position under particular conventions.

This distinction will recur throughout the course. A genome locus, a library call number, a memory address, and a vector embedding are all representations of position in a particular kind of space. They are not interchangeable merely because each can be written as a compact string or tuple.

---

The six questions, carefully distinguished

The terms in the framework are easy to blur together, especially because a well-designed system often hides them from the user.

Object: what exactly is being located?

An object need not be a solid physical thing. It may be:

• the tip of a mouse cursor rather than the whole cursor icon;
• a surveyed monument rather than the surrounding parcel;
• a document edition rather than the abstract work across all editions;
• a file directory entry rather than the bytes stored on disk;
• a weather event defined over a time interval and spatial region.

Granularity matters. “Locate the campus” could mean its administrative boundary, its central coordinate, its main entrance, or a particular building. Each choice produces a different object of location.

Space: where can the object be?

A space is the domain of possible positions relevant to the problem. It need not be physical.

• A display monitor supports positions on a two-dimensional plane.
• The Earth may be modeled as a curved surface or as three-dimensional space around its center.
• A filesystem supports positions in a hierarchy of directories.
• A social network supports positions defined by connections.
• A classification system supports positions defined by category membership.

The space determines which questions make sense. Euclidean distance is meaningful on a monitor plane, but it is not usually the primary way to compare two files in a directory tree. Their common parent directory or path prefix may matter more.

Reference: relative to what?

A reference fixes the conventions that turn “there” into a determinate position.

For a Cartesian plane, reference includes:

• an origin;
• axes;
• positive directions;
• an orientation;
• a scale.

For a filesystem path, reference may include:

• a root directory or current working directory;
• a mounted filesystem;
• namespace rules;
• case-sensitivity conventions.

For geographic coordinates, reference includes an Earth model and a terrestrial reference frame. The details will be studied later, but the principle already matters: latitude and longitude are not self-interpreting.

Dimensions: how many independent components?

Dimensions specify the independent directions or parameters used to distinguish positions.

A flat screen needs two dimensions. A drone position relative to a tower generally needs three. A moving drone may require time as well:

$$(x,y,z,t)$$

A hierarchical system can also have positional components without being geometric. The path /home/learner/notes/week1.md has a variable number of components. Its “dimensions” are structural rather than perpendicular spatial axes.

Units: how is magnitude measured?

Units give scale to numerical dimensions. The pair $(10,20)$ might mean:

• $10$ metres east and $20$ metres north;
• $10$ centimetres right and $20$ centimetres up;
• $10$ pixels across and $20$ pixels down;
• $10^{\circ }$ longitude and $20^{\circ }$ latitude;
• row $10$, column $20$ in a discrete matrix.

Some systems have no metrological units at all. A directory name is not a measurement. In those cases, the relevant question changes slightly: instead of “what unit?” ask what token vocabulary, ordering rule, or namespace convention makes each component valid.

Representation: how is the position expressed?

Representation concerns the format in which a location is recorded, transmitted, displayed, or processed.

The same position can have multiple representations:

• Cartesian coordinates $(x,y)$;
• polar coordinates $(r,\varphi )$;
• a point plotted on a map;
• a street address;
• a machine-readable coordinate reference system definition.

Representation includes details that are often dismissed as mere formatting but can change meaning:

• coordinate order, such as longitude–latitude versus latitude–longitude;
• sign convention;
• decimal degrees versus degrees–minutes–seconds;
• whether the origin is at the lower-left or upper-left;
• text encoding and delimiter rules;
• rounding and numerical precision.

A representation is useful precisely because it can be read, stored, compared, transformed, or resolved. But it always leaves some properties of the object out.

---

A small but complete system: locating a cursor on a screen

The Cartesian plane is an ideal first case because every component can be made visible. The OpenStax example treats a mouse pointer moving across a monitor, with the lower-left corner serving as the origin.

The example can be analyzed as follows:

Framework component	Mouse-pointer system
Object	The pointer’s position, treated as a point at a given instant
Space	The two-dimensional surface of the monitor
Reference	Origin at the lower-left corner; positive $x$ rightward; positive $y$ upward
Dimensions	Horizontal and vertical position, $(x,y)$
Units	Centimetres
Representation	Ordered Cartesian pair such as $(6.0,1.6)$

The pointer begins at:

$$(6.0,1.6)\text{ cm}$$

and ends at:

$$(2.0,4.5)\text{ cm}$$

The displacement is not the final location. It is a vector computed from two positions:

$$\Delta \mathbf{r}=(2.0-6.0,4.5-1.6)\text{ cm}=(-4.0,2.9)\text{ cm}$$

That vector means “$4.0$ cm left and $2.9$ cm up” only because the reference frame specifies what positive $x$ and positive $y$ mean.

A typical computer display introduces a useful complication. In many graphics systems, the origin is at the upper-left of the display, and the $y$-coordinate increases downward. Thus, a point recorded as $(100,50)$ can denote a different physical position depending on whether the system uses mathematical Cartesian axes or screen-pixel conventions.

This is not a minor implementation detail. A system can have the same apparent dimensions, the same numbers, and even the same object, while producing a different location because its reference convention differs.

---

Dimensions, units, and representation are not the same thing

These three components often get merged into the loose idea of “the coordinate format.” Keeping them separate prevents common errors.

Consider a point on a physical monitor.

Change	What stays fixed?	What changes?
Record centimetres rather than millimetres	Object, space, reference, dimensions	Units and numerical values
Record pixels rather than centimetres	Object and physical screen	Units, scale, perhaps representation
Move origin from lower-left to upper-left	Object and physical screen	Reference and coordinate values
Use polar rather than Cartesian coordinates	Object and plane	Representation, coordinate meaning
Treat the cursor icon as an area rather than its tip as a point	General setting	Object definition and boundary rule

A coordinate representation can therefore vary in at least three conceptually different ways:

1. A unit change rescales values.
   The position $1\text{ m}$ from an origin is $100\text{ cm}$ from the same origin.

2. A reference change relocates the origin or reorients the axes.
   The same physical point receives different values.

3. A representation change describes the same position through a different coordinate scheme.
   Cartesian $(x,y)$ and polar $(r,\varphi )$ encode a point in the same plane differently.

Later, we will calculate such transformations. For now, the analytical lesson is enough: before comparing coordinate values, verify that the systems behind them are compatible.

---

Earth as a revealing case: coordinate reference systems

A coordinate reference system, or CRS, makes the framework concrete at a larger scale. The Earth is not a perfect sphere; it is irregular, dynamic, and difficult to describe with a simple mathematical surface. Mapping therefore requires models and conventions.

In the image, the geographic representation gives angular coordinates such as longitude and latitude. The projected representation gives planar coordinates measured in metres. Neither is “the real location” by itself. Each is a representation constructed to serve a purpose.

A simplified analysis of a ground-control mark is:

Framework component	Geographic locating system
Object	A specified physical mark or point on the ground, at a specified epoch
Space	A modeled Earth surface, often extended with height
Reference	Ellipsoid, datum, and terrestrial reference frame
Dimensions	Longitude, latitude, and optionally ellipsoidal height
Units	Degrees for angles; metres for height
Representation	Ordered tuple, such as longitude–latitude–height, plus a CRS identifier

A projected map system changes the representation more substantially:

Framework component	Projected locating system
Object	The same physical ground mark
Space	A two-dimensional map plane derived from the Earth model
Reference	A specified projection, datum, origin, and zone where applicable
Dimensions	Easting and northing
Units	Usually metres
Representation	Ordered planar pair, often accompanied by CRS metadata

The physical object has not moved merely because its coordinate values change. The descriptive system has changed.

The National Geodetic Survey states the principle particularly clearly: a geodetic datum or reference frame is an abstract coordinate system coupled to a reference surface. Its examples also show that different systems support different kinds of measurement.

Two cautions follow.

First, even an apparently global reference system is a convention with a defined realization. A GPS receiver may present numbers that look universal, but their proper interpretation depends on the system and time associated with them.

Second, height is especially revealing. “$100$ m high” is incomplete unless one specifies high relative to what: a reference ellipsoid, a geoid-like surface, a tidal datum, local ground, or a building floor. The numerical value alone does not tell us the vertical reference.

---

Extending the framework beyond geometry

The framework is designed to travel. Consider a file recorded at:

/home/learner/where-is-it/notes.md

This is a genuine location claim, but not a geometric one.

Component	Filesystem example
Object	A particular file or directory entry, ideally distinguished by a file identifier as well as its name
Space	A hierarchical namespace of directories and files
Reference	The root directory, mounted filesystem, operating system conventions, and possibly a current working directory
Dimensions	Ordered hierarchical components such as home, learner, and where-is-it
Units	Not physical units; valid name tokens and separator conventions serve an analogous role
Representation	A slash-delimited text path

The path is informative because it can be resolved: the system interprets each component relative to the preceding directory. Yet it is not a permanent identity. Rename where-is-it to location-course, and the file may remain the same object while its path changes.

This comparison reveals both the strength and limit of the framework:

• It works because every locating system needs an object, a domain of possible positions, and a rule for interpreting a record.
• It must be adapted because not every space has numeric axes, physical units, or Euclidean distance.

A useful general rule is:

Treat “dimensions” as the independent distinctions a system uses to locate something, not automatically as geometric directions.

In geography, dimensions may be longitude, latitude, and height. In a database, they may be field values. In a classification, they may be facets. In a graph, they may be relationships. The later parts of this course will show why these are analogous but not equivalent notions of position.

---

A protocol for analyzing any locator

When encountering a coordinate, address, identifier, or position claim, write a compact specification rather than accepting the notation at face value.

1. Specify the object.
   State its identity, granularity, and, where relevant, the time at which it is being located.

2. Name the space.
   Is it a physical plane, Earth model, hierarchy, network, category system, or database?

3. State the reference.
   Identify origins, axes, orientation, landmarks, datum, root namespace, schema, or other interpretive anchors.

4. List the dimensions.
   Give their number, order, and meaning. Do not assume that the first number is always horizontal position or longitude.

5. State units or component conventions.
   Use metres, degrees, pixels, seconds, category labels, or valid namespace tokens as appropriate.

6. Describe the representation.
   Record tuple order, precision, syntax, data type, CRS identifier, path convention, or serialization format.

7. Ask whether another person or system can resolve it.
   A well-specified locator should enable the intended user to find, retrieve, compare, or transform the object’s position.

For the cursor example, a complete statement might be:

At the recorded instant, the cursor tip is represented as $(6.0,1.6)$ cm in a two-dimensional Cartesian coordinate system on this monitor, with origin at the lower-left corner, positive $x$ to the right, and positive $y$ upward.

Compare that with the bare statement:

The cursor is at $(6.0,1.6)$.

The numbers are the same, but nearly all the information that makes them locational has been omitted.

---

Key takeaways

A locating system is not merely a list of coordinates. It is an organized relation among:

$$\text{object, space, reference, dimensions, units, and representation}$$

The object establishes what is located; space establishes possible positions; reference fixes interpretation; dimensions identify the independent positional components; units establish scale or component conventions; and representation determines how the result is encoded.

The mouse pointer and the geographic CRS illustrate the same logic at very different scales. A physical position can acquire different coordinate descriptions when units, origin, orientation, projection, datum, or representation change. A filesystem path shows that a system can locate something structurally even when it has neither metres nor geometric axes.

Next, we will add the elements this framework still leaves open: how a locator identifies the right entity, how boundaries and relations affect a location claim, and how a system retrieves the thing it purports to locate.