A partir d'un point GPS, obtenir le nom de la commune

Bonjour,
Je voulais savoir s’il existait des utilitaires, qui à partir d’un point GPS (coordonnées long/lat)fournissent la commune à laquelle ce point appartient? Ce qui nécessite derrière une requête spatiale avec des limites de communes assez précises.

Merci par avance,

Cordialement,

Magali Giaume
Etudiante du mastère SILAT
magali@giaume.com

Je ne connais pas d’outils “tout prêt” pour faire ça.

Par contre, en important les communes dans une base POSTGRES/POSTGIS on peut ensuite faire des requêtes spaciales qui peuvent faire ce que tu veux.

Après un import avec osm2pgsql, une requête de ce type m’a donné satisfaction :

select osm_id,name from planet_osm_polygon 
where way && transform('SRID=4030;POINT(6.0333 45.7666)',900913) 
and
_ST_Contains(way,transform('SRID=4030;POINT(6.0333 45.7666)',900913));

Je relance le sujet ici, car j’ai exactement la même problématique.

Peut-être qu’en 3 ans de nouveaux outils ont fait leur apparition ?
(je ne maîtrise pas la méthode expliquée ci-dessus :nerd: ).

Pour une recherche précise dans les polygones de communes déjà présents dans OSM la recette n’a pas changé.

On peut aussi faire une reverse geocoding via nominatim… mais le résultat n’est pas forcément toujours aussi précis et valide.

Exemple: http://nominatim.openstreetmap.org/reverse?format=xml&lat=48.7&lon=2.5&zoom=18&addressdetails=1

Voir: http://wiki.openstreetmap.org/wiki/Nominatim#Reverse_Geocoding_.2F_Address_lookup

Merci pour la réponse, j’ai réussi à faire ce que je voulais avec MapInfo.

Avec les données osm importées dans Mapinfo ou d’autres données ?

D’autres données.

Tiens, coincidence j’avais aussi besoin de récupérer du géojson cette semaine d’une commune en donnant la latitude et longitude.

J’ai fait ceci :
http://osm7.openstreetmap.fr/~etrimaille/showCom/index.php?lat=47.5&lon=6.5

Je voulais savoir si il était possible d’améliorer le temps de traitement. C’est a peu près la même requête que sly.
Je me doute que la requête ne va jamais être instantanée. Mais c’est pour ma culture :wink:

Et ben, ça marche ton truc, c’est l’essentiel, non ?

Je viens de cliquer, et on ne peut pas non plus dire que ça prenne des heures (la page s’est affichée en ~4s)

Sachant que je peux en compter 2 pour le chargement de openlayers, 1 pour le chargement de la géométrie, 0.5 pour l’affichage et 0.3 pour les aller-retour de connexion, ça te fait la requête en 200ms, on va pas non plus se plaindre, si ?

Toutefois, tu peux toujours la coller ici et je te dirais ce que j’en pense

Difficile de dire le temps la, je suis en 3G dans le train. :slight_smile:
Mais quand j’ai fait ca rapidement cette semaine ca mettait en moyenne 15 secondes. Mais la si c’est 4 secondes c’est largement acceptable. Osm7 était peut-être un peu surchargé mardi soir …

15 secondes ?? osm7 est une bonne machine et même si elle fait plein de chose, ça ne devrait pour ainsi dire jamais être aussi mauvais que 15s, tu peux rajouter un print(""); quelque part histoire qu’on puisse voir cette requête ? (rien de confidentiel j’imagine) et ça me permettrait d’y jeter un coup d’oeil

Vim en ssh sur une connexion très lente, c’est pas encore çà :stuck_out_tongue:

Bon, je viens de regarder un peu le temps d’exécution :
http://osm7.openstreetmap.fr/~etrimaille/showCom/index.php?lat=47.5&lon=6.5

Si tu fait ctrl+u pour les sources, en haut il y a :

SELECT ST_asgeojson(ST_TRANSFORM(way,4326)) as way FROM planet_osm_polygon WHERE "boundary"='administrative' and "admin_level"='8' and ST_Contains(ST_TRANSFORM(way,2154),ST_TRANSFORM('SRID=4326;POINT(6.5 47.5)',2154)) LIMIT 1
Début requête : 11:06:15
Fin requête : 11:06:28
Requête exécuté en 13.208 sec

