Your coordinates do not look like latitudes and longitudes. I assumed they are X and Y coordinates projected in Web Mercator. So I started a new project in QGIS, loaded the OpenStreet Maps basemap and checked those coordinates. I saw that they were from Curitiba.
I started looking for open geospatial data from Curitiba to be able to use real information in this answer. I found the following geographic data site: https://ippuc.org.br/geodownloads/geo.htm
From there I downloaded the file of transport terminals, the data are referred to the SIRGAS 2000 system and projected in UTM 22S: https://ippuc.org.br/geodownloads/SHAPES_SIRGAS/TERMINAL_DE_TRANSPORTE_SIRGAS.zip
Looking at the table of attributes, it occurred to me that I could assign Y value to those entities that had inauguration data prior to 1983, and N value to the others. I called the field: "older_than_1983".
I removed other fields and extracted two vector layers, one with all the stations, and another with only the old ones.
At this moment I have some test data to try to make a heatmap of proportion, which indicates: In what proportion, the density of transport stations in an area of Curitiba was inaugurated before 1983, with respect to the total density of transport stations for that sector. The radius to consider was 5000m.
The first thing I did was generate two heatmaps, with the HeatMap (Kernel Density Estimation) tool, one for each vector layer. Both with the same following parameters:
The resulting values in the rasters were not exactly the same, as expected, but were approximately in the range between 0 and 4 (terminals in 5000m round). I gave the same style to both raster:
In order to obtain the ratio between the values of the layers, I performed a raster algebra operation, with the Raster Calculator, and the following expression:
("Terminales_Total_HeatMap@1" > 0) * 100 * "Terminales_Yes_HeatMap@1" / "Terminales_Total_HeatMap@1"
The logic of that expression I would describe in the following way: When the pixel value of the band 1 of the "Terminals_Total" layer is greater than zero, the condition between parentheses returns a 1, indicating true, if the condition results false, returns a 0; to the result of that condition, multiply it by the percentage of the proportion between the pixel values of the "Terminals_Yes" layer and the "Terminals_Total" layer.
Surprisingly, the output raster had values between 0 and 440:
That is, in some places there were 4 times terminals older than 1983, with respect to the total. This is obviously false. Seeing the image, it is difficult to find which are the pixels with high values (they should be white). I suppose that since the layers of origin have a different extension, some estimate at the edges of one raster already gave a value close to 5 while in the other raster it still gave a value close to 1.
Anyway, one more algebraic operation could be done to get rid of values greater than 100. I leave you restless. I solved it only for the visualization, in the style of the layer, stretching the color ramp between 0 and 100:
Let's analyze a little the problem of percentages greater than 100.
At first I thought that the problem was due to an incorrect alignment of the pixels between both input rasters, because they have different lengths. However, when I reviewed the raster information, I saw that both had their pixels in multiple coordinates of 10 meters, so they were correctly aligned.
I decided to make a new algebra to know which were the pixels that gave a percentage greater than 100. I renamed the heatmap of percentages as: Percentage_Greater_than_100_Heatmap. Ok, assigning good names to layers seems not to be among my virtues. But I can deal with that.
I made a new raster algebra with the following expression:
("Percentage_Greater_than_100_Heatmap@1" > 100)
The output is a raster that contains value 1 for the source pixels that have a value greater than 100, and zero value for the others.
I added an assignment of the value 0 as NoData in the Output layer style to see only the pixels of value 1:
The location of the black pixels is totally strange to me, I expected to see only a few points.
I selected any black pixel with the identify tool, to understand what the wrong value was due to:
Indeed, the value of the "Yes" heatmap is greater than the "Total" heatmap value, against the logic.
I consider it an indeterminacy of the estimation of the algorithm that generates the heatmaps. That is, the term "estimation" makes sense in the name of the algorithm (HeatMap (Kernel Density Estimation)).
I think those pixels should be worth 100%. I correct them with the following expression in the raster calculator:
("Percentage_Greater_than_100_Heatmap@1" > 100) * 100 +
("Percentage_Greater_than_100_Heatmap@1" <= 100) * "Percentage_Greater_than_100_Heatmap@1"
This expression returns value 100 for pixels that meet the condition of having a value greater than 100 at the input, and retains the value of the input pixel for others.
The output is a raster that has values greater than zero and less than or equal to 100.