Communauté

Intéressez-vous à TJS

NeoGeo-Online - lun, 09/10/2018 - 13:50

Actuellement, les relations entre la plupart des IDG actuelles et les données tabulaires dont regorgent les collectivités et autres établissements publics sont assez tristes. Les géomaticiens qui participent à la conception, la réalisation et l’administration de telles infrastructures ont été élevés dans le culte de la donnée topographique, de la précision géodésique et des relations topologiques. Résultat : pas de géolocalisation, pas de publication.

Le constat est plutôt amer : les IDG actuelles ne savent pas valoriser des données tabulaires si elles ne sont pas passées entre les mains d’un géomaticien au préalable pour les géolocaliser. C’est regrettable puisque, quelques facteurs concordants devraient pousser leur publication sur des IDG :

  • la majorité des données géographiques produites par les parties prenantes des IDG sont de simples données tabulaires organisées par unités territoriales (dont facilement géolocalisables) ;
  • la majorité des utilisateurs des IDG (en collectivité, dans les services de l’Etat et dans bien d’autres administrations publiques) ont besoin d’indicateurs selon des découpages territoriaux et non de données topographiques qu’elles ne savent pas interpréter ;
  • la majorité des gens qui aimeraient exploiter des IDG, n’ont pas de compétence en géomatique mais sont tout à fait capables de comprendre des cartes avec des indicateurs territoriaux.

À l’heure où l’Open Data prend le pas sur la mise en œuvre d’INSPIRE, la situation des IDG vis-à-vis des données tabulaires n’est plus tenable. Elle l’est d’autant moins qu’il existe justement un standard dont l’objectif est de fournir des données tabulaires à des outils SIG qui se chargeront d’y adjoindre une géométrie : Table Joining Service (TJS). L’intérêt de ce standard ne réside pas uniquement dans le fait qu’il gère des données tabulaires mais aussi que c’est l’application cliente qui se charge d’attribuer une géométrie et une représentation aux informations qui lui sont transmises. Cela permet de publier des données géographiques sans compétences spécifiques en géomatique (en faisant complètement abstraction de la projection, des problèmes de précision géographique, des règles de représentation cartographique…). On évite donc également de devoir publier les données en 3 versions pour satisfaire les adorateurs du RGE, les fans d’OSM ou ceux de je ne sais quel autre référentiel idéalisé.

C’est parce que nous sommes convaincus que les données tabulaires sont sous-exploitées par les IDG actuelles et que TJS apporte une solution concrète que nous avons développé un serveur sous licence ouverte implémentant ce standard : OneTjs. Aujourd’hui l’implémentation phare de TJS est Géoclip. Preuve de son interopérabilité, OneTjs permet d’alimenter le client cartographique d’un Géoclip distant avec vos propres données.

Illustration : offre hôtelière en Normandie servies par OneTjs et affichée dans Géoclip O3

Quand on vous dit que vous devriez vous intéresser à TJS…

Catégories: Société

Blockchain et information géographique

NeoGeo-Online - mer, 07/11/2018 - 18:04

Suite à une série de présentations publiques sur le thème de la blockchain depuis le printemps (FOSS4G-FR, GeoDataDays notamment) il est temps de rendre compte des diverses réflexions qui ont motivé cette démarche et qui ont aussi été alimentées par des échanges nourris avec les participants.

Qu’est-ce que la blockchain ?