Le temps d’exécution est mis sur le pg_query().
Mais en relisant la requête, je me dis qu’il y a un st_transform de trop, non ?
Pourquoi ne pas reprojeter directement dans le système de projection de la base, ca doit être du 900913 ?

SELECT ST_asgeojson(ST_TRANSFORM(way,4326)) as way FROM planet_osm_polygon WHERE "boundary"='administrative' and "admin_level"='8' and ST_Contains(way,ST_TRANSFORM('SRID=4326;POINT(6.5 47.5)',900913)) LIMIT 1
Début requête : 11:16:23
Fin requête : 11:16:23
Requête exécuté en 0.188 sec

C’est pas mieux comme çà ? :smiley:
Si c’est juste …

J’aime rendre service sans n’avoir rien fait :slight_smile:

le résultat devrait etre le meme, c’est juste qu’au lieu de “transformer” la géométrie de la commune,tu le fais juste sur le point. Mais surtout, tu permets l’utilisation des indexes qui eux, sont valables sur la projection 900913

J’aime rendre service sans n’avoir rien fait > :slight_smile:

Si, en me demandant à voir ma requête, tu m’a indirectement inviter à relire ma requête. Mes résultats étaient anormaux. :wink:

le résultat devrait etre le meme

Comment çà il peut y avoir des différences ? De quelques cm ? m ?

Mais surtout, tu permets l’utilisation des indexes qui eux, sont valables sur la projection 900913

Les indexes, ce n’est que des bbox rectangulaires pour éliminer plus rapidement les nombreuses communes au premier calcul ?

En gros, oui.

Par contre, il faut rester dans la projection des données indexées, sinon on ne peut pas comparer des choux et des carottes.

Vu que la table planet_osm_polygon provient du schéma osm2pgsql qui est généralement projeté en 900913 (Google Mercator) pour générer des tuiles dans cette projection, il vaut mieux transformer le point à chercher en 900913 pour tirer parti de l’index.

Comment çà il peut y avoir des différences ? De quelques cm ? m ?

non non, je voulais juste dire que je n’ai pas testé ta requette et bien qu’elle ait l’air correct, ça n’exclu pas un bug.

je pourrais toutefois chipotter en disant que même 0.2s ça me semble encore améliorable. Mais bon, on va pas non plus trop se plaindre.

Dès que je peux, je teste sur osm105 ta requête et je vois si ajouter d’autres conditions/indexes peut encore améliorer.
(comme and ref:INSEE is not NULL ou utiliser le champ simplified_way de la table polygon)

Bon, pas facile d’améliorer encore, les meilleurs résultats que j’obtiens sur osm7, c’est en utilisant exactement la même requête, mais avec la géométrie simplifiée (en remplaçant way par simplified_way) ce que je fais en fait pour mes tests de commune
Je tombe aux alentours de ~50ms mais c’est variable et ça présente le défaut qu’aux bordures, ça peut se tromper.
Mais rajouter des conditions ne semble pas transcender la semoule.

Bref, je crois que ta requête va très bien comme ça :wink:

Merci pour les explications cquest et sly.

Cela dépend de ce que contient osm105 ? C’est que la france élargie aussi ?
Est-ce que postgis exécute d’abord les requêtes non géographiques ? L’idée du ref:insee est bonne, car j’imagine que cela peut éliminer certaines relations probables étrangères à la france.

Et pour les simplified_way, j’ai testé, quand j’ai vu la géométrie, j’ai trouvé çà un peu trop coupé à la tronconneuse :smiley:
Et si mon point entre 2 simplified_way, c’est perdu je pense donc forte probabilité d’avoir pas de réponse.

Merci tout de même pour le test sur osm105.
J’ai une autre question sur postgis, mais je vais passer sur dev-fr :wink:

osm105 est une base monde

Pour une requête régulière, il peut être intéressant d’avoir un index dédié comprenant et la geométrie et une autre valeur (comme le ref:INSEE) dans le cas présent surtout avec les index partiel de postgres !