Doug, Very interesting work, but there always seems to be a fundamental misconception about addresses. Addresses are not just positions, but carry the implication of directions, of a means for traveling to or directing others to a location. If a position encoding does not carry the implication that, yes, this location is at this position on this side of a street that one can travel on, then it’s just another shorthand for a lat-lon coordinate position. Useful for flying to in Google Earth, but not for physical commerce where which side of a protected rail line a position falls on will be vitally important for access and travel time even when street network routing is available. This affects “closeness” as well, since a few feet apart and 20 minutes out of the way by roads or paths is not “close” in many useful senses.
Now, just because a street doesn’t have a name, doesn’t mean it doesn’t still exist and have an identity. In fact, using a position as an address is already presuming some fairly complete streets data and routing capabilities. Leveraging streets and identifiers for streets (hmmm, how about OSM id’s) could result in position encodings which function for people much more like addresses, and would be considerably more likely to be adopted. Food for thought… -Josh Lieberman On Oct 29, 2014, at 10:59 AM, Doug Rinckes <[email protected]> wrote: > That's going to depend on the reaction we get. :-) > > There's two main reasons that we're holding off. We don't want to implement a > feature that nobody uses, because it's much harder to remove a feature than > it is to add it. Secondly, although we've had a lot of engineers looking at > this, we want to get feedback from outside our group, so that if there is a > bug or a weakness that really impacts the usability, we get a chance to fix > things first. > > If everyone shrugs and says meh, maybe never. If the reaction is "looks good, > turn it on, we'll use it", then we get to schedule the work. > > > > Doug > > On Wed, Oct 29, 2014 at 3:50 PM, Doug Rinckes <[email protected]> wrote: > Hi Barry, > > MGRS as far as I recall doesn't truncate elegantly. We looked at MGRS-New, > which from my notes has the format GZD GZD SQ SQ E E E E E N N N N N, so if > you start chopping characters off the end, you just affect the northing. > > But your comment about the xkcd cartoon is good and something we spent a lot > of time arguing about. But as an old manager of mine once said "the good > thing about open standards is there are so many to choose from". :-) > > > Doug > > On Wed, Oct 29, 2014 at 3:31 PM, Barry Hunter <[email protected]> wrote: > Interesting. > > Particully like > https://github.com/google/open-location-code/blob/master/docs/comparison.adoc > > shows have looked into the existing systems. Ref: http://xkcd.com/927/ :) > > I do notice dont include > http://en.wikipedia.org/wiki/Military_grid_reference_system > > in many ways does something very similar. It's encoding UTM, rather than > lat/long, but algorithms are freely available. Not saying its a good > solution, but would be interesting to know why it wasn't considered. > > > > > On 29 October 2014 13:53, Doug Rinckes <[email protected]> wrote: > Hello geowankers > > I'm an engineer at Google, and I have just open sourced a geo project we've > been working on for a while. > > I used to work on our maps, detecting missing road networks and in my spare > time mapping roads in Papua New Guinea, Central and West Africa from the > satellite imagery. But without street names or addresses, a road network > isn't all that useful. People can't use it for directions, because they can't > express where they want directions to. After talking with colleagues from > around the world, I discovered that's it actually very common for streets to > be unnamed. That means that we can't get the names from government agencies, > streetview or user edits - because there are no names to get. > > We thought that we should provide short codes that could be used like > addresses, to give the location of homes, businesses, anything. If we made > them usable from smartphones, we can make addresses for anywhere available to > anyone with a smartphone pretty much immediately. > > We had some specific requirements, including that these address codes should > work offline, they shouldn't spell words or include easily confused > characters. We wanted to be able to look at two codes and tell if they are > near each other, and estimate the direction and even the distance. The codes > should not be generated by a single provider, because what do you do when > they disappear? Finally, it had to be open sourced. > > Open sourcing the project was important. We wanted to allow everyone to > evaluate it so that we don't go implementing something that turns out to not > be useful. If it does turn out to be useful, everyone (including other > mapping providers) should be able to implement it and use the codes freely. > > I'm pre-announcing this to a couple of geo lists today, and I'll be sticking > around for comments and questions. The following links provide more > information: > > Github project: https://github.com/google/open-location-code > Demonstration website: http://plus.codes > Discussion list: https://groups.google.com/forum/#!forum/open-location-code > > Enjoy! > > Doug > > _______________________________________________ > Geowanking mailing list > [email protected] > http://geowanking.org/mailman/listinfo/geowanking_geowanking.org > > > > > -- > Barry > > - www.nearby.org.uk - www.geograph.org.uk - > > _______________________________________________ > Geowanking mailing list > [email protected] > http://geowanking.org/mailman/listinfo/geowanking_geowanking.org > > > > _______________________________________________ > Geowanking mailing list > [email protected] > http://geowanking.org/mailman/listinfo/geowanking_geowanking.org
_______________________________________________ Geowanking mailing list [email protected] http://geowanking.org/mailman/listinfo/geowanking_geowanking.org
