This section describes the key material, data sources, software, formats, and standards used in this geomatics research project (see Table 1); for more details, see Multimedia Appendix 3, Multimedia Appendix 4, and Multimedia Appendix 5. We combined French open data sources with a hybrid software ecosystem (open source and proprietary) for spatial analysis of mortality data. The technical architecture enabled seamless integration between free software and specialized proprietary solutions, perfecting the mortality and geomatic data-processing pipeline (see Figures 1 and 2).

Philcarto is French statistical data cartographic software specifically designed by a geographer. It implements Jenks natural breaks optimization directly on statistical tabular data, applying validated cartographic semiology rules (color palettes, class breaks) and natively producing Keyhole Markup Language (KML)–Direct output for subsequent use in other geomatic environments. Philcarto is the only tool in our workflow that simultaneously performs (1) statistical classification of Khi2LnFr, (2) Traffic-Light color encoding, and (3) KML export in a single, validated operation. It has been used in French academic geomatics workflows for more than 15 years.

QGIS is used exclusively for the spatial engineering step that Philcarto cannot perform: joining the Philcarto-classified KML attribute table to the French National Institute of Geographic and Forest Information (IGN) ADMIN-EXPRESS municipal geometry shapefile and converting the result to GeoJSON via the QGIS Model3 Graphical Modeler for reproducible batch processing.

This sequential, nonredundant use of both tools reflects their respective strengths: Philcarto for expert cartographic classification and QGIS for spatial data engineering and format interoperability. This division of labor is consistent with the multisoftware public health surveillance workflows described in the literature [68].

In addition, we used a number of other tools for specific functions. Google Earth was used to visually verify the data generated by KML-Direct, which was then exported in an indirect KML format (transformed) in the auxiliary optimization step. In Visual Studio (VS) Code, KML-Indirect files were manually inspected and converted to the GeoJSON format using the “View Map GDV 2.4” extension so that they can be read and processed by QGIS, also in the auxiliary optimization step. Mapshaper was used for GeoJSON file size reduction to meet the uMap server upload constraints during the auxiliary optimization step.

R, RMarkdown, and Excel were used for all statistical computations (SMM_10000, DENSI, Khi2LnFr) and to produce the ready-to-use input files for Philcarto. R scripts and RMarkdown programs are available in the public repository. SQLite was used for structured storage and querying of intermediate mortality tables during data preparation. See also Multimedia Appendix 5 and Figures 3-5.

This methodological approach consisted of 3 main parts: data architecture, step 1: geomatics without webmapping, and step 2: geomatics with webmapping.

The first goal was to present the software architecture, which includes a description of the data processing stages (Figures 1 and 2), including the data transformation diagram (Figure 2B). In this study, data management was an essential process carried out in different software environments involving data collection, cleansing, and ordering processes [71]; specialized concepts; processes such as geomatic data processing pipelines; databases; and the extract, transform, and load (ETL) process. We schematized our methodological approaches to enable better monitoring of data pipelines in step 1: geomatics without webmapping or step 2: geomatics with webmapping.

For step 1: geomatics without webmapping, the data pipeline diagram for transforming KML into a GeoJSON file is shown in Figure 3, and the schematics for processing automation in QGIS are shown in Figures 4 and 5.

For step 2: geomatics with webmapping, the resizing processing schematic in Mapshaper is shown in Figure 6. The double caption processing diagram in the computer-aided design (CAD) software and uMap is shown in Figure 7, and the thumbnail processing diagram in the CAD software is shown in Figure 8. Finally, Figure 9 presents the Photoshop processing automation diagram.

See Figure 1 for the software architecture of the mortality atlas for uMap.

All the data sources (Table 1) shared a common identifier: the 5-character INSEE municipality code (eg, 2A014). SQL was used to analyze and process the data in SQLite [25]. All the processing is automated except for one process that stays manual. A simplified data transformation diagram is shown in Figure 2.

The CSV data were imported into SQLite and combined to produce an “insee_death” table. An analysis of the fields (variables) indicated that days and months of birth were not systematically filled in. The age of each individual was calculated, except for those for whom the specific day or month of birth was not documented. The data were then aggregated by the INSEE municipal code, after which the following metrics were calculated: average age (excluding date of birth not provided), 2020 mortality, average mortality over the 2 years 2018 and 2019, and difference in mortality. The final stage in the process, as delineated in Figure 2, was the association of the death data with the reference 2017 municipal population. The database thus created, appointed “insee_death_pop,” was exported in CSV format. The reference structure of the data corresponding to the mortality variables is shown in Table 2 (see Multimedia Appendix 3 and Multimedia Appendix 4).

