FOSS4G-fr : l’événement francophone majeure de la géomatique Open Source

Les 20, 21 et 22 mai sera organisé le premier événement francophone autour de la géomatique open source (FOSS signifiant Free et  Open Source). Après l’événement FROG en 2013, la deuxième édition prend de l’ampleur : plus de conférences, des workshops (on dirait plutôt Travaux Pratiques en bon françois).

Pourquoi y aller ? Il existe de nombreuses bonnes raisons : rencontrer les développeurs (ils parlent une langue proche de la votre et sauront s’adapter) et discuter sur leurs travaux actuels et futurs, d’autres usagers des projets open source qui sauront partager leur point de vue, besoins et solutions qui vous intéresseront, des membres de la communauté OSGeo-fr et notamment des membres du bureau de l’association, des anciens membres du bureau.

Cet événement me fait vraiment penser à mon premier FOSS4G (international celui-là) à Lausanne en 2006  : de la technique mais pas trop et à mon niveau (à cette époque j’étais un vrai débutant et j’y ai  beaucoup appris), un aperçu de ce qui se fait actuellement afin de me mettre à niveau sur le plan des usages actuels, une bonne ambiance et de la bonne humeur que j’apprécie toujours.

Le FOSS4G-fr c’est tout ca et en même temps ca sera complètement différent : car ce sera en français ! Et pour moi, ce sera le moment de partager ce que j’ai appris depuis ce fameux premier FOSS4G, de trouver de nouvelles idées, ce sera aussi, pour moi, la possibilité de discuter avec les développeurs des projets que j’affectionne.

Les présentations et travaux pratiques sont listés dans le programme, si je dois en retenir que quelques uns (donc forcément objectif et non exhaustif), commençons par les TP :

• Automatiser avec QGIS par Jean-Roc Morreales
  
• LizMap par Michaël DOUCHIN et Réné-Luc D’HONT
• TileMill par Sylvain Berochia
• Les plugins dans QGIS par Hugo Mercier
• Talend : François Prunayre Etienne Taffoureau et moi même

Je m’arrête là car je suis en train de tous les lister … J’oublie bien sur PostGIS avancé, MapServer/GeoServer et la directive INSPIRE, etc.

Les conférences auront lieu le 21 et 22 mai :

• OpenLayers 3
• MapServer 7.0
• geOrchestra
• des présentations sur des plugins QGIS
• GeoNetwork
• La plateforme SmartData du Grand Lyon
• OpenTripPlanner Analyst
• Import du cadastre dans une base PostGIS
• La topologie dans PostGIS : un cas d’utilisation

etc.

Notez deux conférences intéressantes et hors FOSS : nous aurons droit à deux conférences par directement lié au FOSS4G mais qui les impactent : Quelle expérience géographique à l’heure du géoweb ? par Thierry Joliveau et Évolutions européennes en cours sur INSPIRE par Marc Leobet.

Il me reste juste à vous dire de vous dépêcher de vous inscrire, l’année dernière le nombre d’inscrit a atteint la limite haute des possibilités ! Les sponsors sont prêts, l’organisation aussi, les petits fours aussi ou presque (car les repas du midi sont pris en charge). Passons quelques jours ensemble !

À très bientôt 😉

Souscrire aux commentaires de cet article

[GDAL-OGR] Mode ajout dans une base de données PostGreSQL

Il y a quelques temps je devais importer des données au format EDIGEO dans une base PostGreSQL/PostGIS existante. J’avais plusieurs fichiers THF à importer par conséquent je devais créer la table puis importer les fichiers les nus après les autres. Après lecture attentive de la documentation puis poser quelques questions sur la liste gdal, voici la méthode ainsi que les petites astuces qui font la différence.

Visualisation du problème

Puisque la table n’existe pas au premier fichier THF, il faut que la commande ogr2ogr s’en occupe puis, dans un deuxième temps, il faut que cette même commande ajoute les données. La doc est assez clair là dessus : il faut lancer deux commandes l’une après l’autre (en fait seules quelques options sont différentes) :

ogr2ogr -gt 65536 -f "PostgreSQL" "PG:dbname=test  host='localhost'" -lco "GEOMETRY_NAME=the_geom" -lco "SCHEMA=test" -lco "OVERWRITE=YES" -nln EDIGEO_parcelle  E0001.THF PARCELLE_id

Cette commande s’exécute sans problème. Les options utilisées ici sont les suivantes :

