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.
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.
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.
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.
> (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 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 (áéíóúñ).
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.
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".
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.
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.
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.
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.
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"
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.
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.
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.
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.
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?
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.
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.
[+] [-] micheljansen|13 years ago|reply
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:
Or just as conveniently: 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:
vs 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.[+] [-] Terretta|13 years ago|reply
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.
[+] [-] deelowe|13 years ago|reply
I'm sure if one were to try hard enough, they could find issues with this scheme in the US as well.
[+] [-] chewxy|13 years ago|reply
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)
[+] [-] atgm|13 years ago|reply
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
[+] [-] arethuza|13 years ago|reply
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.
[+] [-] bct|13 years ago|reply
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.
[+] [-] rtpg|13 years ago|reply
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
[+] [-] ivanca|13 years ago|reply
[+] [-] captainbenises|13 years ago|reply
http://nice-map-urls.herokuapp.com/japan/tokyo/adachi/
[+] [-] paulsutter|13 years ago|reply
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?
[+] [-] gambiting|13 years ago|reply
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.
[+] [-] konstruktor|13 years ago|reply
[+] [-] buro9|13 years ago|reply
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.
[+] [-] paganel|13 years ago|reply
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).
[+] [-] captainbenises|13 years ago|reply
1. http://nice-map-urls.herokuapp.com/united-kingdom/greater-lo...
[+] [-] rmc|13 years ago|reply
Forget India, Ireland (right beside the UK) has no postcodes.
Even within the UK (Fermanagh) postcode usage can be spotty.
[+] [-] vdondeti|13 years ago|reply
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.
[+] [-] hnriot|13 years ago|reply
[+] [-] dsl|13 years ago|reply
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.
[+] [-] captainbenises|13 years ago|reply
http://nice-map-urls.herokuapp.com/congo/kasai-occidental/ka...
[+] [-] 7952|13 years ago|reply
[+] [-] konstruktor|13 years ago|reply
Apple learned it the hard way.
[+] [-] Sprint|13 years ago|reply
[+] [-] aidos|13 years ago|reply
Eg "From the Calvario Church, 1 block south, half a block east"
http://vianica.com/nicaragua/practical-info/14-addresses.htm...
[+] [-] civilian|13 years ago|reply
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.
[+] [-] erikstarck|13 years ago|reply
[+] [-] andyhmltn|13 years ago|reply
Chrome Version 24.0.1312.56 - Ubuntu 12.04 LTS (Desktop)
[+] [-] the_imp|13 years ago|reply
http://maps.google.com/maps?q=199+Valencia+St,+Mission+Dolor...
[+] [-] Millennium|13 years ago|reply
[+] [-] AlexeyMK|13 years ago|reply
[+] [-] ultimoo|13 years ago|reply
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]
[+] [-] captainbenises|13 years ago|reply
https://github.com/bnolan/nice-map-urls/commit/2fee561a61ede...
[+] [-] D9u|13 years ago|reply
[+] [-] barryhunter|13 years ago|reply
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-...
[+] [-] alessioalex|13 years ago|reply
[+] [-] bestest|13 years ago|reply
[+] [-] fsniper|13 years ago|reply
This is a clever and intuitive idea. Nice work ;)
[+] [-] habosa|13 years ago|reply
I like the suggestion here: https://news.ycombinator.com/item?id=5625126
[+] [-] joeblau|13 years ago|reply