Several data preprocessing and statistical calculation stages were performed in R, Excel, and Philcarto. In the preprocessing stage (Table 3, line sections [1], [6], [11], [16], and [21]), the output file “insee_death_pop.csv” from Figure 2 needed additional preprocessing stages in R and Excel. These stages primarily entailed the incorporation of statistical variables and the addition and renaming of fields. The enriched death file (Table 3) could then be used in Philcarto and within the processing chain to instantiate atlases in uMap. Compared with the data presented in Table 2, the output file included modified, renamed, created, and reordered variables. The addition of suffixes to variable names enabled direct typing by Philcarto [34,35]. As illustrated in Table 3, the suffix _R_ appointed a report variable, whereas _N_ indicated a nominal variable. After the implementation of the R project program, the resulting XLSX output file had 24 variables.

In the statistical calculation stage (Table 3, sections a [25] and a [29]), Excel spreadsheets were supplemented with additional statistical variables, namely “raw khi-square” and khi-square with the logarithmic transformation “Khi2LnFr.” The methods for calculating these variables are described in the Computations of the Atlas Variables section. As outlined in Table 3 (line sections b [25] and b [29]), specific variables may have undergone renaming to align with the Philcarto file header standard. For example, the ratio variable “(Obs - Theo) ^2/Theo_Fr,” previously designated “raw khi-square,” was then referred to as “DENSI.”

At the Traffic-Light classification stage (Table 3, line sections [31] and [36]), a new series of Excel processes was used to classify the values of the variable “Khi2LnFr” to generate the fourth variable of the Traffic-Light Atlas associated with excess mortality in 3 colors and to create subnational maps in Philcarto via the variable “Excess Mortality_Traffic-Light_umap.” At this stage, the input file “insee.xlsx” was enriched with information variables such as “Excess Mortality_Traffic-Light_umap,” which was directly recognized by the suffix “umap.” This variable was used to interactively display the municipal tool tips (on hover) of the uMap atlas instantiations.

At the Philcarto software processing stage (Table 3, line sections [31] and [36]), the following files were presented as inputs to the software: spreadsheet-insee.xlsx (France as a whole; 34,833 municipalities online) and vectorial basemap.shp (georeferenced shapefile for the region or France as a whole) [34,35]. As an output, we obtained a first cartography associated with the 4 atlas variables, designated “SMM_10000,” “DENSI,” “Khi2LnFr,” and “Traffic-Light.” The Traffic-Light Atlas variable was named “Excess Mortality_Traffic-Light.” The available output formats encompassed Adobe Illustrator (AI), Philcarto macro language (PMC), Enhanced Windows Metafile (EMF), and KML (see Table 1). The KML format was georeferenced with the World Geodetic System (WGS) 1984–EPSG_4326 [53-56,59]. The KML format eased interoperability and started the processing chain in other software environments, with the aim of obtaining a ready-to-use map in GeoJSON format for the “uMapOSM.fr” remote server (Figures 1–3). Choropleth maps, also referred to as color-coded thematic maps, were systematically accompanied by a discretized legend that uses the Jenks method (see the Jenks Discretization section) [73,74].

Basemaps at the scales of the DROMs; large regions (grouped areas); and submunicipal districts of Lyon, Paris, and Marseille were created via IGN files (Table 1). The georeferencing process was executed in accordance with the WGS84 GPS standard [59], which culminated in the generation of a KML output map for use within CAD software (Table 1; Figures 1-3). The shapefile (SHP) files of France’s municipalities were divided into 4 major subnational municipality regions via the Éclats tool [35] due to limitations in vector file size. The basemap was augmented with one or more administrative boundary layers of greater thickness. The quantity of GeoJSON layers given by uMap was related to the number of choropleth maps displayed for each atlas. Finally, the Traffic-Light Atlas had a total of 12 GeoJSON layers, which included 4 large regions, 3 submunicipal districts, and 5 DROMs. For further information on map background engineering, please refer to the authors’ previous work [35,75].

