Scribeui 0.7 beta

En 2013, Mapgears lance le projet ScribeUI destiné à simplifier la création de cartes pour le Web basé sur Mapserver et l'intégration du langage scribe pour mapserver.  L'objectif était vraiment simple: améliorer notre efficacité d'écriture d'un mapfile pour produire des cartes multiniveau tout en conservant la grande flexibilité de Mapserver.  La première version du projet était vraiment intéressante et on décide de faire un Google summer of code pour améliorer le design de l'outil.  Jessica Lapointe (de l'équipe Mapgears) avait d'ailleurs eu de bons mots à propos de son projet ScribeUI au GsoC 2013 provenant de la responsable de la fondation OSGeo.

Suite à des travaux importants réalisés chez Mapgears, je teste depuis plusieurs jours, une nouvelle version de ScribeUI et je suis vraiment épaté du résultat. Le projet n'est pas encore sur Github, mais il y sera prochainement.  On a remodelé l'interface, ajouté de nouvelles fonctions mais surtout changé le framework Flask pour Pyramid. L'application est maintenant beaucoup plus stable même si quelques petits bogues persistent. La bonne nouvelle est que Jessica Lapointe poursuivra bientôt les travaux entamés sur l'application beta pour améliorer l'utilisation générale du produit.

Personnellement, je ne peux plus me passer de l'outil pour produire des cartes web.  ScribeUI offre une méthode rapide, structurée et efficace pour faire un projet Web Mapping.  Combiné à Git, je peux transférer un projet d'une VM local à un serveur Cloud en quelques minutes, c'est vraiment pratique.

.

En plus de la syntaxe scribe très pratique, deux nouvelles fonctions vraiment cool arrivent avec cette version!  On a intégré un processus Git à la production carto avec ScribeUI. On se disait que produire une carte web est un peu comme faire de la programmation et que git mériterait d'être plus largement utilisé dans ce contexte.  C'est aussi une bonne pratique pour structurer le travail à faire, suivre l'évolution des versions de la carte et faciliter le transfert du projet cartographique d'un environnement à l'autre (DEV, TEST, PROD).  Directement dans l'application ScribeUI, on pourra maintenant, cloner puller et pusher toutes la config d'un projet carto sur un Git.  J'ai un projet complet (data et mapping ) pouvant être cloné ici : https://github.com/smercier/gitscribe.

