I made an example app to show how Google map URLs should look | Hacker News Reader

I made an example app to show how Google map URLs should look

nice-map-urls.herokuapp.com

305 pointscaptainbenises128 comments

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?

The URL in the example could then be:

  https://maps.example.com/37.769944,-122.422264/199-Valencia-St-San-Francisco

Or just as conveniently:

  https://maps.example.com/37.769944,-122.422264/Zeitgeist-Bar

This way, multiple URLs can exist for different entities in the same geographic space.

Multiple places with the same name are also much less of a problem this way:

   https://maps.example.com/51.528642,-0.101599/High-Street

   https://maps.example.com/51.528642,-0.101599/High-Street

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?).

It's good for cutting and pasting into human-readable text:

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.

Just add /places/ in that URL, then it works...

https://maps.google.com/places/united-states/california/san-...

You can fashion pretty URLs for Google maps now: https://maps.google.com/?q=123+main+st+new+paltz+ny

> 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.

> And who types URLs anyway.

Everyone who uses the web.

I agree with you on this one. I think for some websites it makes sense, but for a maps application I think it makes no difference.

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:

https://maps.google.ca/maps?q=47.413395,-77.029266&ll=47...

> Some times for example you are not actually linking to an address

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.

> And yet, astonishingly, you get your mail

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.

Does a single ZIP code map to a single post office, or does the sorting before that need to read the address to figure out the post office?

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.

Also, in the UK and in Canada we use postcodes, which will pinpoint you down to a precise street.

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.

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.

This is a famous issue, with reams of research around navigation tools based on landmarks. Comments directly from Google:

http://googleblog.blogspot.com/2009/12/go-thataway-google-ma...

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.

http://static.googleusercontent.com/external_content/untrust...

>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-...

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.

I understand the need for a nice URL, perhaps indicative of RESTfulness, but I see a few problems with this:

1. From a REST point of view - the map is the resource. The adddress is well, not really a resource (the logic goes like this: if the address is the resource, the browser as a resource getter should only get the address, not the surrounds). IMHO the address should be modelled as an element of the resource, accessible by Maps' javascript.

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.

For example:

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

"a nice URL, perhaps indicative of RESTfulness"

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.

Well said.

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.

Agreed and well said. Nice URLs do not have to be RESTful, but RESTful URLs have to be nice. Personally, its just OK for me if the entire URL looks like:

maps.google.com/whatever-nice-text-describing-location?ll=lat,long

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.

Edit: Formatting

> RESTful URLs have to be nice

Not by any meaningful definition of REST.

> (the logic goes like this: if the address is the resource, the browser as a resource getter should only get the address, not the surrounds).

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 live in Japan , your app doesn't work for me

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

Some people in the USA tend to forget that there are other characters besides the ones the use, a little encode_url would be enough. Special Spanish characters don't work neither (áéíóúñ).

I got this url, I'm not sure if it's correct (I don't read japanese sorry). :(

http://nice-map-urls.herokuapp.com/japan/tokyo/adachi/

Does this 日本東京都足立区足立２丁目 look like this? japan/tokyo/adachi/ Hint: It doesn't.

People are making great points about ways to improve the service based on the way addressss vary around the world.

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?

In the UK it's enough to provide a postcode and the house number to find a specific place. So you can compress:

Flat 3, Bowsden Court, South Gosforth, Newcastle Upon Tyne

To: 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.

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.

Do you have any examples of a UK house number & postcode combo that is used for more than one address? I thought postcodes were unique to each street.

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:

http://www.192.com/places/ph/ph34-4/ph34-4eu/

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 [1] 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"

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.

[1] http://www.royalmail.com/postcode-finder/

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.

>Many addresses are as simple as rose cottage, village, POST CODE, and there might be many 'rose cottages' in that postcode. //

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)." //

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.

Both mine and my neighbours' house have the same post code and house number. They get ALL our post, because their letterbox is nearer to the street.

