[OSM-dev-fr] Aide pour Osmose et SQL: buildings cadastre fractionnés

[Tyndare]

J'ai mis à jour la détection des bâtiments fractionnés:

- j'ai amélioré les fichiers d'exemples servant à l'apprentissage
   (j'avais raté des bâtiment fractionnés, il en manque peu être
   encore) (http://cadastre.openstreetmap.fr/segmented_building_data/)


- Jai finalement abandonné SVM pour passer à une classification avec
   KNeighbors qui donne de meilleurs résultats. PB: c'est bien plus lent
   à l'exécution et ça annule les gains que j'avais obtenu en recodant
   une partie en C. De nouveau ma rajoute 40' pour analyser
   la région Rhône-Alpes avec Osmose-backend.

Si vous voulez voire un résultat d'analyse vous pouvez regarder les 
fichiers -prediction_segmente.osm générés sur cadastre.openstreetmap.fr
comme ici: http://cadastre.openstreetmap.fr/data/040/

Pensez-vous que la qualité soit suffisante pour une intégration dans 
Osmose ?




On 31/05/2016 19:12, Tyndare wrote:
>
>
> Grâce notamment à Didier et Jocelyn les résultats d'analyse sont
> visibles pour l'Alsace ici:
>
> http://dev.osmose.frontend.dirif.info/fr/map/#country=france*&item=1&class=7&zoom=12&lat=47.8762&lon=7.4456&layer=Mapnik&overlays=FFFFFFFFFFFFFFFFFFFFT
>
>
> En essayant de faire des changements pour améliorer les résultats il
> faut que je me rende à l'évidence: je n'ai rien compris à SVM et si ce
> que j'ai obtenu initialement semble presque cohérent c'est un coup de
> bol...
>
> Bon sinon j'ai passé une partie du python en C pour améliorer les
> performances.
>
>
> On 27/05/2016 00:37, Tyndare wrote:
>> Je relance ce vieux sujet.
>>
>> J'ai fait une nouvelle tentative:
>> https://github.com/tyndare/osmose-backend/commit/51ae035847b23af05804b1f6e32387e3f6d435e9
>>
>>
>>
>> Cette fois j'ai arrêté de vouloir faire le malin en SQL, j'ai mis quasi
>> que du python qui teste chaque couple de bâtiment qui se touche en
>> appelant un classifier SVM
>> (celui qui se trouve désormais dans l'export cadastre sur osm104)
>> Je pense que le taux de faux positifs est acceptable pour être intégré
>> dans Osmose (a vérifier)
>>
>> J'ai lancé l'analyse pour la région Rhône-Alpes, il a trouvé 22 000 cas.
>> Sur un pc portable avec ssd, je pense que mon code a pris à lui tout
>> seul environ 40'.
>> En extrapolant, pour la France j'imagine que ça rajouterais environ 8h.
>> Je crois que c'est surtout du temps CPU qui est utilisé, faudrait voire
>> si on ne peut pas paralléliser l'appel des callbacks de
>> l'Analyser_Osmosis pour aller plus vite sur multi cœur.
>>
>> "8h de plus" pour l'analyser_osmosis_building_overlaps, il y a un
>> serveur Osmose quelque part qui peut supporter ça ou c'est mort ?
>>
>> Est-ce qu'il existe un frontend Osmose de test vers lequel je pourrait
>> essayer d'envoyer mes résultats pour validation ?
>>
>>
>> On 16/11/2015 23:38, Frédéric Rodrigo wrote:
>>> Pour l’exécuté dans le backend principal d'Osmose ça dépendent du
>>> temps que ça prend et de la base de données que ça utilise.
>>> Mais rien n’empêche a n'importe quel programme de devenir un backend
>>> d'Osmose en envoyant directement des rapports au frontend d'Osmose.
>>>
>>> Ce genre de grosse requête est quand un long processus d'affinage.
>>>
>>> Le 16/11/2015 23:27, Tyndare a écrit :
>>>> Mais du coup c'est envisageable de faire ce genre d'analyse ou les
>>>> serveurs Osmose sont déjà trop chargés ?
>>>>
>>>> En tout cas merci beaucoup Frédéric pour tes conseils.
>>>> En gros il faut que je réécrive tout ;-) (je dois dire que je m'y
>>>> attendais un peu)
>>>>
>>>>
>>>> Le 16 novembre 2015 22:33, Frédéric Rodrigo <fred.rodrigo at gmail.com>
>>>> a écrit :
>>>>> Salut,
>>>>>
>>>>> Les requêtes actuelles sont déjà assez lourde. C'est assez
>>>>> difficile de
>>>>> faire des choses dans le domaine du bâti.
>>>>>
>>>>> Tu peux déjà éviter d'utiliser une fonction, c'est joli, mais c'est
>>>>> lent.
>>>>> Essayes d'utiliser des temps tables avec des index dessus si
>>>>> besoin, et
>>>>> essaye de réduire le nombre de jointures.
>>>>> Essaye d'éviter d'utiliser way_nodes, tu as aussi les id des nodes
>>>>> dans
>>>>> ways.nodes.
>>>>> De plus way_nodes ne supporte pas le mode diff tu ne peux pas faire
>>>>> touched_way_nodes.
>>>>>
>>>>> Dans osmose la projection est un paramètre de l'analyse.
>>>>>
>>>>>
>>>>> Frédéric.
>>>>>
>>>>>
>>>>>
>>>>> Le 16/11/2015 19:46, Tyndare a écrit :
>>>>>>
>>>>>> Bonjour,
>>>>>>
>>>>>> J'ai voulu essayer de faire une analyse osmose pour détecter des
>>>>>> bâtiments
>>>>>> fractionnés à cause du cadastre.
>>>>>> Pour l'instant ce n'est pas vraiment une réussite, je ne sais pas
>>>>>> si il y
>>>>>> aurait des volontaires pour m'aider, je ne maîtrise pas du tout
>>>>>> SQL ou
>>>>>> PostGIS en fait...
>>>>>>
>>>>>> Ce que j'ai voulu faire c'est détecter les situations où un
>>>>>> bâtiment est
>>>>>> collé à un autre de manière rectiligne, mais dont l'angle avec la
>>>>>> section
>>>>>> commune ne soit pas à 90°:
>>>>>>
>>>>>> -----+----
>>>>>>       /
>>>>>>      /
>>>>>> --+-------
>>>>>>
>>>>>> J'ai deux problèmes:
>>>>>>
>>>>>> 1. Le principe marche relativement bien dans les zones modernes (où
>>>>>> les
>>>>>> bâtiments sont à peut près carrés), mais trouves beaucoup trop de
>>>>>> faux
>>>>>> positifs dans les vielles villes.
>>>>>> Si quelqu'un à une idée d'heuristique pour réduire le nombre de faux
>>>>>> positifs je suis preneur.
>>>>>>
>>>>>>
>>>>>> 2. Ma requête SQL est beaucoup trop compliquée, et elle génère des
>>>>>> tables
>>>>>> intermédiaires de taille exponentielle...
>>>>>> Si une âme charitable est motivé pour jeter un œuil à mon horrible
>>>>>> requête
>>>>>> SQL et me donner quelques conseils d'optimisation:
>>>>>>
>>>>>>
>>>>>> https://github.com/tyndare/osmose-backend/commit/6dd5e773ac7e0f5480518c066ed2bd4b0c50a04e
>>>>>>
>>>>>>
>>>>>>
>>>>>> Merci,
>>>>>>
>>>>>> Tyndare.
>>>>>>
>>>
>>>
>>> _______________________________________________
>>> dev-fr mailing list
>>> dev-fr at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/dev-fr
>>