Tile Schema Config Shortcuts

[james-rae]

Problem to Solve

Every config file has LOD arrays and Extent sets hogging up the space. Big problem. Yuge. Autoformatters love to expand out the data structures, making the LODs take up 4 screens worth of code. Unacceptable. Most of our configs (test samples, Canada maps) always have the same values always.

Current Schema

Tile Schema

• id
• name
• extentSetId
• lodSetId
• overviewUrl
• hasNorthPole

Extent Set

• id
• spatialReference
• default
• full
• maximum

LOD Set

• id
• lods[]
  • level
  • resolution
  • scale

Idea 1 - Defaulting Extent Set and LOD Set

We have some hardcoded / standardized IDs you can put in the Tile Schema to use our regular values without needing to define them in the config.

E.g.

"tileSchemas": [
  {
	"id": "EXT_NRCAN_Lambert_3978#LOD_NRCAN_Lambert_3978",
	"name": "Lambert Maps",
	"extentSetId": "DEFAULT_NRCAN_Lambert_3978",
	"lodSetId": "DEFAULT_NRCAN_Lambert_3978",
	"hasNorthPole": true
  },
  {
	"id": "EXT_ESRI_World_AuxMerc_3857#LOD_ESRI_World_AuxMerc_3857",
	"name": "Web Mercator Maps",
	"extentSetId": "DEFAULT_ESRI_World_AuxMerc_3857",
	"lodSetId": "DEFAULT_ESRI_World_AuxMerc_3857"
  }
]

If an author wants to use a different value (e.g. different extent set) they can define it in the config and reference the ID as usual.

Our config parser would need to know to look for the standard keys and get the values (hardcoded in RAMP core) before searching for the IDs in the config.

Idea 2 - Defaulting the Tile Schema

Essentially less flexible but more lazy than Idea 1.

Either add a new optional field to the Tile Schema called default that can have a hardcoded value, or we allow the hardcoded value in the id field. Regardless, our config parser knows to look for the hardcoded value, and will apply the full set of default values for that Tile Schema.

This idea allows the minimal config footprint (essentially a default app will have a 2 line array for the Tile Schemas). But if we want to adjust anything, we need to fully define all the parts in the config (the old way).

E.g.

"tileSchemas": [
  {
    "id": "DEFAULT_NRCAN_Lambert_3978"
  },
  {
    "id": "DEFAULT_ESRI_World_AuxMerc_3857"
  }
]

For this approach, we also need to correctly handle the language for the Tile Schema Name; should go in the main language resource to support extra languages.

Idea 3 - Fancy Defaulting the Tile Schema

Similar to Idea 2, but with enhanced config parser logic to allow select properties in the Tile Schema to be overridden.

Most flexible, most amount of coding of the Ideas.

E.g.

"tileSchemas": [
  {
    "id": "DEFAULT_NRCAN_Lambert_3978",
    "name": "I have decreed a non-default name"
  },
  {
    "id": "DEFAULT_ESRI_World_AuxMerc_3857",
    "extentSetId": "Toronto_Focused_3857"
  }
]

Wrap Up

All ideas would require good documentation in the schema and in the author guide.

Ideas 1 & 2 get lazy points.

Discussion in chat room has Idea 3 being the favoured approach