Comme dis dans mon titre, j'ai un gros souci au niveau d'une requète permettant de commander un module de géolocalisation
 
 
Je vais tenter de décrire le principe : je me suis inspiré d'un système existant mais je sens que je me suis planté en fait
 
 
En gros j'ai une bdd sur laquelle est stockée dans une table le profil des membres. Je passe sur ce qui se passe avant mais il arrive un moment ou dans une champ "geodata" se retrouve stocké les coordonées de la personne sous la forme :
 

 
(en radians donc, le premier chiffre correspond à la latitude, le second la longitude, toussa dans un seul champ).
 
 
Le problème viens du moment ou il faut calculer la distance entre deux utilsateurs ayant ce champ renseigné : j'en suis arrivé à sortir cette requète :
 

 
Qui me donne geo[0] = latitude de l'utilisateur et geo[1] = longitude utilisateur en fonction de son code postal.
 
 
Ensuite cette requète qui represente en quelque sorte la formule pour calculer la ditance entre deux personnes à partir de leur coordonnées en radians :
 

 
 
Sous SQL aucun souci : la requète fonctionne et me répond bien la distance entre moi et les autres utilisateurs. Mais impossible de la faire fonctionner sous php : je n'arrive pas à exprimer ces fameux geo[0] ou geo [1] : j'ai mes coordonnées, celle de l'utilisateur mais pas moyen d'avoir les deux à la fois
 
 
D'ailleurs en réecrivant les requètes sur HFR je suis en train de voir qu'il y a des éléments en double dans les requètes; j'suis un peu perdu là
 
 
Je me demande s'il ne serai carrement pas plus pratique de séparer les champs longitude et latitude, car finalement mon seul souci est de trouver le moyen d'exprimer geo[0] et geo[1] pour obtenir un nombre "proximite"...qui serai résolu en passant au système des champs séparés (enfin je crois )
 
 
C'est un peu embrouillé comme récit je crois mais je tiens à résoudre ce souci pour avancer un peu
 
 
Quelqu'un aurait une idée ?

Je comprends pas trop ce que tu fais ... ou ce qui ne marche pas ...  
 
Enfin bon, pour le calcul ça n'a rien à faire dans le sql, surtout que là tu le fait pour toutes les ligne de la table.
 
Mets nous la totalité du code php qui pose pblm si tu veux une réponse.

 
 
J'ai réfléchit (oui ça m'arrive ), je vais reprendre ça depuis l'origine. Là ça va pas ce code, ça me pose que des emmerdes depuis deux jours alors que j'aurai du aller au plus simple dès le départ au lieu de me prendre la tête et de ne faire que des conneries
 
 
Sinon cette requète pompe énormement de ressources serveur, forcemment y'a aucune LIMIT. 35275 entrées, ça commence à faire mal
 
 
J'avais dévelopé ce calcul sur phpmyadmin en utilisant mes propres coordonnées géo, ça fonctionnais du tonnerre et me sortais des distances un peu imprécises (du au fait que le calcul se base sur des coordonées => vol d'oiseau en fait), mais pas très éloigné de la réalité (d'où le coefficient 1.4 placé à la fin, pour compenser un peu).
 
 
Je veux mon module de géolocalisation et je l'aurai

éventuellement: précalcule dans une table à part les distances des villes, et mets y un index.
possibilité édition manuelle de la table pour info plus précise.

Oui, s'il y a 2 valeurs distinctes, ce sera obligatoirement plus simple de les gérer dans 2 champs distincts  
(et pas sous forme de champs texte, ca évitera des conversions )

 
 
Alors ma précédente méthode : deux jours pour rien. Après modifs en champs séparés j'ai pu sortir un truc correct en 30 minutes
 
 
Je m'était bien planté, tout simplement
 
 
Là ça calcule uniquement les distances à partir des données inscrites dans la table match_users, donc ça pompe nettement moins de ressources pour le moment, même sans LIMIT. La table ou sont stockés les 35000 villes ne sert qu'a l'inscription de l'utilisateur, ça lui remplis les champs latitude et longitude de match_users . Pourquoi faire compliqué quand on peux faire simple hein ?