wmgeolab / geoboundaries Goto Github PK

Both the ADM 1 and 2 layers for Nauru have large center holes. This problem with the data will need to be corrected in the next release with new shapefiles from open GIS repositories or digitized shapefiles from open source map images.

Uruguay is divided into 19 departments (ADM 1), and those departments are further divided into municipalities (ADM 2). However, holes exist in some departments where municipalities are not located, so there are holes in the ADM 2 layer. Due to this structure created by Uruguay's government, the best solution moving forward is likely to leave the boundary as it is.

FSM (Micronesia) has a disagreement across administrative levels. This is likely due to either buffering in the source data, or a mapping of water borders. As we only attempt to capture land borders, this is something we should look into correcting.

Hi,

Thanks for this great project. I wanted to know if it's possible to update the source for Mali.

I see that this dataset is currently used ( boundarySourceURL):
https://data.humdata.org/dataset/mali-admin-boundaries-level-1-2-and-3-including-2017-population-desagregated-by-sexe

but the official common operational dataset (COD) for Mali cleaned by ITOS and validated is this one:
https://data.humdata.org/dataset/administrative-boundaries-cod-mli

I didn't check the difference in terms of topology/geometry but in HDX data with the COD tags are usually the most accurate and the one the humanitarian use.

Thanks
Ahmadou

South African government is organized into a hierarchy of nine provinces (ADM 1), metropolitan and district municipalities (ADM 2), local municipalities (ADM 3), and wards (ADM 4). While ADMs 1, 2, and 4 encompass the entirety of mainland South Africa, holes exist in the ADM 3 layer. These six major holes (not including the hole where Lesotho is) are generally in the location of major cities such as Johannesburg and Cape Town, which indicates that this is likely an organization established by the South African government.

The United States Congressional Districts pose an interesting case because they don't necessarily align with the other ADMs in all cases, yet they serve as an important administrative division, especially when examining the country at a federal level. Thus, further research is needed to determine whether or not geoBoundaries should include these districts as a US ADM in the next release.

I've just answered a question on StackOverflow (here) about an issue someone was having uncompressing a zip file from your site https://www.geoboundaries.org/. The exact file was https://www.geoboundaries.org/data/geoBoundaries-2_0_0/NGA/ADM1/geoBoundaries-2_0_0-NGA-ADM1-all.zip. I've check other zip files on your site & they all have the same issue.

The fundamental issue is the filenames stored in the central-header and the equivalent local-header sections of the zip files should be identical. In this case they are not.

I'm seeing the central-header filename entries without any leading path components, the matching local-header entries do have a leading path. For example, geoBoundaries-2_0_0-NGA-ADM1-shp.zip in the central-header and release/geoBoundaries-2_0_0/NGA/ADM1/geoBoundaries-2_0_0-NGA-ADM1-shp.zip in the local-header

That means the zip files are badly-formed. See the StackOverflow write-up for more details.

There are a couple of implications with the zip files in their current format

1. The uncompression behaviour will vary depending on the unzipping utility used.
   The person reporting the issue on StackOverflow saw two different behaviours.

2. The zip file may get flagged as malicious.
   See here for details.

Looking briefly at the Python code in this repository it appears that zipfile is being used, I didn't think that Python would let you create a badly-formed zip file.

Is that how you are creating these zip files?

There are some small island chains that aren't well visualized in our preview images right now, as well as a few larger entities (i.e., France) that have far-flung islands they lay claim to. In the future, we would like to add insets into our automated procedures to mitigate this.

Gabon (from SALB) has a license issue we will need to either correct or fall back to an alternative source:

• SALB released a validated version of the 2nd level admin level for the January 2000-January 2006 period during its first phase of activity (2001-2011). This is the layer is the one accessible from the HDX
• The layer integrated into GeoBoundaries has itself been adjusted to correspond to the situation observed in the country since February 2013

Because the original dataset was modified, and we release standardized international boundaries, we will likely need to fallback to an alternative use. In this case, we also may consider an upstream contribution to SALB if we can get permission.

Alright - as we move towards a more structured set of data products, the way we engage with contested borders is going to mean we need to update some of our data products. Just to put this in one spot:

