Division by 0 issue - Problem with running geoclimate on Nice

[balglave]

Hi,
I want to run GeoClimate on Nice, but I am having a "division by 0" issue.
The request is below. Does someone have an idea where could be the problem ?
Thanks ! :)
Baptiste

{
    "description": "Processing OSM data",
    "input": {
    "locations": ["Nice"]
    },
    "output": {
        "folder": "D:\\Users\\alglave\\Desktop\\Research\\geoclimate\\data"
    },
    "parameters": {
        "rsu_indicators": {
            "indicatorUse": [
                "LCZ",
                "TEB",
                "UTRF"
            ],
            "svfSimplified": true,
            "estimateHeight": true
        },
        "grid_indicators": {
            "x_size": 100,
	    "y_size": 100,
	    "rowCol": false,
	    "output" : "geojson",
	    "indicators" :[
                 "BUILDING_FRACTION", 
                 "BUILDING_HEIGHT", 
                 "WATER_FRACTION",
                 "VEGETATION_FRACTION", 
                 "ROAD_FRACTION", 
                 "IMPERVIOUS_FRACTION", 
                 "LCZ_FRACTION"
             ]
         }
    }
}

[ebocher]

Thanks. Investigation under the pipe

[j3r3m1]

@balglave can you share your log file to see exactly where the error is located ?

[j3r3m1]

Here it is:

15:13:38.713 [main] INFO class org.orbisgis.geoclimate.Geoindicators -- The URBAN TYPOLOGY classification is performed
15:13:38.714 [main] DEBUG class org.orbisgis.geoclimate.Geoindicators -- Executing the gathering of scales (to building or to RSU scale)
15:13:38.715 [main] DEBUG class org.orbisgis.geoclimate.Geoindicators -- Executing Unweighted statistical operations from lower scale
15:13:47.051 [main] DEBUG class org.orbisgis.geoclimate.Geoindicators -- Apply a Random Forest model
15:14:16.449 [main] DEBUG class org.orbisgis.geoclimate.Geoindicators -- Executing equality and uniqueness indicators
org.h2.jdbc.JdbcSQLDataException: Division par zéro: "CAST(0 AS DECFLOAT)"
Division by zero: "CAST(0 AS DECFLOAT)"; SQL statement:
DROP TABLE IF EXISTS TEMPO_DISTRIB [22012-224]

[balglave]

Youps, sorry for not responding, I completely missed your comment...
And thanks for running it !

[j3r3m1]

Youps, sorry for not responding, I completely missed your comment... And thanks for running it !

No worries.

The problem comes from the UTRF distribution calculated based on floor area. Normally, if there is no building in a RSU, it is not considered in the distribution calculation. This is OK for the UTRF distribution based on building fraction. However, when the UTRF distribution is based on floor area fraction, it does not work if all buildings in the RSU have a floor area equal to 0, which is the case for a RSU in Nice...

We have two buildings (ID_SOURCE w448862514 and w141719740) within a single RSU having building height = 2 m. Thus, due to the floor area calculation method, the floor area results in 0 m². We have 3 options to solve that:

1. consider that the building cannot have a building height lower than 3 m.
2. consider that the floor area should be equal to the building area when the building height < 3m
3. remove RSU having 0 values in all classes before distribution characterization

I would opt for the second solution. @ebocher what do you think ?

[ebocher]

+1 for second solution

[j3r3m1]

The problem comes from the nb_lev formatting in the OSM workflow. The BDTopo formatting seems OK (the max of heightRoof / h_lev_min and 1 is taken).

Here is a bbox test for the building causing the troubles:
[43.725068,7.297883,43.727635,7.301284]

[j3r3m1]

OK the problem is more complex than expected. I could perform the test for a building having a height lower than 3 m, the building is not even considered if this height information comes alone (ejected from this line).

However, if this information does not come alone as this is the case for building w141719740, thus the building is considered as it also have a nb_lev = 1. However, the nb_lev is downgraded to 0 but not in the initial formatting step. I suspect that it is when there is the building height estimation (I am investigating).

Anyway, there is a first inconsistency in our method: we consider a building as OK if it has a nb_lev > 0 but a building height < 3 m while we consider a building having only a building height < 3 m is not a building (it is evinced). I suggest we keep it and put its nb_lev to 1 (it is the case for BDTopo).

[ebocher]

Fixed thanks @j3r3m1