admin field

[frodrigo]

"city", "district", "county", "state", "country"
This list of fields have the same meaning as admin one, haven't ?

[yohanboniface]

Follow up of our recent discussion on IRC, in quick:

• we try to have some generic keys that should be international (like city, country), so API clients could rely on those
• but every country have it's own specific levels, so we have admin key that is more openly structured; here I see two options (roughly):

  • follow the levels of OSM (2, 3, 4...) as keys; something like:

    {
        …
        "admin": {
             "2": "France",
             "4": "Nord-Pas-de-Calais",
             "6": "Nord"
        }
    }
    

  • have an open array of object which define their level and values; something like:

    {
        …
        "admin": [
             {
                  "type": "country",
                  "name": "France"
             },
             {
                  "type": "region",
                  "name": "Nord-Pas-de-Calais"
             },
             {
                  "type": "mycustomlevel",
                  "name": "Nord"
             },
        ]
    }
    

Thoughts? cc @dianashk

[yohanboniface]

@riordan have you seen a better pattern while looking at geocoders semantics around?

[frodrigo]

Using predefined keys list (city, district, county, state, country) come with problem about semententic (look as #10 for district).

Google API have a nice pattern, allowing possibilities. Partially based on admin level number. No idea if there is a public mapping of this number and admin level of countries.

Finally, using the OSM admin level number with the public mapping on the osm wiki seam form me the most simple and open way todo.

[kiselev-dv]

My vote, is for the array.

There are some levels and addressing features which are has no admin_level=* tags.

For instance:

• boundaries of named landuses
• boundaries of postalcodes
• named landuses
• streets

So it's better to have an ordered list of address parts. It's also possible in that case, to encode, was that part been estimated or have an exact boundary. For example, not all the cities in OSM have polygonal boundaries, some of them have just a point. And in some cases the could be included as a part of the result, but it would be nice to warn user that these parts was estimated.

[riordan]

@yohanboniface to pick up on your question of semantics, I'm really partial to the one @thisisaaronland developed for @whosonfirst, the gazetteer we built at Mapzen. And I'm not just saying that because I'm an employee; it's the gazetteer pattern that we had talked about back when I was at The New York Public Library and Aaron was at The Smithsonian.

It institutes a common hierarchy that's designed to provide the elements you'd use globally, using common and unambiguous terms, but also is easily extended for local cases (like Departments in France(https://fr.wikipedia.org/wiki/D%C3%A9partement_fran%C3%A7ais)).

While it doesn't break apart the components of addresses (something Open Cage Data's Address Formatting Project appears to be doing quite well), it does take care of the rest quite nicely.

Would love everyone's thoughts.

To quote from the overall description:

Who is on first?

For any hierarchy of place types we have identified three “classes” that any one of those place types can fall into. That doesn't mean there can't be others (classes or place types) only that these are the ones we've identified as a good place to start.

Common (C)

These are, well, common across any hierarchy for any place in Who's On First.

This part is important: It means that at some point every single record shares at least one or more common ancestors (for example a country or a continent or occasionally just the Earth). That doesn't preclude very specific additions to the hierarchy for a given location only that those additions need to fit within a common hierarchy shared across all locations.

Common-optional (CO)

These are meant to be part of a common hierarchy but may not be present because they aren't relevant or because we don't have the data. Counties are a good example of this.

Optional (O)

These are the parts of a hierarchy specific, typically, to a country or region. For example, the many nested "departments" in France or Germany. The only rule is that an optional (O) place type has to fit somewhere inside the common (C) hierarchy.

So the minimum list of place types for a hierarchy applied globally looks like this:

- continent (C)
  - country (C)
    - region (C)
       - "county" (CO)
          - locality (C)
            - neighbourhood (C)

A more nuanced version might look like this:

- continent (C)
  - empire (CO)
    - country (C)
      - region (C)
        - "county" (CO)
        - "metro area" (CO)
          - locality (C)
             - macrohood (O)
               - neighbourhood (C)
                - microhood (O)
                 - campus  (CO)
                   - building (CO)
                     - address (CO)
                       - venue (C)

[xlqian]

Personally, i will vote for the ordered list with admin_level in addition:

{
    …
    "admin": [
         {
              "type": "country",
              "name": "France",
              "admin_level": 1
         },
         {
              "type": "region",
              "name": "Nord-Pas-de-Calais",
              "admin_level": 2
         },
         {
              "type": "mycustomlevel",
              "name": "Nord"
              "admin_level": 3
         },
    ]
}