[OSM-dev-fr] Validation de bâtiments fractionnés par le cadastre

[Tyndare]

Le 05/01/2017 à 14:11, Christian Quest a écrit :

> Il faut le limiter au zoom maxi de l'ortho éventuellement +1, après
> c'est affreux et n'apporte que confusion à mon avis.

Je m'étais dis qu'autoriser une grosse différence entre le zoom natif et 
celui affiché limiterais la charge des serveur de tuiles.

Mais Ok, je vais limiter au zoom 21 (+2), 21 est utile car la couche 
cadastre le supporte nativement, et ça serait perturbant d'avoir des 
zoom différents sur les deux panneaux.

>
> Pour OpenSolarMap, c'est fixe, et je dézoome sur les grand bâtiments...
> mais comme je ne sélectionne que des bâtiments d'au moins 10m2 (de
> mémoire) on n'a pas ce problème.
>
>
>
>
>         Il ma proposé ce way avec deux bâtiments diff :
>         https://www.openstreetmap.org/way/125318528
>         <https://www.openstreetmap.org/way/125318528>
>
>
>     L'analyse ne considère les bâtiments à fusionner que deux par deux,
>     c'est une limitation, quand comme là il y a plusieurs cas de fusion
>     possibles pour le même bâti.
>
>     Si les contributeurs dise oui aux deux cas de figure, je sais pas si
>     ça aidera beaucoup à résoudre le problème.
>
>
> Ce que je veux dire c'est que ce n'est pas à cause d'une limite de
> parcelle ou autre que c'est segmenté, mais bien parce qu'il y a un
> attribut différent. On ne devrait pas proposer ces cas là à résoudre à
> mon avis.

Les cas ou le tag wall sont différents sont exclus (jusqu'à preuve du 
contraire ;-)
Par contre j'ai volontairement gardé les cas ou les autres tag diffères, 
car quand un bâtiment est fractionné, les contributeurs OSM ne modifient 
le plus souvent les tags que du plus gros.
Mais si les tags diffèrent il ne faudra pas faire de fusion automatique 
dans OSM, il faudra vérifier ça manuellement.

>         Par contre tu en fais quoi des résultats ensuite ?
>
>
>     Pour l'instant aucune idée...  ils sont juste stockés dans une table.
>
>     Il faudra que je regarde comment Christian a dépatouillé les
>     contributions contradictoires dans OpenSolarMap, et après envisager
>     une modification automatique dans OSM si les bâtiments ont toujours
>     la même géométrie qu'au moment de l'analyse, mais j'ai jamais fait
>     ce genre de choses.
>
>
> La règle pour OpenSolarMap c'est: ok si count(plus fréquent) > cout(des
> autres)+3

Ça me parait bien effectivement.
Pour la proposition des cas à traiter j'ai garder quasi les même 
requêtes SQL qu'OpenSolarMap, donc ils sont proposés d'après ce que j'ai 
compris jusqu'à atteindre ce critère (ou un max de 10 contributions).