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).
_______________________________________________
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr
