I think trying to make geo URLs nicer is a noble effort, but this approach takes a far too naive world view.
Addresses are messy. In most parts of the world (even the "western world"), addresses are hopelessly ambiguous and much of the world cannot nearly as nicely be divided into a neatly hierarchical addressing system as this example suggests.
Real-world addresses are ambiguous, confusing and messy. Pretty much the opposites of qualities that make for a good URL scheme.
How do you deal with multiple places with the same name, or one place that is known by many names? Disambiguation pages and 304 redirects to a single canonical name (which might piss a lot of people off if it's a disputed area)?
Most civilised parts of the world have developed more precise, less ambiguous addressing systems over time, using post codes and other systematic approaches, but even those are not always watertight, often volatile and only work for places where some body issued them (good luck in the desert or ocean).
Geocoding is hard, and reverse geocoding (from a place to a name) is even harder, but fortunately we already have a clear, concise and unambiguous way to address places on earth: the Geographic Coordinate System. Every place on earth can be addressed using a simple latitude/longitude coordinate pair. It's not pretty or user friendly, but at least it's fool-proof.
Why not take a much simpler approach, similar to how many blogging platforms generate pretty urls from post titles?
For a real-word mapping service, there would probably be a need to specify a zoomlevel or bounding box, but those could be provided as URL parameters. Ironically, this is very close to how the URLs in Google Maps currently look. Not as nice, but at least it's actually feasible and future-proof.
> 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.
> 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.
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.
My thoughts exactly. In many foreign countries, the "street address" for a particular location is literally just a name. For example, in Costa Rica, the address for a house we stayed in was something like "The Blue House." No number and no street name.
I'm sure if one were to try hard enough, they could find issues with this scheme in the US as well.
Fascinating! I really think geocoding has a long way to go. Google is doing a pretty good job at it (as opposed to Apple for example), but there is still a long way to go. Reverse geocoding will always remain a bit more tricky though, as some places just have multiple names. You never know which one is going to offend which people.
That's not true for most uk postcodes - many in rural areas represent an area larger than even one town, so a full address is also required. They vary from representing one address to hundreds, it's not really consistent.
It does seem strange that postcodes are not unique to addresses but they were originally just zones intended to help routing. Eventually we will probably end up with one global address space with unique identifiers for addresses like ips and dns; it would clear up a lot of ambiguity while leaving the rest of the address to function as a human readable equivalent. lat,lon doesn't really work as addresses can be on top of one another.
Almost every rule you can think of will have many exceptions in the uk as postcodes are an ad hoc scheme covering areas of varying size - my block of flats has no number, many houses have a name, not a number, many rural houses don't even have a street name or a number, just a name and hamlet name, and many rural houses share a postcode but are not on the same street or even sometimes in the same village. So postcodes are not unique to a street, nowhere near it. Here a quick search for a rural location in Scotland sharing a postcode:
There happen ( by chance ) to be two addresses sharing a number and postcode there in the first 50 addresses, but that's the least of the problems for a scheme using no + postcode as a unique id I'm afraid!
There don't seem to be any properties in that list that violate the rule? The rule is house name or number and postcode. In the cases above, there are no houses that conflict on names or numbers that I can see?
Visit  and try DE4 4HA - addresses include "1 Council Square Brassington, MATLOCK, DE4 4HA", "1 Pleasant Cottage Miners Hill, Brassington, MATLOCK, DE4 4HA" and "1 Windyridge Red Lion Hill, Brassington, MATLOCK, DE4 4HA"
Try HD7 4PD to get "1 Moles Head, Golcar, HUDDERSFIELD, HD7 4PD" and "1 Prospect Place, Golcar, HUDDERSFIELD, HD7 4PD"
And of course there's the other direction: EC1N 8QX covers a bunch of flats in the same building, so one postcode includes "Flat G.7, Ziggurat Building, 60-66 Saffron Hill, LONDON, EC1N 8QX" and "Flat 1.1, Ziggurat Building, 60-66 Saffron Hill, LONDON, EC1N 8QX" - in other words, multiple properties have the same number within the street, and the same latitude and longitude. Also the building "number" has a hyphen, the flat "number" has a dot and can have a letter, and the building has a name too.
This is not a full list of addresses, but there are two no 10s there, and obviously as the postcode covers a large area with many streets, there will be some duplicate numbers, and many houses don't even have a number or street, and if you start to include house names as numbers, you will have duplicate names there too. Many addresses are as simple as rose cottage, village, POST CODE, and there might be many 'rose cottages' in that postcode.
It would be nice if it was a unique identifier, but the uk postcode is not, even combined with part of an address like 10, or even 10 high street, sometimes the village is also required to narrow it down. This might have worked for you on a limited set of data, but the assumptions are not valid across the uk.
>"The Local Authority will liaise with the Royal Mail to ensure there is no conflict with names of other properties in the same street or immediate area, before formally registering the name. If there is a problem, an alternative name must be submitted. In some cases, the Local Authority may explore the possibility of a house number being registered at this point, in addition to (or instead of) the new name. Once the change has been approved, the Local Authority will normally advise relevant bodies such as the emergency services. The same procedure applies for brand new properties which, for whatever reason, cannot be numbered (however, virtually all new properties today are numbered)." //
It may seem unlikely, but that's the way it works (see better examples in the michaelt post above). Often postcodes cover more than one village, and there are thus duplicate street numbers or names. Some attempt is made to avoid clashes for new addresses, but there are plenty of existing ones. You need more than a postcode and number to identify an address, sometimes a street and/or village is also required.
Not quite, in rural areas, most houses have a name. If a name is used instead of a number then the name must be unique. Obviously this doesn't affect those houses on normal suburban streets which have a number but also a name, in those cases the number is the identifier for the house.
The UK is pretty much an exception to the rule here though. In most other places in the world, including the US, post codes are not nearly as precise (source: worked on a real estate search engine that deals with addresses in 8 countries, including UK and India).
OP suggested a simple solution to an inherently complex problem in a complex domain. Doing what you suggested is like building a quorum protocol based on some intuitive idea about how a quorum should work and then fixing "edge cases".
I understand the need for a nice URL, perhaps indicative of RESTfulness, but I see a few problems with this:
2. Of course you can have nice URLs without being indicative of RESTfulness. Consider an address in Japan. They do not have road names, instead, they use building/block numbers for naming/addressing. While that can still be modelled as a nice URL, the convention is now flipped, and people will be confused
3. Consider that some places do not actually have an address. Like my former residence. Due to changes in the roads, my place had a new road with no name, and no actual address (well, eventually it did, and the road still has no name. Getting pizza delivered was tough)
What can be done of course is a bit.ly kind of thing, which I think will work. Something like /maps/199-valencia-street-san-francisco-california-united-states. The current google maps url is already kinda like that (with ?q I believe)
> Consider an address in Japan. They do not have road names, instead, they use building/block numbers for naming/addressing. While that can still be modelled as a nice URL, the convention is now flipped, and people will be confused
It's not flipped at all. Japanese addresses go big -> small, just like the URL. As a matter of fact, the US addresses are flipped since US addresses go the other way.
My understanding is that "nice URLs" and "RESTfulness" are orthogonal. Difference implementations of the same RESTful interface could have completely different URL formats and they should all be compatible with clients written to the interface specification.
Having said that, best to have nice URLs and RESTfulness.
It's in some ways quite anti-RESTful for a consuming client to start to try parsing a URL semantically. "URL building" is not something a client should be responsible for, it should be (semi-)blindly using URLs the service has provided for it.
second edit: seems that the resolution is around ward-level(even when searching romanised addresses like "2-10-3 Honkomagome, Bunkyo, Tokyo", a search which works in google maps) From an intuitive standpoint, there should be no reason for this not to work, there's nothing particularly weird about the address format. I dunno
Whilst it is a nice idea to put textual labels in, and whilst it may work for grid-based cities such as those in the USA... it's really going to have a problem in Europe where many large cities are the result of growth over centuries and the merging of villages and towns into cities.
London has so much duplication in things like High Street, Church Street, Chapel Lane, Market Place... and the system outlined will just fail to disambiguate.
The only thing that could truly work on a global level is some geospatial identifier in the URL, with text that followed it. But then if the place itself was large it could span multiple geospatial points and result in duplication.
Duplication of URLs is probably better than ambiguity over what the URL points to.
PS: I tried to do a query on Open Street Map to discover how many High Streets there are in London but I hit the limit of their disambiguity service. And there are High Streets from one old village that have been extended to the point that they touch the High Street of another old village. 2 different High Streets with an almost identical postal code.
PPS: Perhaps a post-code? In the UK it's good enough to give someone a post-code and door number and you can get to their front door. How that would work globally I do not know... fine for most of the Western World, useless in India maybe, etc.
> In the UK it's good enough to give someone a post-code and door number and you can get to their front door. How that would work globally I do not know
We do have post-codes in Romania but nobody ever uses them. But at least now I understand why one of my first bosses, who was from the UK, was insisting so much that me, the programmer, would implement a reverse geo-thingie that would associate a post-code to a specific physical address (this was back in 2006-2007, the golden days of web-mapping).
The thing with India is that roads didn't necessarily have names or numbers.
I navigated more by "When you're past the ornately carved and colourful chapel go straight on and do a right, turn left when you see the blue building, we're in the red one third down with the blue door.".
Some places have such details, but a lot of the towns and villages just added roads organically and wouldn't stop to centrally register them, name them, number them, assign them identifiers, etc.
In theory there should be only one high street per locality. I didn't try the app with london urls (only berwick street which worked fine ). In theory if you can unambiguously write the address of a place without relying on the postcode, then you should be able to construct a unique url for the place.
Church Lane coming off of Church Lane. One is the A312, the other is just Church Lane.
Google is wrong on this, they're both called Church Road. And historically they were the same thing, but as it evolved from a way to get to the church to a market thoroughfare one main road emerged and left the other road as a side road. Over time this actually led to both roads being distinct, and with their own door numbering schemes, even though they meet each other.
I find the history of places as fascinating as the history of languages.
The town I grew up in had a Something St that at the top of the hill changed to a different street. A street also called Something St. Both have the same postcode. There are many duplicate house numbers.
I think they were originally separate unjoined streets. But a road was built up the hill, joining them together. I guess people couldn't agree on who should have their houses renumbered.
If manually specifying the address you probably have enough wiggle room to specify which 10 Something St you mean. I've encountered systems online that will try to normalize and correct street addresses to an official format... I could imagine that these would cause problems.
(And don't confuse those addresses with the 10 New Something St, or 10 Something Rd, both of which are only a few hundred meters away.)
The postcode and door number (or even street) is not enough in the uk unless you are in a town (and even then not always). Look up some rural postcodes, or blocks of flats with names rather than a number.
High Street is a name for the most important shopping street or main thoroughfare in UK convention. I've never been to a place that had 2 high streets and certainly not 2 called High Street. [Many towns in Scotland have a sort of quadrangle of main shopping streets it seems - one is often part cobbled and called Market Street]. If an area/town/village has multiple streets of equal worth then they might be termed North and South street or named for a building like Church Street or such.
In the past having name collisions would simply be a terrible convention, nowadays we have regulations that prevent it from happening with new names (same for housing).
The Scottish village I grew up in had a High Street - but it wasn't the High Street in the sense of "most important shopping street" (or indeed in any other sense). The "most important" street was Church Street - which even had a shop and a church, whereas High Street only had one church. :-)
High Streets can also be overtaken by events. Edinburgh's High Street hasn't been the most important street for anyone other than tourists for a few hundred years.
In theory there should be only one high street per locality.
There was a story on Russian news a few weeks ago how there are multiple streets with the same name in the city of Sochi. They are tackling the problem before the olympics arrive, but your assumption is probably violated elsewhere as well.
One of the little known "Did you know" is that the primary numbers of postal areas in London were originally alphabetically sorted (which largely remains the case today unless that postal area has been extended or further sub-divided).
Just because your native language can be expressed in ASCII, your name can be split into a first and a last name and you live in a country with grid-like streets doesn't mean that internationalization and anything related to location is easy.
Geocoding is about turning a textual reference into a grid reference. Without some textual reference you can't geocode. The real problem is a lack of methods for expressing uncertainty from a known definite benchmark.
This might seem nice for the USA but it would fail miserably in other places (or require different URL schemes). I could not find a bigger discussion I remember on HN but https://news.ycombinator.com/item?id=2588289 might work as example already.
I took another approach to this. I have been meaning to post it to HN for a while, though it is still a little raw. I call it geokode - https://geokode.com - it is meant to be like bitly for location. You can essentially choose what your url should be for any location. This makes it very user-friendly and you can also brand your location link. Currently, you can only use English characters and numbers. I have pre-populated it with some entries (see examples below), but the goal is to get users to create their own 'geokodes' as I like to call them. I am also working on a API to make the location data available once the geokode is provided. You can even link a geokode to GPS coordinates, which will be especially useful in countries where addresses are not simple. Obviously, the site needs a lot more polish, but let me know what you think. It is currently free to register a geokode - I have to update the demo video.
To be fair, a lot of things fall apart in Nicaragua.
I remember visiting some distant relatives in Sweden and the directions we got were all "take the 3rd light down, and then you'll pass the park, swing a right..." There were road names, my great-aunt just didn't know them. It worked, but it was not a great system.
Google Maps URLs could sure use some help. But I don't know that street addresses are a great naming system. If you want to use lat/lon, many open source tools like Polymaps, ModestMaps, and Leaflet (with the leaflet-hash plugin) support updating the URL automatically on navigation. (No "click here for URL"). For example, here's a clean URL to a map app that describes the base layer, zoom, and lat/lon: http://maps.stamen.com/#toner/12/37.7706/-122.3782
I'd love it if it also supported modifying the URLs, since they are so readable. For example, if I delete the 199 from the end of your URL , it should still show me Valencia St. on the map. However, in its current state, I don't think the app parses any incoming URLs from the location field.
That is a very nice demo and those are very clean and readable URLs. However I'm not sure how useful it is because I think one of the main advantages of human readable URLs would be making a scheme that I could generate by hand from an address I know. I think this scheme requires too much information, specifically in the "neighborhood" part. I didn't even know what to put between the city and the street in my own home address.
It's a very nice-looking URL, but I'm not sure how practical it is. Although the idea that "Cool URLs don't change" is not explicitly stated as one of the core principles of REST, it is nevertheless important. But political boundaries and names do change: some more frequently than others, of course, but they all change in due time. If the URLs are not kept up-to-date, then the mapping API becomes a lot less useful, but it also becomes a lot less useful if they ARE kept up-to-date.
While that scheme works well in the US and in English, some other countries/languages can't follow that pattern consistently. You'll also run into name collions that will break your scheme. I had to add a unique ID at the end of every address just to make sure I didn't get address collisions.
For us native speakers of German, using ss instead of ß or ae instead of ä seems like no big deal. But by accepting this when dealing with Americans, we strengthen the belief that everything can be forced into ASCII, which really fucks over people from countries that are smaller markets but either have different character sets or where diacritical signs are semantically relevant. edit: spelling
I think this takes an incredibly narrow view of addresses.
Many times they aren't just a number on a street -- one street can go by multiple names, one street can have multiple identical numbers (seriously try living outside of the US for a while). So what Google does is allow for flexibility. And it works. Quite well. It's not perfect, but that's because the real world didn't have an IA or DBA designing it.