GeoBases, services et visualisation pour données géographiques

Posté par  . Édité par Nÿco, claudex et baud123. Modéré par baud123. Licence CC By‑SA.
Étiquettes :
21
28
jan.
2013
Python

GeoBases est un projet dont le but est de fournir des services et des possibilités de visualisation pour des données géographiques. En réalité cela fonctionne également avec des données non-géographiques, mais cela limite les possibilités de cartographie.

Le projet contient déjà des sources de données issues d'autres projets (comme GeoNames ou optd), ou encore de l'OpenData. Par défaut une source de données d’aéroports est utilisée. Il est très simple d’ajouter ses propres sources de données pour pouvoir jouer avec.

Parmi les services disponibles :

  • exécuter de simples recherches (trouver cette donnée, trouver toutes les entrées qui ont cette propriété)
  • exécuter des recherches approximatives basées sur une notion de distance entre chaîne de caractères (trouver les données dont le nom ressemble à cela)
  • exécuter des recherches géographiques (trouver les données proches de ce point)
  • afficher les résultats sur une carte, ou bien les exporter en CSV, ou encore utiliser une API Python pour les manipuler directement

Le projet est entièrement en Python, la partie cartographie utilise Google Maps API. C’est un unique package Python, il y a également une interface en ligne de commande plutôt complète.

Installation

Le package est sur PyPI, donc ceci fonctionne :

% easy_install GeoBases

Il est également possible de récupérer la version de développement depuis github.

Exemples en ligne de commande

Comment voir où sont situés les aéroports dont le nom contient international :

% GeoBase --fuzzy international --map

Map

Pour obtenir de simples informations sur les aéroports de Nice et Los Angeles :

% GeoBase LAX NCE

CLI

Et un dernier exemple avec l'interface en ligne de commande, trouver les données proches de l’aéroport de Bordeaux et en extraire le nom :

% GeoBase --near BOD --quiet --show name
Bordeaux-Mérignac
Bordeaux
Gare de Bordeaux-Saint-Jean
Libourne
Arcachon - La Teste-de-Buch
Arcachon

Exemples avec Python

Un exemple d'utilisation de l'API Python :

>>> from GeoBases import GeoBase
>>> g = GeoBase(data='ori_por', verbose=False)
>>> g.get('ORY', 'name')
'Paris-Orly'
>>> sorted(geo_o.findNearPoint((48.85, 2.35)))[0]  # Paris
(0.389, 'PAR')

De nombreux autres exemples sont disponibles sur le site du projet.

Conclusion

Ce projet est encore jeune, toute suggestion de fonctionnalité est la bienvenue !

Aller plus loin

  • # OpenStreetMap ?

    Posté par  . Évalué à 10.

    Ce qui m'a sauté aux yeux immédiatement, c'est l'horrible logo Google accompagné du copyright Tele Atlas, sur tous les fonds de carte. Est-il possible d'utiliser les cartes OSM ? J'ai du mal à concevoir qu'un projet libre puisse utiliser des cartes non libres.

    • [^] # Re: OpenStreetMap ?

      Posté par  . Évalué à -6.

      comme vous j'avais pensé voir comment cela fonctionnerait avec openstreetmap…

      @Auteur
      Ce serait bien de donner des exemples avec OpenStreetMap

    • [^] # Re: OpenStreetMap ?

      Posté par  . Évalué à 3.

      Comme précisé dans les autres commentaires, OSM est utilisé par défaut depuis hier matin. Nous avons commencé à collecter les différentes remarques, questions et réponses sur le wiki du projet.

      Toute critique est la bienvenue :).

  • # Sympa ....

    Posté par  (site web personnel) . Évalué à 7.

    Intéressant projet :) …
    une suggestion? L'utilisation de OSM par exemple? au moins en option…
    leaflet ou Openlayers sont des très bonne librairie pour manipuler les données carto:)

    ça ferais un peu plus de libre pour le projet en bénéficiant de la renommée de ces projets

    • [^] # Re: Sympa ....

      Posté par  . Évalué à 6.

      Effectivement Google Maps a de bonnes alternatives. Je pense que c'est envisageable d'utiliser des fonds de carte libres à terme.

      • [^] # Re: Sympa ....

        Posté par  (site web personnel) . Évalué à 10.

        à terme.

        pour un projet souhaitant faire de l'opendata, cela semblerait un pré-requis…

        • [^] # Re: Sympa ....

          Posté par  . Évalué à 10. Dernière modification le 29 janvier 2013 à 10:30.

          Enfin "à terme", je voulais dire demain :).

          Je viens de commiter l’intégration d'OSM pour la partie fond de carte. Maintenant l'utilisateur a le choix du fond de carte, mais celui par défaut est bien OSM.

          L'API javascript utilisée est en revanche toujours Google Maps, le passage à leaflet requiert cependant un peu plus de code à écrire. J'ai mis à jour les images sur le site.

          Dans la mesure où ce projet sert notamment à vérifier des jeux de données géographiques en les plaçant avec des fonds de carte, il me semble utile de laisser le choix afin de pouvoir croiser les informations. Par exemple :

          $ echo 'd1 48.22 2.33\nd2 49.33 2.24' |GeoBase --map

  • # Désolé...

    Posté par  (site web personnel) . Évalué à 1.

    trouver cette données

    Il y a un s en trop.

    Sinon je plussoie les commentaires sans OpenStreetMap le projet perd beaucoup. Vivement que la proposition de quelqu'un sur la liste de diffusion @talk-fr donne quelque chose : http://lists.openstreetmap.org/pipermail/talk-fr/2013-January/054215.html

  • # Utilisation d'autres données

    Posté par  . Évalué à 3.

    Je n'ai pas trouvé dans la doc comment utiliser d'autres sources de données. Est-ce possible sans passer par une modif du fichier yml ? quels formats sont supportés, uniquement csv ?

    • [^] # Re: Utilisation d'autres données

      Posté par  . Évalué à 4.

      Effectivement il devient urgent de créer des pages de wiki :).
      Si le fichier est formaté en CSV, l'utilisation suivante doit fonctionner:

      $ cat file.csv | GeoBase -i delimiter headers indexes

      Avec headers pour le nom des colonnes séparées par un '/', indexes pour les colonnes qui servent d'index. Par exemple:

      $ cat file.csv