To ensure comprehensibility, geomatic data-processing pipelines and workflows are presented in schematic form.

A nationwide French analysis was conducted for the mortality atlases under consideration, including DROMs, within a fine territorial grid of municipalities or submunicipal districts in Lyon, Marseille, and Paris. This approach supplemented existing studies that primarily used information from coarser grids [16].

Statistical calculations were performed with death data from INSEE to create 4 atlases (see Figures 1 and 2 as well as The Software Architecture: Geomatic Action Plan—Essential and Auxiliary Steps section) based on the following 4 variables: (1) “SMM_10000” variable relating to excess mortality and submortality, (2) “DENSI” variable relating to a raw Khi-Square (Raw Khi2), (3) “Khi2LnFr” variable relating to “Khi-Square Ln Fr”, and (4) “Traffic-Light” variable.

The Jenks method was used to create a map of the whole country for each variable, with a legend of 10 classes. The boundary values of the 10 classes were stored in a repository and used to create thematic maps of the same variable on a subnational scale, including 4 geographical areas (northeast, northwest, southeast, and southwest), administrative regions, submunicipal districts, and DROMs.

In Figure 6, a distinct shape is associated with each of the 2 types of information: diamond: processing and rectangle: input‒output result. See Multimedia Appendix 9.

Once the GeoJSON file had been imported into the remote OSM server of uMap, to address the complexity of the processing in step 2, the data pipeline was diagrammed (Figure 7; see Figures 1 and 2 for a reminder).

Figure 7 includes 3 blocks of procedures numbered 1 through 8. We started with a Philcarto file in EMF format. At the end of the chain, a double map legend was shown with a QR code in PNG format. These legends are on a remote server for univ-lille.fr and are associated with each GeoJSON map on uMap OSM-fr.

For more details about the 2 blocks of procedure stages 1-3, see Figure 8.

For more details about the Photoshop7 workflow legends with and without QR codes, see Figure 9.

Figure 12 shows a choropleth map accompanied by its corresponding single legend for the Traffic-Light variable. The map was augmented with a departmental boundary and presented on a French scale. The first lockdown linked to the COVID-19 crisis (March 1, 2020, through May 15, 2020) was covered.

Based on the Khi2LnFr variable, our statistical indicators were transformed into classes in the legend titled “Excess Mortality Traffic-Light.” The variable “Traffic-Light” represented the increasing excess mortality distributed across the 3 color classes. A fourth pale yellow color class was added to denote values that fall outside the Traffic-Light semantic range. The values in question were proximate to the mortality average or less than the average, thus indicating submortality. A total of 34,833 geographical units were incorporated into the map, excluding 6 municipalities whose population was determined to be zero. At the time of the study, the total population of France was 63,639,133. In total, 20,330 municipalities (20,330/34,833, 58.3%) were classified as outside the 3 Traffic-Light colors, and 14,503 municipalities (14,503/34,833, 41.7%) were assigned one of the Traffic-Light colors corresponding to excess mortality.

A total of 12,198 municipalities (12,198/34,833, 35%) belonged to the green class, in the range from “close to the average to 2 times above the average.”

A total of 1724 towns (1724/34,833, 5%) belonged to the orange class, in the range “2-4 times above the average.”

A total of 581 towns (581/34,833, 1.7%) belonged to the red class, in the range “4–11 times above the average,” which represented an extremely significant excess mortality rate.

An assessment based on a simple Poisson model confirmed the consistency of the red class with the expected 95% quantile exceedance, validating the robustness of the classification.

Below the classes in the Excess mortality_Traffic-Light legend in Figure 12 is a bar chart proportional to the number of spatial units (34,833) included in each modality of the variable. From left to right, the heights of the rectangles are 581 (1.7%), 1724 (5%), 12,198 (35%), and 20,330 (58.3%).

The map aims to signal to the observer immediately (visually) and simplify interpretation for the public via familiar semantics.

The uMap showcase includes examples of our atlases, which cover all of France and include DROMs. Three URLs provide access to these atlases [6,17,18]. There were as many double legends as there are imported GeoJSON layers. Atlas access and display times were relatively short: Regarding average page load times, the time measured for the first display (including layer toggles) was 1.5 seconds, and the full page load time was 5 seconds. However, loading into uMap was slower because of the display of the complete atlas, which loads GeoJSON layers at the municipality level for the major regions, submunicipal districts, and DROMs, representing 34,833 municipalities. Once the atlas was loaded, the navigation experience in the browser was smooth and without slowdowns. The dashboard allowed one to select and configure the desired display features, including tool tips.