On a ajouté un lien direct sur le fichier "readme.md" de votre projet pour favoriser le réflex de documentation. Deux clics suffisent pour éditer le "readme.md" de votre git avec la syntaxe mardown.  Pour ma part, c'est dans le readme que je documente les grandes lignes du makefile d'installation de données (quand c'est requis).

On a amélioré la coloration syntaxique et on pourra mieux apprécier la nouvelle option pour commenter de grande section de mapfile avec un code ouvrant (/*) et fermant  (*/) , ça j'aime VRAIMENT.  On a ajouté un lien direct sur l'aide en ligne(http://mapserver.org/mapfile/)  des mapfiles keywords en cliquant sur ALT et le keywords.

Écrire des mapfiles avec des variables et des codes de niveau de zoom, qui correspond bien plus à notre nouvelle réalité de production cartographique pour OpenLayers ou Leaflet.  Faire une carte avec les données OpenStreetMap devient soudainement bien plus plaisant.

L'autre fonction nouvellement ajoutée est un UI pour lancer des job Mapcache.  Le panorama permet de spécifier le Zoom levels à produire, le Metatile size, le Grid disponible et un Extent spécifique.  Ce dernier peut être dérivé du Map Extent de mapfile mais aussi à partir shapefile ou même d'une requête provenant d'un serveur Postgis.   L'intégration de nouvelles options sera documentée sur github.

J'ai aussi testé l'application avec des Mapfiles standard très volumineux (pour une carte maritime avec des données S-57) 5 mapfiles de 2000 lignes et plus dont un de 3042 lignes.  La navigation entre les groupes me permette de passer rapidement d'un include mapfile très rapidement et rend l'édition de la carte bien plus rapide.

À suivre donc, d'autres infos suivront prochainement.  Les idées ne manquent pas pour ce projet.

Scribe – Une nouvelle façon de faire du mapfile

Créer une belle carte qui véhicule efficacement son message n'est pas chose facile. On dispose souvent d'une grande quantité de données qu'on ne souhaite pas afficher en tout temps ou qu'on souhaite afficher mais avec un style qui varie en fonction du niveau d'échelle. Lorsqu'on défini le style d'une carte, chaque petit détail est important. Le processus se fait généralement de facon itérative et implique beaucoup de modifications, à tous les niveaux d'échelle.

Dans Mapserver, la gestion de l'échelle se fait avec les tags MINSCALEDENOM et MAXSCALEDENOM au niveau du LAYER ou de la CLASS. Cela veut dire qu'aussitôt qu'un élément du style change pour un LAYER ou une CLASS donné, à un certain niveau d'échelle, un nouveau LAYER ou une nouvelle CLASS doit être créé. On se trouve ainsi a réécrire beaucoup de texte pour ne modifier peut-être qu'un seul paramètre. La tâche devient encore plus fastidieuse si on doit changer un paramètre (par exemple la couleur d'une route) définie dans 16 LAYERs différents.

"Scribe" est un outil en python que nous avons créé pour faciliter l'écriture d'un "mapfile" en utilisant des variables et des raccourcis pour la gestion des échelles via des niveaux (maintenant la norme).  Cette façon de faire s'apparente à "Basemaps" mais est plus simple d'utilisation et généralement moins verbeuse.

Gestion des niveaux d'échelle

LAYER {
    1-16 {
        NAME: 'land'
        TYPE: POLYGON
        @layerconfig
        DATA {
            1-4: '110m_physical/ne_110m_land'
            5-10: '50m_physical/ne_50m_land'
            11-16: '10m_physical/ne_10m_land'
        }
        CLASS {
            STYLE {
                COLOR {
                    1-6: '#EEECDF'
                    7-16: '#AAA89B'
                }
                OUTLINECOLOR: 200 200 200
                OUTLINEWIDTH: @land_ol_width
            }
         }
     }
 }

Dans l'exemple précédent, un LAYER appelé "land" est créé. Le tag "1-16" signifie que ce LAYER doit etre affiché des niveaux d'échelle 1 à 16. Le script traduit automatiquement ces niveaux en MINSCALEDENOM et MAXSCALEDENOM. De plus, les données utilisées (DATA) des niveaux 1 à 4 sont au 110m tandis qu'elles sont au 50m des niveaux 5 à 10 et au 10m des niveaux 11 à 16. La couleur (COLOR) elle aussi change en fonction de l'échelle. En utilisant cette nomenclature, il devient très facile de modifier un paramètre pour un ou plusieurs niveaux d'échelle sans avoir à réécrire beaucoup de texte ou à faire des modifications à plusieurs endroits.

Définition et utilisation de variables

"Scribe" ne permet pas seulement de gérer les échelles mais il permet aussi de définir des variables réutilisables. Dans l'exemple ci-haut, les variables "layerconfig" et "land_ol_width" sont appelées a l'aide d'un "@". Ces variables sont définies de la facon suivante:

VARIABLES {
    layerconfig {
        GROUP: 'default'
        STATUS: ON
        PROJECTION {{
            'init=epsg:4326'
        }}
        PROCESSING: 'LABEL_NO_CLIP=ON'
        PROCESSING: 'CLOSE_CONNECTION=DEFER'
     }
     land_ol_width: 1
 }

La variable "layerconfig" contient plusieurs paramètres utilisés dans la définition de presque tous les LAYERs. Ainsi, pour chaque nouveau LAYER, il suffit d'écrire "@layerconfig" pour que tous les paramètres entrent dans la définition du LAYER. L'autre variable 'land_ol_width' prend une valeur unique.

Il est à noter que dans la définition de la variable "layerconfig", PROJECTION est suivi de deux "{". Cette syntaxe permet de gérer les tags comme PROJECTION, METADATA, PATTERN etc qui ne contiennent aucun paramètre, seulement du texte.

Blocs de commentaires

"Scribe" permet également d'utiliser des blocs de commentaire, ce qui n'est pas possible dans Mapserver seulement. D'autres types de commentaire sur une seule ligne peuvent aussi être écrits et apparaîtront dans le "mapfile" résultant.

LAYER {
    1-16 {
        NAME: 'land'
        TYPE: POLYGON
        @layerconfig
        DATA {
            1-4: '110m_physical/ne_110m_land'
            5-10: '50m_physical/ne_50m_land'
            11-16: '10m_physical/ne_10m_land'
        }
        CLASS {
            STYLE {
                COLOR {
                    1-6: '#EEECDF'
                    7-16: '#AAA89B'
                }                
                ##Les commentaires précédés par ## apparaissent
                ##dans le mapfile résultant.
                ##Les blocs de commentaires entre /* */
                ## n'apparaissent pas dans le mapfile résultant.
                /*
                OUTLINECOLOR: 200 200 200
                OUTLINEWIDTH: @land_ol_width
                */                
             }
         }
     }
 }

Conclusion

Finalement, pour exécuter le script, il suffit d'utiliser une seule commande, configurable avec certaines options:

python scribe.py

Le résultat est un mapfile parfaitement indenté avec gestion des échelles et souvent beaucoup plus de ligne que ce qu'il a fallu écrire. "Scribe" représente donc une économie importante en temps et produire des cartes de qualité devient plus facile et agréable.

Il est fort probable que "Scribe" évoluera et que de nouvelles fonctionnalités s'ajouteront.

Pour plus d'information ou pour utiliser "Scribe", consulter l'adresse suivante :

https://github.com/solutionsmapgears/Scribe.git Pour tout commentaire ou pour rapporter un bug : Charles-Éric Bourget cbourget@mapgears.com

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.

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.