Restructure gazetteer "properties" object of a feature

[nickidlugash]

    "properties": {
      "place_name": "Enterprise South Nature Park, Chattanooga",
      "features": [
        {
          "data_layer": "road"
          "key:value": {
            "structure": "none",
            "class": "path",
            "type": "mtb"
        },
        {
          "data_layer": "landuse"
          "key:value" : {
            "class" : "park"
        } 
      ]
    }  

Next steps:

• evaluate how well the above structure would work upstream
• figure out what we want to call the keys that are currently named data_layer and key:value, based on: vector tile spec?

@dasulit

[nickidlugash]

@dasulit hmm, I'm just recalling now that I totally forgot to include the zoom key. We should probably figure out/confirm whether the current system (assigning a specific zoom level to a place) works. Another option could be assigning an array of values (maybe 0: optimum zl for QA, 1: min zl, 2: max zl)? I guess we don't have specific plans upstream yet as to what we might do with a min/max range, but it seems like it might ultimately be useful.

[dasulit]

I think a specific zoom level still makes sense for now! It keeps every gazetteer feature specific and narrow, which is great as a starting point for upstream Q/A needs. A single value makes a lot of sense for usage with the Static API, though I can see where a range might eventually make sense in a GL application.

[dasulit]

Here's the feature structure I've been playing with in carto-cam. It's principally the same as above, with some changes to vocab:

{
  "type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [-73.9933, 40.7298]
  },
  "properties": {
    "place_name": "New York City, United States",
    "zoom": 10,
    "highlights": [
      {
        "data_layer": "place_label",
        "data_layer_fields": {
          "type": "city",
          "scalerank": 0
        }
      }
    ]
  }
}

I like the organization of highlights, easy to work with in a detailed way 👍 I had some concerns along the way about this structure being less semantically comprehensible than the previous iteration, but I think the benefit of continuity with the vector tile spec and the accuracy of this system compared to categories in gazetter 2.0 outweigh the readability issues. Hopefully some level of abstraction can happen upstream!

@nickidlugash what do you see as the next steps to converting gazetteer to this model? From my prototyping, I fear the only way is by lots of handwriting. 😧

[nickidlugash]

Hopefully some level of abstraction can happen upstream!

I feel pretty confident in this approach 👍

I fear the only way is by lots of handwriting.

😬 @dasulit Ya, given the extent of the changes (and the fact that we should strip out less critical tags from the places to keep them more focused), it seems like writing a reasonable conversion script would take just as long as porting these by hand. I'm still happy to port the road features 👍

[dasulit]

@nickidlugash 👍 I'll be porting over at least the existing city (place_label) features and the landuse features today!

[nickidlugash]

@dasulit what do you think about including $type (aka geometry type) as an optional key in a highlight object? E.g.:

{
  "data_layer": "road",
  "data_layer_fields": {
    "class": "pedestrian",
    "structure": "none"
    },
  "$type": "Polygon"
}

[nickidlugash]

@dasulit Flagging that I've added an example of a highlights that has an empty data_layer_fields object:

{
   "data_layer": "building",
   "data_layer_fields": {
   }
 }

Is this accounted for upstream? We could add values but they would not be very meaningful. Some building features will have meaningful values to add, but some don't.

[dasulit]

@nickidlugash including $type could open up some options later on, we should include it!

I hadn't thought about what happens when we don't have valuable data_layer_fields 🤔 But I will think about it now. I think it should be ok for a highlight to not require data_layer_fields.

[nickidlugash]

Per chat with @dasulit we're adding 2 optional top-level keys:

• "description": explanation of that place's significance for design QA (string value)
• "use_case"/"starter_kit"/"collection" (name TBD): which starter kit(s) this place is a part of (array value)

[nickidlugash]

"use_case"/"starter_kit"/"collection"

@dasulit any thoughts on what to name this key? 🤔

[dasulit]

"Collection" is my favorite so far! "set", "series"?

[dasulit]

"compilation"? "edit"?

[nickidlugash]

@dasulit Perhaps "collection" and "set" are the most accurate descriptions for this key? Can you clarify what "edit" means in this context?

[dasulit]

@nickidlugash "edit" as a noun meaning something like "curation", but I think your instinct is right ("collection" or "set" are more accurate). Google's definition of the noun edit affirms that :P

[nickidlugash]

Per chat, going with "collection".

[nickidlugash]

Er, actually I guess "collections", since this is an array value.

[nickidlugash]

@dasulit here's the structure we've currently decided on for geojson features – does this look accurate?

  {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [0, 0]
      },
      "properties": {
        "place_name": "Some Interesting Place",
        "zoom": 16,
        *"sets": ["Auto Navigation", "Best Places Ever"],
        *"description": "Intersection that is difficult to navigate",
        "highlights": [
          {
            "data_layer": "road",
            *"data_layer_fields": {
              "class": "street",
              "structure": "none"
            }
          },
          {
            "data_layer": "road",
            *"data_layer_fields": {
              "class": "pedestrian",
              "structure": "none"
            },
            *"$type": "Polygon"
          }
        ]
      }
    }

* = optional key

Note: currently "data_layer_fields" is not optional, but I think we decided that it should be.

[nickidlugash]

...aaaaand switching from "collections" to "sets" to avoid any conceptual confusion with "FeatureCollection" 😬 Updated above comment.

[dasulit]

Looks awesome @nickidlugash Best Places Ever 😄 !

Nit you may have noticed, but just in case, sets, description, and the final data_layer_fields object are missing a comma at the end of the line.

[nickidlugash]

@dasulit ohh thanks, updated above 👍