From the uMap user interface, several functions and icons were accessible: zoom in and zoom out; search for place names; take a full-screen view; center the map on a location; measure distances; and select the desired “tile layer” basemap from those provided by the OSM, IGN, or National Aeronautics and Space Administration. The user guides for uMap are available at [6,14,50,82,83,86-88]. Printing atlases requires 2 stages: accessing the data sharing functionality and retrieving exported map data in GPX and KML formats (for printing purposes, see also other GIS or web services such as MyOSMatic [89]). Finally, uMap is an interoperable platform for exporting and printing maps on the basis of the API [11].

The uMap environment for the uMap atlas generated by Traffic-Light, France (Figure 10) consists of a 3-part window.

The first part combines the visual aspect of the France atlas with several tool buttons on the left of the screen. The main tool button manages and displays layers (GeoJSON maps) and searches for data via the “Browse data” link.

The second part of the screen, on the right, contains the legend tab showing double legends for each layer.

The third part of the user interface displays a banner with the map title, the designer’s name, and information about the ownership of the uMap environment [87].

Figure 10 shows the Traffic-Light Atlas from the first French lockdown. It includes departmental and regional outlines, as well as labels for the GeoJSON layers associated with the 4 subnational areas: northeast, northwest, southeast, and southwest. The atlas uses colors on the map to display excess mortality. Double legends allow comparisons between subnational and national distributions. Figure 11 provides additional information about the uMap atlas generated by Traffic-Light, by featuring a tool tip focusing on an enlarged view of the southwestern region of Bayonne town.

Two processing streams were generated for the uMap atlas generated by Traffic-Light, France (Figure 10). The first stream reduced the file size via Mapshaper to import the GeoJSON files to the remote OSM server uMap, whereas the second added a double legend (via a geomatic pipeline) to improve the visualization and statistical interpretation of the atlas.

The following URLs direct the reader to the atlases of the “SMM_10000” variable [17] and the “DENSI” variable [18].

Maps in the humanities and social sciences are the result of a process that is sometimes complex and involves a considerable amount of software (or system) and file formats with limited automation. This issue was identified in our data processing activities. The time required to generate atlases in uMap is significantly impacted by our complex, noninterconnected, geomatic data-processing pipelines. However, even in the absence of interconnection between systems, software programs themselves generate file formats that enable interoperability when they are transitioning between software environments [99].

Despite the problems highlighted, the results obtained through the implementation of the 2-step geomatic action plan demonstrate the efficacy of our approach, which uses licensed open-source software, free software, and licensed open data, as well as environments and functionalities tailored to our needs. These elements have enabled the full automation of certain tasks. The 4 weaknesses of the 2-step geomatic action plan are as follows:

uMap, a geomatic environment for collaborative map sharing, has been diverted as a medium for our choropleth maps and double legends representing the mortality atlases [11]. The nationwide Traffic-Light Atlas displayed in uMap has been deemed superior to the regional display (the online second environment [7]), facilitating instant interpretation of excess mortality statistical signals. The use of a municipal grid enhances the appeal of the atlas, allowing users to analyze specific municipalities. Preliminary observations suggest that no technical difficulties have been encountered when displaying the atlases through different web browsers. Building a parameter template via map cloning has been successful.

It is not possible to group atlases within a single uMap URL. New uMap features and updates since 2023 have caused errors in accessing our atlases. This issue was reported on OSM and GitHub [11-13] and was rapidly resolved.

We optimized workflows for GeoJSON layer creation in QGIS step 1 and double-legend creation and management in step 2. This section discusses the optimization of the double legends and the limitations encountered.

The Adobe Photoshop actions file format (ATN) script streamlined geomatic processing for double legends in Adobe Photoshop7 through macro recordings. This semiautomated process accelerated captioning and avoided manual errors. Captions were satisfactory, with or without QR codes. Ideally, newer Photoshop versions or nonproprietary free software would be used.

Batch processing can further optimize ATN scripts but is currently not possible in Photoshop7 because of persistent bugs. Incomplete macro recording with mouse or human-machine interaction limits the use of current ATN files. Editing ATN scripts in XML via JavaScript utilities on a Windows XP virtual machine may resolve this issue [101].