1. Our core high-precision single-country release will always reflect (to the best of our ability) each countries understanding of their boundaries. I.e., we want our Israel boundary to reflect what Israel thinks Israel is in this product.

2. In our single-country global standardized products, we'll be clipping to internationally recognized boundaries (starting with US Department of State, and adding the UN later on). In these products, boundaries will be reflective of the intersection between "what the UN says Israel's boundaries are, and what Israel says they are".

3. In our globally-contigious simplified, standardized product, we'll be first growing borders out for each country, then clipping to a nationally recognized standard (i.e., the UN). So, borders will be reflective of "What Israel says Israel is", + any land that the UN says they have, - any land the UN says they don't have (or US Department of State, depending on the baseline used).

With those notes, we will be working towards the following for 4.0:
-> Israel needs to be updated to reflect Israel + Palestine, rather than only Israel; this will not impact the Palestinian border in our stand-alone country datasets.

-> Other issues will be noted as they emerge here.

We want to move away from using Humanitarian licenses in our open set; AFG ADM0 eventually needs to be moved to Humanitarian release only.

AFG ADM 0, 1 and 2 have been moved to the authoritative and humanitarian sets; we need to identify an open AFG for gbOpen.

There are a few holes in the ADM 3 layer for the Philippines. These holes indicate the presence of lakes. It is important to acknowledge that these lakes are not represented as holes in the other ADM layers. This discrepancy may need to be corrected in the future.

Kyrgyzstan's administrative divisions consist of 7 regions and 2 independent cities for its first level ADM, districts (raions), then rural communities. There are many holes within the country due to its political history and geography.

Geographically, there are many holes from bodies of water that do not fall within a specific district. For example, the large hole is in the north-east due to Lake Issyk-Kul.

There also exist autonomous areas, enclaves, and areas owned by other countries within Kyrgyzstan. For example, the So'x District is an enclave of Uzbekistan surrounded by Kyrgyzstan.

Some areas do not fall under specific district jurisdiction. For example the mining town of Mailuu-Suu located in the Jalal-Abad region is considered an any district. Other examples are the four largest cities in the country which are Karakol, Bishkek (ADM1), Osh, and Jalal-Abad (ADM1). These areas cause holes within the ADM2.

Mailuu-Suu located in the red box

Iran's administrative hierarchy is divided into a system of provinces, counties, and further subdivisions. In ADM 0-3 layers there is a hole in the province of Tehran where the capital city of Tehran is located. The ADM 3 layer has other holes as well: these appear to be centered on the cities of Isfahan, Dehdasht, Mashhad. The ADM 4 layer maintains some of these holes present in the ADM 3 layer while containing other holes, such as those around Malayer.

These discrepancies present an interesting dilemma moving forward. There are two likely possibilities:

1. These boundaries are accurate and represent Iran's true administrative divisions.
2. These boundaries contain inaccuracies at some level.

Moving forward, more research will need to be conducted to discern the true nature of these holes. If these boundaries are indeed inaccurate, they will be replaced.

Switzerland is unique bureaucratically, giving a lot of autonomy to ADM1s. As such, each ADM1 is free to determine its ADM2 and 3s. This means that - in some cases - some of the ADM1s have advocated for 'skipping' the second administrative units, and only subset into ADM3.

There are two paths we could take here:

1. For those ADMs that 'skip' ADM2, move their ADM3s up to ADM2.
2. Keep the state definitions.

Lacking a strong argument for number 1 (which we think would be more confusing than helpful), we're currently leaving the holes in ADM2.

Update the website API examples - specifically, we now return direct links to images and geojsons, so no need for odd name replacements anymore.

The holes are attributed to its geography. Features such as Lake Tonlé Sap border multiple lower-level administrative divisions. In the future, we plan to improve our boundaries to dictate which administrative division each section of the features falls under.

China has holes in its shapefile because it is complicated administratively. For the first level ADM, it is divided into 22 provinces, 5 autonomous regions, and 4 municipalities, and 2 special administrative regions. However, in the second level ADM, holes exist in some areas where municipalities (ADM1) are located. In addition, some areas are noted as sub-prefectural cities, an unofficial designation, are right below the second level ADM, but not considered third level ADM. A combination of the sub-prefectural cities and municipalities account for the holes in the ADM 2 layer. Due to this structure created by the Chinese government, the best solution moving forward is likely to leave the boundary as it is as it would be inaccurate to report otherwise.

