Application de géolocalisation proche

Bonjour à  tous ! 


 


Je suis actuellement sur un projet d'application, l'idée est là , mais la façon de procéder elle n'est pas encore très clair. Je m'en remet donc à  vous pour essayer d'éclaircir tout ça :)


 


Mon idée : une application basé sur géolocalisation, en gros deux personnes qui sont proche l'une de l'autre en sont informé, et peuvent dialoguer/s'envoyer des photos autour d'un thème bien précis. Le même principe que les applications comme "Tinder" d'un point de vue géolocalisation par exemple.


 


Ma question se porte essentiellement sur la base de donnée sur lequel l'application se basera. 


Avez vous des conseils sur la façon de gérer une base de donnée qui sera (dans 90% des cas) utilisé pour l'application ? 


Après quelque recherche je suis tombé sur "Parse", mais étant familiarisé avec le langage SQL je pensé plus m'orienté vers une base de donnée "classic"de ce type et gérer via mySQL.


 


Pour gérer la localisation en elle même, j'ai dans l'idée de stocker la localisation de chaque personnes dans une base de donnée et d'interroger celle ci afin de voir si des personnes se trouvent autour. 


Pour éviter de solliciter la base de donnée principale et pour des raisons de rapidité il est préférable de créer une base de donnée internet à  l'application d'après ce que j'ai pu lire (ce qui parait plutôt logique). Ainsi l'application possèderai les données des utilisateurs en ligne de la région par exemple. 


Est ce la bonne méthode ? Ou y'a t'il un autre moyen plus productif et surtout moins couteux ?


 


Merci à  ceux qui accorderons du temps à  mon post ! 


 


PS : je suis novice en matière de développement iOS, il est possible que la question soit évidente je le conçoit. Mais malgré des recherches sur le web impossible de trouver quelque chose concret.  


 


 


