Is LCZ E highly over estimated ?

[simogeo]

I'm working with geoclimate v1.0.0 and BD-TOPO v3.

And I've got the impression that LCZ-E (bare rock or paved) became over-estimated. I can even see LCZ-E covering agricultural fields. Here some samples :

In Ploemeur (56162) - near Lorient :

In Ploemeur (56162) - on the coast part :

[ebocher]

Yes sure. Because there is no information to qualify those areas. OSM seems better https://www.openstreetmap.org/way/886328845

[simogeo]

thank you @ebocher !

[j3r3m1]

A good way to identify the most probable error cases is to use the UNDEFINED_FRACTION indicator. When it is high the classification becomes very uncertain

[simogeo]

thank you @j3r3m1 : indeed, the value is 0,7446393169013416

But I don't even understand why is this RSU so big. There is also buildings on it (see screenshot - Zoom)

[j3r3m1]

Wow ! Is it a single one on the image you have provided above ? I think the main reason is that due to the sea, there are a deficit of roads in this area (or dead-end roads), thus there are no partitionning. This is definitely a limit of the current workflow. A second problem might explain it (but less surely): in the last GeoClimate version due to a new way to create TSU (using urban areas tag), we might create very long RSU connected by very narrow strips of land. cf #930

[simogeo]

Wow ! Is it a single one on the image you have provided above ?

It is, not only on the zoom I provided above but the full black area below is one piece only !

And yes, from a geographic point of view, it's a total non-sense. I'm really surprised because there is no such inconsistency on others neighbors municipalities on the seashore

For your information he resulting file (only Ploemeur - 56162) is available at https://drop.chapril.org/download/96cdd49e335325ea/#quY2ZDvU_qcWyiNnwEapkA

Just ask me if you want the whole dataset for the given municipality

[j3r3m1]

OK as strange as I would have imagined. The last modification of the RSU partitionning has been done in this PR: https://github.com/orbisgis/geoclimate/pull/853

It would be interesting to see if the problem was already there before this new partitionning (I would guess yes). Do you have a version of GeoClimate right before this modification that you could use ? Otherwise this one is from September 21st (the modification is October 6th).

geoclimate-0.0.2-SNAPSHOT(1).zip

[simogeo]

I've tried using the given geoclimate snapshot, but whatever the BD-TOPO (2.2, 3.0, 3.3) version I used I got an error.

org.h2.jdbc.JdbcSQLSyntaxErrorException: Table "UTRF_RSU_AREA_BD302AC4_8FE9_4BCA_9BE5_905AFD4498E2" non trouvée Table "UTRF_RSU_AREA_BD302AC4_8FE9_4BCA_9BE5_905AFD4498E2" not found; SQL statement: SELECT * FROM UTRF_RSU_AREA_bd302ac4_8fe9_4bca_9be5_905afd4498e2 LIMIT 0; [42102-224]

[j3r3m1]

Do you really need the UTRF ? What if you remove it from the indicatorUse list ?

[simogeo]

Good catch ! I thought I already did try without.

Anyway, the result is even worst - see highlighted shape :

I will have a try with OSM and will post the result as well

[simogeo]

OSM is not perfect but much better :

[j3r3m1]

I suppose the OSM is with the last version, not the one before the RSU modifications ?

[simogeo]

of course !

[j3r3m1]

Means there is definitely a good reason for having scripts merging several datasets to take advantage of all types

[simogeo]

I will use OSM data regarding this specific municipality right now. I'm (almost) fine with that :+1:

I know that all the RSU approach rely on data but but do you think the algorithm could be enhanced to at least prevent these big and inconsistent units when using BD TOPO ? This would simplify manual handling

[simogeo]

Means there is definitely a good reason for having scripts merging several datasets to take advantage of all types

I have no doubt regarding this ! ;-))

[j3r3m1]

These big and unconsistent units are unfortunately a problem even for OSM sometimes (#930). I do not think that "simple solution" as said in this other conversation might solve the problem in BDTopo but hopefully most of the OSM cases. That's why a mix of OSM and BDT data might be a good compromise