Add country layers for administrative divisions in Arabian peninsula

[nickpeihl]

Fixes #224

The boundaries come from our Administrative Regions layer which is based on Natural Earth Data. I added Arabic names from Natural Earth Data when available and Wikidata.

To preview these layers, visit the links below.

• Bahrain
• Kuwait
• Oman
• Qatar
• Saudi Arabia
• United Arab Emirates
• Yemen

[kibanamachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[nickpeihl]

Alternatively, United Arab Emirates emirates or Emirates of United Arab Emirates or just United Arab Emirates? 🤷 😅

UAE is shorter and fits better in the ToC. See also USA States. But I can understand if we want to avoid shortening the name. Any thoughts @jsanz @kelastic?

[kelastic]

@nickpeihl thank you for your help with this.

UAE Emirates (with a capital E) makes sense to me, since it would be similar to USA States: https://maps.elastic.co/#file/usa_states

For https://maps.elastic.co/?manifest=testing#file/uae_emirates would it please be possible to add an Arabic label for "Neutral Zone"?

[nickpeihl]

@kelastic I did some cursory research on these "Neutral Zones" and they appear to be disputed territories with neighboring countries. From the worldview perspective of UAE, these are UAE territories. But they are de facto controlled by other entities.

Since this layer is only UAE territories, I'm considering merging these "Neutral Zones" into their respective emirates in UAE. We have already established a precedent for merging disputed territories into specific country layers such as the Kashmir region in India States layer and Taiwan in the China Provinces layer. To avoid topological inconsistencies, we will still maintain a separate opinionated worldview in the World Countries and Administrative regions layers.

Do you agree that we could include these disputed territories as part of UAE?

[kelastic]

@nickpeihl Yes

[kibanamachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[jsanz]

Changes look OK to me, thanks for documenting the procedure in the Makefile scripts 👏

I have only a question. The CSVs info that adds the Arabic names is coming from Natural Earth, OSM or Wikidata? If the last we need then to add the proper attribution.

Thanks!

[nickpeihl]

I have only a question. The CSVs info that adds the Arabic names is coming from Natural Earth, OSM or Wikidata? If the last we need then to add the proper attribution.

Arabic names come from Natural Earth or Wikidata. I'll document this. Thanks.

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[nickpeihl]

@kelastic do you mind doing another review of this when you have time?

[kelastic]

@nickpeihl I noticed that the English names used for Bahrain (and two for Qatar and one for Yemen) make heavy use of diacritics, but the others do not use diacritics. I'm not saying that this is wrong, but rather I'm asking if we are being consistent with the Romanisation of Arabic place names?

[kelastic]

@nickpeihl Also, will using diacritics make it more difficult to search for these English names, if the user's keyboard does not have these diacritics easily available?

[nickpeihl]

@nickpeihl I noticed that the English names used for Bahrain (and two for Qatar and one for Yemen) make heavy use of diacritics, but the others do not use diacritics. I'm not saying that this is wrong, but rather I'm asking if we are being consistent with the Romanisation of Arabic place names?

The Romanisation is only as consistent as the upstream data source which, in this case, is Natural Earth. With few exceptions, our precedent is to keep as close to the source data as possible. This makes it easier to apply updates automatically.

That said, I'm not opposed to making exceptions. But I would prefer to rely on a definitive purpose for going against precedent.

@nickpeihl Also, will using diacritics make it more difficult to search for these English names, if the user's keyboard does not have these diacritics easily available?

Are you asking about searching in Elasticsearch? The default standard analyzer could be used to search without requiring the user to type diacritics. I have an example below that you can copy and paste into the Dev Console in Kibana.

Click to expand demo

PUT qatar_test
{
  "mappings": {
    "properties": {
      "label_en": { 
        "type": "text", 
        "analyzer": "standard"
      },
      "label_ar": {
        "type": "text",
        "analyzer": "arabic"
      }
    }
  }
}

PUT qatar_test/_doc/1
{
  "label_en": "Ash Shīḩānīyah",
  "label_ar": "الشحانية"
}

GET qatar_test/_search
{
  "query": {
    "match": {
      "label_en": {
        "query": "Ash Shihaniyah"
      }
    }
  }
}

[kelastic]

@nickpeihl Thanks for the clarifications. I agree with you, let's keep things as they are currently.