619 fonctions avancées d’analyses spatiales

QGis n'est pas un outil très utilisé au Québec, par contre les Analystes en Géomatique doivent absolument y jeter un oeil.  Nous utilisons QGis dans la très grande majorité de nos projets chez Solutions Mapgears.  Je n'avais pas encore regardé ce que pouvait offrir l'extension Sextante (aussi disponible sous ArcGIS et gvSIG), probablement parce que ma todolist est un peu trop longue! Bref, ce post d'Oslandia n'avait pas eu encore de suite.

Incroyable, mais on retrouve dans la toolbox de l'extension, pas moins de 619 géoalgorithmes!  GDAL, GRASS, SAGA, OTB(télédétection), R (statistique)....     Vrai que l'interface utilisateur de GRASS n'est pas très sexy, mais on pourra quand découvrir sa puissance via la liste interminable de fonctions dans le toolbar Sextante.  De plus, l'outil dispose d'un "Modeler" mais là vraiment je peux pas en dire plus je ne l'ai pas testé ...

J'ai aussi découvert l'outil d'analyses géoscientifiques System for Automated Geoscientific Analyses (SAGA) un logiciel FOSS.  Le plugin Sextante propose 279 algo de cette plateforme. Le développement semble avoir cessé en 2007, par contre l'outil est le fruit de plusieurs années de développement et vaux vraiment la peine d'être examiné. À mettre sur votre todolist donc!

Produire un effet de “couleur dégradée” avec Mapserver

Nous avons  travaillé sur un projet de Web mapping dernièrement dans lequel on voulait produire un effet de "couleur dégradée" (fade to white) entre la terre ferme et l'océan. J'ai trouvé dernièrement une superbe carte dans l'"Atlas of Design" (que je recommande fortement pour les maniaques comme moi) de la NACIS (North American Cartographic Information Society).

À la page 64 on trouvera le genre d'effet de "couleur dégradée" en question:

On a l'habitude de voir ce genre d'effet dans un atlas et il s'agit la plupart du temps d'une retouche "photoshop". Il est par contre possible de reproduire l'effet avec une suite de buffers "concentrique" ou "excentrique" autour des entités d'une classe de provinces ou de continents par exemple pour "dégrader" la couleur de l'eau. Je me suis inspiré de d'une recette sur le forum SIG pour le faire dans PostGIS.

La méthode pourrait certe être plus optimale et performante si elle était gérée nativement dans Mapserver (nous acceptons volontier le financement pour le faire), par contre le résultat est superbe.

Donc première étape: chargement... shp2pgsql -s 3163 -c -g the_geom -I -W "latin1" QUARTIER_POLYGON.shp nc_noumea | psql -d nc -h 192.168.6.20 -p 5432 -U nc

Pour créer les anneaux "excentriques" j'ai utilisé ces suites de requêtes SQL. On devra jouer avec la largeur du buffer si on doit afficher le "fade effect" à plusieurs échelles et créer plus d'anneaux. Dans l'exemple suivant (de 0 a 35 mètres) on comprendra que l'effet ne sera visible qu'à très petite échelle. Si on veut appliquer la recette à plus grande échelle, il suffira simplement d'ajouter des anneaux supplémentaires ET à des intervalles plus larges.

