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?
The URL in the example could then be:
Multiple places with the same name are also much less of a problem this way:
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.
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?).
Hey guys come to the launch party for my new startup! 9pm Saturday, at the Mumblefrotz office: http://maps.google.com/united-states/california/san-francisc...
(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.
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.
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.
> And who types URLs anyway.
Everyone who uses the web.
Some times for example you are not actually linking to an address or a building for example, and you want precise coordinates. Just very randomly:
You, and the parent you're agreeing with, seem to have overlooked I'd already made that point:
> Presumably one would fall back to lat/lon if one is trying to do something other than find an address.
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.
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.
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.
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.
I'm sure if one were to try hard enough, they could find issues with this scheme in the US as well.
The idea of a human usable URL would be that they'd compose the hierarchy of address URL using local addressing standards and end up with a pin at the right spot.
My understanding is this is one eventual goal of Street View database: to be able to use image recognition (street names, street numbers, buildings, landmarks, etc) to more correctly locate pins.
They're now using reCAPTCHA to assist with that: http://techcrunch.com/2012/03/29/google-now-using-recaptcha-...
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)
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.
Tokyo-to (city), Taito-ku (ward), Yanagibashi (neighborhood) 2 (area)-20 (block)-2 (building) 602 (room number)
It would fit into the proposed URL scheme perfectly: Tokyo/Taito/Yanagibashi/2/20/2/602
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.
If the lat/long is missing, then ask Maps to do a search. If its present, then its just a "nice" URL. Not necessarily RESTful.
Not by any meaningful definition of REST.
The browser doesn't retrieve the resource, it returns a representation of the resource. A map centered on a location is a valid representation of a resource identified by an address.
I tried searching 日本東京都足立区足立２丁目 (google suggestion) and your app doesn't accept.
we're able to get all the computers in the world to be more or less on the same network but we still can't figure out encoding problems from 1982
edit: I messed up writing this, should have been 足立区六町２丁目. Using http://nice-map-urls.herokuapp.com/japan/tokyo/adachi/rokuch... I get the right spot, but the search box doesn't seem to work for me(but I am behind a very high-latency line, it might be my connection that is borking)
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
Could we present these as helpful suggestions, especially including one or more examples based on our local knowledge? Rather than everyone piling on with dismissive one-upmanship?
Newcastle Upon Tyne
3, NE3 1RR
And that's it, it just can't mean anything else.
However, in other countries, like Poland, a postcode is used per city, so a postcode 32-600 is not telling you much apart from the name of the town, you need to provide a full address.
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.
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!
Try HD7 4PD to get "1 Moles Head, Golcar, HUDDERSFIELD, HD7 4PD" and "1 Prospect Place, Golcar, HUDDERSFIELD, HD7 4PD"
Try HD4 6XA and see "1 Broad Lane, Thurstonland, HUDDERSFIELD, HD4 6XA", "1 Blake House Thurstonland, HUDDERSFIELD, HD4 6XA", "1 Clough Cottages Thurstonland, HUDDERSFIELD, HD4 6XA", "1-2 Clough Cottages Greenside Road, Thurstonland, HUDDERSFIELD, HD4 6XA"
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.
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.
This seems unlikely. In a small village people know the other house names enough to avoid a collision - in England I've a feeling Parish Councils used to keep order in this regard.
This page suggests that Local Authories legislate (bylaws I guess) on the allowed names: http://www.housenameheritage.com/hnh_extras_officialviewlong....
Quoting that link:
>"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)." //
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.
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).
It is not possible to unambiguously write all addresses in the UK without including the post code.
The post code and door number are the primary key of the data.
A fine example: http://nominatim.openstreetmap.org/search.php?q=high+road%2C... Zoom out one level and you'll see that High Road is surrounded on both sides by High Street. And yes, that is correct.... High Street > High Road > High Street = One road in one very old town.
Crazily if you look down a little further you'll see the Southern High Street (A408) goes East, and what is technically another High Street heads on Southwards.
3 High Streets, and 1 High Road... in less than 1 mile in 1 town.
I was actually looking for the Church Road in Uxbridge that comes off of Church Road, but I think Google Maps incorrectly has both of them as Church Lane.
Here you go: http://nice-map-urls.herokuapp.com/ub5/united-kingdom/englan...
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.
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.)
You will have to throw out assumptions like that as soon as you start dealing with addresses in any serious manner.
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).
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.
SE20 7QR, SE25 6EP, E13 0AP, E15 2LR, W5 5DB, W3 6LJ, NW10 4SJ, N14 6BW
For a map see . As you can see, plenty there are several roads the Royal Mail considers to be called High Street, London!
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.
London post codes are the result of London moving from a single post town to a town with multiple towns (for the purpose of postal sorting offices).
The whole concept of a central post office broke down in the 1850s and London needed to be sub-divided to solve that.
Postal codes merely solved the routing problem between divisions, and wasn't a response to the street names problem.
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).
Forget India, Ireland (right beside the UK) has no postcodes.
Even within the UK (Fermanagh) postcode usage can be spotty.
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.
Some examples to highlight use cases:
Also, I will be at TC Disrupt in NY today in the Startup Alley in the Mobile category. Feel free to come by.
It also lacks a lot of things I normally link friends to in Google Maps. For example when giving directions I always link to the street view of the main entrance.
Apple learned it the hard way.
Eg "From the Calvario Church, 1 block south, half a block east"
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.
Chrome Version 24.0.1312.56 - Ubuntu 12.04 LTS (Desktop)
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.
[I attached google's original link just for reference]
In fact the 'example' url pretty much works
Na baště Svatého Jiří,
160 00 Prague-Prague 6,
I tried using utf-8 urls but I couldn't work out how to handle them in rails.
Actually, looking at the search term you entered, I must have a bug, because the iconv output is correct, it definitely shouldn't be stripping letters out of the url.
I could have used UTF-8, and made the URL http://archäologie-oö.info/orte/hörsching, but then all of the sudden 95% of the worlds population couldn't type that URL anymore.
This is a clever and intuitive idea. Nice work ;)
I like the suggestion here: https://news.ycombinator.com/item?id=5625126
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.
Also, all those / can't be good for SEO...
Good luck with all the address formats and disagreements about addresses (and places like Ireland where the address can be in either language).
(and Quebec maybe)
Not sure how GMaps deals with this
[blocked] The page at https://nice-map-urls.herokuapp.com/united-states/california... ran insecure content from http://maps.googleapis.com/maps/api/js?libraries=places&....
I know, nice idea, 'REST' etc, good looking.
As all the other comments stated, this will break down around the corner.
Country name. How do you locate a point in the ocean? What about Österreicht (easy level). ประเทศไทย (hard level)
State name. Not all countries have states. Or they're not used day to day. So in case of Ireland, do I put 'Dublin' or 'Leinster'
'Mission-dolores'? Street name? Street number?
Oh and by the way, the street numbers match the google maps position if you're lucky (it's getting better)
Why on earth are you concerned about a point in the ocean? Do you need driving directions there? Or perhaps street view? I didn't realize most ships these days navigate with google maps
I'm sure if google implemented something like this they would still support search and linking by lat/lon.
Why would I really? After all it's only 2/3 of the planet.
More realistic case: streets that haven't been mapped, rural roads.
Maybe worth noting? I opened this up in Firefox (Aurora) for Android, which changes the URL bar to show only the page title until you tap it.
Don't just strip these! paseo-de-la-estacion would be better.