In an orienteering mapping project, I wanted to review a GPS track and geotagged photographs against an existing map. No surprise: they didn’t line up neatly. I could move the track, but would the new position mean I had corrected a location, or just changed where I drew it?
The mismatch alone couldn’t answer that. A recorded location could be inaccurate, the map could need updating, the layers could be positioned incorrectly, or any combination of those things. Moving an overlay until it looks right doesn’t tell us which explanation is right.
I developed an ad-hoc review tool, with AI assistance on the implementation, that kept the original geographic coordinates separate from the display adjustments. The viewer could move, rotate, and scale the track-and-photo overlay. Those settings were saved separately; they didn’t replace the coordinates recorded in the source files.
For example: a photo marker appears to be a little east of a map’s trail junction icon. Move the overlay west, and you could get the marker to sit on the junction. That may be a useful alignment for reviewing the photographs, but the device didn’t change its account of where the photo was taken, the reviewer just added an interpretation. If I had overwritten the recorded location with the adjusted one, the next person would have lost that distinction.
Keeping the settings separate also lets the reviewer undo an adjustment or reset the alignment without reconstructing the original data. A different alignment can be tried without becoming a new version of the observations.
The geographic data exports retained the original coordinates too. Someone importing the track or photo locations into another application might see the same disagreement with their map, and that’s information they should have. An export of adjusted coordinates would be a different product, needing a label and an explanation of the transformation used to produce it.
The tests had a similar boundary. I could check the transformation calculations and whether the display reproduced a chosen reference screenshot. Matching that screenshot established that the application could reproduce the requested placement. It wouldn’t establish that the placement was correct on the ground; that would require independent geographic evidence, such as field checks against known locations. A closer match to a picture doesn’t supply that.
This comes up in less scenic data work, too. Suppose an import operation maps several department names to one reporting category. Keeping the supplied name alongside the assigned category and the mapping rule lets someone revisit that decision. If the rule changes, they still have the information needed to apply the new one.
Original data can be wrong. Preserving it doesn’t make it authoritative, and corrections shouldn’t be forbidden, but a correction needs evidence and a record of what changed. In the mapping tool, a saved display adjustment said how they wanted to view the observations. I wanted the next person to be able to tell where those observations ended and the user’s judgment began.
—jhunterj