NOTE: Merci à Vincent Picavet de la firme Oslandia pour le conseil de l'incroyable commande generate_series(), que je connaissais pas! Vraiment bien cette commande. Cette instruction SQL très compacte, va même créer la table pour moi! drop table nc_noumea_step; create table nc_noumea_step as select 0 as gid,0 as step,the_geom from nc_noumea; insert into nc_noumea_step (gid,step,the_geom) select 1 as gid,5 as step,ST_Difference(ST_Buffer(st_multi,5),ST_Buffer(the_geom,0)) from nc_noumea; insert into nc_noumea_step (gid,step,the_geom) select 2 as gid,10 as step,ST_Difference(ST_Buffer(st_multi,10),ST_Buffer(the_geom,5)) from nc_noumea; insert into nc_noumea_step (gid,step,the_geom) select 3 as gid,15 as step,ST_Difference(ST_Buffer(st_multi,15),ST_Buffer(the_geom,10)) from nc_noumea; insert into nc_noumea_step (gid,step,the_geom) select 4 as gid,20 as step,ST_Difference(ST_Buffer(st_multi,20),ST_Buffer(the_geom,15)) from nc_noumea; insert into nc_noumea_step (gid,step,the_geom) select 5 as gid,25 as step,ST_Difference(ST_Buffer(st_multi,25),ST_Buffer(the_geom,20)) from nc_noumea; insert into nc_noumea_step (gid,step,the_geom) select 6 as gid,30 as step,ST_Difference(ST_Buffer(st_multi,30),ST_Buffer(the_geom,25)) from nc_noumea; insert into nc_noumea_step (gid,step,the_geom) select 7 as gid,35 as step,ST_Difference(ST_Buffer(st_multi,35),ST_Buffer(the_geom,30)) from nc_noumea;
SELECT i as step, ST_Difference(ST_Buffer(st_multi,i),ST_Buffer(st_multi,i-5))
INTO nc_noumea_step
FROM nc_noumea n, generate_series(5,35,5) AS i;

On pourra utiliser un buffer négatif pour produire le même effet mais en dégradant la couleur vers l'intérieur (anneaux concentriques):

...
insert into communes_50_step (gid,cod_commun,step,the_geom) select gid,cod_commun,200 as step,ST_Difference(ST_Buffer(the_geom,-100),ST_Buffer(the_geom,-200)) as the_geom from communes_50;
insert into communes_50_step (gid,cod_commun,step,the_geom) select gid,cod_commun,300 as step,ST_Difference(ST_Buffer(the_geom,-200),ST_Buffer(the_geom,-300)) as the_geom from communes_50;
...

J’ai fait plusieurs essais dont des buffers successifs qui embarquent les uns sur les autres, mais l'effet est moins propre et le résultat moins prévisible. Le meilleur résultat et le plus flexible est vraiment une suite d'anneaux (buffers polygone) successifs qui n'empiètent pas les uns sur les autres. De cette façon on peut gérer la transparence avec couleur de fond pour chaque classe ET/OU des couleurs uniques ET/OU une orthophoto en fond de carte, tout est possible.

Enfin, dans le mapfile j'ai cartographié dans plusieurs CLASS chacun des anneaux désirés avec une transparence spécifique en dégradé :

LAYER
    TYPE POLYGON
    STATUS ON
    GROUP "zone"
    NAME "nc_contour_2_16"
    PROJECTION
        "init=epsg:3163"
    END
    MINSCALEDENOM 4096
    MAXSCALEDENOM 8192
    DATA "DATA_VDN/nc_noumea_step.shp"
    CLASSITEM "step"
    CLASS
        EXPRESSION "0"
        STYLE
            COLOR 255 255 255
        END
    END
    CLASS
        EXPRESSION "5"
        STYLE
            COLOR "#3fc1b7"
            OPACITY 80
        END
    END
    CLASS
        EXPRESSION "10"
        STYLE
            COLOR "#3fc1b7"
            OPACITY 60
        END
    END
    CLASS
        EXPRESSION "15"
        STYLE
            COLOR "#3fc1b7"
            OPACITY 50
        END
    END
    CLASS
        EXPRESSION "20"
        STYLE
            COLOR "#3fc1b7"
            OPACITY 40
        END
    END
    CLASS
        EXPRESSION "25"
        STYLE
            COLOR "#3fc1b7"
            OPACITY 30
        END
    END
    CLASS
        EXPRESSION "30"
        STYLE
            COLOR "#3fc1b7"
            OPACITY 20
        END
    END
    CLASS
        EXPRESSION "35"
        STYLE
            COLOR "#3fc1b7"
            OPACITY 10
        END
    END
