Explicit segment boundaries for a location-history review file

Why a discarded row can still matter

A location-history review often begins with a deceptively simple transformation: read a file, keep usable coordinates, sort them by time, and draw the remaining points. The difficulty is that an unusable row can describe a meaningful boundary even when its coordinates cannot be plotted. Removing that row without recording what happened may connect observations that should remain separate. A reviewable import contract should therefore describe both the observations it retains and the reasons it declines to connect them. This article develops that contract as a design exercise, not as a report of measured performance or an implementation already tested against a particular export format.

Keep identity separate from array position

Give every source row a stable identifier before filtering or sorting. A convenient identifier for a small local file is the original row number combined with a label for the source file. It is not a permanent identity for a person or a place. Its purpose is to let a reviewer find the same observation after transformations have changed its position in a list. Keep the original representation alongside a normalized working value where practical. When a timestamp fails to parse, an error record should refer to the original row rather than only to the position in an intermediate array that may be rebuilt on the next pass.

Make validation results explicit

Model validation as a result with a reason, rather than as a Boolean that silently drops information. A row might have a usable timestamp but an invalid latitude, or a usable location but an ambiguous timestamp. Those cases create different review questions. The result can describe whether the row is usable for ordering, whether it is usable for plotting, and whether it is allowed to connect to a neighbor. This avoids forcing a single valid or invalid label to carry several incompatible meanings. It also makes it possible to display a small, understandable review table without exposing the entire raw export to someone who only needs to inspect a specific problem.

Choose a time interpretation before comparing rows

A string that looks like a time is not necessarily a well-defined instant. Some inputs include a numeric offset; others use local wall time without specifying a zone. A useful contract declares what forms it accepts and what it does with missing offsets before sorting begins. Do not silently assume that every local time belongs to the computer's current zone. A traveler may cross zones, and a reviewer may open the file somewhere else. If the available data cannot support a confident interpretation, retain the uncertainty as a review item. A polished route should not conceal a time interpretation that was selected merely because a parser accepted it.

Represent a break as data

One practical design is to produce a sequence of observations and boundary markers. A boundary marker can carry a reason such as an unresolved timestamp, a deliberate privacy omission, or an explicit source segment change. The drawing stage then starts a new segment after a boundary instead of connecting every retained observation to the next one. This design does not establish what happened between those observations. It simply prevents the absence of information from being rendered as an ordinary continuous path. The exact marker structure is an implementation choice; the important property is that the rendering stage cannot accidentally forget that the earlier review stage requested a break.

State the duplicate policy separately

Two rows with identical coordinates are not automatically duplicates. They may describe a pause, two observations recorded at different times, or repeated exports of the same observation. Likewise, two rows with identical timestamps may disagree about their locations. Define which combinations count as duplicates and preserve the reason for any removal. For a review tool, keeping a duplicate group together can be more useful than picking a winner silently. A reviewer can then see that several records were considered. Avoid treating a stable sort order as evidence that one conflicting record is more accurate; ordering is a convenience for repeatability, not a measurement of truth.

Keep editorial omissions reversible

Privacy edits should operate on a working selection instead of deleting the original observations. For example, a sharing copy may omit the start and end of a journey because they reveal a home address. Record the omission at a suitably broad level without reproducing that address in a public note. The private working file and the public animation serve different purposes and should not be confused. Reversibility helps when someone later requests a different audience or a shorter excerpt. It does not mean that private details must be included in every derivative. A useful review contract supports deliberate removal while retaining a private explanation of the decision.

Test invariants with small hypothetical inputs

Before using a large personal export, define a few tiny examples whose expected behavior is understandable on paper. One example might place an invalid row between two otherwise usable observations and require two separate segments. Another might contain the same location at two different times and require both observations to survive. A third might reverse the input order and require a declared ordering policy to produce the same reviewed sequence. These are proposed test cases, not results from an executed test suite. Their value is in making assumptions visible before an attractive interface makes those assumptions difficult to notice. Document the expected segments as well as the expected retained rows.

Explain the difference between a recap and evidence

A route animation can help a viewer understand the broad order of a journey, but its visual continuity is an editorial representation. It does not certify that a traveler followed the exact line shown between samples. If an animation has been simplified, cropped, or divided into segments, explain those decisions in language appropriate for its audience. Formal evidentiary uses require standards beyond the review exercise described here. For an ordinary travel recap, a short uncertainty note may be enough to prevent an overconfident interpretation. The objective is not to make a map look authoritative; it is to make the available story clear without claiming more precision than the observations support.

Use a small handoff record

Keep the source file, review decisions, and sharing copy distinct. A modest handoff record can name the selected date range, the revision, the broad omissions, and any unresolved boundaries without containing account credentials or a complete location history. Project association disclosure: this article is published on behalf of the related Timeline Visualizer project and was prepared with AI writing assistance. The associated google map timeline visualizer is a browser-based route-animation tool, not an independent certificate of location accuracy. Its basic features are free; the announced Pro option is a one-time $2.99 purchase, and custom music belongs to Pro. These product details are not a claim that the proposed import contract or hypothetical tests have been implemented or independently audited in that tool.