Forum Programmation.autre Comment démarrer mon projet de recherche spatiale / sql?

Posté par (page perso) . Licence CC by-sa
Tags : aucun
2
27
juin
2013

Bonjour,

Je travaille sur un projet pour lequel je devrais faire des recherche spatiales associées à des villes / départements / régions / pays. Genre "chercher les items qui se trouvent dans un rayon de 100km autour de Berlin".

J'imagine un schéma de base SQL genre :
* une table qui liste les villes avec département associé, région, pays, et coordonnées géographique
* une table qui liste mes objets avec une ville associée

Quand je fais une requête, je fais une requête "chercher dans cette ville et dans un rayon de X kilomètres" et je récupère donc l'ensemble des objets qui sont associées à toutes les villes qui se trouvent dans le rayon de recherche demandé.

Pour les gens qui maîtrisent les bases de données géographiques, ce genre de problématique est probablement trivial. Pour moi, hm… disons que je ne sais pas du tout par où commencer et où chercher.

Je suis preneur de liens vers des tutoriaux, de comment implémenter cela, sachant que j'envisage de me baser sur des données "brutes" genre ce qu'on peut téléchargere là - http://earth-info.nga.mil/gns/html/namefiles.htm ; ou encore sur un dump openstreetmap (ou encore sur openstreetmap directement, mais dans ce cas, comment faire le lien entre la ville recherchée, la zone géographique associée ?).

Au final, j'ai l'impression que ce dont j'ai besoin c'est un simple "calculateur de distance" utilisé dans la clause WHERE de mes requêtes SQL… mais c'est une approche de béotien ; il y a certainement des techniques/pratiques qui m'échappent…