END
LAYER
    TYPE POLYGON
    STATUS ON
    GROUP "zone"
    NAME "nc_contour_1_17"
    PROJECTION
        "init=epsg:3163"
    END
    MINSCALEDENOM 2048
    MAXSCALEDENOM 4096
    DATA "DATA_VDN/nc_noumea_step.shp"
    CLASSITEM "step"
    CLASS
        EXPRESSION "0"
        STYLE
            COLOR 255 255 255
            OUTLINECOLOR "#3fc1b7"
            WIDTH 0.4
        END
    END
    CLASS
        EXPRESSION "5"
        STYLE
            COLOR "#3fc1b7"
            OPACITY 50
        END
    END
    CLASS
        EXPRESSION "10"
        STYLE
            COLOR "#3fc1b7"
            OPACITY 30
        END
    END
    CLASS
        EXPRESSION "15"
        STYLE
            COLOR "#3fc1b7"
            OPACITY 10
        END
    END
END
LAYER
    TYPE POLYGON
    STATUS ON
    GROUP "zone"
    NAME "nc_contour_1_18"
    PROJECTION
        "init=epsg:3163"
    END
    MINSCALEDENOM 1500
    MAXSCALEDENOM 2048
    DATA "DATA_VDN/nc_noumea_step.shp"
    CLASSITEM "step"
    CLASS
        EXPRESSION "0"
        STYLE
            COLOR 255 255 255
            OUTLINECOLOR "#3fc1b7"
            WIDTH 0.4
        END
    END
    CLASS
        EXPRESSION "5"
        STYLE
            COLOR "#3fc1b7"
            OPACITY 50
        END
    END
    CLASS
        EXPRESSION "10"
        STYLE
            COLOR "#3fc1b7"
            OPACITY 20
        END
    END
END
LAYER
    TYPE POLYGON
    STATUS ON
    GROUP "zone"
    NAME "nc_contour_1_18"
    PROJECTION
        "init=epsg:3163"
    END
    MINSCALEDENOM 0
    MAXSCALEDENOM 1500
    DATA "DATA_VDN/nc_noumea_step.shp"
    CLASSITEM "step"
    CLASS
        EXPRESSION "0"
        STYLE
            COLOR 255 255 255
            OUTLINECOLOR "#3fc1b7"
            WIDTH 0.4
        END
    END
    CLASS
        EXPRESSION "5"
        STYLE
            COLOR "#3fc1b7"
            OPACITY 50
        END
    END
END

Transférer une symbologie “ArcGIS font Symbol” à Mapserver

Voici donc une procédure toute simple pour transformer une symbologie complexe d'une ligne basée sur l'utilisation de font dans ArcGIS vers un mapfile pour Mapserver. Partant de votre panorama de "Symbol Property Editor" dans ArcGIS:   on trouvera un symbole utilisant deux symboles de font. Cliquer sur "Symbol...", pour avoir accès à plus d'options. Dans ce panorama, on pourra récupérer le "Unicode" du symbole dans le fichier de font. Dans cet exemple on pourra donc utiliser le code 99 de la font "MapGenFont" Ce code est l'identifiant unique permettant d'identifier le symbole dans cette font. Toujours dans cet exemple, l'autre caractère utilisé dans cette symbologie complexe est dans la font "ESRI Default Marker" unicode 181. Pour utiliser cette font avec Mapserver on devra copier les fichiers de font dans l'arborescence de fichiers de configuration Mapserver. On trouvera facilement le fichier en naviguant dans le répertoire de fonts Windows "C:/Windows/Fonts". Ensuite on va ajouter la font dans le fichier fontset.
  #FONTSET File