• -gt 65536 : permet de grouper les géométries par groupe de 65 536 géométries avant de les commiter. Cela évite de commiter les géométries les unes après les autres. La valeur utilisée est celle préconiser par la documentation.
• -lco « SCHEMA=test » : importer les données dans un schéma particulier.
• -lco « GEOMETRY_NAME=the_geom » : totalement inutile mais j’aime bien avoir une cohérence dans mes noms de colonnes géométriques.
• -lco « OVERWRITE=YES » : obligatoire quand on fait plusieurs essaie ou quand la table existe déjà pour cause d’import déjà réalisé. Cette option indique que la table sera écrasée (détruite puis recrée).
• -nln EDIGEO_parcelle : donner un nom différent à la table que l’on va créer. Notez le mélange de majuscules et de minuscule, nous en reparlerons plus tard.

La deuxième commande que j’ai testé pour ajouter les données à une table existante esty celle-ci :

ogr2ogr -append -update -gt 65536 -f "PostgreSQL" "PG:dbname=test host='localhost'" -lco "GEOMETRY_NAME=the_geom" -lco "SCHEMA=test" -nln EDIGEO_parcelle  E0002.THF PARCELLE_id

Et là, ca marche beaucoup moins bien car je reçois ce message :

ERROR 1: Layer test.edigeo_parcelle already exists, CreateLayer failed.
Use the layer creation option OVERWRITE=YES to replace it.
ERROR 1: Terminating translation prematurely after failed
translation of layer PARCELLE_id (use -skipfailures to skip errors)

Et les logs de PostgreSQL montrent que cela ne provient pas de la base de données :

Postgresql log file shows:
2013-03-06 15:35:44 CET LOG:  could not receive data from client: Connection
reset by peer
2013-03-06 15:35:44 CET LOG:  unexpected EOF on client connection

Compréhension du problème et solution

En regardant les logs d’un peu plus près, voici ce que l’on y trouve :

