Traces, tracés géographiques et MySQL

Bonjours à toutes et tous

Je recherche des informations pour l'intégration de données géographiques dans une base de données (MySQl et chez Free)
Mon but est de mémoriser un parcours comprenant 0 ou plus directions ( au sens google map ou autres ) et 0 ou plus lignes ( tracé direct entre 2 points )
ainsi que des waypoints (ou points particuliers), information sur l'altitude, coordonnées du rectangle entourant le parcours (et autres info telles que distance, D+, D-...).
Mais cela peut aussi provenir d'équipement GPS (Garmin, Polar...)

Cela pour optimiser la consommation de données dans la base, permettre la recherche d'un parcours proche, ...

Dois-je enregistrer le contenu du fichier gpx, KML, ..., ou les données brutes liées à l'ensemble des données (directions, lignes).

Bref, pour faire simple j'ai un parcours. Comment le sauvegarder en base de données de façon optimale et utilisable?

Merci,

JLMAG

NB: je ne cherche pas que l'on me fournisse des requêtes toutes faites, ni même un diagramme, juste des informations pour une meilleure compréhension.

salut,

je te conseille d'épurer les traces... car beaucoup contienne un nombre de points colossal (enregistrement à intervalle régulier par exemple)...

après à toi de voir si tu souhaites stocker ça ensuite en format dédié à ça dans mysql où avec un format perso...

regarde dans le sous-forum php-mysql j'ai abordé ça avec un mec pour son site sur les randonnées y a quelques mois...

la boite englobante est toujours est bon moyen d'élimination rapide oui, surtout avant d'appliquer des calculs de distance géodésique par exemple :ccool:

Bonsoir Eric,

En premier lieu, merci de ta réponse.

J'avais déjà lu le post cité. Mais il ne m'avait donné d'informations complémentaires. Néanmoins, tu as été extrèment serviable pour cette personne :-)

Bien, je fais quelques essais ICI (les info sont dans la console de Firefox).
En utilisant la bibliothèque "google.maps.geometry.encoding" pour 726 enregistrements, je passe à 2245 caractères (409947 pour fichier XML et 15950 pour juste le tracé), jouable par rapport à une optimisation (via Ramer-Douglas-Peucker par ex.)?
Je testerais la manip inverse (decodage) pour vérifier si autant de précision sur le tracé.

Demain, j'essaierais avec l'algorithme de Ramer-Douglas-Peucker (si je m'en sors !-|)

Pour une recherche de parcours proche dans MySQL (par exemple), juste les données SW et NE du rectangle englobant suffisent, ou bien?

Dernière question, un peu hors sujet, il me semble avoir remarqué dans l'appli sporttrack une optimisation façon "google...encoding" pour des données telles que:
vitesse, élévation, ou autres. Aurais-tu des infos la dessus?

Merci encore,
Jean-Luc

NB: l'affichage chez moi est très réactif (chemin, box) via le site chez Free et pas de code (de ma part) optimisé.
Le but est d'intégrer cela à mes essais (ici et là) via qooxdoo

y a des endroits où ton truc colle bien au rue à d'autres non...

je peux pas dire pour les différents algorithmes faut tester pour voir...

surtout que google est loin de produire beaucoup d'explications... ni la plupart des apis en général, ce qui peux parfois devenir problématique... :roll:

après ça te rajoute une étape ajax si tu veux le faire en php à partir de ce que j'avais fait (ou autre), mais bon ça devrait pas être trop dur à adapter en javascript

après méfie toi JavaScript en version client est très dépendant du navigateur et la puissance de la machine cliente donc tu peux avoir des expérience très variables...

après ça dépend aussi de comment tu veux gérer tes chemins...
de manière générale je suis pas très convaincu par l'approche texte sur plus que 100 ou 200 points... après ça dépend de où tu fais des calculs quand tu en as besoin et avec quel api ou techno (JavaScript, php, sgbd) et de leur complexité...

pour trouver les chemins proches, le rectangle englobant suffit, après tu affines si besoin...
c'est pareil en 3d... c'est aussi comme ça qu'ils font pour afficher les choses rapidement dans beaucoup d'application de géoréférencement (tu ne charges que les objets dans la zone de rendu et tu ne t'occupes pas des autres)...

sinon non j'ai pas d'infos sur l'optimisation de sporttrack...

le soucis c'est que de toute façon sur des trucs gourmands, le matériel autan que la techno est en jeu...:zoubi:

méfies toi si tu es en mutualisé, les performance peuvent être hyper aléatoires lorsque tu joueras avec le sgbd avec des bd fournies...:aie:

:ccool:

Merci de tes retours.

La montre (forerunner305), que j'utilise, n'est pas forcément adaptée pour le vélo et quelque peu ancienne.

Bien, m'en vais poursuivre mes essais :bug:

Merci encore,

A+