Rapport sur l’atelier conjoint W3C-OGC sur les cartes pour le Web
Traductions disponibles : La version originale en anglais est ici 中文翻译在这里
Résumé
L’information géospatiale sur le Web est fragmentée, mal couverte par les normes Web et manque d’interopérabilité, ce qui crée des obstacles importants à son utilisation efficace. Les efforts visant à normaliser la géoinformation se sont concentrés sur les développeurs géospatiaux établis, laissant de côté les nombreuses personnes qui communiquent au moyen de données cartographiques sur le Web. Il existe aujourd’hui une occasion de normaliser les cartes et l’information spatiale en HTML, ce qui réduit les obstacles pour divers intervenants, notamment les développeurs Web, les développeurs de systèmes d’information géographique (SIG), les fournisseurs de données, les fournisseurs de solutions cartographiques, les services commerciaux d’applications géospatiales et les utilisateurs individuels du Web, en particulier les personnes handicapées.
Les concepteurs de navigateurs sont plus ouverts que jamais à l’intégration d’idées et de codes lorsque la communauté Web demande clairement une solution particulière. Il incombe aux collectivités de s’organiser pour revendiquer la nécessité et la définition de telles normes. La communauté mondiale de l’information géospatiale peut et doit se mobiliser pour simplifier et normaliser la géoinformation pour le Web — les cartes en HTML — appuyant le rendu de cartes géographiques et non géoréférencées, ainsi que des schémas d’interaction courants.
L’atelier a permis de recueillir un large éventail de renseignements et d’opinions sur la normalisation des cartes pour le Web. Certains participants hésitaient, craignant qu’une solution normalisée soit moins efficace que les offres exclusives actuelles. D’autres ont prudemment appuyé l’idée, et ont fortement encouragé à la garder simple. Mais il y avait aussi un enthousiasme manifeste, avec des appels à l’action pour normaliser les cartes Web dans l’espoir de réduire les obstacles à leur utilisation par les personnes de toutes capacités techniques, physiques et cognitives.
« [Un élément HTML cartographique natif] nous permettrait certainement de nous concentrer davantage sur ce que nous pouvons faire avec les cartes; comment nous pouvons créer de belles cartes, comment nous pouvons aider les utilisateurs en créant de belles cartes […]. Plus j’y pense, plus j’aime […] le concept de base […] d’une carte avec fonctions de zoom et de panorama […]. Avec cela en place, les bibliothèques de cartographie pourraient probablement prendre des orientations auxquelles nous ne pensons même pas encore. Cependant, le fort accent actuellement mis sur le rendu s’oppose assurément […] à d’autres types de développements. »
Andreas Hocevar, développeur OpenLayers / OSGeo
Bien que l’atelier ait démontré la réceptivité de la communauté des normes Web à l’idée de normaliser les cartes dans les navigateurs (la plateforme Web), il a permis d’émettre une mise en garde quant aux coûts et au temps requis pour un tel travail. Les défenseurs de la plateforme Web suggèrent que les efforts visant à normaliser les cartes devraient être progressifs, en commençant par les cas d’utilisation et les exigences, puis en passant à la spécification et à l’élaboration.
Pour la communauté des normes géospatiales, la plateforme Web offre un terrain de jeu ouvert et équitable essentiel au développement et à l’innovation, donnant accès aux cartes et à l’information spatiale au plus grand nombre d’utilisateurs. Compte tenu de la volonté prudente de coopération de la communauté des normes Web, la communauté des normes géospatiales devra continuer de promouvoir la normalisation des cartes sur le Web et d’accroître la participation à l’élaboration de normes Web pertinentes.
Le présent rapport conclut que la prochaine étape de cette initiative devrait être la négociation du mandat d’un groupe de travail du W3C qui tire ses propositions et ses exigences des groupes de travail pertinents du W3C, du WHATWG et de l’OGC (normes).
Des vidéos de la séance, des transcriptions et des documents d’appui sont accessibles sur la page de l'ordre du jour du site Web de l’atelier.
Introduction
Ressources naturelles Canada (RNCan) a parrainé le premier atelier conjoint sur la normalisation des cartes pour le Web, qui s’est déroulé en ligne du 21 septembre au 2 octobre 2020. L’atelier était organisé conjointement par le World Wide Web Consortium (W3C) et l’Open Geospatial Consortium (OGC), et a réuni un comité organisateur formé d’employés de RNCan, du W3C, de l’OGC, d’Environnement et Changement climatique Canada (ECCC), de la National Geospatial Intelligence Agency (NGA) des États-Unis et de la National Aeronautics and Space Administration (NASA) des États-Unis ainsi que de bénévoles de la communauté Maps for HTML. L’atelier devait d’abord avoir lieu en personne au même endroit que la réunion du Comité technique de l’OGC en juin 2020, mais il a été en ligne en format virtuel en raison de la pandémie de la COVID-19. L’atelier était accessible au public gratuitement.
Un appel de positions, d’articles et de conférences a été lancé sur le site Web de l’atelier et fait l’objet d’une promotion conjointe par les voies de communication des membres du W3C et de l’OGC. L’atelier était organisé par thème, tous les thèmes étant en théorie axés sur la normalisation des cartes dans la plateforme Web. Les thèmes comprenaient l’accessibilité, l’internationalisation, la protection des renseignements personnels et la sécurité, le rendement, la réalité augmentée, les normes et la technologie des cartes Web et les points de vue des intervenants.
Plus de 150 inscriptions ont été reçues, avec la présentation de 13 exposés de position, 33 conférences, 7 tables rondes et 3 séances en petits groupes. Toutes les séances de l’atelier ont été enregistrées et l’enregistrement de chaque journée est lié au point à l’ordre du jour de cette journée. Les discussions sur les conférences et les tables rondes ont été (et sont toujours) encouragées, et ont eu lieu pendant les présentations, au moyen du clavardage, en direct, ainsi qu’après, chaque conférence, table ronde ou séance en petits groupes constituant un sujet de discussion distinct sur les normes Web. Pour faciliter l’examen, chaque sujet de discussion distinct est lié à l’enregistrement précis de la présentation ou de la table ronde.
Thèmes des ateliers
Accessibilité (a11y)
Nic Chan et Robert Linder ont analysé l’accessibilité des solutions d’intégration de cartes Web existantes, mesurée en fonction des Lignes directrices sur l’accessibilité des contenus Web (WCAG). En résumé, aucun des cadres de cartographie Web évalués ne répond à tous les critères de réussite des WCAG 2.1. Pour certains critères, aucun des cadres évalués n’a obtenu la note de passage. En réponse à l’évaluation, certains responsables de la tenue à jour des cadres ont pris des mesures pour améliorer l’accessibilité de leurs cadres, ce qui est un premier résultat prometteur de l’atelier.
Nicolò Carpignoli et Joshue O’Connor ont présenté un résumé des exigences relatives aux cartes Web accessibles. L’un des besoins importants qu’ils ont soulignés est l’accessibilité des « annotations » textuelles géolocalisées. Compte tenu des modèles géographiques types, ces annotations textuelles correspondent aux descriptions des entités simples de l’OGC. Cette norme de l’OGC décrit l’architecture courante pour la géométrie des entités simples et a déjà été adoptée dans plusieurs normes populaires comme KML, GeoPackage et GeoJSON. La normalisation des géoannotations nécessiterait un moyen de représenter ces entités en HTML. Un prérequis implicite pour la prise en charge par le navigateur d’entités géographiques annotées est le contrôle par le navigateur du rendu de la carte (l’utilisateur doit savoir où représenter l’entité). Par conséquent, les exigences semblent appuyer implicitement la notion de base de l’intégration des cartes dans le langage HTML et les normes d’accessibilité connexes (CSS, ARIA, WCAG). La présentation a également mis l’accent sur la nécessité de séparer l’information primaire du contexte ou du « bruit » qui l’entoure; en d’autres termes, la nécessité de créer un modèle de cartes à couches permettant aux utilisateurs de la technologie d’aide de se concentrer sur la couche pertinente.
L’utilisation de cartes pour améliorer l’accessibilité des emplacements intérieurs a été décrite par Claudia Loitsch et Julian Striegl, dont les recherches ont montré que la couverture des cartes intérieures est très faible de nos jours. De plus, il n’existe aucune norme sur la façon dont les cartes et les données géographiques devraient être accessibles selon les différents contextes et les besoins variés des utilisateurs. Les conférenciers ont conclu qu’étant donné que le marché des données cartographiques intérieures devrait croître considérablement dans les prochaines années, les problèmes susmentionnés représentent l’occasion idéale d’élaborer de telles normes, avant que des efforts de cartographie ne soient dépensés, et potentiellement gaspillés, sur des solutions incompatibles.
L’accessibilité physique se rapporte aux installations qui donnent accès aux personnes ayant un handicap physique, comme les rampes d’accès pour fauteuils roulants. Sebastian Felix Zappe de WheelMap.org suggère que les cartes en HTML pourraient être utilisées pour « l’intégration des personnes handicapées », c’est-à-dire pour veiller à ce que l’information sur l’accessibilité fasse partie de tous les services cartographiques sur le Web par l’entremise de normes.
Brandon Biggs, du Smith-Kettlewell Eye Research Institute, a insisté sur l’importance de présenter le contenu des cartes aux utilisateurs aveugles et ayant une déficience visuelle. Les normes et les techniques des WCAG n’englobent pas actuellement la complexité de l’information graphique dans les cartes Web ni les façons de communiquer cette information spatiale aux utilisateurs Web non voyants. Grâce aux nouvelles capacités intégrées aux navigateurs, comme les interfaces de programmation d’applications (API) Web de vibration, audio et vocales, il est possible de créer des cartes non visuelles plus avancées pour le Web. Pour produire des cartes numériques auditives ou vibroauditives, chaque entité d’un ensemble de données géospatiales doit avoir un nom et une géométrie complète. Les cartes non visuelles que Brandon Biggs a créées fonctionnent par détection de collision spatiale; l’utilisateur manipule sa position virtuelle dans l’espace, et lorsque cette position entre en collision avec l’entité, l’attribut de nom de l’entité est lu. Les cartes matricielles existantes et les ensembles d’entités vectorielles non marquées ne fournissent pas les descriptions textuelles requises; même les cartes qui étiquettent les entités en tant que points de repère ne suffisent pas, car l’échelle de l’entité dans l’espace est inconnue. M. Biggs conclut qu’il ne servirait à rien de créer une composante HTML type sans tenir compte des exigences en matière de modélisation des données imposées par les cartes non visuelles à l’information sur les entités cartographiques Web, ce qui indique au moins une paire d’exigences importantes devant être abordées par une norme sur les cartes Web.
Cartes Web pour l’accessibilité cognitive
Les besoins cartographiques des personnes ayant des déficiences cognitives ont été le sujet de discussion d’un groupe d’experts comprenant David Fazio, John Kirkwood et John Rochford, tous membres du Groupe de travail sur l’accessibilité pour les personnes ayant un trouble d’apprentissage ou une déficience cognitive (COGA) du W3C. Lisa Seeman, présidente du Groupe de travail, a également contribué à la planification de la table ronde, mais n’a malheureusement pas pu y participer en raison d’un problème de communication. En résumé, les membres du groupe d’experts ont indiqué que, bien qu’il reste beaucoup de recherche à faire auprès des utilisateurs dans ce domaine, de façon générale, la technologie de cartographie Web accessible qui répond aux besoins des utilisateurs ayant un trouble d’apprentissage ou une déficience cognitive est un énorme marché auquel tout le monde finit par appartenir. Plus précisément, à mesure que le cerveau vieillit (en particulier le lobe pariétal), la fonction associée à l’orientation (c’est-à-dire la navigation, à l’intérieur ou à l’extérieur) diminue. Le principal défi de l’orientation est de trouver des façons de décrire l’information spatiale et les directions à l’aide d’indices propres aux capacités cognitives de l’utilisateur. Ces indices peuvent être visuels ou textuels et prendre des formes différentes pour différentes personnes. Le groupe d’experts a également affirmé que cette technologie n’avait pas besoin de se limiter à des logiciels exclusifs, et le groupe de travail travaille en fait à l’élaboration de normes pour les utilisateurs ayant un trouble d’apprentissage ou une déficience cognitive. Il est à espérer que les groupes de travail sur les normes concernés collaboreront pour faire avancer ces besoins pour les utilisateurs de cartes.
Création de gadgets logiciels pour des cartes Web accessibles
L’atelier a réuni un groupe d’experts et de chercheurs du monde entier dans le domaine émergent de l’accessibilité des cartes Web. Ils ont abordé des questions liées à l’utilisation des cartes Web par les personnes handicapées, en particulier celles qui ont une déficience visuelle, et les mesures que la communauté de cartographie Web peut prendre collectivement pour faciliter l’accès au contenu et aux fonctionnalités des cartes. Le groupe d’experts était notamment constitué de Doug Schepers, du Fizz Studio, de Brandon Biggs, ingénieur au Smith-Kettlewell Eye Research Institute, de Tony Stockman, Ph. D., de l’Université Queen Mary, et Nicholas Giudice, Ph. D., de l’Université du Maine.
Le groupe a d’abord décrit la nature des cartes audio et les différents types de cartes audio et vibrotactiles qui existent, ainsi que les caractéristiques de ces cartes et leurs distinctions, y compris les icônes sonores (carillon), la relation et les similitudes entre les sens de la vue et du toucher, et la façon dont ces cartes peuvent se prêter aux mises en œuvre et aux API. Le groupe d’experts a aussi mis l’accent sur les considérations ou les exigences importantes en matière de cartes audio normalisées, comme le besoin d’attributs de nom ou d’étiquette pour les entités cartographiques, et le besoin de pouvoir transformer automatiquement les données matricielles pour les présenter aux utilisateurs auditifs ou tactiles. Le groupe a également discuté du fait que des règles en matière de cartographie sont bien établies pour les cartes visuelles, et qu’il est nécessaire qu’on élabore des normes psychophysiques semblables pour les cartes non visuelles, par l’entremise de recherches faisant directement participer les utilisateurs.
Tony Stockman, sur les défis associés au domaine des cartes auditives :
« L’un des véritables problèmes, en fait, est l’absence de normes pour les affichages sonores en général. »
Nicholas Giudice, à propos des défis liés au domaine des cartes auditives et vibrotactiles :
« […] Pour les variantes non visuelles de cartes, les cartographes […] n’ont pas pensé aux cartes auditives et vibrotactiles [cartographie], et nous devons donc intégrer cela à n’importe quel type de lignes directrices standard pour la conception, obtenues de façon plus empirique, qui […] permettent de s’assurer que ces éléments sont à la fois perceptibles et pertinents sur le plan cognitif. »
Brandon Biggs, au sujet des défis que doivent relever les organismes de normalisation :
« Il y a trois [défis]. Le premier est les données; il faut travailler beaucoup plus avec les données. Le deuxième est les API. Il y a de nouvelles API, comme le périphérique XR, qui sortent et nous devons y réfléchir et voir comment nous pouvons représenter les cartes de cette façon. Le troisième défi est de faire participer les utilisateurs à tout ce que nous faisons. »
Brandon Biggs, sur la façon dont les organismes de normalisation peuvent faciliter l’innovation en matière de cartes auditives :
« Il faut que nous créions plus de cartes pour tous les types de modalités […]. Le plus gros problème est que […] nous n’avons pas vraiment essayé de faire des cartes BART ou des cartes topologiques du Grand Canyon, ou, par exemple, différents types de cartes qui sont nécessaires pour être un professionnel, un géographe. »
Réalité augmentée (RA)
Jan-Erik Vinje, de Norkart.no, qui est directeur général de l’Open AR Cloud Association, a fait une présentation sur la norme émergente sur la géopose de l’OGC, où il a décrit ce qu’est une « géo-pose » en la comparant à des points d’intérêt 2D. Contrairement aux points d’intérêt, qui peuvent être représentés sur une carte Web en deux dimensions, la géopose se prête à un rendu dans un environnement de projection du globe en trois dimensions et soutient « six degrés de liberté », ce qui signifie qu’une géopose peut décrire la position et l’orientation rotationnelle d’un objet dans l’espace 3D. M. Vinje a rappelé qu’avec la géopose, on tente de créer une norme pour décrire le comportement des objets dans les mondes réel et virtuel, qui ont tendance à se déplacer; leur géométrie n’est pas figée dans l’orientation par rapport à la Terre. La géopose fait partie d’une volonté pour un Web spatial ouvert, qui exige également que la représentation des objets (géométrie, sémantique et relations) soit lisible et actualisable par machine, bien que cela n’exclue pas la possibilité d’interventions manuelles. M. Vinje a indiqué que tous ces concepts sont fondamentalement compatibles avec une carte de couches thématiques, mais présentés en 3D. L’aspect « réalité augmentée » réside dans le fait que la carte représente souvent le monde réel entourant l’utilisateur, mais pourrait contenir des objets virtuels, comme des représentations d’objets historiques, qui sont superposés à la réalité physique.
Jan-Erik soutient qu’une API de cartes d’un navigateur natif devrait prendre en charge un « mode globe », qui pourrait être la base d’une réalité augmentée normalisée :
« [Avec l’aide de la géopose dans] les éléments cartographiques natifs, […] les objets de [la] carte deviendraient particulièrement utiles […] si nous pouvions nous assurer que les éléments cartographiques prennent en charge le mode globe, […] comme […] les plateformes Cesium ou Google Earth. »
Christine Perey et Josh Lieberman ont fait une présentation sur la façon dont la géopose pourrait être intégrée aux cas d’utilisation ou fournir de tels cas pour appuyer les cas d’utilisation et les exigences concernant les cartes Web en cours d’élaboration par le groupe communautaire Maps for HTML. Ils ont décrit en détail comment la géopose s’harmonise avec les cas d’utilisation pour différents intervenants – auteur de contenu, visiteur de sites Web ou développeur d’applications – et les accroît en tenant compte des facteurs 3D relatifs à la géopose. Certains cas d’utilisation supplémentaires axés sur la géopose, comme les vues le long d’un itinéraire à partir de différentes directions, s’harmonisent avec les considérations liées aux indices spatiaux pour les utilisateurs ayant des besoins cognitifs qui ont été présentées par les participants à la table ronde sur l’accessibilité pour les personnes ayant un trouble d’apprentissage ou une déficience cognitive.
Josh Lieberman – Open Geospatial Consortium :
« Il y a vraiment un continuum […] entre une carte plane orientée vers le nord ayant une superficie et une échelle fixes et […] la réalité augmentée où vous regardez vraiment ce qui vous entoure et se trouve devant vous, et où des objets cartographiques sont placés dans cette vue. […] [Une] carte Web qui […] peut passer de […] la réalité augmentée à [un] formalisme cartographié de la réalité […] peut vraiment être mis dans ce spectre […]. La géopose fait partie intégrante de l’établissement de ce continuum. »
Une table ronde sur la RA et la cartographie 3D a rassemblé un prestigieux et enthousiaste groupe de chercheurs, d’entrepreneurs et de spécialistes de la normalisation en matière de RA : Patrick Cozzi, PDG de Cesium, Thomas Logan d’Equal Entry, Christine Perey et Jan-Erik Vinje de l’Open AR Cloud Association, et Ada Rose Cannon de l’équipe Internet de Samsung.
La table ronde a débuté avec Thomas Logan qui a souligné que souvent, lorsque les gens pensent à la réalité augmentée, ils pensent à l’application purement visuelle. Toutefois, a-t-il relevé, les sons peuvent constituer un ajout important pour les personnes ayant une déficience visuelle ou les aveugles. Le groupe a abordé des questions sur les exigences en matière de précision de l’information géospatiale en RA et sur la façon d’ancrer ou de relier les systèmes de coordonnées de la RA au monde réel. Le groupe d’experts a discuté de l’accessibilité des jeux et de la convergence importante des jeux vidéo, des graphiques et de la technologie géospatiale tridimensionnelle. Les experts s’attendent à ce que la collaboration entre ces secteurs soit essentielle à l’avancement de la RA. Le groupe a également répondu aux questions de l’auditoire au sujet de l’idée de faire avancer progressivement la plateforme Web pour y ajouter la RA en commençant par les cartes 2D, comme le suggère la communauté Maps for HTML.
Jan-Erik Vinje – Open AR Cloud Association :
« J’approuve! Il est préférable de commencer par les [cartes Web natives en 2D] et […] de les utiliser pour aller de l’avant. Si nous avons des éléments cartographiques natifs qui sont d’abord en 2D, nous pouvons ensuite les améliorer. Les cartes du globe et les modes d’immersion pourraient donc être accessibles plus tard. Alors, allons-y avec cela; ça serait génial. »
Ada Rose Cannon — Samsung Internet :
« Ce serait intéressant qu’il y ait un élément natif. À l’heure actuelle, Web XR est le seul moyen de faire de la RA sur le Web […]. La meilleure façon d’intégrer la plateforme Web à Web XR serait de pouvoir utiliser une mémoire tampon, de sorte que le moteur Web que vous utilisez puisse prendre ce contenu et le transformer de façon intelligente pour le superposer correctement dans votre environnement. »
Thomas Logan — Equal Entry :
« Les cartes 2D dans mon milieu représentent un défi constant depuis mon arrivée dans le domaine de l’accessibilité. Donc, j’en ai simplement parlé pour m’assurer que les gens s’en soucient et prennent en compte le cas d’utilisation [relatif à l’accessibilité] en 3D. »
Patrick Cozzi — Cesium :
« Je crois vraiment que pour faire progresser la RA pour les cartes et la géospatiale tridimensionnelle en général, nous avons vraiment besoin de cette collaboration, à l’intersection des jeux, des graphiques et de la géospatiale. Je pense que nous n’en sommes qu’au début de ce genre de fusion des domaines géospatial et du jeu. »
Internationalisation
La « présentation sur le « rendu de texte multilingue » de Brandon Liu a exploré la relation entre le rendu du texte et les cartes, suggérant que ce qui définit une carte est la combinaison de géométries spatioréférencées avec des descriptions textuelles, souvent rendues sous forme d’étiquettes sur la carte. M. Liu suggère que les exigences d’un rendu de texte adéquat doivent être prises en compte d’un point de vue propre à la carte, et d’un point de vue multilingue, lors de l’évaluation des différentes méthodes de cartographie Web. Brandon a évalué la prise en charge du rendu de texte adapté à la langue dans les navigateurs et les cadres de cartographie. Il a conclu que la grande complexité du rendu de texte par des processus JavaScript ou Web Assembly (WASM) personnalisés, combinée au manque de prise en charge entre navigateurs pour les infrastructures de rendu de texte accessibles et à rendement élevé en matière de normes graphiques, comme les spécifications d’interface (en particulier WebGL), encourage l’utilisation de méthodes de cartographie qui emploient la même aide textuelle multilingue intégrée et améliorée parallèlement au rendu de texte CSS et HTML du navigateur, et s’appuient sur cette aide. Brandon a également indiqué qu’il faut faire preuve de beaucoup de prudence lorsqu’on préconise une norme, comme MapML, plutôt que le recours à un ensemble d’outils JavaScript de bas niveau qui peuvent être utilisés pour réaliser une tâche, car une norme Web doit être vraiment internationale. Par exemple, il note que les cartes imprimées en chinois, japonais ou coréen ont souvent un rendu de texte vertical, tandis que les cartes sur le Web en ont rarement. Les navigateurs Web prennent en charge le texte vertical; il serait donc idéal que les cartes Web puissent tirer parti de cette fonction des navigateurs. Brandon a relevé, en réponse à une question, que le fait de s’assurer que le texte de la carte fait partie de l’interface de programmation DOM HTML, que ce soit dans l’interface utilisateur de la carte ou non, contribue à l’internationalisation des cartes.
Cartes Web mondiales : défis dans le contexte mondial
L’atelier a réuni un groupe d’experts des défis technologiques internationaux liés à la cartographie Web, qui ont eu l’idée de prendre les normes relatives aux cartes Web comme point de départ de la conversation. Ces experts comptaient notamment Brandon Liu, de Protomaps, Thijs Brentjens, de Geonovum, et Siva Pidaparthi, d’ESRI. Les sujets de discussion comprenaient la façon d’améliorer l’état de la cartographie Web, la localisation du contenu des cartes en tirant parti du travail qui a été consacré à l’aide textuelle des navigateurs, les défis en matière de sécurité et de protection des renseignements personnels pour les données géospatiales, les projections des cartes et les normes, et l’importance de l’accessibilité pour les utilisateurs des cartes Web.
Brandon Liu, Protomaps :
« Pour que quelque chose devienne une norme Web, il ne faut pas avoir qu’une solution d’internationalisation partielle; ce n’est pas bon si la solution n’est qu’un produit minimal viable qui ne fonctionne que de gauche à droite, comme les langues […]. Je suis curieux de savoir si [l’internationalisation intégrée aux] navigateurs Web peut déjà avoir une incidence sur les possibilités cartographiques plus vastes pour les cartes Web. »
Thijs Brentjens, Geonovum :
« [L’accessibilité des cartes Web] est un sujet très important […]. [Toutefois], ce n’est pas [très important] dans les travaux géospatiaux […]. [Nous avons] cette idée que les cartes ne sont que visuelles […], qu’on ne peut les rendre accessibles. Donc, nous ne le faisons tout simplement pas. […] Il nous faut […] commencer […] à éliminer l’idée […] que nous avons qu’il n’est pas facile de rendre les cartes accessibles, parce que je pense qu’il y a des options. »
Siva Pidaparthi, ESRI :
« Lorsque nous envisageons de nouvelles normes, nous devrions aussi penser à des systèmes de coordonnées différents, pas seulement la projection Web Mercator ou le système WGS84, qui sont bons pour les données mondiales, mais pas pour les données locales. Nous devrions tenir compte d’autres systèmes de coordonnées. »
Protection des renseignements personnels
Thijs Brentjens, de Geonovum (Pays-Bas), a fait une présentation sur la géolocalisation floue. Cette question a suscité de l’intérêt chez Geonovum en raison du débat aux Pays-Bas sur les applications de suivi des cas de COVID-19, en particulier des préoccupations relatives à la protection des renseignements personnels en ce qui a trait à la saisie et au stockage des données de géolocalisation des particuliers sur un serveur. Par conséquent, le personnel de Geonovum a discuté de la façon dont les services d’API pourraient être utiles pour masquer la position ou l’emplacement réel de l’utilisateur ou y ajouter un caractère aléatoire avant que ces données ne soient transmises aux services internes. Thijs a offert de collaborer avec les parties concernées pour mettre en œuvre un service ou une API de « géolocalisation floue ».
Performance
Andreas Hocevar, contributeur principal à la bibliothèque de cartographie Web OpenLayers, a présenté des travaux de recherche qu’il a effectués, dans le groupe communautaire Maps for HTML, sur l’utilisation de l’API OffscreenCanvas dans Web Workers (fils informatiques parallèles dans le navigateur), pour permettre un chargement et un rendu plus rapides et plus fluides des pavés dans les cartes OpenLayers, sans provoquer le blocage de l’interface utilisateur. Andreas a montré une vidéo qui montre clairement la différence de vitesse de rendu de cette technologie par rapport à l’extraction asynchrone (la norme actuelle). Andreas a terminé en invitant Webkit (Apple) et Gecko (Mozilla) à achever la mise en œuvre de la spécification OffscreenCanvas, afin que les bibliothèques de cartographie et d’autres bibliothèques graphiques puissent déployer ces améliorations de performance dans tous les navigateurs, l’interopérabilité étant un avantage fondamental de la plateforme Web.
Normes et technologie des cartes Web
Amelia Bellamy-Royds a abordé le comportement et les modèles courants des cartes Web ainsi que l’état d’avancement du rapport sur les cas d’utilisation et les exigences relatifs aux cartes Web Elle a mentionné que si les exigences devaient être satisfaites par les cadres existants, aucune mesure ne serait nécessaire, mais cela ne semble pas être le cas, surtout en ce qui concerne l’accessibilité des interfaces utilisateurs. Amelia a présenté des exemples de diverses technologies de cartes Web et de cas d’utilisation, en commençant par l’élément HTML
Dan « The Ducky » Little a présenté GeoMoose, un projet OSGeo mature né en 2003, et qui a subi deux révisions importantes depuis sa création. Le projet utilise toujours le concept d’un catalogue XML pour déclarer la structure de l’application, et ses utilisateurs adorent cet aspect déclaratif. GeoMoose a évolué au fil des générations de cadres JavaScript et prend en charge des formats modernes, comme GeoJSON pour les entités, les pavés vectoriels MapBox, le format GeoTIFF optimisé pour l’infonuagique et d’autres. Le style cartographique des entités continue d’être un défi sans prise en charge directe de la plateforme Web, même s’il existe plusieurs générations de styles d’entités, comme MapCSS, SLD, les feuilles de styles Mapbox GL et les styles OpenLayers. La performance ne va pas de soi, même lorsqu’on utilise des outils de rendu accélérés matériellement, comme WebGL, car le contenu des cartes est souvent présenté dans des formats à grand volume de données qui ne sont pas optimisés pour un rendu dynamique. GeoMoose a pris en charge les protocoles de l’OGC, comme le WMS et le WFS dès le début, et a obtenu une aide financière par l’entremise des subventions du Federal Geographic Data Committee (FGDC) pour permettre l’échange de géoinformation entre les pays, ce qui signifie que les installations de GeoMoose se sont répandues dans le Minnesota et d’autres États du Nord.
Dan Little a offert plusieurs conseils sur la normalisation des cartes pour le Web. Premièrement, les définitions des couches devraient être dissociées des données sources, car cela a représenté un obstacle majeur dans le cadre du projet GeoMoose. Ensuite, il faut intégrer le style dynamique des entités de la carte, conformément à la pratique cartographique.
M. Gobe Hobona, directeur du programme d’élaboration des normes de l’OGC en matière d’API, a fait une présentation sur les principes, la portée, la méthode, l’historique et les plans d’élaboration et de mise en œuvre des normes de l’OGC en matière d’API – la prochaine génération des normes pour les développeurs géospatiaux de l’OGC, qui utilisent la spécification OpenAPI. Les normes précisent les blocs fonctionnels modulaires permettant d’accéder aux données spatiales fournies par les API Web. Ainsi, les normes de l’OGC en matière d’API appliquent également les pratiques exemplaires en matière de données spatiales sur le Web. Afin de faciliter l’élaboration des normes de l’OGC en matière d’API, des courses au codage sont tenues régulièrement pour permettre au grand public d’y participer.
Tom Kralidis a présenté les travaux du projet libre pygeoapi mené par lui-même, Angelos Tzotsos et Francesco Bartoli. Le projet est conçu à l’aide des nombreuses bibliothèques Python de données géospatiales disponibles et prend en charge différentes sources de données finales, en raison de l’intégration du moteur de données spatiales GDAL. Il met également en œuvre la nouvelle API du catalogue d’actifs spatiotemporels (STAC) et les API de l’OGC (entités, pavés, dossiers) ainsi que d’autres normes sur les API. Francesco Bartoli a fait une brève démonstration du cadre. Tom a invité l’auditoire à venir discuter du projet avec les développeurs sur le fil pygeoapi sur Gitter.
Joan Masó du CREAF, rédacteur de l’API de l’OGC – spécification, a fait une présentation sur l’élaboration du langage de balisage de cartes (MapML) par l’entremise du programme de banc d’essai de l’OGC et sur le grand potentiel d’intégration du MapML avec les services Web et les API de l’OGC. Joan a mentionné la relation entre l’ensemble matriciel de pavés en deux dimensions, le service de pavés de cartes Web et le MapML, en soulignant la régularisation du modèle URL dans les trois normes et en rappelant que c’est par l’application de modèles URL que l’on peut dissocier le client et le serveur. Il a indiqué qu’il y a une grande similitude entre un document de métadonnées sur un ensemble de pavés (provenant de l’API de l’OGC) et un document simple en MapML. Il a conclu que le MapML pourrait être le moyen le plus facile et le plus simple de rendre l’API de l’OGC sur les pavés utile à un navigateur, surtout si l’API produit des documents en MapML.
Jonathan Moules de GeoSeer.net, un moteur de recherche de services Web géospatiaux, a fait une présentation sur les limites et les obstacles liés au repérage de services cartographiques par l’entremise de son service GeoSeer. Le principal problème relevé par Jonathan est l’existence de centaines de géoportails. Bien qu’il y ait des millions d’ensembles de données dans le moteur de recherche, sans l’organisation manuelle minutieuse effectuée par GeoSeer, l’utilisateur ne serait pas en mesure de chercher des données dans les portails. Jonathan a soutenu que les organisations qui publient des données au moyen de ces portails ne produisent pas de bonnes métadonnées, ce qui complique davantage le repérage de leurs services. Bien qu’environ deux millions de services aient été répertoriés par GeoSeer, seulement plus ou moins 1500 recherches sont effectuées chaque mois. Bien que le regroupement des portails (p. ex., les services de catalogage en cascade) soit potentiellement une excellente solution à un problème, le problème réel est qu’il n’y a tout simplement pas une grande demande pour le repérage de services. Jonathan termine en posant la question suivante : parmi les deux millions de services répartis dans de nombreux géoportails, combien servent à l’échange et combien à la création de cartes pour un usage individuel? De plus, le fait de mettre des ensembles de données dans un géoportail pour se conformer à un règlement (p. ex., INSPIRE) constitue-t-il une bonne utilisation des ressources, alors que personne (sauf le producteur, peut-être) ne semble utiliser les données ou les chercher aux fins d’utilisation?
Satoru Takagi, membre du groupe de travail sur le SVG du W3C et contributeur de longue date aux normes Web du W3C pour le compte de KDDI Corporation, a élaboré un SIG Web fondé exclusivement sur les normes Web, dont HTML, SVG, CSS et JavaScript. Bien que M. Takagi vise une cartographie Web décentralisée ce qui est également un objectif du groupe communautaire Maps for HTML, il ne croit pas que modifier les navigateurs pour inclure dès le départ un code de cartographie soit un objectif pratique, car les cartes peuvent déjà être créées en combinant les normes Web existantes, comme son travail le démontre. M. Takagi suggère d’élargir la définition du concept de « pavé » de l’Open Geospatial Consortium pour y ajouter des systèmes de pavage particulièrement performants et adaptatifs comme son pavage vectoriel Quadtree. Il propose également que l’industrie géospatiale participe directement au processus du W3C.
Peter Rushforth, de Ressources naturelles Canada, a fait une présentation en deux parties sur la proposition MapML (partie un, partie deux), une proposition élaborée au sein de la communauté Maps for HTML visant à définir les éléments HTML permettant d’intégrer du contenu cartographique à des pages Web et à décrire des données cartographiques (entités vectorielles et ensembles de pavés d’image, ainsi que les annotations et métadonnées correspondantes) dans des fichiers dédiés. MapML répond aux cas d’utilisation et aux exigences permettant de combler les besoins en matière de cartes Web géoréférencées et non géoréférencées, au moyen d’une <map> progressivement améliorée et d’un nouvel élément <layer> en HTML, et est conçu pour soutenir les fonctionnalités de base à l’aide d’une API pour les améliorations programmées.
Simon Pieters de Bocoup, contributeur aux normes du WHATWG et du W3C, à divers navigateurs et aux essais de la plateforme Web, a présenté son examen des documents du groupe communautaire Maps for HTML. Simon a relevé que les cas d’utilisation et les exigences relatifs aux cartes Web sont tout à fait sur la bonne voie, tandis qu’il recommande que la spécification et l’élaboration de l’aide des navigateurs relativement aux cartes soient effectuées progressivement. Plus précisément, il suggère que les efforts de normalisation soient axés sur les primitives fondamentales, c’est-à-dire les petits éléments de fonctionnalité qui peuvent être exposés individuellement et échangés par des applications non géospatiales. À titre d’exemple, il mentionne une demande relative à une entité qu’il a présentée au Groupe de travail sur les CSS, suggérant qu’un modèle d’interaction d’utilisateur avec fonctions de zoom et de panorama (contenu graphique géospatial et non géospatial) devrait être intégré dès le départ aux navigateurs comme solution de rechange à l’interaction de défilement axé sur le texte.
Brian Kardell d’Igalia a fait une présentation sur l’échelle et l’importance de la technologie Web, et les défis connexes liés à l’élaboration de normes Web, soulignant le fait que leur création est coûteuse, risquée et se fait à long terme. Il suggère que la communauté de la cartographie se concentre sur la définition d’objectifs communs et définis qui renforcent progressivement la prise en charge des cartes dans la plateforme Web. Il a offert les services d’Igalia pour aider et suggéré une liste de technologies pour lesquelles l’entreprise aimerait offrir son aide, y compris les fonctions de panorama et de zoom, OffscreenCanvas, le SVG accéléré matériellement et d’autres.
Terence Eden, un partisan de longue date de la normalisation des visualiseurs de cartes en HTML, a fait une présentation qui a encouragé la communauté Maps for HTML à demander aux développeurs leur opinion sur la syntaxe MapML proposée, pour déterminer si celle-ci est trop compliquée ou pas assez explicite pour la communauté. Il a insisté sur le fait que le Web est une ressource internationale partagée par des développeurs de différentes langues, nationalités et expériences, et qu’il est préférable d’élaborer des normes en tenant compte de leur rétroaction itérative.
Iván Sánchez Ortega a fait une présentation dans laquelle il a exprimé ses préoccupations au sujet de l’applicabilité de la proposition MapML, ou de toute approche purement déclarative visant les cartes en HTML. Il a donné des exemples d’API de navigateur existantes et émis des hypothèses sur la façon dont elles pourraient être intégrées aux cartes. Par exemple, l’API Gamepad ou les API d’orientation du dispositif peuvent être utilisées pour manipuler les vues de cartes, mais pas si le visualiseur de cartes est une boîte noire contrôlée par le navigateur. M. Sánchez Ortega a également décrit comment les textures WebGL ont des similitudes avec les données de couverture matricielles d’un SIG; les pavés d’imagerie multispectrale GeoTIFF devraient être considérés comme des minicubes de données de 256×256×7. Il a émis l’hypothèse que le traitement des images pour l’information satellitaire à l’avenir sera effectué dans le navigateur sous forme de « traitement informatique de pointe », en raison des API incroyablement puissantes que la plateforme Web fournit à tous les développeurs, et s’est interrogé sur la façon dont de telles API puissantes fonctionneront avec MapML.
Iván a ensuite insisté sur le fait que la normalisation est un choix et laissé entendre que MapML ne peut pas résoudre les problèmes commerciaux ou juridiques qui sous-tendent les raisons pour lesquelles les cartes sur le Web sont fragmentées et non standard. Iván a donné l’exemple précis du plugiciel GoogleMutant Leaflet, qui utilise l’API de Google avec l’API Web standard Mutation Observers pour superposer et synchroniser les visualiseurs Google et Leaflet, étant donné que les conditions d’utilisation de Google Maps interdisent le rendu direct des pavés d’images de Google au moyen d’un visualiseur autre que celui de Google (comme Leaflet). Iván affirme que les astuces comme son plugiciel GoogleMutant ne devraient pas être nécessaires, et que les fournisseurs de cartes devraient plutôt exposer le contenu au moyen d’API standard qui permettent l’intégration de données cartographiques provenant de sources multiples dans le navigateur. Iván affirme que l’interface standard MapML proposée ne changera pas le comportement des fournisseurs de cartes, mais qu’elle ne fera que dupliquer la fonctionnalité (interfaces non standard) déjà disponible dans les cadres de cartographie JavaScript.
Daniel Morissette de MapGears a fait une présentation sur la mise en œuvre de MapML par MapGears dans MapServer, GDAL et OGR. La présentation de Daniel a mis en évidence la volonté de certains experts de la communauté FOSS4G d’aider à promouvoir l’adoption des normes Web proposées et d’offrir des possibilités d’expérimentation et de rétroaction, grâce à l’intégration de nouveaux formats de données cartographiques dans un logiciel serveur géospatial libre largement utilisé.
Karel Charvat a une présentation sur la technologie « tableau blanc de carte »,et organisé une séance en petits groupes sur la technologie des tableaux blancs que son projet a permis de créer. Un tableau blanc de carte est une carte qui agit à peu près comme un document Web partagé (p. ex., comme un document Google Doc ou MS Teams), ce qui permet aux éditeurs et aux visualiseurs d’enregistrer et de mettre à jour en même temps et dynamiquement la vue de chaque contenu à mesure qu’il change. Le tableau blanc de la carte est construit à l’aide du cadre de cartographie libre OpenLayers JavaScript et s’appuie sur un document JSON sur les compositions de cartes, qui élargit ce que faisait l’ancien type de document de contexte de cartes Web (WMC) en format XML de l’OGC, en y ajoutant de nombreuses caractéristiques modernes.
Kathi Schleidt, à titre personnel, Hylke van der Schaaf et Thomas Usländer ont fait une présentation sur les défis de la cartographie Web des données et métadonnées dynamiques et d’observation obtenues à partir de capteurs. L’API SensorThings de l’OGC suit l’architecture de l’API OData RESTful. Parmi les défis abordés par le projet, mentionnons l’affichage d’une couche de carte bien mise à l’échelle en présence de données à échelles multiples. Le modèle SensorThings est utile, car il permet de formuler vos requêtes en fonction du graphique défini par votre modèle de données, et les requêtes qui en résultent fonctionnent bien avec l’API OData RESTful. Les défis posés par l’affichage des données SensorThings sur des cartes à échelles multiples sont gérés par leur bibliothèque JavaScript qui fonctionne à la fois avec Leaflet et OpenLayers, lequel accepte un objet de configuration JSON qui vous permet de l’étalonner pour l’utiliser dans votre application et est accessible sur GitHub.
Karl Grossner, directeur technique du World Historical Gazetteer et chercheur à l’Université de Pittsburgh, a fait une présentation sur une proposition de prolongation de temps pour GeoJSON, appelée « GeoJSON-T ». GeoJSON est une norme d’encodage de géodonnées Web pour la transmission et la consommation d’entités, de leurs propriétés et de leur géométrie, fondée sur le modèle répandu d’entités simples de l’OGC. La proposition GeoJSON-T élargit le modèle standard avec une composante « quand », ce qui permet au codage de décrire de façon normalisée le moment où l’entité est pertinente. La structure de la composante « quand » n’est pas achevée, mais elle est conçue pour englober des heures précises et floues ainsi que des intervalles de temps. La proposition GeoJSON-T est utilisée par la communauté des sciences humaines numériques, mais pourrait idéalement être façonnée et adoptée hors de cette communauté également.
Bryan Haberberger, président du groupe de spécification technique des cartes de l’IIIF, a fait une présentation sur son travail qui consiste à créer des annotations sémantiques pour les ressources culturelles qui ne sont pas détenues par son organisation, en utilisant GeoJSON-LD, une intégration de la norme GeoJSON (pour coder les entités vectorielles géographiques dans les fichiers de données JSON) avec JSON-LD (données couplées), une méthode pour annoter les objets de données avec des renvois au schéma normalisé définissant leur structure. GeoJSON-LD est basé sur JSON-LD 1.1, car la version originale de JSON-LD ne prend pas en charge les listes de listes, qui sont nécessaires pour le type de géométrie polygonale de GeoJSON. En outre, Bryan a discuté du modèle standard d’annotation Web, qui permet de créer des annotations GeoJSON-LD pour toutes les ressources de données couplées et de les géolocaliser.
Nicolas Rafael Palomino a fait une présentation dans laquelle il a expliqué comment et pourquoi la normalisation de l’information géospatiale est essentielle pour se préparer à un avenir numérique. Dans l’ensemble, il recommande de faire progresser l’objectif de normalisation des cartes en HTML.
Intervenants gouvernementaux
Danielle Dupuy, du Geological Survey des États-Unis (USGS), a présenté les avantages de l’automatisation du style cartographique déclaratif axé sur les données. . L’USGS a mis au point un système qui stocke les renseignements sur le type et le style de carte dans une base de données et présente un emplacement central pour modifier les valeurs déclarées de certaines propriétés de la carte, y compris les symboles, la couleur, la taille et le « volet » des cartes (une abstraction interne Leaflet qui pourrait être décrite comme étant des « catégories » d’index Z). Ces « propriétés » cartographiques peuvent facilement être manipulées par des non-développeurs, et elles réduisent ou éliminent le besoin d’intervention du développeur dans le processus de création de cartes. L’USGS a constaté que le système stimule la productivité, et il prévoit d’appliquer cette technique à d’autres projets.
Chris Little, boursier en technologies de l’information du Met Office du Royaume-Uni, a donné un aperçu éclair de l’histoire et de l’avenir de la cartographie et de la météorologie. Ce fut une visite fascinante à travers des milliers d’années d’évolution des cartes et de la technologie de gestion de l’information spatiale, qui s’est terminée par quelques observations sur les besoins actuels et les tendances futures potentielles. Chris a d’abord observé que la métaphore actuelle de la « couche » de carte Web ne fonctionne pas pour les cartes météorologiques. La combinaison dans les cartes de centaines de « niveaux », à des centaines de points temporels ou d’intervalles, avec des centaines d’ensembles de données donne des millions de couches possibles. Chris prédit l’intégration de l’information spatiale et des navigateurs sur une période de 10 ans, sans préciser comment cette intégration se produira ou devrait se produire; cependant, il souligne que l’environnement technologique actuel est particulièrement propice à une telle croissance. Chris indique qu’il préférerait commencer l’intégration de la technologie cartographique dans le navigateur avec du contenu 3D, et obtenir du contenu 2D à partir de cette intégration, ce qui faciliterait la résolution de certaines catégories de problèmes.
Sajeevan G. a fait une présentation sur l’application Web GIS appuyant le Programme des routes rurales du premier ministre indien (PMGSY). L’application PMGSY existe depuis plus de 15 ans et a notamment permis la migration d’une application commerciale basée sur un SIG vers une interface Web, fondée sur les normes de service Web, le libre accès et les logiciels commerciaux. M. Sajeevan a relevé que, bien que l’application puisse produire et consommer des services standard de l’OGC, de nombreuses entreprises doivent encore accepter du contenu d’entités en tant que fichiers de forme seulement. On s’attend à ce que les prochaines API Web de l’OGC fassent partie intégrante des transactions d’entités à l’avenir. En ce qui concerne la normalisation des cartes en HTML, M. Sajeevan souligne l’importance des systèmes de coordonnées locales et recommande qu’une vue du globe semblable à celle de Google Earth soit jugée essentielle dans une future norme sur les cartes Web. Un visualiseur sphérique évite d’avoir à préciser des projections cartographiques dans la norme, en permettant au visualiseur de réaliser spontanément une déprojection vers la vue du globe au moment de l’exécution. Le visualiseur devrait pouvoir consommer des services de données cartographiques externes, prenant en charge à la fois les types de données matricielles et vectorielles (entités). M. Sajeevan prévoit d’énormes contributions de la part de la communauté des développeurs à un visualiseur de cartes HTML dans un navigateur, et voit les services de données géospatiales comme une nouvelle occasion d’affaires en conséquence.
Intervenants : les fournisseurs de données géospatiales du gouvernement et le Web
Un groupe d’intervenants gouvernementaux s’est réuni pour discuter de l’importance de l’information géospatiale pour les gouvernements et de l’incidence qu’une norme sur les cartes Web pourrait avoir sur les objectifs de leurs organisations. Le groupe était composé de Sébastien Durand, gestionnaire de la Plateforme géospatiale fédérale (PGF), de Cameron Wilson, gestionnaire du programme GéoConnexions à Ressources naturelles Canada, d’Emilio López Romero, directeur du Centre national d’information géographique de l’Espagne, et de Don Sullivan, scientifique spécialiste en géospatiale et expert en normes à l’Ames Research Center de la NASA et l’un des auteurs originaux de la norme de l’OGC sur le service de cartographie Web. Sébastien a fait valoir que les cartes Web offrent une vue des données en contexte unique et presque magique dans sa capacité de transformer les données en connaissances. En général, les membres du groupe étaient réceptifs ou enthousiastes à l’égard de la proposition visant à normaliser et à intégrer les cartes à la technologie des navigateurs, particulièrement au moyen des API de l’OGC et du HTML, parce qu’ils croient qu’une telle intégration réduirait les obstacles à une meilleure utilisation des infrastructures de données spatiales publiques, en plus de fournir une norme interexploitable pour une « image opérationnelle commune » qui recoupe les cadres JavaScript.
Don Sullivan, Ames Research Center de la NASA :
« Quand j’ai entendu parler […] des cartes sur le Web et des cartes en tant que citoyen de première classe, je me suis dit “oh mon Dieu, oui”. Je suis donc ici […] en tant que champion. Je pense que cette idée est extraordinaire et qu’on l’attend depuis trop longtemps. En fait, je l’attends depuis plus de 20 ans. »
Intervenants : libre accès pour la cartographie Web
Un groupe de développeurs de logiciels géospatiaux et de navigateurs libres a discuté de ce qu’il faut faire pour intégrer la prise en charge des cartes aux navigateurs Web. Tom Kralidis d’OSGeo, responsable de nombreux projets Geopython, a animé une réunion d’experts regroupant Simon Pieters de Bocoup, Daniel Morissette d’OSGeo/MapGears, Will Mortenson du programme Gnome de la NGA et Andreas Hocevar d’OpenLayers/OSGeo. Le groupe a discuté de la collaboration entre les communautés Web et géospatiale et de ce qu’il faut pour apporter des idées et des exigences aux normes HTML et aux bases de codes de navigation. De plus, le groupe a abordé les problèmes liés aux bibliothèques de cartographie Web qui pourraient être plus faciles à résoudre grâce à une meilleure prise en charge par le navigateur des interfaces de cartes avec fonctions de zoom et de panorama, dans des domaines comme la performance et le style des entités vectorielles, sans laquelle les développeurs de cadres de cartographie Web et les auteurs de contenu doivent maîtriser des API complexes de bas niveau comme WebGL.
Daniel Morissette, MapGears / OSGeo :
« Le service de cartes Web (SCW) est un bon exemple d’une norme qui fonctionne et qui est efficace, même si elle est simple et qu’on pourrait la qualifier de défectueuse. Si elle est assez bonne, les gens vont l’utiliser, et si l’intégration des cartes en HTML est assez bonne, elle gagnera en popularité au fil du temps. »
Will Mortenson, Programme Gnome de la NGA :
« Je recueille les besoins des clients et des utilisateurs; […] en tant que fonctionnaire, je ne sais pas nécessairement tout [sur le fonctionnement des navigateurs Web.] Donc, si des gens […] du public pouvaient souligner pourquoi il est important [d’investir dans les cartes dans les navigateurs], [le gouvernement pourrait investir] de l’argent dans ces efforts. »
Andreas Hocevar – OpenLayers / OSGeo :
« [Un élément HTML cartographique natif] nous permettrait certainement de nous concentrer davantage sur ce que nous pouvons faire avec les cartes; comment nous pouvons créer de belles cartes, comment nous pouvons aider les utilisateurs en créant de belles cartes […]. Plus j’y pense, plus j’aime […] le concept de base […] d’une carte avec fonctions de zoom et de panorama […]. Avec cela en place, les bibliothèques de cartographie pourraient probablement prendre des orientations auxquelles nous ne pensons même pas encore. Cependant, le fort accent actuellement mis sur le rendu s’oppose assurément […] à d’autres types de développements. »
Simon Pieters – Bocoup :
« Les développeurs de navigateurs et de cadres cartographiques doivent se parler et s’entendre sur les cas d’utilisation et les exigences et sur la façon dont nous pouvons modifier le navigateur pour mieux répondre à ces besoins d’une manière bien conçue […] au moment de concevoir des solutions dans [cet] espace […]. Les cartes devraient être accessibles aux personnes qui utilisent des lecteurs d’écran […] par défaut, dans la mesure où elles peuvent l’être. Mais pour un rendu plus personnalisé, lorsque vous utilisez des spécifications d’interface ou WebGL, il est difficile d’avoir une accessibilité par défaut, mais vous devrez rendre possible l’intégration, d’une manière ou d’une autre. »
Intervenants en cartographie commerciale
Ted Guild du World Wide Web Consortium (W3C) a présidé un groupe d’intervenants des plateformes de cartographie commerciale, dont Ed Parsons (Google), Johannes Lauer (HERE, anciennement Nokia, cartes), Daniel Lewis (Geotab) et Thomas Lee (Mapbox). Ce groupe d’intervenants a trouvé un terrain d’entente sur des questions liées à la cartographie Web et abordé de façon réfléchie le thème de l’atelier (normes pour les cartes Web) tout en discutant de divers sujets, notamment l’avantage potentiel des normes sur les cartes du côté client pour améliorer l’agilité relative à l’itération des produits, les avantages et les limites des données ouvertes (gouvernementales et autres) pour créer du contenu cartographique, l’importance de la performance du rendu pour le contenu cartographique du côté client, la façon dont les cas d’utilisation simples, comme le rendu GeoJSON sur des cartes de base, dégagent une grande valeur; la valeur des renseignements relatifs aux pavés vectoriels pour créer des interfaces et des styles accessibles et accroître la performance; la nécessité de mener d’autres travaux pour élaborer des approches en matière de licences de données qui reflètent l’état avancé du processus d’octroi de licences de logiciels libres, la perspective que la technologie 5G puisse améliorer les cartes pour tous, la façon dont les annotations et les balises textuelles et sémantiques intégrées aux pages Web peuvent être liées de façon importante aux emplacements et aux cartes, et la révolution prochaine de la cartographie intérieure.
Daniel Lewis – Geotab :
« […] [En cas de] catastrophe, […] la capacité des décideurs à accéder rapidement à ce genre de données […] influe à terme sur […] leur capacité à prendre des décisions éclairées par ces données […]. Il est vraiment important de pouvoir rapidement itérer le processus […]. L’interopérabilité est […] un élément clé dans tout cela […]; et intégrer cette norme à l’outil que tout le monde utilise […] permet d’éliminer rapidement les obstacles […]. »
Tom Lee — Mapbox :
« Pour nous, il est vraiment important d’augmenter la performance. La transition vers une mise en œuvre native pourrait vraiment accroître la performance. […] Tout ce qui peut être fait pour améliorer davantage la performance fera avancer les choses, et si la normalisation peut en faire partie, alors ce serait vraiment formidable. »
Ed Parsons – Google :
« Ce que je veux dire, c’est que nous devons davantage nous adresser au grand public. Nous devons beaucoup plus agir comme des citoyens du Web que créer notre Web géospatial distinct où nous faisons les choses différemment. »
Conclusion
Wendy Seltzer – Avocate et responsable de la stratégie au W3C :
« […] En tant que responsable de la stratégie au W3C, je suis ravie de ce que j’entends et nous accueillerons toute mesure de suivi suggérée concernant les lacunes à combler dans les travaux sur les normes existantes ou les nouveaux travaux que vous aimeriez que le W3C entreprenne. Sachez que l’équipe est là pour vous aider. »
Les normes de cartographie sur le Web ont déjà été axées sur les technologies et l’infrastructure côté serveur, et il existe un ensemble robuste de normes pour les serveurs de cartes qui interagissent étroitement avec les techniques modernes universelles du côté client, comme les cartes à pavés avec fonction de panorama et de zoom. Étant donné que ces techniques sont de facto des normes entre tous les fournisseurs de cartes Web et qu’elles sont stables depuis quelques années, il y a des facteurs communs qui bénéficieraient de toute évidence d’une normalisation officielle du côté client, comme le pavage, le panorama, le zoom, les systèmes de référence à coordonnées, les couches, les entités cartographiques accessibles (p. ex., les zones d’intérêt géométriques) et plus encore.
Un autre moteur de la normalisation des cartes est l’amélioration de l’accessibilité des cartes Web, ce qui constituait un thème important de l’atelier. Plusieurs examens des cadres de cartographie existants ont révélé un manque fondamental d’accessibilité, qui doit être abordé dans les normes Web.
Prochaines étapes
La prochaine étape logique consiste à entamer la discussion sur la façon dont un groupe de travail devrait définir la portée de ces entités dans sa charte. Les deux principaux points de discussion sont ce qui est visé ou non par la première charte et s’il faut définir des entités propres à la carte de niveau supérieur ou décomposer la fonctionnalité en des primitives plus génériques qui peuvent résoudre un plus grand nombre de cas d’utilisation au-delà des cartes.
La charte devrait également définir la relation et la coordination entre les normes sur les cartes du côté serveur et du côté client, et plus particulièrement les groupes de travail du W3C qui devraient être consultés et avec lesquels il faudrait collaborer afin d’obtenir le meilleur résultat possible. Il existe une relation mutuelle entre le W3C et l’OGC, qui comprend une entente de collaboration conjointe qui faciliterait le rassemblement des bons intervenants et des groupes de travail pertinents des deux organisations.