geoBoundaries CHN ADM2

Map with ADM2 listed. Those colored in green are not considered second level ADMs

A big goal of ours is to standardize every boundary in our database to a single license - the Open Data Commons. We're eyeing ~5.0 for this, but have a large hill to climb as there are currently hundreds of boundaries in our database that are not portable over. We'll add specific issue trackers for this in the future, but placing this issue here as a placeholder for now.

Svalbard is missing from our ADM layers of Norawy. Aiming to fix this one for 3.1.

Mongolia is divided into 21 provinces (ADM 1), and those departments are further divided into districts (ADM 2). The major holes that exist is due to the capital of Mongolia, Ulaanbaatar is governed independently and does not fall under the province it is surrounded by.

Ulaanbaatar (Ulan Bator) is broken up into three features surrounded by various districts

I'm trying to use the new geoBoundariesCGAZ-3_0_0 files but I'm finding different simplifications include/exclude different observations without clear rationale. This has been true for the couple of pairs i've checked.

For example:

> geoBoundariesCGAZ_ADM2_100 <- st_read("https://www.geoboundaries.org/data/geoBoundariesCGAZ-3_0_0/ADM2/simplifyRatio_100/geoBoundariesCGAZ_ADM2.topojson") #

> geoBoundariesCGAZ_ADM2_10 <- st_read("https://www.geoboundaries.org/data/geoBoundariesCGAZ-3_0_0/ADM2/simplifyRatio_10/geoBoundariesCGAZ_ADM2.topojson") 

> nrow(geoBoundariesCGAZ_ADM2_100)
[1] 113074
> nrow(geoBoundariesCGAZ_ADM2_10)
[1] 113070

> setdiff(geoBoundariesCGAZ_ADM2_100$shapeID, geoBoundariesCGAZ_ADM2_10$shapeID)
[1] "IRL-ADM2-3_0_0-B4911"  "IRL-ADM2-3_0_0-B8456"  "IRL-ADM2-3_0_0-B20054" "IRL-ADM2-3_0_0-B21132" "IRL-ADM2-3_0_0-B27172" "SVN-ADM2-3_0_0-B213"   "KWT-ADM2-3_0_0-B23"    "CHE-ADM2-3_0_0-B166"  
> setdiff(geoBoundariesCGAZ_ADM2_10$shapeID,geoBoundariesCGAZ_ADM2_100$shapeID) 
[1] "RUS-ADM2-3_0_0-B1719" "RUS-ADM2-3_0_0-B1789" "URY-ADM2-3_0_0-B55"   "URY-ADM2-3_0_0-B58" 

Mauritius has a large disagreement in our source data between the ADM0 and ADM1 boundaries. For a future release, we should attempt to identify an authoritative source. We also need to be specific in that we are mapping land boundaries, not sea, which may have other ramifications across our dataset.

In addition to the simplified release, as per the discussion in the referenced ticket we should eventually aim to create a single, unified release with all boundary information. We'll only do this in the simplified case to keep file sizes reasonable. Essentially, putting all ADM levels into one single file.

#5

We're observing what we believe is a topology error in the Canadian boundary for Newfoundland, which results in it being clipped out of our products. This will be a high priority fix, aimed for 3.1.

Armenia first level ADM are 11 provinces (marzer), WIth the second level ADM being municipal communities (hamaynk). The holes are a result of Lake Sevan located in the Gegharkunik Province,

Egypt and Sudan share a contested border to the Southeast (Halyib Triangle). In the individual shapefiles for each country, both countries should claim this space. However, right now:
EGYPT ADM0 - ADM3 all claim this space.
SDN0 does not claim this space, and should.
SDN1 does not claim this space, and should.
SDN2 does claim this space.

Change needed to close this is to ensure SDN1 and SDN2 both include Sudanese claims in the Halyib Triangle.

The holes are attributed to its geography. Features such as Lake Tana multiple lower-level administrative divisions. In the future, we plan to improve our boundaries to dictate which administrative division each section of the features falls under.

Ethiopia with OpenStreetMap base