mgfont                ./fonts/MGfont.ttf
esri_default_marker   ./fonts/esri_11.ttf
...
Enfin on va créer le symbole de cette façon:
 #symbolset File
  SYMBOL
    NAME       "rock-1"
    TYPE       TRUETYPE
    FONT       "mgfont"
    CHARACTER  "c"
    GAP        3
  END
  SYMBOL
    NAME       "rock-2"
    TYPE       TRUETYPE
    FONT       "esri_default_marker"
    CHARACTER  "µ"
  END
  #Mapfile
  ...
    TYPE                    LINE
    CLASS
      NAME                  "Sand"
      STYLE
        SYMBOL              "rock-1"
        COLOR               78 78 78
        SIZE                7
      END
      STYLE
        SYMBOL              "rock-2"
        COLOR               78 78 78
        SIZE                7
        OFFSET              3 3
      END
    END
   ...

Encodage de base de données Postgresql

Je suis tombé sur un problème d'encodage de ma base de données OSM dernièrement.  Mon besoin était pourtant très simple: je voulais imprimer sur ma carte les noms de rue en MAJUSCULES.  Je pensais donc utiliser la fonction upper() de postgresql via un mapfile, mais étrangement les caractères accentués ne suivaient pas:

osm= select upper('échap');
upper
-------
éCHAP
(1 row)

L'encodage da la base de données était bien UTF-8 puisque tous les caractères accentués apparaissaient convenablement.  Par contre le "Ctype" était à la valeur C. Dans la documentation de Postgresql on y mentionne que:

initdb initializes the database cluster's default locale and character set encoding. The character set encoding, collation order (LC_COLLATE) and character set classes (LC_CTYPE, e.g. upper, lower, digit) can be set separately for a database when it is created. initdb determines those settings for the template1 database, which will serve as the default for all other databases.

postges=l
Name    | Owner    | Encoding  | Collate |    Ctype
osm     | osm      | UTF8      | C       |    C

On a pas vraiment l'habitude de se soucier de cette valeur, mais elle affecte le fonctionnement de certaines fonctions qui traitent les caractères.  Pour contourner le problème, il y a deux options:

  1. Créer une nouvelle COLLATION dans Postgresql;
  2. Recréer le cluster de base de données;

Option 1

Une solution temporaire de contournement serait de créer une nouvelle COLLATION dans la base de données.  Avant on doit s'assurer d'avoir la Collation sur le serveur:

sudo locale-gen fr_CA.UTF-8 en_CA.UTF-8

Ensuite, on peux ajouter une nouvelle Collation correspondant dans la Base de données:

osm= CREATE COLLATION fr_ca_c (LOCALE='fr_CA.utf8');
osm= select upper('échap' COLLATE "fr_ca_c");;
upper
-------
ÉCHAP
(1 row)

Option 2

Cette option plus drastique sera plus robuste et efficiente à long terme.  Elle consiste à recréer le cluster de base de données pour supporter le bon encodage et la bonne Collation(Ctype). En principe, on doit être en mesure de créer la base de données avec les bons réglages de la façon suivante:

sudo su postgres -c'createdb -E UTF8 --lc-ctype en_CA.UTF-8 -T template0 template_postgis'
sudo su postgres -c'createlang -d template_postgis plpgsql;'
sudo su postgres -c'psql -U postgres -d template_postgis -c"CREATE EXTENSION postgis;"'
# # sudo su postgres -c'psql -U postgres -d template_postgis -c"select postgis_lib_version();"'
sudo su postgres -c'psql -U postgres -d template_postgis -c "GRANT ALL ON geometry_columns TO PUBLIC;"'
sudo su postgres -c'psql -U postgres -d template_postgis -c "GRANT ALL ON spatial_ref_sys TO PUBLIC;"'
sudo su postgres -c'psql -U postgres -d template_postgis -c "GRANT ALL ON geography_columns TO PUBLIC;"'
Par la suite, on doit refaire une nouvelle base de données avec ce template et le problème sera réglé: La création d'une nouvelle base de données avec le template UTF-8:
 sudo su postgres
 createdb -E utf8 -T template_postgis osm
 psql -d osm
 postgres= CREATE USER osm WITH PASSWORD 'osm';
 postgres= GRANT ALL PRIVILEGES ON DATABASE osm to osm;
 postgres=\l
 ----------------------------------
 Name | Owner | Encoding | Collate | Ctype
 osm | osm | UTF8 | C | en_CA.UTF-8
 postgres=\q
