Une Hackfest à Zanzibar (j’adore ce titre)

Cette année, la hackfest QGIS, aussi appelée « developer meeting », s’est tenue juste avant le FOSS4G international de Dar-Es-Salaam en Tanzanie, et à quelques encâblures au large dans la région autonome de Zanzibar.

J’ai eu l’immense chance de pouvoir y participer, et au passage de visiter un peu le pays, voilà l’occasion de partager ce que j’ai pût y voir.

Coucher de soleil à Zanzibar

Et

Visite de la Land Mapping Commission of Zanzibar et d’un projet de cartographie drone à très haute résolution de tout le territoire puis de digitalisation du bati,  la Zanzibar Mapping initiative. Open Source à tous les étages, QGIS, PostgreSQL, mais surtout une vrai vision à long terme n’oubliant pas l’humain. Impressionné et admiratif pour l’équipe et ceux qui les appuient depuis quelques années. .

Les données vont être versées à OpenStreetMap, et des challenges de Machine Learning vont être lancé au FOSS4G pour améliorer les process de mise à jour des données.

Les étudiants de l’université de Zanzibar sont également venu découvrir cet étrange évènement qu’est une hackfest, et comprendre comment commencer à contribuer. Et effectivement, ce n’est pas évident au premier abord de rentrer dans une pièce relativement silencieuse et d’oser interrompre des personnes en apparence très préoccupées par leur bug du jour 🙂

Nous avons eu une discussion très concrète pour la mise en œuvre de règles claires pour les entreprises et instituts souhaitant être certifiées pour délivrer des certificats aux stagiaires.  Certifier les certificateurs donc.  Nous avons abouti à un workflow relativement pragmatique et tolérable avec les quelques ressources dont le projet dispose, et avec également des propositions pour répondre au besoins des universités et écoles. Les annonces devraient arriver rapidement.

Pour ma part, j’ai profité de ce moment sans sollicitation pour tester les performances du rendu du moteur de QGIS Desktop, en comparant les versions.  En effet, les travaux menés par Oslandia sur les performances ont permis d’identifier des régressions de vitesse de rendu des lignes et des polygones dans QGIS Server 3. Ces régressions sont bien visibles dans les rapports de performance générés automatiquement et déposés sur les serveurs de QGIS.org. Face à ce constat, je souhaitais donc prendre le temps de vérifier de nombreuses hypothèses de rendu coté QGIS Desktop pour évaluer si ce sont des phénomènes purement liés à QGIS server, pendant que les collègues auditent le code du serveur en parallèle.
J’ai donc utilisé des scripts standalone dédié à QGIS 2, pris le temps de les adapter à l’API QGIS 3, et joué les mêmes tests en parallèle dans QGIS desktop. Le travail n’est pas fini, mais les conclusions sont claires. C’est un très bon exercice pour évaluer l’ampleur des ruptures d’API entre les deux versions. [edit]  Je vous livre mes conclusions, QGIS3 desktop est en moyenne 2 fois plus rapide que QGIS2 pour du rendu, parfois 4 fois plus rapide dans certains cas. Ce qui est une excellente nouvelle! Et l’autre bonne nouvelle est que le problème est uniquement dans QGIS server, ce qui sera bien plus simple à corriger (enfin on espère).  Bon, en fait c’est pas si simple, les options de compilation mettent du bruit, et on semblerait se rapprocher d’un QGIS 3 un peu plus rapide que QGIS 2, mais d’un ordre de grandeur similaire. Au conditionnel, parcequ’on trouve de nouveau des résultats contradictoires [/edit]
Nous avons eu également quelques présentations des divers projets travaillés pendant la hackfest:

  •  Démonstration du plugin Dataplotly par Matteo Ghetta – A conseiller vivement pour tous les data scientists en herbe!
  • Matthias Kuhn et Denis Rouzaud on présenté les dernières évolutions de QField. On atteint un niveau de maturité vraiment intéressant désormais, et l’outil est traduit dans plus de 20 langues maintenant

quelques bières aussi

et évidemment, l’ambiance incroyable de la ville de Stone Town, les magnifiques plages de Zanzibar, et quelques magnifiques parcs en Tanzanie (Ngorogoro, Tarangire, Manyara)

  

L’expérience continue maintenant avec le FOSS4G à Dar Es Salaam!

 

…. Et même les produits ménagers ici semblent avoir choisi leur camp !

Publicités
Une Hackfest à Zanzibar (j’adore ce titre)

Le plugin Mask dans QGIS, genèse d’une extension python bien pratique

L’idée de créer ce blog est parti du déficit de valorisation des contributions que j’ai pû faire ou financer autour de QGIS.

Commençons donc par l’histoire d’un plugin, simple au départ, qui nous a amené à modifier le moteur de rendu de QGIS et étendre beaucoup les fonctionnalités initiales.

Une question récurrente sur les forum d’aide géomatique est donc:

 » Comment puis-je détourer un territoire pour masquer les contours en dehors de cette zone, et n’afficher les étiquettes que pour les objets dans ce territoire? »

ça, par exemple:

masking_bv

Le monde de Mapinfo nous avait habitué au bon vieux et frustrant « Pochoir », lent, qui coupait les objets, et masquait absolument les objets en dehors, y compris les étiquettes qui débordent.

La première chose qui m’a toujours choqués sur une carte, c’est de cacher le territoire auquel appartient notre zone d’intérêt. La beauté de la lecture de carte, c’est de comprendre le territoire dans lequel on vit. Et la réalité, comme le nuage de Tchernobyl, ne s’arrête pas à nos frontières de papier.

Donc, exit le pochoir, bienvenue la couche de masquage avec transparence, modes de fusions, lissages et ombrages. Pouvoir mettre en lumière le contexte géographique d’un territoire, mais en le mettant mieux en valeur, sans complètement masquer le reste.

