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 LeBouquetin (site web personnel, Mastodon) . É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 NeoX . Évalué à 2.
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 LeBouquetin (site web personnel, Mastodon) . É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 NeoX . É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 LeBouquetin (site web personnel, Mastodon) . É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 Sébastien Maccagnoni (site web personnel) . É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 :
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…
[^] # Re: SQL, vraiment ?
Posté par barret benoit . É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 MrBidon . É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 LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
Une lib bien en python ? Tu parles de PPyGIS ?
[^] # Re: SQL, vraiment ?
Posté par NabZ . É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 LeBouquetin (site web personnel, Mastodon) . É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 NabZ . Évalué à 0.
Turbogears?
Ça existe encore?
Je pense que Pylons ou flask sont un peu plus vivant. ^
[^] # Re: SQL, vraiment ?
Posté par LeBouquetin (site web personnel, Mastodon) . É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 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 errno . É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²
[^] # Re: optimisation
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
Optimiser les recherches, créer des index adéquats, des boîtes englobantes, j'imagine que c'est ce dont se charge des soft comme PostGIS ; d'où ma question initiale : un tuto pour utiliser PostGIS.
J'ai l'impression, ceci dit, qu'avec ma liste de villes, PostGIS installé et une couche "d'abstraction" telle que PPyGIS devraient faire l'affaire…
Si j'ai bien compris, je vais faire ça :
* j'enregistre mes villes comme des points (latitude et longitude) - http://www.fabianowski.eu/projects/ppygis/classes.html#point-single-point
* je vais enregistrer les départements sous forme de Collection (de villes/points) - http://www.fabianowski.eu/projects/ppygis/classes.html#geometrycollection-collection-of-arbitrary-geometry-objects
* je vais enregistrer les régions sous forme de liste de Collections (contenant les départements associés)
Et ensuite je vais requêter :)
[^] # Re: optimisation
Posté par MrBidon . Évalué à 2.
Concernant Postgis je trouvais ce tuto pas trop mal fait : http://2010.foss4g.org/workshop04.php
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.