d1 48.22 2.33
d2 49.33 2.24
$ cat file.csv | GeoBase -i ' ' name/lat/lng name

      Pour rajouter file.csv comme un nouvelle source de données permanente, il faut effectivement modifier le fichier YAML.

      Si le fichier n'est pas formaté en CSV, il faut utiliser l'API Python pour remplir la base à la main.

      Soit on arrive à transformer la source sous forme de file-like, auquel cas on peut loader d'un coup comme ceci (en reprenant le même fichier comme exemple):

      >>> from GeoBases import GeoBase
>>> g = GeoBase(data='feed', 
...             source=open('file.csv'),
...             delimiter=' ',
...             headers=['name', 'lat', 'lng'],
...             indexes = ['name'])
>>> g.getLocation('d1')
(48.22, 2.33)
>>> g.visualize()

      Soit il faut créer l'objet vide et le remplir à la main comme cela:

      >>> from GeoBases import GeoBase
>>> g = GeoBase('feed')
>>> g.set('d1', 'lng', 2.4)  # ces données proviennent d'ailleurs
>>> g.set('d1', 'lat', 48.2)
>>> g.visualize()

      Je viens de fixer un bug pour que la dernière ligne fonctionne :).

      • [^] # Re: Utilisation d'autres données

        Posté par  . Évalué à 3.

        Tu ne supportes que du lon/lat, ou bien on peut lui fournir des données dans des référentiels différents?

        • [^] # Re: Utilisation d'autres données

          Posté par  . Évalué à 2.

          En effet pour les input, pour l'instant, je ne supporte que lat/lon, qui est un format très standard.

          J'ai quelques outils de conversion déjà présents ici, mais je suppose que je pourrais soit nativement supporter d'autres formats (ce qui me semble ajouter de la complexité pour un gain pas évident), soit juste fournir les outils de conversion directement dans le package.

          Tu pensais à un format particulier? Mercator?

          • [^] # Re: Utilisation d'autres données

            Posté par  . Évalué à 4.

            Je pensais essentiellement aux formats du RGF93 (Lambert93 d'une part, et les multiples coniques conformes associées d'autre). Les anciennes projections de la NTF peuvent être utiles aussi (Lambert Zone, etc.) Et je suppose que dans d'autres pays des besoins comparables existeront.

            Bref, il y a déjà des bonnes bibliothèques en Python (proj4?) qui permettent de gérer tout cela, ce serait dommage de s'en priver. Par contre, effectivement, il ne faut pas que ça se fasse au détriment de la simplicité. Tu devrais - il me semble - continuer à gérer une projection par défaut, mais permettre de la modifier (en conservant WGS84 comme choix initial). Et puis - idéalement - il faudrait trouver la moins mauvaise manière de spécifier la projection (sous forme de code EPSG?) d'une source de données particulière.

Suivre le flux des commentaires

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