La blockchain n’est que le dernier avatar d’une longue série de techniques destinées à conserver de l’information de manière durable. Les premiers exemples d’écriture témoignent déjà de ce besoin. Ce sont les comptables qui les premiers ont tracé des symboles dans l’argile, ce sont aussi les comptables qui les premiers ont vu l’intérêt de la technologie blockchain pour inventer les cryptomonnaies. La blockchain n’est rien de plus qu’un registre numérique sécurisé et distribué, permettant de s’affranchir d’une autorité régulatrice, chacun faisant office de tiers de confiance (mais on parle déjà là de gouvernance, nous y reviendrons). Ce registre numérique sécurisé vise à reproduire dans notre monde de fake news et copies illicites la notion d’infalsifiabilité qui fait la valeur des registres papier reliés. Dans ceux-ci, une page sans rature signifie que les informations n’y ont pas été altérées. La présence de toutes les pages, vérifiables par leur numérotation ou l’absence de déchirure, permet de certifier que toutes les informations sont bien présentes. C’est exactement ce que vise à reproduire la blockchain dans le contexte d’un registre numérique.

Comment ça marche ?

Si le principe de la blockchain est finalement assez simple, il recourt à des algorithmes très sophistiqués que je serais bien en peine de vous expliquer en détail et que l’on désigne sous le nom de fonctions de hachage (hash en anglais). Ceux-ci sont capables de générer des chaînes de caractères de longueur fixe (32 bits, 64 bits…) uniques (si la longueur est bien choisie évidemment) à partir d’un contenu quelconque (fichier, image, texte, chiffres) servant ainsi d’empreinte numérique compacte à des choses très variées. On s’en sert pour vérifier l’intégrité d’un téléchargement par exemple, car l’altération du moindre bit change radicalement l’empreinte numérique. Par exemple le hachage par SHA256 (un des algorithmes les plus répandus) du terme « géomatique » donne D47A202B297CB6CCD4238CB88BBD49670209447787BE73EA834725A1AB184F6E tandis que pour « geomatique » (sans accent donc) on obtient 3BF2C56948337C47F1E031E2ACE3F4EEFEE62FC2D3AB55625688683FE385274E ! Impossible de les confondre ou de supposer de leur proximité littérale.
A l’aide de ces puissants algorithmes, la blockchain reproduit les deux preuves de non altération du registre qu’offre la version papier broché :

  • La page devient le bloc. Il est composé de lignes d’écriture (transactions, opérations diverses). Dans l’en-tête du bloc (le haut de page en quelque sorte), on écrit l’empreinte numérique des opérations, de telle sorte que si une d’entre elles venait à être modifiée, l’empreinte ne correspondrait plus au contenu. Le registre ayant vocation à être public et distribué, chacun peut faire ce genre de vérification.
  • Chaque bloc est relié au bloc précédent, en reprenant également son empreinte numérique dans son en-tête. Ainsi, si tout le bloc venait à être modifié (opération + en-tête), c’est dans le bloc suivant qu’on verrait l’incohérence. La falsification n’est pas impossible, mais imposerait de réécrire toute la chaîne, de régénérer tous les hash, en suffisamment peu de temps pour que ça passe inaperçu. C’est donc de facto irréalisable.

Ça donne alors à peu près ça :

On a ici le bloc n° 3 référençant le bloc précédent (previous) par son hash, contenant une charge utile composée de transactions, dont l’empreinte numérique et l’horodatée sont également inscrits. Toute altération de ce contenu serait détectable très rapidement, car le hash se calcule en quelques centièmes de seconde et peut donc être vérifié par tout utilisateur, voire automatiquement par des programmes spécialisés.

Pour quoi faire ?

Belle technologie donc, mais on n’est pas des comptables non plus, et on n’a pas forcément envie de se convertir aux cryptomonnaies, qui recourent largement à ces technologies. Donc que va-t-on pouvoir bien faire d’un registre infalsifiable ? Mais ce qu’on veut, c’est ça qui est extrêmement séduisant ! On va pouvoir y écrire absolument ce qu’on veut, des positions de véhicules, des valeurs de capteurs, des noms de fichiers, des empreintes numériques de documents, mélanger le tout, secouer, la blockchain est agnostique. Dès lors qu’on doit pouvoir prouver l’enregistrement d’une information à un moment donné (la patrouille de police était devant la mairie, le document d’arpentage a été publié, le taux de CO2 dépassait la norme) sans avoir à douter de celui qui tient le registre, le serveur, la base de données, tous ces intermédiaires qui peuvent, avec les systèmes de bases de données traditionnels (fichiers ou SGBD), falsifier un contenu numérique, sans avoir à se reposer sur un tiers de confiance, la blockchain fait des merveilles.