Maps can be hard to read without knowing the cartographic or graphical semiology background. Our atlas targets a wide audience of users (the public, health care, political decision-makers, and the uMap community) seeking relevant, more comprehensive information that can be communicated to everyone. Intuitive comprehension is paramount for capturing and maintaining users’ attention. The Traffic-Light Atlas is particularly clear, offering a comprehensive overview of the current situation for each municipality.

Although this is not an epidemiological article, this geomatics research project indirectly prompts an examination of the factors contributing to the observed variation in mortality rates across municipalities and districts, with some exhibiting high rates of excess mortality and others demonstrating low rates of submortality (reminder: the excess mortality in 2020 was compared with that in 2018 and 2019). The objective of our research was to provide these atlases at a highly detailed scale, ranging from the municipality to the submunicipal district and encompassing the entirety of France, including the DROMs. This approach enables each inhabitant of a municipality or district to assess its position in relation to its region, department, or national level.

Two epidemiological aspects emerged indirectly from our municipal mortality atlases for 2020. The INSEE data used are for municipalities, except Marseille, Lyon, and Paris, which use district data.

The first aspect is that the available and less biased municipal-level statistics on all-cause mortality (see Multimedia Appendix 2 on cartographic information bias) supplement pandemic-era aggregated data studies [16,103-107]. One additional limitation should be highlighted: singular cases of small municipal populations that distort mortality data.

The second aspect is the source of the death data and our approach, which is similar to that of France 3 TV. It consists of a comparative analysis of mortality rates with those of previous years and the municipal grid. According to France 3, “Even if the cause of death is not mentioned in the INSEE data, an excess of mortality, compared with the two previous years, can be an indication of the impact of the coronavirus, whose information has been aggregated at the departmental level. This is how we were able to measure, for example, the impact of the deadly heatwave in France in the summer of 2003” [106].

In addition to the initial version of the Traffic-Light Atlas presented in this study, we produced a second version covering 4 periods in 2020 (website published in November 2024 [7]). Owing to a minor statistical error in version 2 [7], our goal was to revise this version while reducing the software used in the geomatics data processing pipeline. This online version 2 of the atlas links 4 French policy measures to the 4 periods of 2020: from January 1 to February 28 inclusive (excluding the COVID-19 crisis), from March 1 to May 15 inclusive (first lockdown), from May 16 to October 28 inclusive (excluding lockdown), and from October 29 to December 31 inclusive (second French lockdown, less strict). The division into 4 periods facilitated a better analysis of the phenomenon (ie, the Traffic-Light Atlases for each period aligned better or more precisely with the policies implemented during the respective periods).

We began the first statistical exploration of new death data from INSEE on July 23, 2021. We noted that the methods used to collect deaths differed between our current version and the second version, which covered 4 periods. The statistics for version 2 showed that an “excess mortality statistical signal” affected 40% (13,944/34,833) of the municipalities. (Reminder: In version 1, the excess mortality statistical signal concerned 41.7% [14,503/34,833]).

Once the update to version 3 is complete, we will be able to compare the results of the atlases with those of health policies implemented nationwide. This will highlight the impact of effective policies and the more nuanced impact of others. We should cross-reference data on excess mortality or submortality with municipalities’ sociodemographic data. Comparing France with a neighboring country such as Belgium might be useful, but there are methodological obstacles to consider. The 4 periods of France and Belgium are out of sync [111], and it is unclear whether 2018 and 2019 are reference years.

Notwithstanding the disparities between Belgium and France regarding the covered time periods, it can be asserted that the methodology used in this study is applicable to any geographical area for which data on mortality (all causes combined) are available.

With and without webmapping, geomatic processing chains, such as the production of GeoJSON layers for the uMap Traffic-Light Atlas with “double legends and tool tips,” must be optimized. We also plan to improve how different environments work together. To do this, we could use (1) an ETL pipeline architecture consisting of proprietary software under different types of licenses and (2) a programming language such as Python, where libraries exist for most purposes [99,112]. In the short to medium term, the goal is to revise the atlases. As planned, we may switch to the R project to improve the reproducibility of the “geomatic data processing pipeline in step 1,” thereby eliminating the need for Excel, Philcarto, Google Earth, VS Code, and QGIS.

