Un tableau à deux dimensions, avec recherche

Bonjour,

Je suis a la recherche d'une solution simple pour faire un "tableau" à deux dimensions, avec possibilité de faire une recherche sur les enregistrements répondant à un critère sur les deux colonnes.

Le "tableau" enregistre les latitudes et longitudes d'un trajet, et je souhaite être en mesure de récupérer l'ensemble des latitude/longitude appartenant à un intervalle.

Sous Basic4PPC, j'ai fait cela avec une "table, et la fonction filtre.

A priori, cela pourrait marcher avec un TTABle, mais cela oblige a mettre en place une BdD, et le pauvre pgm travaillera sur PNA (Wince4.5).

La recherche se fait toute les secondes, cela doit donc être très réactif.
La quantité de ligne est assez réduite (de l'ordre de 5000 max).

Avez-vous une idée?

Tu peux peut-être faire ça aussi sous la forme d'une liste de points X,Y

Dans quel sens cela me permettra de faire une sélection plus aisément ?

Est-ce que quelqu'un dispose d'un exemple de gestion de Bdd simple type tdbf?

As-tu regardé ici pour le tdbf: http://wiki.freepascal.org/Lazarus_Tdbf_Tutorial/fr

Sinon, il me semble qu'utiliser une BDD pour stocker ces infos équivaux à sortir l'artillerie lourde, à moins que tu aies beaucoup de trajets à gérer de cette façon ?
De façon simple, un trajet est une succession de coordonnées X et Y. Tu peux regrouper chaque coordonnée X et Y dans un type TPoint (ou enregistrement), ayant donc un attribut X et un attribut Y. Le trajet revient donc à un tableau à 1 dimension (un vecteur) de TPoint. A partir de là, la recherche d'un ensemble n'est qu'un problème algorithmique, car il te suffira de parcourir ton tableau et en fonction du filtre (intervalle) choisi, tu récupèreras seulement les infos qui t'intéressent.

Bonjour,

Tout dépend de savoir s'il s'agit d'une recherche à l'identique ou au plus proche.

Si c'est le premier cas : je placerais la valeur Longitude+'|'+Latitude dans une StringList ou un array statique ou dynamique d'une seule colonne - Recherche - Puis résultat obtenu avec un équivalent de explode...

Dans le deuxième cas, une approche par StringGrid.

Cordialement. Gilles

Bonsoir, et merci de vos reponses.

Pour ce qui est des résultats a trouver, ce sera un ensemble de points (lat/lon), compris entre deux bornes lat min/lat max et lon min/lon max).

La solution de lecture et recherche est possible, mais est-ce rapide?
Car cette recherche aura lieu très fréquemment (chaque seconde environ).

je suis en train de faire des tests avec Sqlite, car le programme tournera sur PNA WinCE 4.5

Bonjour,

Le facteur temps semble donc déterminant. Mais est-ce compatible avec le passage par une BDD... toutes les secondes ? D'ailleurs quel est le mode d'acquisition des 5000 (max.) coordonnées (vous ajoutez une coordonnée toutes les secondes ?) et sous quel format ? Indépendamment de la sauvegarde de vos acquisitions dans une BDD (qui est une autre problème), il faut traiter immédiatement les acquisitions... en mémoire. Si celles-ci sont fournies sous forme :

• d'une chaine à chaque fois (genre lat+';'+long), considérant les éléments que vous fournissez, je persiste à penser qu'il serait préférable d'utiliser sur une StringList voire même un simple array une méthode de tri rapide [cf http://fr.wikipedia.org/wiki/Tri_rapide]..., tri qui peut être optimisé en fonction du caractère "pseudo" alétoire des données car s'il s'agit de la captation d'un mouvement, il est peu probable que le mouvement soit traduit par une série de points réellement aléatoires (sauf si la fréquence des mesures est trop peu élevée par rapport aux variations de la trajectoire) [cf http://fr.wikipedia.org/wiki/Smoothsort]].
• deux chaines, la StringGrid possède des fonctions de tri puissantes et relativement simples. Il est possible de trier notamment sur plusieurs index... J'en ignore par contre la rapidité...

Cordialement. Gilles

Bonjour, et merci pour ces renseignements.

Donc, pour préciser l'idée, a chaque déplacement du tracteur (toute les secondes, fréquence du GPS, donc 3600 enregistrements par heure), je mémorise la position, effectue le tracé du trajet.

Afin de minimiser la taille mémoire utilisée, je dessine sur un format plus petit que l'ensemble total du trajet.

Donc, a chaque déplacement, je redessine les mini déplacements précédents effectués sur la zone visible.Pour cela, je recherche les déplacements compris dans ma fenêtre relative et les redessine.

Donc, le travail consiste bien en une recherche parmi les éléments mémorisés.
L'optimisation du traitement doit être importante, car le travail total (recup nouvelle coordonnée, recherche et dessin de l'ensemble des mini déplacement) doit se faire dans la seconde....

Je joint le résultat de mes essai sur B4PPC, afin de vous permettre de visualiser le besoin. Nota, le fichier en entrée en un fichier extrapolé à partir de coordonnées GPS reelles, adapté par algorithme à la visualisation.

J'ai dézippé votre programme qui ne fonctionne pas... sur mon PC (je n'ai pas de WinCE :mouarf: )

Par contre, j'ai ouvert le fichier csv. Alors je crois mieux comprendre le problème.

Si tel est le cas, pour réduire les temps de traitement (en réalité augmenter la fluidité), pourquoi ne pas faire deux array ou StringGrid. Un(e) d'acquisition et l'autre "de dessin"...

