Hi Josh, Sure, this is pretty much a shorthand for lat/lng with some interesting properties. I wanted something that would work without depending on Google or OSM or anyone to have mapped the area, so didn't want to rely on id's from anyone. It should work for places that aren't even near roads, and maybe not even on land!
If someone is using a code in a situation such as you mention, if it really is vitally important that you know which side of the street or rail line it's on, then they can say "+2GFWJV Mombasa. North side". It's the same way that I expect people in multi-storey buildings will provide the floor or room number. But if they don't, then it either won't matter, or it will still be better than trying to follow instructions like "left just before Mazeras, over the railway line, second left through the gate, left at the fork, left around the storage tanks, then through the fence,left along the fence line, and ask anyone you see for me". :-) Doug On Wed, Oct 29, 2014 at 4:32 PM, josh@oklieb <[email protected]> wrote: > 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