Et l’information géographique là-dedans ?

Comme indiqué précédemment, on peut enregistrer ce qu’on veut dans la blockchain, de l’information géographique ou autre. On peut donc très bien avoir des geoblockchains dédiées et optimisées à cet usage, dans lesquelles on peut imaginer des conditions de validation supplémentaires (vérification de cohérence géographique, de topologie, tout ce qui fait le miel du géomaticien au quotidien). Mais on peut aussi en faire le déclencheur de la validation du bloc. C’est une notion que nous n’avons pas encore abordée, mais s’il peut sembler clair que tout un chacun (les utilisateurs de la blockchain au moins) vont être en mesure d’enregistrer des opérations, qui valide les blocs ? Pour le Bitcoin il s’agit également des utilisateurs eux-mêmes, suscitant des courses de vitesse très énergivores pour calculer le premier le Proof of Work, autre empreinte numérique obéissant à des contraintes fortes, afin de ne pas être calculable trop vite, car dans le monde des cryptomonnaies les validateurs de blocs sont rétribués et il ne faut pas trop stimuler la création monétaire. Tout est donc fait pour qu’un bloc mette 10 minutes en moyenne pour être validé. Dans un monde géomatique, les choses n’ont pas la même criticité, et surtout nous ne créons pas de monnaie. Donc qui valide le bloc, c’est tout l’enjeu de la gouvernance.

Qui c’est qui commande ?

On voit déjà s’indigner le burelain, le rond-de-cuir, appliqué à soigner les pleins et les déliés de son registre jalousement gardé dans son tiroir fermé à clé… « Ne seriez-vous pas un peu des anarchistes vous autres ? », « que vais-je devenir ? « . Mais comme pour ce qu’on met DANS la blockchain, la manière de piloter la blockchain, d’assurer sa gouvernance, est très libre. Au modèle égalitaire et horizontal revendiqué des cryptomonnaies, il existe des approches plus intégrées, des blockchains de consortium ou même privées, dans lesquelles les droits à l’écriture des opérations et à la validation des blocs sont réservés à certains utilisateurs, comme du temps des registres papier. La distribution du registre pour lecture peut ainsi être ouverte à certains utilisateurs, et les modifications à d’autres. Rien de très original donc, si ce n’est que même si vous déléguez la saisie des opérations à un tiers, il n’aura néanmoins pas la possibilité d’en falsifier le contenu. Ou s’il le fait ça se verra… L’information géographique peut elle-même servir de preuve. Parce que je suis à tel endroit je suis en mesure de certifier que : la voiture de location s’y trouve aussi, la borne cadastrale est bien positionnée, le bureau de l’AFIGEO est toujours au bistrot…

Alors on se lance ?

De nombreux secteurs d’activités s’intéressent de près à cette technologie. C’est évidemment le cas des banques, qui disposent déjà de blockchains de consortium en interbancaire, des assurances, de l’aviation… du foncier évidemment avec quelques programmes pilotes en Afrique. La totale liberté du contenu de la blockchain et de sa gouvernance devrait en séduire d’autres, dès lors que la réticence due à la proximité encore marquée avec les sulfureuses cryptomonnaies se sera dissipée et que la blockchain sera ramenée à la place qui est la sienne, un bon vieux registre.

Catégories: Société

Où en est le BIM pour les Infrastructures ?

Geospatial France - ven, 02/02/2018 - 17:27
Dodge Data & Analytics a mis récemment à disposition un rapport sur “la valeur du BIM pour les Infrastructures 2017”. Vincent Fredon en parlait aussi sur Civil Made in France. Les pays couverts...