Il est possible d'avoir des problèmes de création de cette bd J'ai eu des problèmes de création d'une base de données template Postgresql supportant les caractères accentués et/ou l'encodage UTF-8.
sudo su postgres -c'createdb -E UTF8 --lc-ctype en_CA.UTF-8 -T template0 template_postgis'
createdb: database creation failed: ERROR:  invalid locale name en_CA.UTF-8

Comme mentionné plus haut, Postgresql va créer un moteur cluster (service, fichiers config, fichiers de données, logfile, etc) de base de données et ce moteur utilise les configurations d'encodages au moment de l'installation.  Si par mégarde, l'encodage UTF-8 n'était pas disponible, il faut détruire le cluster Postgresql avec pg_dropcluster, mettre à jour les variables locales d'encodage, et en créer un nouveau cluster avec pg_createcluster:

NOTE: Attention vous allez perdre toutes les BD de votre serveur!
sudo /etc/init.d/postgres stop
sudo su postgres
export LANGUAGE=en_CA.UTF-8
export LANG=en_CA.UTF-8
export LC_ALL=en_CA.UTF-8
locale-gen en_CA.UTF-8
pg_dropcluster --stop 9.1 main
pg_createcluster 9.1 main
exit
sudo /etc/init.d/postgres start
Juste pour être certain que tout est ok avec l'encodage de votre user :
export LANGUAGE=en_CA.UTF-8
export LANG=en_CA.UTF-8
export LC_ALL=en_CA.UTF-8
sudo localedef -i en_CA -f UTF-8 en_CA
sudo locale-gen en_CA.UTF-8
sudo update-locale
sudo sudo dpkg-reconfigure locales

Données ouvertes et cartographie Web

Voici donc un lien sur ma conférence à Vision Géomatique 2012:  données ouvertes et cartographie Web.  Vous pouvez accéder aux applications présentées via un lien ajouté sous le vidéo.  J'en profite également pour ajouter le lien de la présentation du conférencier qui me suivait, Nicolas Delffon.   Sa conférence, "La Datavisualisation ou l'art de présenter les données" est une suite logique de ma conférence.  Je vous invite à regarder les liens pertinents à la fin de sa présentation, si le sujet de "dataviz" vous intéresse.

Les 300 conférenciers qui ont assités à Vision Géomatique 2012 ont eu droit à un excellent colloque.  La série de conférences sur l'Open source organisées par OSGeo-qc a été une réussite sur toute la ligne et a attirée beaucoup de gens de différents milieux liés à la géomatique, comme on le souhaitait.

L’échec d’Apple Maps

On avait bien hâte de la voir cette nouvelle Apple Maps.  Étant moi-même maniaque de cartographie Web, j'étais impatient de voir le résultat.  Les aperçus qu'on nous avait servis étaient prometteurs et j'espérais avoir un produit épuré, basé sur des données Open Street Map complété intelligemment avec d'autres sources de données.

L'appréciation générale de la nouvelle application de cartographie semble catastrophique. Selon Snappli (qui se spécialise dans la compression de données pour appareils mobiles), il ne resterait que 4% d'utilisateurs de Apple Maps. J'ai donc fait quelques petites validations dans la région de Québec.

La liste bien garnie de fournisseurs de données fut donc ma première surprise.  Règle générale au Québec, TomTom est le fournisseur officiel pour le réseau routier.  Pas vraiment surprenant, car pour la fonction de navigation routière ("turn-by-turn") il fallait obligatoirement utiliser TomTom.  Pour le reste on ne retrouve absolument rien de Open Street Maps pour les informations de contexte dans la carte!