Merci d'avance pour vos pointeurs, conseils et remarques sur le sujet.

  • # J'ai commencé par...

    Posté par (page perso) . Évalué à 3.

    La lecture de cette présentation de David Blasby à propos de PostGIS :
    http://postgis.refractions.net/files/OSDB2_PostGIS_Presentation.ppt

  • # ca depend

    Posté par . Évalué à 2.

    Au final, j'ai l'impression que ce dont j'ai besoin c'est un simple "calculateur de distance" utilisé dans la clause WHERE de mes requêtes SQL… mais c'est une approche de béotien ; il y a certainement des techniques/pratiques qui m'échappent…

    en fait ca depend du type de distance que tu veux,
    si c'est à vol d'oiseau (ce qu'on entend souvent pour dire "autour de"… ou dans un rayon de…), alors c'est un simple calcul trigonometrique avec les coordonnées de depart, et un cercle autour de ce point, puis chercher dans la base tous les points dont les coordonnées sont dans ce cercle.

    si c'est de la distance par la route, il faut un calcul d'itineraire, là ca devient plus complexe.

    • [^] # Re: ca depend

      Posté par (page perso) . Évalué à 2.

      Ouais le cas de base c'est un simple calcul de distance ; mais je me dis que c'est pas optimal parce qu'à chaque requête, tu dois calculer la distance avec l'ensemble des éléments pour savoir s'il est proche ou pas proche. De ce que j'ai compris, postGIS (par exemple) permet de stocker des indexs correspondant à ce genre de requête.

      D'où ma recherche de "tutoriel" et pointeurs vers des ressources en ligne pour découvrir comment mettre en oeuvre cela.

      • [^] # Re: ca depend

        Posté par . Évalué à 2.

        en mysql ce sont des tables temporaires, qui pourraient contenir ville de depart/ville arrivée/distance

        sinon tu peux precalculer ces distances et les mettres dans une vraie table, les distances ne vont pas non plus bouger tant que ca.

        du coup tu demarres avec cette table vide,
        et tu cherches la distance dans cette table, si elle n'existe pas, tu la calcule et tu la stocke.

        la fois d'apres pour la meme distance, tu aura deja l'info.

        • [^] # Re: ca depend

          Posté par (page perso) . Évalué à 2.

          Ouais t'as raison : je vais commencer avec un truc comme ça simple mais qui marche ; on verra plus tard pour faire des choses plus flexibles / évolutives :)

  • # SQL, vraiment ?

    Posté par (page perso) . Évalué à -1.

    Es-tu sûr que SQL est adapté à ce que tu veux faire ?

    Dans la mesure où ce qui est important pour toi c'est la position géographique relative à d'autres objets ou villes, alors tu as surtout besoin d'une base qui met en relation :

    • un objet et une coordonnée géographique
    • une ville et une coordonnée géographique

    Il n'y a pas nécessairement de relation directe entre un objet et une ville.

    C'est peut-être plutôt une base de données plates dont tu as besoin…

    Les SGBDR ne sont pas la réponse à n'importe quel besoin de stockage…

    https://www.domotego.com/ | https://www.maccagnoni.eu/ | https://www.smm-informatique.fr/

    • [^] # Re: SQL, vraiment ?

      Posté par . Évalué à 2.

      C'est sûr que c'est pas la réponse immédiate ni le seul choix, mais :
      Comme dit plus haut, Postgresql avec PostGis fait très bien l'affaire,
      comme je le voie à l’œuvre depuis quelques mois sur un projet professionnel.

      • [^] # Re: SQL, vraiment ?

        Posté par (page perso) . Évalué à 1.

        Postgis est une référence en la matière. Ce moteur de base de donnée est utilisé par les plus grand. Il existe aussi des librairies qui font le job par exemple geotools en java. Il y en a une qui a l'air bien en python mais je ne me rappelle plus son nom.

        • [^] # Re: SQL, vraiment ?

          Posté par (page perso) . Évalué à 3.

          Une lib bien en python ? Tu parles de PPyGIS ?

          • [^] # Re: SQL, vraiment ?

            Posté par . Évalué à 2.

            Je dirais que l'équivalent python de geotools est en partie Shapely. Sinon pour utiliser postgis2 avec python, je te conseille Geoalchemy2 qui est vraiment très complet.

            Geotools est un toolkit tellement complet.

            • [^] # Re: SQL, vraiment ?

              Posté par (page perso) . Évalué à 3.

              Geoalchemy2 ça me paraît nickel pour mon appli cible, vu que j'envisage de développer sur Turbogears. :)

              • [^] # Re: SQL, vraiment ?

                Posté par . Évalué à 0.

                Turbogears?

                Ça existe encore?

                Je pense que Pylons ou flask sont un peu plus vivant. ^

                • [^] # Re: SQL, vraiment ?

                  Posté par (page perso) . Évalué à 2.

                  En fait dans l'ordre des choses, pour "remplacer" Turbogears il foudrait s'orienter vers Pyramid. L'intérêt de Turbogears par rapport à Pyramid c'est que c'est un framework "full stack". Certains risquent de s'engouffrer dans la brêche pour dire que Django est mieux, mais en fait, pour diverses raisons, Django ne répond pas non plus à tout ce à quoi répond Turbogears. La manière dont se présentent les projets est d'ailleurs significative :

                  • TurboGears will help you to create a database-driven, ready-to-extend application in minutes.
                  • Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design.

                  TurboGears est orienté "développement rapide d'applications basées sur des bases de données".
                  Django est orienté "développement web en python, pragmatique et rapide". C'est un framework Haut niveau (ce qu'est aussi TurboGears).
                  Des framework comme Pyramid, par exemple, sont moins "full stack", et donc nécessitent d'intégrer les différentes lib entre elles (exemple : SQLAlchemy)

  • # optimisation

    Posté par . Évalué à 1.

    Je ne suis pas un expert en SQL, mais le calcul de distance est relativement couteux et j'imagine qu'en faisant une requete du type:
    SELECT * WHERE distance(A,B) < d; Le SGBD va avoir du mal a indexer correctement.
    Plusieurs pistes pour optimiser:
    Faire un premier filtrage dans une boite englobante du genre:
    pour les points a une distance d de P.
    select * as A where A.x < P.x+d and A.x > P.x-d and A.y < P.y+d and A.y > P.y-d;
    tu pourras ensuite calculer la distance sur ce sous-résultat.
    Un calcul de distance implique l'utilisation de racine carré, mais du coup tu peux encore optimiser un poil en comparant la distance au carré. (P.x-A.x)²+(P.y-A.y)² < d²

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.