There is some discussion around releasing a simplified version of geoBoundaries. As the core purpose of geoBoundaries is to focus on high-precision, open data, we would only do this as a secondary product.

We welcome suggestions as to algorithmic approaches for simplification, and will provide details on our discussions here.

One big challenge to multi-level administrative datasets is a lack of congruency between levels - i.e., a county on the edge of a state may be represented by a slightly different line than the state boundary. In 4 (..maybe 5.0), we would like to write checks to detect these errors, so we can begin the process of manually correcting them.

There are ongoing discussions with a number of users to examine the potential to create a global version of geoboundaries that enforces a single set of ADM0 boundaries.

We hope to select one set of ADM0 to use as a reference (i.e., UN; World Bank); conversations on this topic are ongoing and will be updated here as they move forward.

ADMs 1, 2, and 3 for the Philippines are all generally very similar, yet at a granular level the coastlines of these boundaries do not match in some areas. This issue is likely due to differences in data collection given that they all come from the same source. Newer and more standardized boundaries may need to be collected in the future.

The holes are largely attributed to its geographies such as the features Salt lake Uyuni, Laguna Coipasa, and Lake Poapo.

A terrain map of Bolivia

There are clear holes attributed to the geographic features

For the website, a walkthrough of the difference between simplified, high precision, and standardized would be helpful for new users. China provides a good case study of all of these cases, for future reference when we engage with this.

The following files create loading problems for SF
"geoBoundaries-2_0_1-CAN-ADM0.geojson" "geoBoundaries-2_0_1-CAN-ADM1.geojson" "geoBoundaries-2_0_1-CAN-ADM2.geojson" "geoBoundaries-2_0_1-CAN-ADM3.geojson" "geoBoundaries-2_0_1-CHL-ADM0.geojson" "geoBoundaries-2_0_1-GBR-ADM0.geojson" "geoBoundaries-2_0_1-HUN-ADM3.geojson" "geoBoundaries-2_0_1-JPN-ADM0.geojson" "geoBoundaries-2_0_1-NOR-ADM0.geojson" "geoBoundaries-2_0_1-NZL-ADM0.geojson"
"geoBoundaries-2_0_1-PHL-ADM0.geojson" "geoBoundaries-2_0_1-PHL-ADM1.geojson"

After a whole day of updating packages, R to 4.0, ubuntu to 20.0 I've been able to move from straight crashes to a printable warning of
"GDAL Error 1: GeoJSON object too complex, please see the OGR_GEOJSON_MAX_OBJ_SIZE environment option"

In R console this will work

> library(sf)
Linking to GEOS 3.8.0, GDAL 3.0.4, PROJ 6.3.1
> temp <-  "https://www.geoboundaries.org/data/geoBoundaries-2_0_1/CAN/ADM0/geoBoundaries-2_0_1-CAN-ADM0.geojson" %>% st_read()
Reading layer `geoBoundaries-2_0_1-CAN-ADM0' from data source `https://www.geoboundaries.org/data/geoBoundaries-2_0_1/CAN/ADM0/geoBoundaries-2_0_1-CAN-ADM0.geojson' using driver `GeoJSON'
Simple feature collection with 1 feature and 5 fields
geometry type:  MULTIPOLYGON
dimension:      XY
bbox:           xmin: -141.0181 ymin: 41.68144 xmax: -52.61941 ymax: 83.1355
geographic CRS: WGS 84
> 

In rstudio, it slows to a crawl because it's throwing thousands of warnings and usually fails outright.

I haven't resolved this problem yet but I wanted to flag it for others.

> library(sf)
Linking to GEOS 3.8.0, GDAL 3.0.4, PROJ 6.3.1

> sessionInfo()
R version 4.0.0 (2020-04-24)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04 LTS

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/liblapack.so.3

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C               LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8     LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8    LC_PAPER=en_US.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C             LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] sf_0.9-3

loaded via a namespace (and not attached):
 [1] compiler_4.0.0     magrittr_1.5       class_7.3-17       DBI_1.1.0          tools_4.0.0        units_0.6-6        Rcpp_1.0.4.6       KernSmooth_2.23-17 grid_4.0.0         e1071_1.7-3        classInt_0.4-3    