Le principe fondamental "homogénéité" des données est pourtant élémentaire en cartographie.  L'utilisation de couches généralisées (hydrographie, boisée, etc) sans niveau de précision suffisant à cette échelle est une erreur de débutant, pour ne pas dire inacceptable!  La rivière Chaudière n'aboutit même pas jusqu'au fleuve, puisqu'on devrait gérer le réseau hydrique filamentaire à cette échelle.   Avec un peu de déception, je n'ai même pas poussé plus loin l'analyse, je vous laisse le soin de vous amuser les nombreux exemples d'erreurs répertoriées sur ce site qui deviennent pour le moins gênants pour le géant Apple.  Forcé d'admettre l'échec lamentable, c'est sans surprise que Tim Cook lui-même a du fournir des excuses aux utilisateurs iOS 6!

Apple a été tenté par des fonctionnalités sexy comme la navigation "turn-by-turn", le 3D, la reconnaissance vocale Siri, etc.   Mais on a oublié de se concentrer sur la base: une belle carte pratique à utiliser et pertinente!  La compagnie TomTom n'a pas été à la hauteur pour fournir ce dont Apple avait besoin.  Ils font de bons appareils de navigation automobile, mais TomTom n'a pas ce qu'il faut pour produire une cartographie Web de qualité pour les appareils mobiles.   De mon avis personnel, l'esthétique de la cartographie Web de TomTom dans la région de Québec est loin du minimum requis qu'une carte doit avoir de nos jours.  Je vous laisse le soin de voir vous-mêmes.

Chargement Shapefiles dans PostGIS en batch

Il existe un moyen vraiment simple de charger le contenu d'un répertoire de shapefiles dans une base de données Posgresql/PostGIS avec les outils, shp2pgsql et psql. L'utilitaire permettant de charger les commandes SQL (psql) interdit la saisie d'un mot de passe en clair dans une ligne de commande. Pour contourner ce problème, on peut configurer un fichier .pgpass. Le contenu de ce fichier prend cette forme: nom_hote:port:database:nomutilisateur:motdepasse Il est impératif de changer les droits d'accès à ce fichier sinon psql n'en tiendra pas compte.
sudo vim ~/.pgpass
sudo chmod 0600 ~/.pgpass
Par la suite, j'utilise ce petit bash pour générer les lignes de commandes. Ici je transforme le nom du shapefiles en minuscule parce que Postrgresql est "case sensitive" et c'est plus propre de garder les noms de tables en minuscules:
vim shp2sqlfile.sh
---> ajouter ces lignes:
#!/bin/bash
for f in *shp
do
  name=$(basename $f .shp| tr '[A-Z]' '[a-z]')
  echo /usr/lib/postgresql/9.1/bin/shp2pgsql -c -I -W "latin1" -s "EPSG:4326" -g "the_geom" $f $name "| psql -d my_geodb -h localhost -U postgres -w"
done
Ne reste plus qu'a exécuter le batch et rediriger dans un fichier de commandes:
$ sh shp2sqlfile.sh >batch.sh

Investissements du Québec en santé

english version follow...
Nous avons réalisé dernièrement une nouvelle application de visualisation de données sur les "Investissements du Québec en santé".  Nous avons trouvé l'application vraiment "cool" alors on a décidé de la diffuser durant la présente campagne électorale 2012 parce qu'il est intéressant de pouvoir visualiser la taille de ces investissements.
Pour cette application, nous avons utilisé l'information publique du "Ministère de la Santé et des Services sociaux" diffusée via le site de données ouvertes du gouvernement du Québec, et des outils Web de visualisation de données pour mettre en relief le poids des investissements en santé versus la population et le budget total de la province de Québec.
Pour réaliser cette application, nous avons utilisé la librairie d3.js, Leaflet, puis Mapserver pour tuiler ( Mapcache ) et diffuser notre carte.
------------------------------
We recently launched our new data vizualisation application "Investissement du Québec en santé".  We find it cool so we decided to publish it.  It's interesting to visualize the size of these investments in this Quebec election campaign.
For this Web application, we used public data from the Government of Quebec Opendata Web site. We used data from "Ministery of Health and Social Services" and data visualization tools to highlight the amount of investments in health versus population of Quebec and the total budget of the province of Quebec.
To build this application, we used d3.jsLeaflet, and we used Mapserver to tiled (Mapcache) and served our map.