Avec des threads, l'ensemble restera cohérent... Un thread d'acquisition des données de votre GPS... L'array aura une taille faible. Il sera vidé à chaque enregistrement dans la BDD. Un autre de détermination de l'espace à afficher (les coordonnées à l'échelle)...

Mais le problème est le chargement du "tableau de dessin". La détermination de sa taille est plus compliquée parce qu'elle est liée à la partie de la trajectoire que vous voulez dessiner. Donc, si j'ai bien compris, c'est ici qu'intervient le bornage longitude et latitude... (sur le principe d'un zoom)... Vous donnez les coordonnées des 2 coins opposés du rectangle (zone bleue, coins verts sur le dessin)... Est-ce cela ?

Et le problème "délicat" c'est, si on place un "traceur temps réel" sur la dernière position, il faut être capable de reconstruire de manière dynamique "le zoom" à chaque fois que nécessaire [proche du bord (bleu) par exemple...] sinon on ajoute le point.

Evidemment, si on a la mémoire suffisante... Mais, à priori vous ne l'avez pas...

Ce qui va imposer d'aller chercher, à chaque fois que nécessaire et finalement peut-être pas si souvent que cela, la partie de l'historique des points dans la BDD. Evidemment, la question n'est pas de savoir si on peut filtrer la base de manière continue dans la seconde (ie en 1 seconde)... Il n'est pas question d'accéder à la base à chaque rafraichissement du dessin. Et même, à mon avis, il faut espacer autant que possible l'accès à la base dans la limite de ce que peut contenir la RAM. Donc dans la mémoire, il faudrait élargir (écarter) les coins de manière à pouvoir travailler "confortablement" [la zone jaune]. Lorsqu'on approche une certaine limite (quand le tracteur rentre dans la zone jaune), on refiltre la BDD tout en continuant l'affichage avec l'array actuel (en mémoire) qui suffit "pour l'instant"... sinon on ajoute "simplement" le nouveau point (recalculé à partir des coordonnées GPS)... Avez-vous déterminé combien de points vous pouvez mettre en mémoire ? Est-il possible de déterminer en temps réelle la RAM dispo ? (Je ne sais pas... c'est un problème que je n'ai pas rencontré depuis très longtemps...)...

Donc à mon avis, compte tenu de ce que j'ai compris, le problème de la vitesse du tri (donc de sa méthode) n'est pas déterminant. C'est plutôt la détermination de la plage des coordonnées que l'on va placer dans "l'espace de zoom" en mémoire qu'il faut optimiser... et le déclenchement au bon moment de l'accès à la BDD.

http://www.selzig.com/1011021100/1.png.

Cordialement. Gilles

Je rentre juste du boulot et je vous remercie de votre reponse.
Je vais y réfléchir à tête reposée ce soir.
Pour le PGM, s'il ne fonctionne pas, c'est certainement un problème de manque de DLL, je les remets dedans et je met à jour.

Bonsoir,
grâce aux conseils de Selzig, j'ai avancé et "résolu" en partie mon problème avec un TStringrid a 4 colonnes : une décrivant la dalle d'affichage et un compteur pour redessiner dans le bon ordre (clé de tri), une pour la comparaison lors d'un changement de dalle (clé de recherche), une pour la latitude et une pour la longitude.

Partie chargement de la grille à chaque nouveau point

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

procedure Tform1.memo_grid(latpta,latptd,lonpta,lonptd:single;h:integer); begin strgrid1.RowCount:=strgrid1.RowCount+1; // ajout pour avoir une dynamique strgrid1.Cells[0,j]:= floattostr(int(latpta/maxsize)) + '_' + floattostr(int(lonpta/maxsize)) +'!' +inttostr(H); strgrid1.Cells[1,j]:= floattostr(int(latpta/maxsize)) + '_' + floattostr(int(lonptd/maxsize)); strgrid1.Cells[2,j]:= floattostr(latptd); strgrid1.Cells[3,j]:= floattostr(lonptd); end;

---

Partie recherche des points de la dalle

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

procedure TForm1.chargement_dalle; var ind : integer; memlat,memlon:string; begin memlat := '0'; Txlat := 115 -latact; Txlon := 115 -lonact ; If (Txlat<>0) OR (Txlon <> 0) Then begin //efface l'image //image1.Picture.Clear; end; // tri de la string grid strgrid1.sortcolrow(true,1); for ind := 1 to strgrid1.RowCount-1 do begin if strgrid1.Cells[0,ind] = dalkey then begin //on trace les points sur la fiche if memlat <> '0' then trace_point(memlat,memlon,strgrid1.cells[2,ind], strgrid1.cells[3,ind]); memlat := strgrid1.cells[2,ind]; memlon := strgrid1.cells[2,ind]; end; end; // on traite le dernier point.... if memlat <>'0' then trace_point(memlat,memlon,strgrid1.cells[2,ind], strgrid1.cells[3,ind]); end;

---

Maintenant, je vais affiner la partie création/effacement de l'image, car pour l'instant, ça ne marche pas...

Une petite question : j'ai initialisé le Tstringrid a 5000 lignes, mais je trouve cela assez moyen, car c'est de la mémoire utilisé pour rien, ou c'est limitatif si on travaille plus de 1,40 heure . Existe-t-il un autre moyen plus intéressant, (incrementation à la ligne,par groupe...) : cela optimiserai aussi la parti recherche de dalle...

Auto reponse en italique rouge dans le message