google
is there a specification for determining the most accurate OLC for a place?
Addresses are traditionally references to physical places rather than physical locations, and it seems the goal of OLC is to serve as addresses.
Has any work been done on a specification/process/algorithm to determine the correct level of precision for a given place; and, to determine the most accurate/canonical OLC for a place that may be ambiguous - for instance, it relatively equally crosses two OLC boundaries at a level, but going smaller means that there are multiple OLC s that could address it equally well.
Mainly, my concern is how to make sure that any generation of OLCs from existing cadastre/parcel data will result in a single canonical and non-ambiguous OLC for each place.
There are some ideas floating around, but I don't think that any of it has been strictly specified.
One aspect is the precision necessary and useful to properly address a real-world location. Less than 10 digits means that the resulting area is often too big to be useful - 12 or more might easily be more precise than necessary (see also #190). That leaves 10- or 11-digit codes, probably shortened to a "XXXX+XX[X], City" format. For what it's worth, Google Maps displays the 10-digit variant, which could be considered a statement towards those.
Other than that, an idea that has been brought up in the past is to use the OLC closest to the relevant entrance, or the door bell, or mail box, so that potential visitors (or the postman, if OLC is used as a mailing address) end up in a sensible place.
I wonder, does cadastre data even regularly include data like exact locations of main entrances or, more generally speaking, useful "points of contact"?
You can have a single, canonical and non-ambiguous OLC for a place - but that doesn't mean it's useful. :-(
For example, you could us the 10-digit OLC that contains the center point. Does that make sense for the Boeing factory? Maybe - it all depends on what you're trying to do with it.
An alternative is to say "the largest OLC that fits within the polygon (or bounding box?) that contains the center point". That will give you a sense of size, but for small buildings it may go to 11 or 12 digits. (This could be a good thing depending on your point of view.)
I'm mostly interested in the applications around addressing, directions, access, so I tend to go for the 10-digit code that is nearest the entrance (if known) or the building center. I'm personally cautious about using additional digits simply because I don't believe most consumer GNSS devices are that precise, although additional digits may have their place to disambiguate buildings that are small and near each other.
For a cadastre or land parcel, you may want one code that gives you the center, but you may also want to compute a covering of codes to provide a definition of the area.
There is some work done by the Pacific Northwest National Laboratory in the US around using it for building IDs.
@bocops cadastre data doesn't normally contain building footprints, at least globally; even in the USA, it's very rare. It definitely doesn't contain any door/etc points.
The precision question is a bit easier - either from a parcel or (satellite or in person) building footprint, it can be specified as the largest precision that completely fits within the boundaries; or perhaps the smallest precision that completely encloses at least 50% of a parcel/building, but not 50% of any other (just examples - this is what I'm thinking on currently).
@drinckes and usefulness is part of what I'm looking for. I'm interested in exploring ideas for how to determine which OLC, at what precision, best describes a place that something might be delivered to. To that end, I see two possibly "best" locations:
- designating the building
- designating the nearest intersection to a street.
I'd like to find a way to avoid duplicate OLCs for a place; even if it's as simple as "the OLC that most contains the building and no other"; something that can be generated either via a computer with parcel/building footprints, or via a person on-location.
This issue raises: "is there a specification..."
The answer is that no, we do not have such a specification and it appears that there is not an appetite to add such a specification to the Open Location Code specification.
Recommending to close this issue as resolved.
