Analytical hierarchy process tool in Google Earth Engine platform: a case study of a tropical landfill site suitability

Kolkata being a metropolitan city in India has its main municipal solid waste dumpsite situated at Dhapa just adjacent to the East Kolkata Wetlands (Ramsar site). The current prevalent situation at Dhapa is open dumping leading to various contaminations and hazards putting forth the need to look for alternative sites where the landfiilling operation can be shifted to using scientific methods. A user interface (UI)–based analytical hierarchy process (AHP) tool has been developed within the Google Earth Engine (GEE) cloud platform to find out the alternative dumping sites using geospatial layers. AHP function is not available as a native algorithm or developed by any researcher in GEE. The tool has three major functionalities, of which the first one handles the UI elements. The AHP procedure is within another function, and the last function integrates the AHP coefficients to the layers generating the final suitability layer. Users can also upload comparison matrix as GEE asset in the form of CSV file which gets automatically integrated into the AHP to calculate the coefficients and consistency ratio to generate the spatial suitability layers. This approach showcases a generalized AHP function within the GEE environment, which has been done for the first time. The tool is designed in the cloud platform which is dynamic, robust and suitable for use in various AHP-based suitability analysis in environmental monitoring and assessment.


Introduction
With the remarkable advances in the Earth Observation (EO) data acquisition techniques and plenty of EO missions, the quantity of Remotely Sensed (RS) data has been increasing from exabyte to petabytescale every year. Some of the RS data repositories are USGS Explorer, Bhuvan, NASA's portal. In view of the present and future mission, much higher spectral, spatial or temporal resolution sensors would probably generate data of higher dimensionality. On the other hand, planetary-scale applications in Earth science or environmental studies may inevitably aggravate the complexity of data and its processing. Therefore, RS data have been accepted as Big Data not only because of the extreme data volume but also Abstract Kolkata being a metropolitan city in India has its main municipal solid waste dumpsite situated at Dhapa just adjacent to the East Kolkata Wetlands (Ramsar site). The current prevalent situation at Dhapa is open dumping leading to various contaminations and hazards putting forth the need to look for alternative sites where the landfiilling operation can be shifted to using scientific methods. A user interface (UI)-based analytical hierarchy process (AHP) tool has been developed within the Google Earth Engine (GEE) cloud platform to find out the alternative dumping sites using geospatial layers. AHP function is not available as a native algorithm or developed by any researcher in GEE. The tool has three major functionalities, of which the first one handles the UI elements. The AHP procedure is within another function, and the last function integrates the AHP coefficients to the layers generating the final suitability layer. Users can also upload comparison matrix as GEE asset in the form of CSV file which gets automatically integrated into the AHP to calculate for the complexity and variety the data gives rise too (Wang et al., 2019). The incorporation of Big Data analytics and Cloud computing to facilitate largescale scientific applications has revealed an easy-touse approach to the extreme computational and storage challenges. This is hugely beneficial because now anyone can view and process those data without owning costly and powerful hardware.
One such example is Google Earth Engine (GEE) which is the backbone of this study. GEE is a cloudbased service that is free for research purposes without downloading and managing data locally (Gorelick et al., 2017). Google cloud-computing infrastructure is the backbone of the platform, and Google itself handles computations. All are automatically performed on the CPUs and GPUs of Google (Gorelick et al., 2017). Since GEE was mainly developed and optimized for analysis on geospatial data, it can process large amounts of RS data in large geographical scales and long temporal coverage (Ravanelli et al., 2018). Thus, it is a great tool for analyzing regional or global-scale applications. Various datasets are already available within GEE, and users can also easily upload and use their own datasets and scripts to generate the products on the fly (Kumar & Mutanga, 2018). GEE stores and analyses RS imagery based on a pyramiding and tiling concept (Fuentes et al., 2019). Every image imported into GEE has its own pyramids at different resolutions, making the processes and visualizations much faster and smooth (Gorelick et al., 2017). Every function and option within GEE processes images on 256 × 256 tiles. Different scales of the pyramid are used at different zoom levels enabling GEE to process and show large areas of processed images quickly and efficiently (Amani et al., 2020). Pyramid representation means to break down the input image into multiscale representation which provides a series of residual images and one approximate image. This process provides access to the enhanced image features of various sizes (Kaur et al., 2020). GEE is a prime example of cloud computing with many inbuilt/native functions and commands that make it very simple to code. GEE has a lot of workedout examples and an active community. The best part is that even though GEE is based on programming, which might seem daunting at first, it uses JavaScript (JS) and Python script which are very established and mature discipline. GEE has many inbuilt functions and datasets, but the Analytical hierarchy process (AHP) which is a function widely used in different decision-making problems (Saaty, 1980;Alanbari et al., 2014, Acharya et al., 2019, Alkaradaghi et al., 2019 has not been implemented as a native algorithm or developed by any researcher. In the present study, the AHP method has been developed in GEE environment using JS. The user needs to provide the CSV files containing the pairwise comparative scoring values as GEE asset, and the code will automatically put them in the matrix calculation of AHP and calculate the individual weightage coefficients. These coefficients are then used to process the associated layers and ultimately provide us with a map highlighting the suitable sites located within the stipulated area of concern. Landfill suitability analysis as a case study has been taken up in the present study to highlight the technological prowess of GEE which may further help other environmental applications based on AHP.

Tool development
The whole AHP method was developed within the GEE environment using JS (Fig. 1). Separate functions have been set up for import of dataset, AHP process, display the results and UI components. The development and work have been described in the following sections.
General understanding of AHP procedure The AHP being a well-known form of Multiple-Criteria Decision-Making (MCDM) is an effective and established tool to deal with decision making, which are complex in nature. It might help users set their preferences and make the best decision (Saaty, 1980). AHP helps to provide both subjective and objective parts of a decision by reducing the said decisions to a group of pairwise comparative values. On top of this, AHP incorporates a useful method to check the consistency of the users pairwise comparative scoring, thus reducing the tendency to be biased while carrying out the decision-making process. The AHP at first considers a set of main criteria. Each of these will have alternative options from which the best decision can be made. First, a weightage for each criterion is generated according to the user's pairwise comparisons. A higher score to that criterion means its importance is greater as compared to the other ones. Next, for each criterion, a score gets assigned to each option according to the user's pairwise comparisons. Lastly, the AHP process combines the weightage for the criteria and the scores. This provides a global score for each option and a respective ranking. The global score for an option is a weighted sum of the scores it obtained with respect to all the criteria. The values of (a ij ) when (i = 1, 2, 3, …, m) and (j = 1, 2, 3, …, n) are used to indicate the performance values in the rows and columns of the matrix. Here, a ij is the element of the row (i) and column (j) of the matrix. A typical comparison matrix for the criteria is represented as follows in a matrix formation: The eigenvectors for each row gets calculated. It is done by multiplying the value for each criterion in each column in the same row. The matrix to be considered is the original pairwise comparison matrix and not the normalized one. Then those are applied to each row. This is shown as below (Saaty, 1980): where i is the eigenvalue for the row (i) and n is the number of elements in row (i).
Normalizing the eigenvalue to 1 (divided by their sum) gives the priority vector or AHP weight (Saaty, 1980), as follows: The maximum lambda (λmax) or maximum eigenvalue is obtained from the summation of products between the sum of columns of the reciprocal matrix and each component of the priority vector, as shown in the following formula (Saaty, 1980): Here, a ij represents the criteria in each column in the matrix, and W j is the value of weight for each criterion corresponding to the priority vector in the decision matrix.
As stated before, AHP incorporates a technique to check the consistency for the evaluations made by the user when creating each of the pairwise comparison matrices for the process. The technique provides the computation of a suitable consistency index (CI). The consistency index gives the equivalent of the mean deviation of each comparative element and the standard deviation of the evaluation error from the ones that are true. This can often turn out to be larger than the value describing a fully consistent matrix in order to provide a measure of severity of this deviation (Saaty, 1980).
where CI is the consistency index and n is the size or order of the matrix.
The consistency ratio (CR) is found by dividing the consistency index value (CI) by the random index (RI) value, and n being the size of the matrix. Table 1 shows the mean random index value RI for a matrix with different sizes (Saaty, 1980). A perfectly consistent decision-maker should always obtain CI = 0, but small values of inconsistency may be tolerated.
If the ratio between CI and RI (CR) is greater than 0.10, the user has to re-evaluate his/her initial scoring input. If less than 0.10, then consistent values will be generated as the ratio value goes lower.
There can be any number of criteria that can be taken into consideration for the procedure of landfill site selection. But the following criteria were taken based on the location, datasets availability, and importance (Chabuk et al., 2017). Further study using these criteria is also possible, as is adding more criteria.

Implementation of AHP in GEE
GEE provides an integrated database that is easy to implement and work with, can be easily integrated or called into user codes, and requires no additional effort except an account. This database was extensively used within the code; various functions that are natively supported were also used a lot for developing the AHP procedure. The whole coding was done using JS code editor (Fig. 2).

Functions and algorithms
The elements that can be called functions, algorithms, layers, and other entities are all server-side elements. These can be included within codes by using ee.
Number for some number calling, ee.Array for arrays, or ee.Image for image or image collection from GEE datasets. The interactive UI is what greets the user once the code is run. It includes information over each input box, which has been implemented using ee.Textbox, telling the user what to input, default values have also been set where required using "if" conditions along with checkboxes (ui.Checkbox) to activate or deactivate "region selection" and "suitability layer download" functions. The pairwise comparative scores for both criteria and sub-criteria need to be input into a CSV file; then, uploaded within GEE as an asset, the corresponding asset IDs need to be provided in their respective input boxes along with the criteria names. The code simply uses.getValue command to extract the input data from the asset ( above mentioned CSV file) linked in the textbox by the user. A sample CSV file is also linked for example purpose. The button just below the criteria name input boxes is used to check the CR value for the criteria which also displays a message box in the Map UI telling the user if the CR is less than or greater than 0.10. This button, implemented with ui.Button function, calls the AHP function, which extracts the user inputs data from the criteria CSV file, puts them inside the matrix calculation procedure, and finds the coefficients for each of the input layers. This is then passed on to the layers in another function where the coefficients get multiplied with the layers and added to generate the suitability maps. Besides these commands like ui.Panel for UI panel creation, ui.Label for typed lines within the UI was also used, as discussed below.

GEE layers and datasets
GEE data catalog and the option for user imported layers is one of the main reasons that make GEE so comprehensive. GEE has long-term datasets of different sensors and models' outputs, and those are updated regularly. GEE database was used to include layers like slope, temperature, precipitation, population, and land use into the code using native commands like ee.ImageCollection and ee.Image within the first function. Any function or command starting with "ee" is termed a proxy used to manipulate or use objects from the server-side of GEE being with the client-side. These layers that are natively supported within the platform make it very easy to implement.
One can also import and use user-defined or created layers in either raster or vector form for data that are not covered within the GEE database. There is also support to convert vector to raster within GEE, which was also used. For example, layers like roads, water bodies, protected zones, geomorphology, and groundwater were all externally created and ingested into GEE as assets and converted those vector layers into raster layers. The first function also handles the AHP calculation for the reclassified values or sub-criteria for the individual criteria, wherein the ranges or reclassified values are scored from 1 to 9 based on their relative importance in a similar fashion as that of the main AHP function as below. The data sources for each layer have been given in Table 2.
Here, for each sub-criteria, a coefficient from the sub-criteria AHP calculations is obtained. These two need to be multiplied to get the final output for each layer. But simple.multiply would not work directly as the coefficients are arrays and the layers are images. To combat this, the array values were converted to images which were then ready to be multiplied. But the output still needs to be reclassified. This was also done here using.gte, .gt, .lte, .lt, and .eq functions as required to provide ranges that are used to classify the layer. The ranges for reclassification were so chosen to have a better variation of the criteria within the area of interest, but can be changed as per the need of the user within the code. After the reclassification, the array converted to the image was multiplied by the imported layer. This was then added to the map or display using map.addLayer. Colour palettes were also chosen as well as the mapped output was clipped to keep the result within our area of interest. As stated earlier, vector to raster conversion was done within GEE for the user imported layers. Four layers of slope, temperature, precipitation, and Land use were imported directly from GEE datasets. More specialized layers like road, water body and protected zone proximities, groundwater layer, and geomorphologic layer were imported as assets into GEE, which shows the flexibility of GEE using users to import layers of their choice in various formats. All of these layers are then added together to make one single layer to be displayed in the map view as the suitability layer.
The second function handles the AHP, wherein the user inputs are accepted into the code as CSV files; these are then passed onto the different variables via parseFloat() function to convert the accepted string into returning floating-point number. Inputs or data taken from the user using ui.Textbox are all in string, so no mathematical calculations can be done while the data is in String format. To solve this, parseFloat, a native JS command, was used, which parses the string input and returns a floating-point number with which further operations can be done. The reciprocal of these criteria scores also need to be present in the CSV file. All of these are then put into an array with ee.Array function to bring the matrix formation 1 3 Vol.: (0123456789) of AHP in the code, numbers in the upper triangular matrix being the inputs, diagonals being 1, and numbers in the lower triangular matrix being the reciprocals of the user inputs. These are then sliced up or separated from the above array into individual arrays so that the calculation can be done using each separate numbers. GEE provides many client-side libraries to be included into codes and expand the usability. These were used extensively throughout. Within the AHP function, functions like .add, .divide, and .multiply were used to do the whole operations on the different Arrays. So within the AHP function, we get different coefficients as outputs for each of the layers or criteria. The CR acts as the accuracy check to assess if the inputs are optimized or not. These are then passed onto all the other main functions to be used in those. It is necessary to pass the value of one computed variable from one function to another function to be used further.
Next comes the function that handles the UI operations. This has been made with wide usability and user-friendliness in mind. The user will be able to get the suitability layer with minimum input. With the inclusion of the CSV input method, the usability has been simplified further. The user can download the CSV template file, make two CSV files for criteria and sub-criteria respectively, upload, and provide the asset IDs within the UI. The code handles the rest. The important headings have been highlighted in bold letters and clear instructions. All the imported assets used in the study have been made accessible to all.
There is also a tertiary function which is mainly for convenience purposes during the coding and debugging stage. It handles all the printing of various variables from the AHP function, mainly into the console.

AHP and its implementation
AHP is the backbone of the whole operation wherein it is being used to evaluate the possible outcomes from among the input layers according to the pairwise scoring being provided by the user according to their priority or decision. The AHP procedure or function that has been created here within GEE using native functions or commands. The whole system of the user inputting the comparative scores through CSV files, using those to run the AHP and providing coefficient values with CR value for accuracy checking, has been done exclusively within GEE. It is currently working with nine criteria in the present study, but in the future, it can easily be adapted for more than that, simply by slightly customizing the current code. The process has been kept simple and to the point in which the AHP function first calls the raster layers and pairwise comparison values as input from the user and transforms them to the array. These are then run through the whole process of AHP calculation in the matrix format, and the coefficients, CI, and CR values are generated accordingly. These are then called into other functions for further processing to generate the suitability layer.

JavaScript (JS), client and server sides of GEE
The client libraries section is the API reference for both JS and Python clients. The code editor section handles functionality available throughout the online IDE i.e., Earth Engine code editor for JS and the REST API section which handles the Earth engine restful API. The use of JavaScript Object Notation (JSON) architecture for receiving the computed data from the GEE server to the user console, JS, is being used throughout the coding process, and it becomes necessary to differentiate between JS and GEE objects. The server handles the calculations, and the client-side simply calls that answer or result, which gets to the user in JSON format, which is a format for storing or transporting data. JSON is often used in JS to send data from the server-side to the clientside, which is happening in this code. JSON is a datainterchange format, lightweight, easy for humans to read and write, and also easy for machines to parse and generate. GEE has two sides or formats, client and server sides. It is best not to intermingle them. But one can use proxy objects on the client-side to manipulate server-side objects. Anything starting with "ee" is a proxy object which does not itself contain any data, but it helps to call or use server functions within the client-side, like ee.Image, ee.ImageCollection and ee. FeatureCollection. So accordingly, server-side data like maps, datasets, and algorithms that were to be included were called as above into the client-side, the GEE code that was developed. Within the AHP function, ee.Array function was used to access the array functionality from the server-side and further mathematical operations were done.

UI development in GEE
The UI is simple with a minimalistic approach. The first input box asks the number of criteria from the user; the next two textboxes accept the Asset IDs for the two.csv assets that need to be uploaded by the user containing all the comparative scores for the criteria and sub-criteria. The next 9 text boxes will have to be filled with the names of the 9 criteria that are within the header of the sub-criteria CSV file. Then, all the user has to do is click on the button below to run the main AHP function to check the CR value. The CR check dialogue will be visible in the Map UI; next, the user can opt for ward wise visualization or whole area for the suitability map layer along with a download function. GEE is the environment where one can do the coding, edit it, call datasets, do spatial calculations, and visualize the outputs. GEE apps provide an effective and easy way to publish our finished codes with individual URL for public access. With apps, users can use simple UI elements to access Earth Engine's data catalog and computational power. Anyone can type in the URL and visit a webpage containing the code with the designed UI visible and mapping area; the user simply gives the input and clicks on a button to get the processed output result. The processing is totally handled by GEE running in the background, as the webpage is just a frontend to the codes written in the GEE code editor in the backend. In our case, too, the UI has been designed to be as minimal and user friendly as possible having input boxes with clearly written information on top. Users can interact and input the required data and get an output which can be map data, numbers, graphs, etc. as the coding was done. In the present case, when the user chooses the number of criteria they want to include, input the pairwise comparative values and just click on a button below the UI and the AHP procedure will give the weightage values based on the input, and these will be applied to the number of criteria selected as layers and then that suitability layer will be generated.
A panel was created using ui.Panel to hold all the front end elements and then within it messages and texts were displayed using ui.Label along with styling options. Next, an input box was provided where the user can provide the link to the CSV asset containing the comparative scoring for all the criteria. The command ui.Textbox was used extensively to create the input boxes along with styling options. At the end of the panel, a button is present, which when clicked calls the AHP function. This function accepts the inputs from the CSV asset provided by the user and further calculations proceed. Here, the panels, widgets, input boxes, and buttons are all created. Next, GEE gives us functions and commands to create a front end, accept user inputs, and make and display buttons that when clicked trigger or call a part of the coding; these were all implemented in this study. Besides these, charts, checkboxes, sliders, and many more options are also available to the user.

Analysis of AHP outputs
Kolkata Municipal Corporation handles a maximum of the total MSW generated daily within Kolkata, about 3500-4500 MT/Day. Dhapa disposal ground (Fig. 3) is located on the fringes of the East Kolkata Wetlands and covers a total area of approximately 35 ha, out of which 12.14 ha is the old dumping ground that is closed off and turned into a green zone. The remaining 23 ha is in use at present for the daily disposal of collected MSW from and around Kolkata (KMC, 2010). This disposal ground at Dhapa is an ecological and environmental hazard (Kim & Owens, 2010;Matejczyk et al., 2011;Paoli et al., 2012) has long been abolished but still underuse (KMC, 2010;WBPCB, 2015). The dumping has led to contaminated water bodies (nearby fisheries), soil (Ali & Ahmad, 2019) and affecting the people living in the vicinity of the dump. So even though it is high time to look for viable alternatives and shift to that, in turn, closing this landfill site, KMC is still using it (KMC, 2010).
MSW Landfill suitability within the vicinity of Kolkata city was taken as a case study to find alternative/additional landfill location of Dhapa Landfill. The developed tool in GEE is being used to find the weightage of each layer to calculate the suitability of MSW landfill. The weightage is based on the comparative scores between the different criteria given as input to the tool. In addition, a consistency check has been integrated inside the code, which checks if the user's scores will provide optimized results. All the input layers have been shown in Fig. 4. Spatial layers (a) Land slope Within the area of interest, away from the river Ganga, highly suitable to suitable conditions are commonly observed with occasional marginally suitable conditions. When shifted closer to the river specially near the banks, conditions ranging from unsuitable to marginally suitable are observed, indicating significant changes in the slope of the ground. (b) Population density The regions of highly suitable conditions are mainly observed in the north and southeastern parts of the area. Regions of suitable and marginally suitable are mainly seen in the eastern and western parts. All of this primarily suggests that the main central regions and some parts in the north and south are completely unsuitable. (c) Precipitation The precipitation variation is not very significant within this area; that is why 30 year data has been considered from which the mean value is taken to map the suitability condition. Highly suitable and suitable regions and mostly confined towards the northern end of the area with southern regions having unsuitable conditions. (d) Temperature Temperature variation throughout the area is not that significant, so 30-year data has been considered from which the mean value is taken. This shows highly suitable and Suitable regions are mostly confined in the eastern region outside the Kolkata ward boundary. Inside the boundary, mostly, unsuitable and conditionally suitable conditions are prevalent. (e) Surface water bodies As discussed in Table 3  with respect to this criterion, and the most unsuitable is the inter-distributary marsh (Nath et al., 2014). (i) Groundwater This layer represents the distribution of the groundwater in the region. The most highly suitable region may be observed in the southwestern part of the area. This region has the highest groundwater depth, with the lowest being the brown and red areas, making them unsuitable and conditionally suitable. (j) Suitability map The area of interest or the study area is shaped like the one as seen above due to the geomorphology data, which was limited to that extent. This geomorphology layer data is very accurate at such a small scale as boreholes were used to collect the physical data (Nath et al., 2014). The COPER-NICUS LULC layer used in the study is a global dataset. The accuracy required at the regional scale of Kolkata is not present in this dataset, and thus, some misclassifications may occur. To solve this issue, regional scale LULC is required which will increase the accuracy of the classification.
The overall suitable areas have been firstly chosen from the suitability layer generated by GEE-based AHP framework (Fig. 5), where the nine layers are being incorporated based on the comparative scoring into one suitability layer. The area for each class was calculated and has been shown in Table 4. Total municipal solid waste, population, waste generation rate, and other datasets are being used to calculate a volume. From this area are being calculated using the depths and surface area of such landfills. The surface area can be compared with the patches of the suitability pixels to identify the potential areas. More accuracy can be achieved in pinpointing the exact locations by taking into account the secondary attributes like odour, public acceptability, and distance from the current dumping location. Due to the ongoing pandemic situation within the timeline of this study, physical data collection or collection of ground truths could not be carried out. To mitigate this, Google Earth, Google Maps, and Street view were implemented as a reference and validation procedure visually (Fig. 6). The street view images are collected from Google maps itself, which are user-submitted images of the area within close vicinity to the selected Overall precipitation variation is not much observable within the area of interest, so a relatively lower weightage has been given Temperature 0.09 Overall temperature variation is not much observable within the area of interest, 1 to 2 °C at best. So a relatively lower weightage has been given Water Bodies 0.11 Excluding areas covered by water and buffering regions around it is necessary so as to avoid wrong suitability and close proximity to such water bodies. The buffers range between 0, 200, 400, 600, 800 and 1000 m Protected zones 0.09 Same goes for protected zones, monuments, public places and other points of interest within the area interest. The buffer ranges between 200, 400, 600, 800 m and greater Roads 0.06 Readymade road maps were also not available for free access and which were editable and usable, so this layer was created externally in a GIS software with Google maps as reference as well as OSM basemap, from which the main roads were extracted and the missing roads were filled in. Buffers were created which ranges from 100 to 400 m Groundwater 0.05 The depth of groundwater is an important aspect so as to not cause contamination due to shallow depth of groundwater in the suitable areas. Regions with the highest water depth are to be chosen as the most suitable Geomorphology 0.04 Soil characteristics and geomorphic nature of the suitable areas will dictate a lot of other characteristics and this needs to be addressed with high priority suitable sites as specified above. This type of validation is quite unique and accurate in its approach as a real view of the concerned area can be observed in aerial view and as images geotagged to that area.
Importance of GEE and AHP and their combination AHP as MCDM process helps calculate the weightage values for each criterion based on the pairwise comparative values from the user. The same procedure has been implemented in the GEE environment. Previously, no such functions or commands were integrated within GEE. This helps us calculate the weightage criteria for each of the layers like slope, population, land use, and precipitation, according to the comparative pairwise value from the user as input. This helps us determine which layer gets what kind of importance and ultimately affects the site selection. So AHP within GEE enables us to use the GEE dataset repository with other GEE assets to generate a landfill site suitability over Kolkata and its surroundings using the calculated criteria weights from the AHP process. It is a one-stop application for weightage calculation and mapping the suitable layer on-fly for various applications. AHP integration or the use of AHP to asses layers' weightage and prepare a suitability map is nothing new. However, it was not implemented in GEE earlier. Earlier in the studies (Acharya et al., 2019;Peter et al., 2020;Swain et al., 2020;Yalew et al., 2016), where AHP was used to assess suitability, AHP was done externally on some other platform, and then, those coefficients were given as inputs to the code. But the fact that the present tool is dynamic in nature makes it more future-forward as it can accept user inputs and works accordingly seamlessly. The AHP calculation and mapping integration is dynamic and works right from the start where the user inputs the pairwise comparative scores directly into the code panel as input and the coefficients, integration into each layer, and the final suitability map all happens on the fly with the click of a button. This makes the code applicable for site suitability and various other decision-making cases within GEE.
The calculations made by AHP are simple and always follow the decision maker's choices and inputs. The tool can thus be used to translate the decisions and choices made by the decision-maker into a multi-criteria ranking (Marcomini et al., 2008). On the other hand, AHP may require the user to make many decisions, especially for problems with many   criteria. The number of pairwise comparative scores grow quadratically with the increase in the number of criteria. The developed tool is flexible to increase the input layers and correspond pairwise comparison values with some customization in the code.
The Run with profiler option in GEE code editor provides the information about different computation time and memory usage of different sections of the code like reduceRegion, loading assets, and array computations. On average, 0.032-s CPU time and peak memory consumption of 337 k is initially observed, while all the resources are loaded, algorithms are called, and the assets finish loading. Once the user provides all the necessary inputs or decides to run with the default values, click the button in the UI to start the AHP and layering process, the code begins its processing (Fig. 7). Overall this shows that the code is optimized and quick to run even if it is handling a lot of data, calculations, and resources; even the memory consumption is under check as GEE limits the amount of memory bandwidth each user gets.

Conclusions
In the present study, the computation power of GEE has been harnessed to implement AHP, a method of MCDM, which is used to acquire alternative solutions to problems having multi-dimensions and criteria. AHP, although being an established method, was not developed in GEE. The most exciting and important factor is that this tool can be used for many AHPbased applications. These cases can be varied, but if it involves multiple criteria and decision making is required, this code will handle it with ease, with space to add more criteria and change region, making it ideal for MCDM approaches. The whole process of giving weightage to each layer depends on the user's pairwise comparative values. These comparative values will vary from user to user or application to application. The tool provides the opportunity to upload pair wise comparison values as CSV format. Site suitability analysis of Dhapa Landfill of KMC has been considered as an example for the case study. However, the code can be used for other suitability analysis for other areas and not limited to the use case presented here. Data availability The datasets generated during and/or analysed during the current study are available from the corresponding author on reasonable request. However, most of the datasets are available publicly in Google Earth Engine data catalog.

Conflict of interest
The authors declare no competing interests.