Depuis QGIS 2.4, il est possible de faire énormément de choses avec des expressions et des variables, mais ces solutions sont longues à configurer, et pas forcément à la portée du premier venu. Et notre objectif à l’agence de l’eau était de rendre ça accessible à tous.

Nous avons donc réalisé une première version d’extension QGIS, le plugin Mask, surtout pour se faire la main en python. Une sélection polygonale, on fusionne les objets, on fait un très grand carré autour, et hop on fait un trou… Basique, efficace, pas vraiment beau.

Mais zoomer sur la couche.. nous envoie à l’échelle européenne. Et les objets tombent parfois en dehors des zones de validité des projections de la carte..

 On passe à la V2.

Idée brillante de Xavier, mon collègue: « Pourquoi ne pas faire un mode de rendu qui représente les objets inversés, en représentant le polygone univers, sans bricoler les géométries? »

Oui, mais c'est une évolution du core de QGIS en C++...

Et la magie de l’Open Source opère. Un cahier des charges de deux pages,  un marché avec société spécialisée qui va bien, et c’est parti.

Faire un masque ne nécessite ainsi aucun plugin. On sauvegarde dans sa bibliothèque de styles un symbole inversé joli, on filtre la couche, et c’est fait!

Coup de chance, ou plutôt inspiration réciproque, Nyall Dawson ajoute en même temps le mode de rendu de bordure de polygone dégradés:

et ça donne vraiment bien avec notre rendu par polygone inversé:

mask

 

C'est bien, mais les étiquettes en dehors du masque, c'est vraiment illisible

Comme on a des expressions un peu partout, on peut alors imaginer filtrer les étiquettes sur la base d’une géométrie en mémoire.

Là on a eu un peu peur que des intersections spatiales à la volée sur des objets géographiques soient vraiment très peu performantes. Donc, on a décidé de tester la preuve du concept dans un plugin python, quitte à proposer ça dans le core plus tard si c’est validé.

Avant, avec les étiquettes partout:etiquettes_no_mask

Après:

etiquettes_with_mask

Wonderfull, j’en ai rêvé depuis mes débuts en SIG, ça fait du bien de se sentir un peu capable d’influencer les choses.

Comment ça marche ?

Voilà la solution technique trouvée avec Oslandia (merci Hugo et Vincent):

  • le plugin Mask ajoute deux choses au moteur d’expression:
    • une variable contenant la géométrie de l’objet Masque courant. (on a donc un seul masque actif à la fois)
    • une expression qui renvoie 0 ou 1 selon que l’objet cartographique évalué est dans le masque ou non. in_mask(srid). L’expression spatiale étant variable suivant les types d’objets, et la vitesse d’execution étant plus rapide avec des centroides, on donne le choix à l’utilisateur de choisir ses opérateurs

mask_variable

  • et aussi une interface qui permet d’activer le masque, choisir et changer styles et paramètres, activer ou non les filtres d’étiquettes sur les couches du projet, sauver en fichier ou en mémoire…

mask_UI

L’expression in_mask se positionne dans les paramètres contrôlés par expression d’étiquetage de chaque couche à filtrer. Au passage, nous avons découvert que l’expression Rendu/Afficher l’étiquette permet d’alléger le moteur d’étiquetage en n’envoyant pas cette étiquette dans le calcul de conflit d’étiquettes, ce qui paradoxalement va accélerer l’étiquetage dans bon nombre de cas. Youpi!

Une petite démonstration valant mieux qu’un long discours:

 

OK, chouette, mais moi j’ai besoin de générer 250 cartes de communes avec un masque, vous savez faire? (on a des utilisateurs exigeants ici)

Ah, ça tombe bien, notre première contribution était un cofinancement de l’Atlas de QGIS, on imaginait donc bien que c’était faisable.

On ajoute donc quelques évènements (signaux Qt) dans QGIS qui seront captés par le plugin pour modifier à la volée la géométrie de l’objet Atlas, tout en gardant ses propriétés. A partir du moment ou un masque est actif, il n’y a donc rien de plus à faire. Si on ne vaut pas de masquage d’Atlas, on enlève cette couche du projet.

Dans les premières versions du plugin qui ont introduit ces fonctionnalités, nous utilisions une couche temporaire spécifique à l’Atlas… ce  fut une MAUVAISE IDEE… Le composeur de carte est en effet généralement utilisé en verrouillant les couches de chaque carte, et donc la couche de masque temporaire n’en fait pas partie, et donc… pas de masque dans le composeur. Mais c’est corrigé en version 1.5.

Il reste encore des cas mal maitrisés, comme le renommage de couche qui désactive le mask à la réouverture du projet, ou encore l’obligation d’utiliser le plugin Memory Layer Saver pour sauver les couches mémoire avec le projet.

N’hésitez pas à signaler les soucis sur le dépôt github:

https://github.com/aeag/mask/issues

La documentation est là aussi, dans le wiki

https://github.com/aeag/mask/wiki

 

 

 

 

 

 

 

 

 

Le plugin Mask dans QGIS, genèse d’une extension python bien pratique

Encore un blog géospatial

Mais pourquoi encooore un blog sur les données, le géospatial, la carto, les outils libres??

Mais tout simplement parce que, comme le python, c’est bon.

Et j’ai des tas de trucs à dire aussi.. Sinon parler pour ne rien dire, c’est pas mon truc.

Je causerais donc en vrac de QGIS, Postgis, Data, Open Source, au grès des humeurs, des disponibilités.

Soyez donc prévenus, plus il y aura de neige, moins ce blog sera actif.

C’est parti!

 

Oh, j’allais oublier. Ici on cause anglais ou français en vrac, selon le besoin et les envies 🙂

Encore un blog géospatial