Trop verte la carte de “La Route Verte”

L'organisme gouvernemental "Vélo Québec" a lancé dernièrement son nouveau site Web de cartographie dynamique "La Route Verte".  Loin de vouloir faire du négativisme et encore moins, prétendre que je suis mieux qu'un autre en ce domaine, mais pour ce billet je désire simplement émettre mon opinion "cartographique" de l'application Web de "La Route verte" sans même m'attarder au design du site Web.  Ceux qui me connaissent savent je suis maniaque de cartes et de vélo alors c'est un peu normal!

1 ) Les fonctionnalités d'itinéraires fait avec pgRouting dans la base de données Postgresql/PostGIS fonctionne à merveille.  Il est bon de souligner qu'il s'agit (à ma connaissance) d'un des premiers site Web "Grand public" à utiliser cette technologie avec la base de données Adresse Québec.  Le calcul de route est rapide et on a même une très bonne description d'itinéraire ("turn-by-turn"); un incontournable pour ce type de fonctionnalité.  De plus, on y retrouver quantité d'information utile est abondante.

2 ) L'idée de présenter une application selon les régions administratives est comment dire, très "fonctionnaire"! Le "Grand public", puisque c'est bien pour eux que le site est dédié, en a peu à faire... Présenter les régions de cette façon donne aussi la fausse impression que certaines régions sont très importantes.  Par exemple, la région "Saguenay" m'apparaît trop apparente et semble démontrer que c'est une grosse région densément habitée alors que ce n'est pas réellement le cas.  Le "Manicouagan" est une magnifique région à visiter certes, mais en vélo, à moins d'être fanatique du cardio (ou un expert) ça l'est beaucoup moins.  Il faudrait peut-être recentrer l'application sur "La Route Verte" et ne pas tenir compte des "Régions Administratives".

3 ) Y a beaucoup de vert dans la carte.  Si on passe tous les niveaux de zoom on pourra compter cinq couleurs de vert pour cartographier 3 types d'entités complètement différentes: des routes, des parcs, des régions administratives.  Si on désire mettre en évidence "La Route Verte", il faudrait à mon avis, ne garder que "La Route Verte" verte pour ne pas brouiller le message.  Tout le reste devrait être moins apparent pour l'oeil.

Pour qu'un utilisateur puisse bien gérer les informations cartographiées dans une application, on devrait se limiter à moins de cinq couleurs.  Vrai que c'est souvent difficile, mais on devrait toujours avoir cette cible.  D'ailleurs, Marie-Josée Proulx rappelle bien dans "Le Data-ink ratio appliqué à la cartographie" cette limite dans le contexte de choroplèthes, mais le même concept s'applique aussi pour ce genre de carte.

Le Web n'est pas comme une carte imprimée.  L'image qui suit est un bel exemple de la surutilisation du vert dans cette carte Web.  "La Route Verte" se perd dans un spaghetti de lignes grises, pleines et pointillés.  De plus je ne comprends pas l'utilité des limites territoriales  pointillées dans ce genre de carte, sinon de se confondrent avec les routes.

4 ) Toujours au sujet de  l'image précédente, on ne devrait peut-être éviter de présenter autant d'écussons de carte routière dans une carte de piste cyclable.  À cette échelle, nous avons 25 écussons de routes pour les voitures et seulement 3 pour "La Route Verte".  De plus, ça me semble trop d'informations à gérer pour l'oeil et on perd le l'objectif du sujet. On aurait peut-être dû utiliser les écussons que pour les numéros de "La Route Verte" et réduire tous les autres à de simples rectangles numérotés bleu et vert.   Enfin je suis surpris de voir de gros bateaux noirs à cette échelle!  Encore un fois ça surcharge la carte pour rien et à ce niveau nous n'avons pas besoin de les voir.