{Cliquez sur le titre pour lire la suite...}

Vues panoramiques dans AutoCAD, Map 3D et Civil 3D-Webinaire Brockwell et Cyclomedia le 8 février 2018

Geospatial France - mer, 01/24/2018 - 09:12
Le 8 février 2018 à 16h, Brockwell et Cyclomedia organisent un webinaire sur l’utilisation des vues panoramiques 360 degrés de Cyclomedia sous Autocad (aussi pour Map 3D et Civil 3D). Brockwell est...

{Cliquez sur le titre pour lire la suite...}

Additions to the MapFish Protocol

Eric Lemoine - sam, 04/18/2009 - 23:55

We recently added new stuff to the MapFish Protocol.

As a refresher, let’s first take a look at what the MapFish Protocol had before the new additions.

(Note that you’d need the JSONovich FireFox extension to see the output of the examples given below in your web browser.)

Geographic query params

  • box={x1},{y1},{x2},{y2}: the features within the specified bounding box
  • geometry={geojson_string}: the features within the specified geometry
  • lon={lon}&lat={lat}&tolerance={tol}: the features within the specified tolerance of the specified lon/lat

Examples:

Limiting and Sorting

  • limit={num}: the maximum number of features returned
  • offset={num}: the number of features to skip
  • order_by={field_name}: the name of the field to use to order the features
  • dir=ASC|DESC: the ordering direction

Examples:

The new params

  • no_geom=true|false: so that the returned feature has no geometry (“geometry”: null)
  • attrs={field1}[,{field2},...]: to restrict the list of properties returned in the features
  • queryable={field1}[,{field2},...]: the names of the feature fields that can be queried
  • {field}__{query_op}={value}: filter expression, field must be in the list of fields specified by queryable, query_op is one of “eq”, “ne”, “lt, “le”, “gt”, “ge”, “like”, “ilike”

And now an example combining all the new parameters:

The above query returns a GeoJSON representation of the summits whose names include “col” and whose elevations are greater than or equal to 3500. The returned features have no geometry and their attributes include “name” and “elevation” only.

Not including the geometry in the features makes the parsing in the browser much faster, so for cases where the geometries aren’t needed this is a big win.

Credits for the “queryable={field}&{field}__{query_op}={value}” syntax goes to FeatureServer!

Catégories: Technique

Secure TileCache With Pylons and Repoze

Eric Lemoine - dim, 02/15/2009 - 19:14

This post shows how one can secure TileCache with Pylons and Repoze.

In a Pylons application one can run a WSGI application from within a controller action. Here is a simple example:

class MainController(BaseController) def action(self, environ, start_response): return wsgiApp(environ, start_response)

TileCache is commonly run from within mod_python. TileCache can also be run as a WSGI application, therefore it can be run from within the controller action of a Pylons application. Here’s how:

from TileCache.Service import wsgiApp class MainController(BaseController) def tilecache(self, environ, start_response): return wsgiApp(environ, start_response)

Pretty cool… But it gets really interesting when repoze.what is added to the picture. For those who don’t know repoze.what, repoze.what is an authorization framework for WSGI applications. repoze.what now provides a Pylons plugin, making it easy to protect controllers and controller actions in a Pylons application. Here’s how our tilecache action can be protected:

from TileCache.Service import wsgiApp from repoze.what.predicates import has_permission from repoze.what.plugins.pylonshq import ActionProtector class MainController(BaseController) @ActionProtector(has_permission('tilecache')) def tilecache(self, environ, start_response): return wsgiApp(environ, start_response)

With the above, anyone who tries to access /tilecache will have to be granted the tilecache permission. Otherwise, authorization will be denied.

TileCache is secured!

People often want finer-grained authorization, like give certain users access to certain layers. With Pylons’ routing system this can be easily and elegantly achieved using repoze.what, I will show that in a later post.

Catégories: Technique
S'abonner à OSGeo-fr agrégateur