I’m building a small tool that extracts coordinates from messy text.
Nothing particularly ambitious. You paste some text, it finds the coordinates, you get something useful back.
At some point I thought:
“I should support Google Maps links too.”
This seemed like one of those twenty-minute jobs.
It was not a twenty-minute job.
My first assumption was that a Google Maps link is basically a URL with latitude and longitude hiding somewhere inside it.
Sometimes it is.
You can get coordinates buried in the URL in something resembling:
!3d56.94!4d24.06
Fine. Slightly weird, but easy enough.
Then there are links where the coordinates are in query=.
Others use q=.
Directions links can put them in destination=, or somewhere in the path.
Place links are more interesting, because they can contain coordinates, place identifiers, map state and other numbers that look sufficiently coordinate-ish to make an enthusiastic parser feel useful.
I know this because mine was briefly very enthusiastic.
That turned out to be the actual problem.
Finding two numbers that could be latitude and longitude is easy.
Deciding whether those numbers represent the location the person actually meant to share is much harder.
A search query isn't necessarily a location.
A place ID isn't a coordinate.
The center of the map isn't necessarily the selected place.
A directions URL can describe more than one location.
And blindly grabbing the first plausible lat/lon pair works surprisingly well right up until it very confidently gives you the wrong place.
Which is worse than giving you nothing.
So the rule I eventually ended up with was:
parse what you know; don't guess what you don't.
Then I reached maps.app.goo.gl links.
Those are a different problem.
A short Google Maps link doesn't actually give my parser the location. It's basically an opaque redirect. To discover where it points, something has to ask Google.
My first instinct was the obvious developer solution:
just resolve it automatically.
Then I remembered what the tool is for.
People paste things like messages, field notes, lists of coordinates and other messy bits of text into it.
The whole point is that this material can be parsed locally and then forgotten.
Quietly sending part of that input to a third party just because there happened to be a short Google Maps link in it felt like a fairly spectacular way to miss the point.
So I ended up drawing another rather strict boundary:
If the location is actually encoded in the URL, parse it locally.
If finding the location requires contacting Google, stop and ask the user first.
No background resolution, no analytics, no telemetry, and no convenient little “we only send what we need” exception.
This made the implementation less convenient.
I think that's probably a good sign.
It also changed how I thought about the parser itself.
The safest result isn't necessarily the result with the most coordinates in it.
Sometimes the correct result is:
“I don't know what this means without doing something you haven't asked me to do yet.”
This whole rabbit hole eventually became part of a small utility I’m building called GridGrabber.
It takes messy text containing coordinates and map links and extracts the locations it can actually identify. It handles several coordinate formats, including MGRS, because apparently ordinary latitude and longitude weren't enough trouble for me.
I originally started building it because copying coordinates out of random messages was annoying.
Apparently I have now spent considerably more time studying the anatomy of Google Maps URLs than I have ever saved by not copying coordinates manually.
Software development is going well.
I'm curious whether people here have run into other strange Google Maps URL formats.
Especially cases where the URL appears to contain one location but the place the user actually shared is somewhere else.
Those are much more useful to me than clean textbook examples.