Outil de recherche de vols CFD (SIG / BdD géospatiales)

<< < (4/10) > >>

piwaille: Citation de: PiRK le 18 Octobre 2011 - 11:13:57 Perdu pour toujours, bof... on peut facilement faire deux bdd separees, une avec tous les points pour nos applications du futur et une allégée qui ne servira que pour la recherche. eumpf .. me permet de réfléchir à "voix haute" hein ;) 2 bases de données peut être pas ... mais 2 tables : une table des points et une table des chemins (qui relie les points) ... du coup dans ta table des chemin tu peux avoir (pour 1 même vol) et le chemin complet et le "symplify" (un DL2 5 ? ) qui "représente" le vol réflexion suivante : quand tu calcules le simplify (si tu te fais une fonction perso), vu que tu as le temps, tu peux déjà tenter de t'appuyer sur des points déjà existants ... un peu comme le fait actuellement la déclaration CFD : la trace passe à moins de x km de tel point remarquable (remarqué) ... on la fait passer par ... après faut nourrir la base des points remarquables :grat:

marc: Plutôt que 2 tables, 1 champs supplémentaire serait plus judicieux/facile (Pirk utilise GeoDjango) 1 vol serait alors représenté par sa trace complète et une version simplifiée (+ d'autres info bien sûr).

PiRK: Citation de: piwaille le 19 Octobre 2011 - 08:39:33 après faut nourrir la base des points remarquables :grat: Oui, ca serait un gros boulot. Citation de: piwaille le 19 Octobre 2011 - 08:39:33 une table des points et une table des chemins (qui relie les points) ... Citation de: marc le 19 Octobre 2011 - 08:45:26 Plutôt que 2 tables, 1 champs supplémentaire serait plus judicieux/facile (Pirk utilise GeoDjango) 1 vol serait alors représenté par sa trace complète et une version simplifiée (+ d'autres info bien sûr). Je ne sais pas exactement comment fonctionne une base de donnees et qu'est ce qui influence la performance des recherches, mais quand j'ai fait mes test "traces completes" vs. "decimation a 10s" vs. "decimation a 20s"  j'ai eu l'impression que la recherche des traces etait quasiment instantannee dans tous les cas mais que ca ralentissait au moment d'y acceder en fonction de la quantité de données trouvée meme en n'accedant qu'a des champs leger tel que le nom du pilote, la distance... donc avant meme d'essayer d'acceder a la trace. Donc je me demande si rajouter un champ tout en gardant la grosse trace complete va vraiment arranger les choses. Mais je rajoute ca sur ma liste de tests a faire quand j'aurais le temps. EDIT: Peut-etre que la recherche initiale se fait uniquement sur les boites englobantes et que la recherche precise se fait par la suite au moment d'acceder aux donnees  :grat: Tu comprends comment ca marche precisement, Marc ? Si l'idees de faire deux champs fonctionne, on peut meme imaginer faire une recherche initiale sur le champs avec une precision de 500 m voir 1 km puis une seconde recherche avec la trace complete sur le premier sous-ensemble. EDIT2: Non, en fait mon idee est conne. On va perdre des traces a la premiere recherche et on va pas les retrouver a la deuxieme.  :clown:

marc: Plusieurs choses... Faut voir quelle opération prend du temps *exactement*. La BD fait effectivement un filtre avec les boîtes englobantes (cherche "index spatial", regarde ce que fait la bibliothèque "rtree", par exemple. Il y a beaucoup de chose à lire là dessus) pour les opérations qui peuvent en bénéficier (recherche d'intersection & cie). Par contre, tu utilises une couche d'abstraction qui potentiellement te cache des opérations coûteuses ! La recherche peut être super rapide, et dès que tu regardes les valeurs retournées, ça prend du temps: peut être que tu fais des conversions sans t'en rendre compte ? (pense que tu agis à plusieurs niveaux: BD/postgis, puis GeoDjango, puis GEOS, puis peut être JSON & cie ? Une même opération peut se faire à chaque niveau, mais à des coûts très différents ! Autant que possible, il faut faire les opérations coûteuses au niveau BD car elle est sensée être fait pour ça. Plus tu montes dans les abstractions, plus ça va te coûter bonbon. Si tu boucles sur les points d'une trace dans ton code python par exemple, ça va être lent à mourir. Effectivement, rajouter un champs dans la table ne va pas arranger ton problème car je pensais l'utiliser pour les recherches, qui sont déjà instantanées d'après ce que tu dis. Si tu peux me dire où dans ton code se passe l'opération qui prend trop de temps à ton goût, je peux essayer d'y jeter un oeil...

PiRK: Citation de: marc le 19 Octobre 2011 - 10:29:20 Effectivement, rajouter un champs dans la table ne va pas arranger ton problème car je pensais l'utiliser pour les recherches, qui sont déjà instantanées d'après ce que tu dis. Si tu peux me dire où dans ton code se passe l'opération qui prend trop de temps à ton goût, je peux essayer d'y jeter un oeil... Ce qui est instantane c'est quand je fait : Code: v = Vol.objects.filter(trace_gps__intersects = GEOMGeometry("POLYGON((5.85 45.3667, 5.9667 45.3667, 5.8333 45.2667, 5.85 45.3667))")).order_by('-distance') Et ce qui prend du temps c'est d'acceder a un element ou tous les elements de v : Code: print(v)   # 45 s print(v[156].distance)  # 15 s for tmp in v:     print (tmp.date, tmp.pilote, tmp.distance)   # 45 s len(v)    # 45 s pour 2476 traces A noter que dans le cas des commandes qui accedent a toutes les donnees (len(v), print(v) ou la boucle for), seule la premiere prend du temps. Les suivantes sont instantanees. Je fais l'equivalent de la boucle for dans mon template de page web, je perd peut etre de la performance avec la couche django.contrib.template.

Navigation

 Index des messages

Page suivante

Page précédente