5 ) "too-much-information"!  Ça vaut aussi pour les cartes.  Trop de routes, trop d'icônes un par dessus l'autres, et encore une fois 5 couleurs vertes à gérer pour l'oeil.   Trop d'informations et ça devient difficile à assimiler!  Toutes les routes autres que "cyclables" devraient devenir secondaires et s'effacer pour laisser parler "La Route Verte".

6 ) OÙ SONT LES CÔTES?  Si vous faites du vélo comme moi tout l'été vous savez très bien que c'est la première chose qu'on veut savoir! Ne pas mettre cette information capitale dans la carte pour vélo montre qu'on a oublié le public cible.  D'accord nous avons quelques icônes mais ils ne montrent pas toutes montées.  Ajouter les courbes de niveau, un fond 3D ou un graphique vertical d'élévation (dans l'itinéraire) auraient grandement aidé.

7 ) J'adore le fait qu'on trouver beaucoup d'informations utiles sur la carte.  C'est toujours très pratique pour un cycliste de savoir où il pourra se ravitailler en eau et se reposer.   Épiceries, dépanneurs, abreuvoirs et aires de repos, autant d'informations utiles à retrouver sur une carte de vélo.

8 ) Je comprends qu'on veut garder le focus sur "La Route Verte"  mais pourquoi ne pas ajouter les autres circuits de vélo?  C'est une bonne intention de publiciser "La Route Verte" à l'aide d'une application cartographique Web, mais sans les autres circuits, ça devient une application moins intéressante pour planifier un week-end vélo.  Dans les Cantons de l'Est on trouvera de magnifique parcours de vélo comme "La route des vins" par exemple.  Je trouverais interessant des les voir.

9 ) Autre question de cycliste: Y a t'il un accotement (2 à 3 pieds minimum) pour cycliste et quel est le débit de circulation sur cette route?  L'information n'a pas besoin d'être parfaite, mais elle donne une bonne indication du type de randonnée à prévoir.

10 ) La gestion des couches est à mon avis superflu et est contre indiquée pour cette carte.  Ce type de fonctionnalité  typiquement "géomatiques" me semble inutile et ne semble pas être en mesure de bien servir la clientèle intéressée.  Toutes ces informations de couches doivent se fondre à la carte en un tout cohérent.  Et puis qu'est-ce que c'est au juste un "Village-relais" et est-il d'intérêt pour le cycliste?

11 )  Une très bonne pratique,  c'est maintenant une orientation gouvernementale, serait de mettre un lien sur les sources de données ouvertes pour les mettre en valeur et permettre à d'autres de les utiliser.

imposm and PostGIS 2.0

I recently load OSM planet in PostGIS 2.0.  It works but you have to created manually your database:
 sudo su postgres
 createdb -E utf8 -O postgres osmplanet
 psql -d osmplanet -c "CREATE EXTENSION postgis;"
 createuser --no-superuser --no-createrole --createdb osm
 psql -d osmplanet -c "ALTER USER osm WITH PASSWORD 'osm';"
 psql -d osmplanet -f /usr/local/lib64/python2.7/site-packages/imposm/900913.sql
 psql -d osmplanet -c "ALTER TABLE geometry_columns OWNER TO osm;”
 psql -d osmplanet -c "ALTER TABLE spatial_ref_sys OWNER TO osm;"
 sudo vim /var/lib/pgsql/data/pg_hba.conf
 -->add this line "host osmplanet osm  127.0.0.1/32 md5"

 sudo virtualenv venv
 source venv/bin/activate
 venv/bin/pip install imposm
I use multiprocessing option with "imposm" in one line command read/write
 sudo imposm -c 8 --overwrite-cache --read --write --database osmplanet planet-latest.osm.bz2
Final database is 66 GB at this moment
postgres@osm:/home/smercier> psql -c "SELECT pg_size_pretty(pg_tablespace_size('pg_default'));" osm
 pg_size_pretty
----------------
 66 GB
(1 row)