Digital advances and developers’ interest in geomatics mean that this challenge can be met by streamlining the geomatic processing chain and developing new mapping packages (in accordance with graphic semiology standards). These developers invite us to use the same software environment and R project to process all the data and generate maps; they encourage us to support reproducible cartography [74,110]. The “Cartography” package, now renamed “mapsf,” is more user-friendly, lighter, and more robust [73,74]. Our study’s methodological stages (data collection and cleansing-scheduling processes, analysis, and cartographic representation) could soon be followed and conducted in the same software environment to produce atlases, thus avoiding task dispersion and complications. In other words, this approach serves to unify the workflow and map reproducibility process. The R project could be considered an optimal choice for the geomatic data processing pipeline in step 1 without webmapping.

Reproducible cartography poses a challenge with respect to sensitive, regulated, or inaccessible health data. We cannot make health data available for cartographic reproduction, even for a designated health care community. This barrier is even stronger for nonhealth care communities. Nevertheless, new positive perspectives are emerging as “think tanks” made up of health care professionals [113] working to improve the reusability of health care data, particularly hospital data, for public health and epidemiological research.

We have demonstrated the value of the FOSS uMap [11], a collaborative and interoperable mapping platform that is experiencing rapid growth. By instantiating all-cause mortality atlases at the municipal level (covering the first lockdown in France), we demonstrated the potential of uMap by creating a new type of map in uMap: the choropleth map and double legends, which did not exist at the beginning of our atlas project. Among the atlases developed, we presented the main one in this study: the Traffic-Light Atlas. Owing to its strengths in terms of displaying and visualizing results, our France-wide atlas offers enormous potential in terms of attractiveness and usability (ergonomics) and in terms of understanding and semantic interpretation of cartographic and statistical results. This atlas is relevant because the instant message it conveys is easily interpretable by all audiences, particularly for the general public. In this context, existing maps related to COVID-19 have been supplemented by all-cause mortality Traffic-Light Atlas creation. In keeping with the concept of the uMap platform, our mortality atlases have been published within uMap and made available to users for sharing. The databases use open data from INSEE [84] and are based on a license not subject to the GDPR. To achieve the desired results, the uMap platform does not require any additional IT development or management of the remote uMap server (handled by OSM-fr).

This municipality-level interactive uMap atlas is designed to support both operational public health decision-making and retrospective quality analyses (Multimedia Appendix 2 and Multimedia Appendix 13).

First, local public health teams and municipal crisis management units can use the interface for situational awareness by continuously monitoring spatial and temporal variations in mortality across municipalities, identifying emerging mortality hotspots, and promptly targeting public health communications, resource allocation, and preventive interventions (eg, action protocols during heat or pandemic waves and reinforced medical screening during epidemics).

Second, quality assurance, epidemiology, and health information teams can use atlases to plan and prioritize retrospective audits by systematically flagging municipalities, time periods (version 1 or version 2), and excess deaths relative to comparable areas and atypical trends. These signals then guide focused chart reviews, audit investigations of clinical care pathways, assessment of local health system capacity, and verification of data completeness and coding accuracy in mortality reporting systems.

By providing fine-grained, geocoded mortality intelligence at the municipal level—a resolution not systematically available in routine departmental or regional dashboards—this application complements existing surveillance systems rather than replacing them and supports evidence-based public health action at the local level where resource allocation and outbreak response decisions are made (Multimedia Appendix 2).

When available, basic usage analytics characterize how different stakeholder groups engage with the tool uMap atlases in real-world practice.

For future use of uMap, it would first be legitimate, within the restrictive framework of health data, to create a private uMap platform dedicated to health [116]. Second, as part of an epidemiological approach, our mortality atlases are useful in the retrospective context of the pandemic. To improve our understanding of the municipal landscape, following the detection of excess mortality or submortality statistical signals, we could consider combining our results with sociodemographic data from municipalities. Third, a second version of the Traffic-Light Atlas, encompassing 4 periods in 2020, will be updated using either the “experimental choropleth layer” feature recently developed by the uMap team or, if this feature proves insufficient, the geomatic optimization process via the R project. Finally, for real-time crisis management monitoring, the uMap collaborative platform could be relevant because of its new “choropleth layer” feature and its overall active development.