Hi Tony, Good point. For a campus or any large building complex, it might be useful to hashtag buildings that are associated with the main 'campus address.' Would it be feasible to do 'separate chaining' for each main campus address to an array of pointers linking to other campus buildings?
Being a recent college graduate I have, many times, given directions to visitors regarding other campus buildings, such as Arch., Eng., Sc., etc. Best, Alex On Tuesday, February 7, 2017 at 2:21:47 PM UTC-5, Tony B wrote: > > Doug and Alex > > In street addressing, the designation of a precise "rooftop" address is > considered highly desirable for individual buildings, but for campuses made > up of collections of buildings, it is often inadequate or confusing. > Designating the entrance to the campus by a plus code is one way to resolve > this, but it doesn't logically indicate the extent of the campus. > > Could the concept of a campus made up of an associated "group" of plus > codes solve this issue? Or perhaps a plus code indicating the campus > entrance which can be associated with a subset of selected plus codes > covering the remainder of the campus? > > -Tony > > > On Monday, 6 February 2017 09:26:58 UTC+2, Doug Rinckes wrote: >> >> Hi Alex, >> >> That's an interesting problem you have! >> >> The precision of plus codes depends on the length. A 10 digit code is >> (roughly) 14x14 meters, and this is the length that we expect will be >> mostly used as an address. >> >> OLC uses base-20, so a shorter code, say 8 digit, is actually 250x250 >> meters. (Each side is 20 times larger. The reason for using base-20 is so >> that we get down to a small area with a short code.) >> >> I've attached a screenshot of the Kenya Parliament Buildings from the >> plus.codes <https://plus.codes/6GCRPR69+4V> site (there is a menu option >> to display the grid) so you can compare the size of the grid squares. Note >> that the grid is always north oriented. >> >> And you can see that for large buildings, there are going to be multiple >> codes that fall on it. I expect that people will end up doing one of two >> things - they will use the code that covers the center of the building, or >> they will use the code that covers the main entrance to the building, since >> that's where you want people to go. >> >> Remember that we designed this primarily to give people a usable address >> in cities that don't have addresses, and that may not be well mapped, so we >> couldn't rely on knowing where the buildings or even the roads are. >> >> If you can get the different organisations to agree on the approach (yeah >> I know), then you should be able to solve this. >> >> One alternative option is that you could try taking the addresses and >> feeding them through a geocoder >> <https://developers.google.com/maps/documentation/geocoding/intro> >> service, to get a lat/lng, and then coding that lat/lng into a plus code, >> or reverse geocding >> <https://developers.google.com/maps/documentation/geocoding/intro#ReverseGeocoding> >> >> it to an address. That way, you should be able to convert your two "dirty" >> addresses above into a common reference (either a plus code or a "cleaned" >> address). >> >> Potentially, giving addresses using plus codes over radio this way could >> be easier, reducing confusion and improving response times, since instead >> of me trying to say "corner of Onderdonk Ave and Catalpa Ave" I can just >> say "P32W plus HP" (or papa three two whiskey plus hotel papa). As long as >> both ends know we're talking about New York, we're good. The people at the >> other end can just punch that into their map and go. >> >> Regarding MGRS - OLC is a much easier conversion to latitude and >> longitude, the codes are shorter, and OLC doesn't have overlapping areas. >> (It's possible for one place to have multiple MGRS codes, similar to your >> address problem.) I understand it is well used by some emergency services >> in the US, although I'm not sure if that's just Coast Guard/Search and >> Rescue or if it includes city fire and police. >> >> This is a really interesting problem, thanks for raising it and let me >> know if I can help further. >> >> >> Doug Rinckes, Technical Program Manager, Google Switzerland GmbH; >> 9G8F+5XM Zürich >> >> On Fri, Feb 3, 2017 at 6:39 PM, alexandros vlachokostas < >> alexvlac...@gmail.com> wrote: >> >>> Dear OLC team, >>> >>> I am working on a project regarding database deduplication/matching. The >>> problem that we are trying to solve is that many databases (Department of >>> Buildings, Finance, Urban Planning, Assessor, Police, Fire, etc) have >>> address duplicates or mismatches due to misspelling and/or abbreviation. >>> For example, >>> >>> - 123 S Main Boulevard Apt 101 New York NY 10001, >>> >>> can appear in another database as: >>> >>> - 123 South Main Blvd # 101 New York NY 10001. >>> >>> As a result, in the case of an emergency, the Fire and Police department >>> have a communication mismatch since the same building is differently >>> 'mapped' in their database. >>> >>> >>> I am thinking that OLC can solve that problem. However, I would like to >>> ask the following: >>> >>> >>> *1.* Considering the Nairobi parliament building as an example. Does >>> the user decide on the grid size that describes the building? >>> >>> The Nairobi parliament building can be described by a 14m x 14m >>> square but it can also be described by a 20m x 20m. As a result, for the >>> same building, there will be two distinct Plus Codes. How could OLC tackle >>> this problem? >>> >>> >>> *2.* How different is OLC from MRGS (Military Grid Reference System)? >>> Is OLC more flexible and less verbose? >>> >>> >>> Thank you for reading my message. Looking forward to your reply. >>> >>> >>> Best regards, >>> >>> Alex Vlachokostas >>> >>> >>> >>> -- >>> Public site: http://www.openlocationcode.com/ >>> Github project: https://github.com/google/open-location-code >>> Demo site: http://plus.codes/ >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "open-location-code" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to open-location-code+unsubscr...@googlegroups.com. >>> To post to this group, send email to open-loca...@googlegroups.com. >>> Visit this group at https://groups.google.com/group/open-location-code. >>> To view this discussion on the web, visit >>> https://groups.google.com/d/msgid/open-location-code/311d57a5-f6f4-4caa-b9ea-5eea27ca956b%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/open-location-code/311d57a5-f6f4-4caa-b9ea-5eea27ca956b%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- Public site: http://www.openlocationcode.com/ Github project: https://github.com/google/open-location-code Demo site: http://plus.codes/ --- You received this message because you are subscribed to the Google Groups "open-location-code" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-location-code+unsubscr...@googlegroups.com. To post to this group, send an email to open-location-code@googlegroups.com. Visit this group at https://groups.google.com/group/open-location-code. To view this discussion on the web, visit https://groups.google.com/d/msgid/open-location-code/511bceba-ba1e-4812-9b42-8beedd339279%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