1. le nom de la table créée est test.edigeo_parcelle, ce qui est incorrecte en regard de la commande que j’ai lancé (le nom de la table aurait dû être EDIGEO_parcelle.
2. une commande est réalisée lors du mode ajout et celle-ci ne cherche pas la table dans le schéma test mais dans le schéma public.

Ces deux problèmes peuvent être réglés de plusieurs manières différentes.

La solution « fainéant »

Résumons la par « Ah ben ca marche pas avec des majuscules et dans un schéma autre que le schéma public, tant pis ». La solution ici est de mettre le nom de la table en minuscule (bonne pratique) et celle-ci dans le schéma public (pas bien !).

La solution dite de « contournement »

Elle s’approche de la première car elle n’utilise pas les options nécessaires (et ajoutées pour) ce cas de figure et elle ne sert qu’au deuxième problème (celui du schéma) :

ogr2ogr -append -update -gt 65536 -f "PostgreSQL" "PG:dbname=test host='localhost'" -nln test.edigeo_parcelle  E0002.THF PARCELLE_id

Notez ces modifications :

1. -lco « SCHEMA=test » et -lco « GEOMETRY_NAME=the_geom » ont été supprimés car inutile. Les options -lco ne sont pas utilisées en mode append ou update (ben oui le c de lco est pour « création », logique !).
2. le nom de la table dans l’option -nln a été modifié en test.edigeo_parcele : tout en minuscule et ajout du schéma

La solution qui utilise les bonnes options

Comprenons bien les problèmes. Un premier problème vient du fait que le nom de la table que nous souhaitons créer contient des majuscules qui sont transformés en minuscule. Le deuxième problème vient du fait que nous utilisons une option de création pour définir le schéma dans lequel insérer des données alors que nous somme en mode append/update.

Nettoyage des noms de couches/table, colonne

Le pilote PostgreSQL dans GDAL/OGR contient un système de nettoyage des valeurs données lors de la création d’une couche. Cette option se nomme « LAUNDER » et est définie dans la page du pilote : http://gdal.gloobe.org/ogr/formats/pg.html (en français) :

Elle peut être définie à *YES* pour forcer les nouveaux champs créés sur cette couche à avoir les noms de champs « nettoyés » dans une forme compatible avec PostgreSQL. Cela convertie la valeur en minuscule ainsi que certains caractères spéciaux comme « – » et « # » en « _ ». Si la valeur *NO* est utilisée les noms exacts seront préservés. La valeur par défaut est *YES*. Si activé le nom de la table (couche) sera également nettoyé.

Si l’on souhaite garder nos majuscules il faut définir cette option à « NO ».

Définition du schéma en mode append/update

Lorsque nous somme en mode append ou update, nous ne somme pas en mode de création. C’est peu de le dire, c’est évident, mais au final on n’en saisit pas toujours les conséquences : les options de création ne nous serons d’aucune utilité ! Heureusement il y a une possibilité : le paramètre « active_schema » dans la chaîne de connexion. Notre commande devient alors :

ogr2ogr -append -update -gt 65536 -f "PostgreSQL" "PG:dbname=test host='localhost' active_schema=test" -nln edigeo_parcelle  E0002.THF PARCELLE_id

Merci à Even Rouault pour son aide sur la liste.

Souscrire aux commentaires de cet article

Export OSM France en Shapefile

Un export au format Shapefile vient d’être publié sur le site http://download.qualitystreetmap.org/osm/. Cette mise à jour date du 26/11/2010. D’autres mises à jour seront publiés régulièrement, l’objectif étant d’industrialiser cela.
Vous y trouverez :

• admin_level.zip : limites communales, départementales, régionales et nationales – 171 Mo
• amenity.zip : education, entertainment (cinéma, théatre), restaurant/pub/café, finance, santé, transport (couche ponctuelle) – 4.4 Mo
• leisure.zip : sport, etc. – 4.1 Mo
• urbanism.zip : routes, autres routes, rails, stations, adresses – 191 Mo

D’autres thématiques seront ajoutées en fonction de la demande.

Souscrire aux commentaires de cet article

Données thématiques libres OSM sur la France

Je considère toujours les données OSM comme des données brutes enregistrées dans une base de données. En l’état peu de chose peuvent être réalisé. Il faut toujours un peu de traitement : du nettoyage, créer des méta-données, différentes projections, différents formats de fichiers, des thématiques différentes et d’autres contraintes.

Lire plus »

Souscrire aux commentaires de cet article

Sortie de la version 1.4.0 de PostGIS

L’équipe de développement de PostGIS vient d’annoncer la sortie d’une nouvelle version (la 1.4.0) après une « période de médidation et de recherche intérieure » (je cite l’annonce). La version est téléchargeable ici : http://postgis.refractions.net/download/postgis-1.4.0.tar.gz
Cette nouvelle version de PostGIS inclus une augmentation importante de la performance, une documentation améliorée, un nouveau format en sortie (GeoJSON) et un système interne amélioré de teste. PostGIS 1.4 gère la version récente de PostgreSQL 8.4.

Compatibilité minimale :

• PostgreSQL 8.2 et supérieure sur toutes les plateformes ;
• GEOS 3.0 et supérieure seulement ;
• PROJ4 4.5 et supérieure seulement.

Nouvelles fonctionnalités :

• ST_Union() utilise l’union rapide en cascade lorsqu’il est compilé avec GEOS 3.1+ (Paul Ramsey) ;
• ST_ContainsProperly() nécessite GEOS 3.1+ ;
• ST_Intersects(), ST_Contains(), ST_Within() utilise les géométries préparées en cache super rapide en fonction de GEOS 3.1+ (Paul Ramsey) ;
• amélioration importante de la documentation et du manuel de référence (Regina Obe & Kevin Neufeld) ;
• exemples de figures et de diagrammes dans le manuel de référence (Kevin Neufeld) ;
• ST_IsValidReason() renvoi des explications explicites sur l’échec de la validité (Paul Ramsey) ;
• ST_GeoHash() renvoi une signature geohash.org pour les géométries (Paul Ramsey) ;
• Interface multi-plateforme pour le chargement de Shape (Paul Ramsey) ;
• ST_LineCrossingDirection() renvoie des directions de passage (Paul Ramsey) ;
• ST_LocateBetweenElevations() renvoie des sous-chaînes basé sur Z-ordonnées (Paul Ramsey) ;
• le parser de géométrie renvoi des messages d’erreur explicites sur l’endroit des erreurs de syntaxe (Mark Cave-Ayland) ;
• ST_AsGeoJSON() renvoie un format JSON ;
• Populate_Geometry_Columns() — ajoute automatiquement les enregistrements dans les tables geometry_columns pour les TABLES et les VIEWS (Kevin Neufeld) ;
• ST_MinimumBoundingCircle() — renvoie le plus petit polygone circulaire qui peut entourer une géométrie (Bruce Rindahl).

Amusez vous bien !

Souscrire aux commentaires de cet article

En vrac

Je pensais ne jamais faire ce genre de message, mais je dois bien avoué que certaines informations méritent d’être relayé ici sans qu’il ne soit possible d’en faire un article. Donc voici un « en vrac » premier d’une série, entre coupé d’article plus long, en préparation.

Souscrire aux commentaires de cet article

Un WebSIG complet, en utilisant PostGIS et X3D

Le Foss4G édition 2007 n’a vu que peu de présentations sur la gestion et le rendu de données 3D. Mais cette présentation par Olivier Courtin donne un aperçu du processus complet de stockage, traitement, export et visualisation de données 3D.

Il montre comment PostGIS a été amélioré pour gérer des données 3D dans le but de fournir un SIG 3D complet dans un contexte web. Ce travail est lié à une collaboration entre les sociétés TPLM3D et Camptocamp.

Lire plus »

Souscrire aux commentaires de cet article