The following article is the ACTPLAN for upgrading Eoscala/Velkscala and Stadestér to a degree of relability. Eoscala contains historical GDP (PPP) statistics, whilst Velkscala and Stadestér act as bases for one another: Velkscala focused on global gridded population, and Stadestér focused on global urban population. All datasets are to be constructed at 1-year time intervals.
Note that due to significant faults, each of these datasets require significant wrangling. HALIENNE currently only covers the Timetable up to finishing Stadestér, with the rest being consiered relatively obvious.
Naissance/Gridmap.
In the future, a detailed Gridmap editor is to be built into Naissance using Maptalks as previously discussed, with each tab opening up a gridmap file. Each layer on the given gridmap file are actually separate .pngs with attached encoding functions as .txts, and .jsons for storing RGBA ID related data.
Each unique RGBA value can have a JSON object associated with it. There would also be the ability for a base reference layer with masks, the entire setup being similar to a raster painting application with extra steps.
Maptalks Visualisation.
Stadestér should come with a built-in Maptalks visualisation or web map for debugging that can be sorted by country and time period. This way, geolocators and any erroneous results could be fixed. Pins should be draggable such that they can be fixed, though this would have to be in a future version due to time constraints.
These steps should be followed in rough order such that Eoscala/Velkscala can each be released into a rough 1.0 state; specifically Eoscala 1.1/Velkscala 1.0. This timetable is still missing significant features, such as bringing up subadministrative scaling from Populstat, but it is hoped that a HYDE3.2 substratum can rectify most of these issues.
./output/velkscala/hyde_3.2) by running the following code:processHYDEASCToPNG(`<absolute_file_path>`, './output/velkscala/hyde_3.2');./output/archives/ to HYDE3.3../output/velkscala/hyde. Inspect base popc_ contents before calling adjustRastersFromMcEvedy().eoscalaGeneratePotentialEconomicActivityRasters();scaleGDP_PPPRasters();<city_name>, <wikipedia_jurisdiction_name> and take the first result that can be found. The .coords field should be borrowed from Chandler/Modelski/Populstat, and the name would be the same.
Reprocess Eoscala as suggested above after Velkscala is integrated with Stadestér.
Remember to clean stray popc_ pixels in Velkscala:
Remove any stray popc_ pixels BEFORE applying Stadestér.
Processing Hierarchy.
Make sure to properly digitise and process The Historical Atlas of the Eight Billion first, which we are using as a regional source. Proper measurements remain to be taken.
Stadestér is a historical population database of roughly 30 thousand real-world cities, gleaned from Chandler/Modelski + Populstat + Wikipedia and geolocated. The following methodology remains to be implemented:
The population density of a country's upper quartile of population gridcells can be used as a proxy for global urban density rank. This ranking has a Zipfian distribution, and can be so contrasted to rough global urban population density. Radial gridmap rings around the centre of a city can then be generated from the assumed area, and the pixels weight scaled until they equal the projected population for that ring. Velkscala can then be normalised back as seen in the Velkscala section to ensure correct urban cell populations. Note that these scalars should be exponential in the way they are allocated per ring such that they align with any substrata Velkscala pixels.
The way cities should be scaled is by scaling cities first, marking the areas within cities as being scaled in a boolean index array, and then rescaling the rest of the raster to fit previously known Velkscala population models excluding any true booleans.
Originally, Velkscala's planned processing hierarchy was intended to be quite different, with the following pipeline:
This is planned to be introduced in a future version, that likely being Velkscala 1.5.