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

[Tyndare]

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