WB boundaries db - to incorporate

[stufraser1]

WB sending us vector files - need to explore inclusion (replacement?) of GAUL location DB

[stufraser1]

Three things:

• resolve disputed territory issues 1: (show disputed as dashed in the right place according to WB layer)
• resolve disputed territory issues 2: Ensure J&K appear as disputed but as part of Inaida/Pakistan, not separate ADM0
• Ensure that by including WB boundaries, we can still show overseas territories separately (cannot show effectively in mapping window if all considered as one ADM0)

I've had a look at the layers, and I think the next steps are:

• Combine the WB ADM0 (g2015_2014_0) and disputed (g2015_2014_disputed) layers. At the moment, any disputed territory is not represented in g2015_2014_0. The two layers share the key fields for TH! spatial aggregation. GFDRR task

• Define what we have to do for ADM1/ADM2 level in disputed areas: Disputed areas are not represented in either the WB ADM1/2 layers, or disputed. This means that in TH! these areas will not be zoomable. I don't know whether the TH DB structure requires ADM1/2 for every ADM0, in which case we might have to combine disputed boudnaries into these layers, with a unique ADM1/2 codes, and use the name from ADM0. TBC - ask camptocamp.

• Add ESP and FRE versions of country names to the combined ADM0 layer. These exist in the GAUL adjusted-for-TH layers, in which we've previously been trying to adjust boundaries, names as flagged as error by users. These ESP and FRE fields drive the location search for those languages. GFDRR task

• Consider what happens with overseas territories. This affects the mapping extent, I think. I cannot remember how the mapping extent (which originally included all French oversea territories in a single window, so they were not readable. In the end a solution was found so France showed up on its own, but I can't remember whether that is because the GAUL data we use now separates Guadeloupe, Martinique, etc from France - so in TH! they are considered completely separate ADM0 units. This is not the case for WB ADM0, so I worry we will come up against the same problem as we had in the first development phase. I'll ping Ariel and see if he remembers what the solution was. TBC - ask camptocamp.

• Identify whether or not we can combine into the DB, the Geonames DB that ITS relies on for Operations Portal. If switching to WB ADM0 names, perhaps this isn't required. If still required, perhaps we can include a spatial match in the API, or leave this outside of our remit and let ITS fix up an automated process thhemselves outside of TH! - after all this is only required for the Ops Portal.

• Once the above are resolved, we can provide to camptocamp, and ask them to update the spatial DB used in aggregation process. hopefully it is not too onerous, given the WB attribute tables are largely the same as GAUL.
  Note: using the WB name will solve the Viet Nam / Vietnam issue - WB recognises it as Vietnam.

[stufraser1]

If resolved, should solve #788

[stufraser1]

Issues:

• Host WB official boundaries on TH basemap (correct shading, shows rivers, appropriate labelling for showing hazard levels
• Jammu and Kashmir to show in Pakistan and India
• Kosovo boundaries to show as determined by WB
• Nepal boundaries to refelct 7 provinces, not 5 (old boundaries)
• Resolve changes to any ADM codes due to change in data source
• Ensure overseas territories are shown separately in map window (influences zoom and visibility of data)

[stufraser1]

We have a new layer, which holds the potential to incorporate WB boundaries into the TH basemap, to show disputed boundaries.

A question remains over whether (or how easily) this new layer can be implemented in TH.
Currently, the map is implemented using Openlayers Javascript to access the style via a MapBox API URL + access key. The revised map (HTML file sent by email) is generated using MapBox GL JS, with the access key embedded in the code. @ErikKBethke has been doing the hard work on this and believes the most difficulty will be in executing the map.on('load') function when loading the maps on each page.

@fjacon Please can you advise on whether you could implement an HTML file using MapBox GL JS?
It remains possible that we could create a new style that TH accesses in the same way as the current method, but we've hit challenges in creating that so far, which has led to this long delay in implementation. The new approach, although requiring further development, may be the most efficient solution.

For the selection of locations and classification of hazard levels, we would provide a matching set of ADM boundary shapefiles to replace shapefiles we currently use.

[tonio]

I made some experiments & got something working with mapboxgl as baselayer BUT it is very slow, due to, among others:

• libraries download,
• some very large vector tiles (some are up to 2Mo in Indonesia) — I wonder what's wrong in the configuration —

Page size is multiplied at least by 3, and loading time by 2 in the test I ran today with mapboxgl & OL.

As there won't be interaction with the baselayer, it looks quite overkill to use mapboxgl for this. I would strongly advise to find a solution to be able to access image tiles directly usable in OL.

[vdeparday]

@tonio can you have a look at this layer: https://api.mapbox.com/styles/v1/gsdpm/civtq56ch000z2klqcuvgmzdw.html?fresh=true&title=true&access_token=pk.eyJ1IjoiZ3NkcG0iLCJhIjoiY2lqbmN5eG9mMDBndHVmbTU5Mmg1djF6MiJ9.QqFCD7tcmccysN8GUClW8w#1.61/1.3/-9.3

It should have only boundaries and labels as cleared by the WB cartographic team.

If it works, then @stufraser1 can you remove the boundary and labels from the basemap? And then we can display this service on top of the basemap.

Thank you.

[tonio]

Looks good.

It would be nice to have another layer without boundary & labels to test it before modifying the one in production.

[stufraser1]

Removed naming of countries and settlements of all levels. Boundaries were not included on this style.
Style URL: mapbox://styles/stufraser1/cjftf111617x32spjhncapgm2

[stufraser1]

Available and viewed on int.
Border shows well, however we are forced to use labelling in WB layer.
We need a balance of names in our basemap: adding back in state and city names, but keeping town names off (some are included in WB layer once you zoom in). Removed marine labelling from our basemap as these are included in WB layer. Hopefully that gives a better coverage of names for states and cities.

called THbase-balance, its here -- mapbox://styles/stufraser1/cjg85v8ry11j42rs78ktuee4j

testing INT layer - no labels in texas:

Current public layer - useful labels:

At closer zoom, a couple of town names appear in WB layer:

If we keep the town names in the current public TH layer then they will clash with town names in WB layer (Pasadena e.g.) - but we should keep the city name (Houston):

[tonio]

@stufraser1 do you need anything from our side on this ticket?

[stufraser1]

Can you integrate mapbox://styles/stufraser1/cjg85v8ry11j42rs78ktuee4j please?
It has a balance of naming that should be used, to get best result between the one now on INT and the one on PROD

[tonio]

I just switch to the new style on integration.

[stufraser1]

@tonio thank you for switching the layers. Having reviewed this, we need to revert to the previous baselayer without labels. There are too many clashes of labelling. Please revert to use the basemap .../stufraser1/cjftf111617x32spjhncapgm2

This can then be pushed to production

[matamadio]

Updated shapefile for admin boundaries have been loaded.