An interesting conversation has come up regarding SALB and HDX-sourced data, talking with both users and data generation.

The fundamental challenge we are (all) faced with is licensure - some boundaries (i.e., those released by UN OCHA on HDX) have 'fuzzy' license types that we would not want to include in the core geoBoundaries products in the long term - i.e., "For Humanitarian Use Only".

However, there is value to UN OCHA in a full dataset of UN OCHA boundaries + geoBoundaries global. From email exchanges, we also know there would be considerable value to other agencies as well.

What we're thinking is, looking forward to ~4.0, rebuilding our product line to look something more like this:

This would involve simplifying our own processes a bit in some ways (i.e., removing our formal release of the globally country standardized datasets), and adding new processes for the newer paradigms. We would also roll the simplified release into the geoBoundaries 'open' release, with an API flag for folk that only want simplified. The API itself wouldn't change except to add new options, so existing scripts should work fine after this shift (if we do go down this road).

As a part of this, we would also likely move the sub-releases into a different folder structure. I.e., right now:
geoboundaries.org/data/geoBoundaries-3_0_0/** <- contains 'core' / 'open' release
geoboundaries.org/data/geoBoundaries****-3_0_0/** <-- contains 'simplified'/'standardized' releases (etc)

this would become:
geoboundaries.org/data/gbOpen/geoBoundaries-4_0_0/** <- contains 'core' / 'open' release for 4.0.0
geoboundaries.org/data/gbHumanitarian/gbHumanitarian-4_0_0/** <- contains humanitarian release
geoboundaries.org/data/gbCGAZ/gbCGAZ-4_0_0/** <- contains CGAZ 4.0
geoboundaries.org/data/gbAuthoritative/gbAuthoritative-4_0_0/** <- contains the authoritative boundaries release

From a user perspective, the choice will now be between:

1. Best fully open (inc. commercial use) boundaries, in the gbOpen dataset.
2. Best humanitarian boundaries, as up-to-date as possible, in the gbHumanitarian. May have more restrictive open licenses.
3. Global composite & fully open, in gbCGAZ.
4. Best legal authoritative boundaries, possibly lacking full global coverage. Slow to update and may have more restrictive open licenses. May not be accurate because of political processes to create these taking a long, long time.

Hello,
I checked your data for Japan and it looks like the shapeName is missing.

Metadata details:

boundaryID JPN-ADM2-2_0_1-G286
boundaryISO JPN
boundaryYear 2017.0
boundaryType ADM2
boundarySource-1 OpenStreetMap
boundarySource-2 Wambacher
boundaryLicense "Open Data Commons Open Database License 1.0"
licenseDetail "Open Data Commons Open Database License 1.0"
licenseSource https://www.openstreetmap.org/copyright
boundarySourceURL https://wambachers-osm.website/boundaries/
boundaryUpdate 2020-01-16
downloadURL https://geoboundaries.org/data/geoBoundaries-2_0_1/JPN/ADM2/geoBoundaries-2_0_1-JPN-ADM2-all.zip

This is interrelated with
#2

This issue will result in a new globally valid version of geoBoundaries, with all ADM boundaries clipped to the US Department of State ADM0s. We are moving forward with the US DoS first, because they make their boundaries publically available on a semi-regular basis. This is pegged for 3.0.

We are planning on the creation of a 'nesting' ID for administrative hierarchies. This would only be released as a part of our global / unified data products (i.e., those that are designed to provide cross-country topological validity based on a third party ADM0 dataset). This would provide better compatibility with other products out there (like GADM).

Current thoughts on this:
A) For every administrative boundary less than ADM0 (i.e., ADM1 - ADM5), calculate the centroid.

B) If the centroid is not contained by the polygon, move the centroid to the nearest point that would be contained by the polgyon.

C) For each higher administrative boundary (ADM2 would search through ADM1 and ADM0, for example), identify the geoBoundary shapeID that the centroid falls within (i.e., "AUS-ADM1-2_0_0-B2"). This would allow lookups of the appropriate shapes at higher levels of the hierarchy.

D) Add this shapeID to a column indicating the ADM hierarchy it belongs to, and add one metafield for easier parsing - i.e., a row might look something like:

Column - Value
shapeID - AUS-ADM2-2_0_0-B2    
ADM1- AUS-ADM1-2_0_0-B3
ADM0 -  AUS-ADM0-2_0_0-B1
ALLADM - AUS-ADM1-2_0_0-B3|AUS-ADM0-2_0_0-B1                             

It was raised that the Benin layer we have from HDX is not congruent with the original license from SALB; it looks like it was released under an incompatible license on HDX itself. We will likely need to replace this layer in the short term.

Specifics:

• SALB has not yet released a validated, and therefore publicly available, version of the admin boundaries for this country
• The one generated during the first phase of SALB somehow ended up on HDX which should not have been the case and then in the GeoBoundaries dataset

Because we release our global standardized products, this would put us out of the licensure terms for SALB, specifically:

“The SALB dataset (codes and digital maps) is copyrighted. The owner of the data agrees on the use, reproduction, distribution, display, publication and dissemination at no cost to third parties of the SALB dataset, in any manner and in any form whatsoever, subject to the copyright and acknowledgement mentioned in the metadata. It is prohibited to change the contents of the database without consent of the owner. The SALB dataset is for non-commercial purposes only.”

The administrative divisions of Israel are broken down with 6 main districts for the first level ADMs which is further divided into cities, municipalities, and regional councils for its second level ADMs. Our data gathered from OpenStreetMap does not contain all the information of Israel due to ongoing conflict between Israeli and Palestine areas. This leaves areas outside of civil jurisdiction, however, more areas could be not listed or listed under jurisdiction due to ever-changing environment.

In addition, there are bodies of water within Israel that produce some of the holes.

Map of second leven ADMs of Israel with areas outside of civil jurisdiction

Things we'll include in the updated Readme -

1. Example Image
2. Citation Information
3. API information

Need to add the website code to this repository (www.geoboundaries.org).

South Africa has a disagreement across administrative levels. ADM 1 includes territory not encompassed in other boundary levels. This difference largely appears to be water boundary along the coastline, but there is a major difference as ADM 1 includes Marion Island while the other boundaries do not. Thus, the coastline of ADM 1 should be corrected while the other boundaries need to include Marion Island.

We intend to construct new zip files for individual administrative levels in the near future. Pegging this here to the 3.0 milestone.

A number of boundaries in 3.0 were simplified before inclusion into the "High Precision" dataset to facilitate our build (mostly for automated topology fixes); these simplifications were manually conducted to produce the best tradeoff between precision and computation. In 3.1, we will be re-releasing these boundaries in a full high precision (original) set. For reference, here is the set of boundaries this impacts for 3.0:

ADM0
NRU, PHL, ROU, VAT, AFG, AGO, ALB, CAN, CHE

ADM1
AUS, AZE, MDA, MUS, ROU, CAN

ADM2
AZE, BRA, CAN, CHE, COL, CYP, GBR, GEO, GTM, IRL, IRN, KOR, LVA, MNG, NZL, ROU, RUS, SAU, SWE, THA, TKM, TUN, TWN, URY, USA

ADM3
CAN, CHE, CHN, GBR, GIN, HUN, IRN, KOR, PAN, POL, RUS, SVK, TUN

ADM4
IRN, MMR, SVK

This is interrelated with
#2

This issue will result in a new globally valid version of geoBoundaries, with all ADM boundaries clipped to the UN ADM0s, retrieved from GAUL. Right now, we intend to use the 2015 GAUL boundaries, as they are the most recent we have available. We will plan on supporting future UN versions when / if we are able to retrieve updated UN boundaries.

In 2.0, we had two versions of Belgium ADM2 sneak through. We need to add a check to ensure that we don't have duplicate cases in the master releases. Planned for this spring (3.0).

A license issue was reported - we will likely need to temporarily switch to another source for Cape Verde. This is another instance of the layer on HDX being incorrectly released / re-licensed.

• SALB has not yet released a validated, and therefore publicly available, version of the admin boundaries for this country
• The same license restriction on modifying source data would apply (as in the Benin case, see #48).

In a future release, we would like to standardize the names of license granting agencies which we use frequently. For example, the Humanitarian Data Exchange is currently written in a few different ways (i.e., HDX).