We get most of our neighbour's post as they are a basement flat - they are 31A and we are 31.

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.

In some cases (at least for Google) a postcode seems to be enough if there is only one property in that postcode.

e.g.

KW11 6UF

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".

http://nice-map-urls.herokuapp.com/united-kingdom/greater-lo...

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).

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 [1]). 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.

1. http://nice-map-urls.herokuapp.com/united-kingdom/greater-lo...

Theory meets practise.

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.

Edit 1:

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.

Edit 2:

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.

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.

In theory there should be only one high street per locality.

You will have to throw out assumptions like that as soon as you start dealing with addresses in any serious manner.

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.

Use the Royal Mail's 'find an address' tool [1] to look up the following postcodes:

SE20 7QR, SE25 6EP, E13 0AP, E15 2LR, W5 5DB, W3 6LJ, NW10 4SJ, N14 6BW

For a map see [2]. As you can see, plenty there are several roads the Royal Mail considers to be called High Street, London!

[1] http://www.royalmail.com/postcode-finder [2] https://maps.google.co.uk/maps?q=from:SE20+7QR+to:SE25+6EP+t...

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.

That's not uncommon. London postcodes were invented because there were numerous streets with the same name in London.

That's not true.

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.

http://en.wikipedia.org/wiki/London_postal_district

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).

How that would work globally I do not know... fine for most of the Western World, useless in India maybe, etc.

Forget India, Ireland (right beside the UK) has no postcodes.

Even within the UK (Fermanagh) postcode usage can be spotty.

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.

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.

Some examples to highlight use cases:

https://geokode.com/*abckitchen

https://geokode.com/*disrupt

https://geokode.com/*joneswedding

https://geokode.com/*dormroomfundhq

Also, I will be at TC Disrupt in NY today in the Startup Alley in the Mobile category. Feel free to come by.

People already have geocodes, it's their address. Nobody wants yet another address.

The biggest problem with geocoding is that not all places have addresses. Especially in the developing/third world.

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.

I think it'd be cool to have urls like:

http://nice-map-urls.herokuapp.com/congo/kasai-occidental/ka...

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.

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.

Apple learned it the hard way.

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 applaude the effort - but there are plenty of places where this falls apart. The most glaring I can think of is Nicaragua - where addresses are described based on landmarks:

Eg "From the Calvario Church, 1 block south, half a block east"

http://vianica.com/nicaragua/practical-info/14-addresses.htm...

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.

Cool. I'm working on something similar: http://addressaddress.com (be gentle, still work in progress). I've mostly tested it with Swedish addresses, so might be problems with US ones.

The form on the front page doesn't seem to be submitting:

Chrome Version 24.0.1312.56 - Ubuntu 12.04 LTS (Desktop)

Same here. But when I edited the URL to include my hometown, of which there are 3 places sharing the same name, the inclusion of a zip code returned the correct map.

How exactly is this any nicer than what Google Maps already does?

http://maps.google.com/maps?q=199+Valencia+St,+Mission+Dolor...

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.

Not quite as heirarchical as what you've got, but check out http://mapof.it/199-valencia-st-san-francisco

Nicely done.

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 [1], 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.

[1] http://nice-map-urls.herokuapp.com/united-states/california/...

[2] https://maps.google.com/maps?q=199+Valencia+Street,+San+Fran...

