> In most parts of the world (even the "western world"), addresses are hopelessly ambiguous
And yet, astonishingly, you get your mail. If the mail can find its way to the right point, so can this type of URL.
Your counter examples are interesting but not what this example is showing: a nice URL for a physical mailing address. Presumably one would fall back to lat/lon if one is trying to do something other than find an address.
> just as conveniently
Contrary to the OPs example, having to look up lat/lon first in order to pinpoint an address on a map seems not convenient at all.
> And yet, astonishingly, you get your mail. If the mail can find its way to the right point, so can this type of URL.
Yes, mail can find its way to the right point precisely because most countries have added a post code to the addressing system in order to deal with ambiguity.
Furthermore, mail is routed by machines, but ultimately delivered by people. And not always flawlessly too (especially with "weird" addresses. I used to live in a house with "28 1/3" as a number, which lead to massive problems). URLs are expected to work without human intervention, so more precision is required.
> Your counter examples are interesting but not what this example is showing: a nice URL for a physical mailing address.
No, the title of this post is "I made an example app to show how Google map URLs should look". And who types URLs anyway. If you are on HN, you probably belong to the tiny group of people who occasionally types "google.com?q=myquery" into your address bar, but I'm pretty sure you did not get to the page you are currently on by typing https://news.ycombinator.com/item?id=5624287
URLs are not the best form of user input, and even if they were, typing searching for "199 valencia st sf" is a lot more efficient (and less sensitive to errors) than typing the full URL of this example (http://nice-map-urls.herokuapp.com/united-states/california/...).
So, the URL is not short enough to be useful for direct user input and not precise enough to serve as a reliable permalink to a specific location, so what exactly is it good for?
My example also sucks for direct user input (for reasons you mentioned: lat/long coordinates are not user friendly), but at least they're better permalinks. I'm not sure if a solution exists that does both well, and even then, I'm not sure if it can beat search (hell, people already search for "facebook" on Google rather than typing "facebook.com" into their address bar, so how are we going to get people to use this?).
(Note: no actual party Saturday, and that's the example URL the post pointed to.)
In real world usage people will very often just cut and paste URLs directly into text, rather than figure out how to turn it into a link. Would you rather have this kind of link dumped in as plaintext, or would you rather have a lengthy machine-friendly link full of raw lat/long data, view choices, dbrefs, and whatnot?
Sure, fall back to a geolocation URL if it's not a point on a street grid. But I suspect that a huge percentage of the map URLs that people pass around are on street grids.
> I suspect that a huge percentage of the map URLs that people pass around are on street grids.
Then you probably live in the US. Most of the world is not so neatly gridded as the US.
URLs should first and foremost point to the resource (in this case a maps page) that you expect them to. This URL scheme cannot guarantee that, so it's a bad idea. It could work if you include a post code, but a post code is only marginally less ugly than a lat/long pair.
URLs too often devolve into machine formats for no good reason other than that its easier for machines (read, the machines' developers).
Friendly URLs help people understand the hierarchy of information and orient themselves within it. Friendly URLs serve as a kind of breadcrumb navigation. Friendly URLs are "hackable" by normals.
> not precise enough to serve as a reliable permalink to a specific location
If delivering mail is solvable, and considering the miracle of Street View exists, surely giving each address its own human-friendly URL is solvable too.
There are many places (where people live) that you can’t send a letter to. Instead you’ll have to send it to a mail drop where the intended receiver will have to pick it up.
> If the mail can find its way to the right point, so can this type of URL.
What in the world do those things have in common with each other? Mail gets "resolved" over a period of days and involves a small army of people, many with local knowledge. It also frequently fails and needs updated (postal codes change, street names change, etc).
> having to look up lat/lon first in order to pinpoint an address on a map seems not convenient at all
Who has to look up anything? We're talking about a URL--the software does the lookup and the user just sees the correct map.
> Who has to look up anything? We're talking about a URL--the software does the lookup and the user just sees the correct map.
On the contrary, we're talking about friendly URLs, comprehensible to normals. A human can compose a URL of the format proposed by the example, and have it point to the correct map. With lat:lon URLs, the human would have to geocode their address into lat:lon then compose the URL.
However, to agree with one part of your point, software manages to accomplish that today: put in an exact mailing address, and get a pin on a map. Therefore, one can obviously parse an address from a URL, and get the same pin on a map. Best of both worlds: human friendly URLs, while supporting lat:lon for any non-address POI.
I'm not sure mail is a good point for comparison, since it's essentially using just ZIP to get it to a local post office, at which point it is sorted by humans.
ZIP codes are also deceptive lies: ZIP code maps doesn't exist. The Post Office just has a list of addresses which belong to each ZIP code (which essentially means, which post office delivers mail to which address). They provide these lists of address to third-party mapping companies, who draw up maps of what a ZIP code hypothetically looks like based on the set of addresses. The post office, however, is constantly moving addresses between ZIP codes, as they update their postal routes to make them more effective.
To a first approximation, ZIP codes are post offices. My understanding is that sorting starts with the postal codes, but I'm not clear exactly how much sorting happens where. For instance, the first three digits of the post code denotes a regional central processing facility. When 123xx has mail for 456xx, do they sort it before or after sending it to 456xx? Does the central facility for 123xx sort the mail for 12345, or just send it all to the post office? I could see it going either way.
It depends on how big your post office is. Some have machines that use OCR to sort letters into the order that the carrier runs his/her route. They grab the bundle and go.
Still, the mail system has the benefit of numerous human sorters and carriers that fill in the gaps that computers cannot.
Figuring out an address-based URL pattern seems as daunting as lat/lon lookup (if not more, because you have to arrange the segments just so and get various spellings and symbol representations correct or program tons of logic around fool-proofing these segment interpretations) to the end user once you move outside of the cleanest address cases.
And yet, astonishingly, you get your mail. If the mail can find its way to the right point, so can this type of URL.
Your counter examples are interesting but not what this example is showing: a nice URL for a physical mailing address. Presumably one would fall back to lat/lon if one is trying to do something other than find an address.
> just as conveniently
Contrary to the OPs example, having to look up lat/lon first in order to pinpoint an address on a map seems not convenient at all.