Réponses

  • AliGatorAliGator Membre, Modérateur
    septembre 2014 modifié #2
    Hello

    Je ne comprends pas trop tes explications en fait : par définition la géolocalisation d'une personne change constamment vu que la personne se déplace. Et avoir une base de données en interne dans l'application du coup qui communique que très peu souvent avec une base de serveur est un petit peu contradictoire, non ?
  • TerflogagTerflogag Membre
    septembre 2014 modifié #3

    Et bien en fait dans mon idée la base de donnée (appelons la BD1) interne prendrai ses données sur la base de donnée principale (appelons la BD2).


    Ainsi, la BD2 principale contiendrai toutes les données utilisateurs ainsi que la localication mise à  jour régulièrement.


    La BD1 quand à  elle serait prendrai ses infos de la BD2 de façon moins régulière et seulement la zone géographique qui l'intéresse (ex rayon de 30km).


     


    Mais en effet c'est pas très utile... Etant donner que la BD1 ne serait pas à  jour en temps réel. 


     


    Au final ma question plus précisément est : comment font les applications de géolocalisation pour gérer autant de données qui sont en perpétuelle changement (puisque les données de géolocalisation change constamment) ? 


    Je me vois mal faire une application qui toute les 10s fait une requête à  la base de donnée pour actualiser la position + regarder qui est autour. Le cout me parait totalement énorme... A petite échelle pourquoi pas, mais à  grande échelle la solution ne me parait pas viable (à  moins d'avoir un cout financier énorme ? )


     


    Et merci pour ta réponse !


  • Am_MeAm_Me Membre
    septembre 2014 modifié #4

    Alors ça à  l'air cool mais niveau implé je te souhaite bonne chance  :o


    Alors petite idée mais je dois être surement taré pour te proposer ça. 1) Ca va te demander du temps 2) C'est presque iréalisable


     


    Le but serait : prenons un exemple de la France. Tu créerai une base de données (le but est de coupé la france en petit carrée, hexagone, cercle comme tu veux) Est Ouest Nord Sud et dans chaque de ses bases de données du divise encore et encore. Pas trop non plus. Le but étant qu'un utilisateur dans La BDD Est->Nord->Est-Ouest n'interroge que ses voisin et lui même. Qu'il n'aille pas interroger les bases Sud, Ouest, Nord. Et quand un utilisateur se déplace et qu'il change de zone : tu le supprime de son ancien "foyer" et tu le migres vers le nouveau 


     


    ==> Voilà  je suis  B) (fou)


     


    En gros ça ressemble un peu au principe du réseau téléphonie : http://upload.wikimedia.org/wikipedia/commons/3/37/Reseau_de_telephone_mobile.png

  • AliGatorAliGator Membre, Modérateur
    septembre 2014 modifié #5
    Heu tu sais beaucoup de base de données moderne, (MySQL y compris) gèrent les données geolocalisées ?

    Tu peux avoir des champs contenant des coordonnées, faire des requêtes SQL sur ces champs avec les opérateurs spécialisés (genre demander uniquement les résultats dont ledit champ contient des coordonnées qui sont à  moins de N mètres de telle autre coordonnées) etc...


    Donc pas besoin de découper la base en régions carrées ou hexagonales ou autre, d'autant plus que si tu fais ça ça risque de poser des problèmes au niveau des frontières entre chaque région (si l'utilisateur est à  la limite d'une region et ne vois pas quelqu'un qui est juste à  côté juste parce qu'il est dans une autre base / region de l'autre côté de la frontière...)

    La doc sur le sujet
  • TerflogagTerflogag Membre
    septembre 2014 modifié #6


    Alors ça à  l'air cool mais niveau implé je te souhaite bonne chance  :o


    Alors petite idée mais je dois être surement taré pour te proposer ça. 1) Ca va te demander du temps 2) C'est presque iréalisable


     


    Le but serait : prenons un exemple de la France. Tu créerai une base de données (le but est de coupé la france en petit carrée, hexagone, cercle comme tu veux) Est Ouest Nord Sud et dans chaque de ses bases de données du divise encore et encore. Pas trop non plus. Le but étant qu'un utilisateur dans La BDD Est->Nord->Est-Ouest n'interroge que ses voisin et lui même. Qu'il n'aille pas interroger les bases Sud, Ouest, Nord. Et quand un utilisateur se déplace et qu'il change de zone : tu le supprime de son ancien "foyer" et tu le migres vers le nouveau 


     


    ==> Voilà  je suis  B) (fou)


     


    En gros ça ressemble un peu au principe du réseau téléphonie : http://upload.wikimedia.org/wikipedia/commons/3/37/Reseau_de_telephone_mobile.png




     


    Voilà  c'était ça mon idée. Mais éffectivement comme le dis AliGator il y a bien plus simple. 


     




    Heu tu sais beaucoup de base de données moderne, (MySQL y compris) gèrent les données geolocalisées ?

    Tu peux avoir des champs contenant des coordonnées, faire des requêtes SQL sur ces champs avec les opérateurs spécialisés (genre demander uniquement les résultats dont ledit champ contient des coordonnées qui sont à  moins de N mètres de telle autre coordonnées) etc...


    Donc pas besoin de découper la base en régions carrées ou hexagonales ou autre, d'autant plus que si tu fais ça ça risque de poser des problèmes au niveau des frontières entre chaque région (si l'utilisateur est à  la limite d'une region et ne vois pas quelqu'un qui est juste à  côté juste parce qu'il est dans une autre base / region de l'autre côté de la frontière...)

    La doc sur le sujet




     


    Je ne savais pas du tout ! Voilà  qui résous pas mal de soucis dans ma tête... Merci bcp pour l'info ! (je n'avais pas vraiment fais de rechercher du coté de la gestion des localisations via les SGBD)


     


     


    Du coup, si j'actualise ma position et que je fais une requête pour voir les utilisateurs autours de moi toute les 10 s (admettons), ça fait 2 requêtes toutes les 10 s pour chaque utilisateurs utilisant l'application  B)


    Ca me parait toujours assez "énorme" d'un point de vu cout comme gestion pour mon application  (matériel et financier)... ou alors je suis complètement à  coté de la plaque  :(. Mais pour avoir quelque chose à  jour ça me parait être la seule solution !


    Ceci dis je ne me suis absolument pas renseigner et je n'ai pas calculer le type de serveur que ça demande (au début ça sera de toute façon assez insignifiant...).


  • jpimbertjpimbert Membre
    septembre 2014 modifié #7

    Il faut identifier tous les cas à  considérer et établir une stratégie de mise à  jour qui fonctionne pour chacun des cas, par exemple :


    - (personne ne bouge) ; ne nécessite pas de mise à  jour de BD1, donc toute stratégie est a priori OK  


    - je bouge ; je mets à  jour ma BD1 à  un rythme qui dépend de ma vitesse de mouvement et de la largeur de ma zone de contact, j'informe BD2 que je bouge  


    - les autres bougent ; le serveur BD2 m'informe par notification Push des entrants et sortants de ma zone de contact  


    - j'apparais (sans me déplacer, par exemple par activation de l'application, connexion de l'appareil, ...) ; j'informe BD1 et je crée ma BD1  


    - je disparais (sans me déplacer, ...) ; je ne fais rien (puisque je n'existe plus) et les autres seront informés de ma disparition lorsque un autre essaiera de me contacter ; il pourra alors informer BD2 et me tagger (dernière position connue)  


    - je veux sortir du "jeu" ; je me détruis de BD2 avant de quitter l'application  


  • AliGatorAliGator Membre, Modérateur
    Ca change pas grand chose au fait que le traffic réseau va etre monstrueux. La le serveur de push va exploser s'il doit envoyer un push à  chaque fois que les gens bougent et changent de zone !!
  • TerflogagTerflogag Membre
    septembre 2014 modifié #9

    Pour avoir quelque chose de précis il n'y a pas vraiment le choix il semblerai... 


    Du coup ça ne parait pas être réalisable, du moins pour un développer indépendant ? 


     


    Je serais curieux de savoir comment sont gérer les applications utilisant la géolocalisation (Happn notamment que je viens de découvrir et qui fonctionne d'un point de vue géolocalisation comme je souhaiterai le faire), et surtout le budget que cela demande d'un point de vue serveur...


Connectez-vous ou Inscrivez-vous pour répondre.