[I attached google's original link just for reference]

Thanks. Just pushed support for that...

https://github.com/bnolan/nice-map-urls/commit/2fee561a61ede...

At first, I thought that the address indicated what Google assumed was my geographic location, but a quick search returned, "The Zeitgeist Bar" in San Francisco.

Google Maps have tried this, I guess it failed, because it no longer distributes such urls, but for the most part the old links still work, eg https://maps.google.com/places/ca/bc/nanaimo/wallace-st or https://maps.google.com/places/uk/london

In fact the 'example' url pretty much works

https://maps.google.com/places/united-states/california/san-...

http://www.jasonbirch.com/nodes/2009/09/24/365/google-place-...

Btw it's cutting out some special chars to make the url pretty. Test this: Pitești, Argeș, Romania

yeah, a definite lack of utf-8 character support -- but this could get a bit ugly from the implementation point of view.

Yeah, lots of Czech characters get omitted - anything with an accent on it. So this

Na baště Svatého Jiří, 160 00 Prague-Prague 6, Czech Republic

becomes this

http://nice-map-urls.herokuapp.com/czech-republic/hlavn-msto...

I'm using iconv to convert from utf-8 to ascii, but the transliteration isn't as complete as I'd like. :( Sorry it strips out prague addresses.

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.

When converting from utf-8 to ascii with iconv, try specifying "ASCII//TRANSLIT" as target encoding to avoid removing foreign characters.

Your foreign characters are my native. UTF-8 is 20 years old now. Just use it already!

Jeeze... do you really think that your native characters are a good idea to be used in an URL? Take this URL for example: http://archaeologie-ooe.info/orte/hoersching

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.

sure but they could have easily replaced all the problematic characters by "simpler ones" like é,è->e, œ -> oe having an address (in France) containing some of these characters the deletion make it barely readable, therefore useless since the goal is to have understandable urls

Why everyone is trying to make this to work for every address available over the world? Why not just let it work for where it can work for and then iterate? What happened to the MVP idea?

This is a clever and intuitive idea. Nice work ;)

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.

I like the suggestion here: https://news.ycombinator.com/item?id=5625126

I wrote a speed trap application a few years ago and I used this similar structure for speed trap locations. eg

    http://www.vroomtrap.com/speed-trap-list/united-states/california/san-francisco/1900-mission-st-san-francisco-ca-94103-usa--VT144-2

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.

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

Remind me again what the point is?

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...

Now make it work internationally.

Good luck with all the address formats and disagreements about addresses (and places like Ireland where the address can be in either language).

And Belgium

(and Quebec maybe)

Not sure how GMaps deals with this

I get this in the JS console:

[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&....

Stop it.

I know, nice idea, 'REST' etc, good looking.

Stop it.

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)

No, you stop it.

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 on earth are you concerned about a point in the ocean?"

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.

Not every solution has to work for every country. This would be very nice for the UK and our address system works great.

I'm reminded of Derek Sivers' post about Japanese addresses:

http://sivers.org/jadr

Nice work on an interesting project! Google Maps' urls were always hideous for sharing before they introduced the shortener.

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.

I like the clean interface more than the clean url :) Google should look like this...

I wish Google would improve their Google+ url's, too, now. Are they still allowing to choose your own vanity url, or did that work only for a limited time period last year?

You got Berlin right and even split Kreuzberg off from Friedrichshain-Kreuzberg. It's a little buggy and your URLs should probably convert ß to ss, but I'm impressed.

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

Paseo de la Estación turns into paseo-de-la-estacin, which is not very pleasant.

Don't just strip these! paseo-de-la-estacion would be better.

This seems somewhat simpler http://mapa.arredemo.org/ Anyway they both feel nice.

Directions might be tricky as the URL will become a lot longer (especially if you're giving directions to multiple locations)

I loved the full screen-ness of it!

It's always bothered me that Google doesn't have pretty URL formating. Well done here.

Good job on the URL and on the site as a whole.

Cool, I would love to see the source.

Source is here...

https://github.com/bnolan/nice-map-urls

Google isn't so good at SEO ? ;)

Nice, but I would make it realtime:

.../#united-states--california--

Not necessary - http://diveintohtml5.info/history.html

no support on IE 8,9 so yes - I would definitely use a hash to make it ajaxified

So make IE8 and 9 do full page refreshes rather than compromising on URL quality :)

that's not the right priority

Fantastic.

the whole thing is all about human-readble URL debate.

i love this.

Reply on news.ycombinator.com