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

Tyndare tyndare at wanadoo.fr
Mar 31 Mai 17:12:05 UTC 2016



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
>



Plus d'informations sur la liste de diffusion dev-fr