[OSM-talk-fr] téléchargement d'une zone trop grande

[Philippe Verdy]

Le 22 février 2012 15:49, sly (sylvain letuffe) <liste at letuffe.org> a écrit :
> On mercredi 22 février 2012, sukran.geo sukran.geo wrote:
>> Bonjour,   J'ai une zone dans OSM que je veux télécharger, mais...
>> apparemment, elle est trop grande, et voici le message qui s'affiche. (voir
>> JPEG Joint) J'ai ensuite téléchargé le fichier de Geofabrik, mais idem, pb
>> de taille. Que faire ? Il me faut toute la zone, et je ne veux pas pas faire
>> plein de petits morceaux.
>
> Elle est grosse comment ta zone ?
> Parce que si tu veux ouvrir un département complet dans JOSM, il vaut mieux
> oublier tout de suite et faire autrement ;-)
> Si c'est raisonnablement petit, mais que l'api officielle te bloque, dans JOSM
> tu peux tenter de remplacer api.openstreetmap.org par api.openstreetmap.fr
> les limites en téléchargement son plus élevées

Mais c'est vrai aussi qu'il manque à la base OSM un vrai système de
réplication sur des miroirs synchronisés, capables de répondre de
concert à une même requête.

Quelques idées suivent...

Une sorte de RSYNC mais adapté aux bases de données (et non à un
système de fichiers hiérarchique), par lequel toute modification
enregistrée dans la base principale permet d'alimenter un flux de
redistribution des transactions "committées" vers un ensemble de bases
miroirs. De tels systèmes de réplication sont dans tous les RDMBS
commerciaux, mais pas toujours dans les RDBMS libres où ce sont
souvent des greffons mal intégrés ne garantissant pas la
synchrinisation de l'ensemble et la cohérence relationelle des
transactions annulées par un "rollback".

Cela nécessite des systèmes réellement transactionnels pour valider
l'état réel des modifications confirmées sur une base centrale, mais
aussi un système de "rattrapage" permettant même de resynchroniser une
base esclave qui aurait perdu à un moment donné le fil et devrait se
remettre à jour (par exemple en cas d'arrêt momentané pour une
maintenance, ou à cause d'un problème réseau temporaire, ou simplement
pour démarrer une nouvelle base esclave au départ vierge, avec une
synchronisation qui va progressivement charger les donnés manquantes).

Enfin si une telle réplication était réellement opérationnelle et
assez rapide pour qu'un ensemble de bases miroirs puissent toutes
répondre à une demande de chargement de données (je ne parle pas des
requêtes de modification de ces données), une déclaration de ces bases
miroirs opérationnelle pourrait avoir lieu dans le système DNS afin
que ces requêtes soient distribuées au hasard sur n'importe laquelle
de ces bases et pas forcément la base centrale qui est bien plus utile
et seulement nécessaire pour valider les transactions de modification.

Cela imposerait d'avoir deux adresses (URL) de bases de données dans
les éditeurs : une pour les chargements et mises à jour, l'autre pour
les modifications, sachant que ce n'est qu'au moment où on va valider
les données (dans un système de « validation en deux phases ») que la
première chose qui sera faite sera de comparer les versions provenant
des miroirs et celles actuellement dans la base, afin qu'à ce seul
moment-là le serveur central puisse fournir une URL vers les données à
jour dans un des miroirs disponibles sur lequel le serveur central
pourrait poser un verrou temporaire sur les objets correspondants,
pour la validation en deux phases, jusqu'à ce que soit la transaction
soit validée par un "commit" soit annulée par un "rollback", soit que
cette annulation ait lieu automatiquement après un délai raisonnable,
le client devant alors refaire ses transactions et étant prévenu que
sa dernière transaction a été annulée).

Bote: les transations sont autre chose que les groupes de
modifications qui sont des regroupements logiques effectués
utilisateur par utilisateur (selon leur propre logique et leur
déploiement car un même utilisateur peut utiliser simultanément
plusieurs outils et donc avoir plusieurs groupes de modification
ouverts. Ces groupes sont ouverts pour une durée relativement longue
(la fermeture automatique n'a lieu qu'au bout de deux heures
d'inactivité sur ce groupe, en théorie du moins car j'ai déjà vu le
serveur fermer prématurément un groupe en moins de 5 minutes, et même
parfois au beau milieu d'un enregistrement, les autres modifications
non envoyées étant alors rejetées mais devant être enregistrées dans
un autre groupe).

Pour moi la fermeture automatique des groupes n'est pas nécessaire,
sauf pour leur attacher quelques attributs en commun. Notamment le
suivi des attributs indiquant quel est logiciel utilisé, qui l'a créé,
quand il a commencé et quand *l'utilisateur* a indiqué qu'il avait
terminé, et finalisé son commentaire.

Le commentaire ne devrait être finalisé que si *toutes* les modifs ont
pu être envoyées. En cas de conflit d'édition, un groupe de modifs
peut rester ouvert relativement longtemps, le temps pour l'utilisateur
de régler ces conflits avant de soumettre les autres données, dont bon
nombre d'ailleurs ne sont pas en conflit.

Mais le serveur alors va fermer prématurément un groupe de modifs,
alors que les données envoyées sont incomplètes, ce qui laisse par
exemple des noeuds ajoutés, mais pas les chemins qui les connecte, ou
des voies ajoutées sensées remplacer une autre dont la demande de
suppression n'est pas encore passée.

A cause de cela, cela laisse des doublons et données incohérentes dans
la base, et aucun moyen pour les outils de suivi de savoir quoi faire.
D'autant plus que le serveur OSM ne renseigne même pas quand il a
*lui-même* fermé un groupe de modification laissé ouvert (normalement
le temp pour l'utilisateur de régler les conflits ou ses problèmes de
connexion).

Bref, la fermeture automatique des groupes de modification est une
très mauvaise idée, et même une totale et complète ***aberration*** du
schéma actuel. Cela ne correspond d'ailleurs à rien en terme
transactionnel, puisque les validations (commits) et réplications se
feront à une échelle bien plus petite, celles des objets (avec leurs
attributs et leurs membres pour les relations).

Les groupes de modifications eux-mêmes sont un objet distinct de la
base de données. Leur existence est nécessaire avant toute autre
opérations de création/modification/suppression sur les autres objets,
mais personne d'autre que l'utilisateur qui l'a créé via son logiciel,
***pas même le serveur***, ne doit avoir à en contrôler l'indication
de sa fermeture, ni certains autres attributs tels que le commentaire,
voire des métadonnées nécessaires à la l'octroi de licence, car
personne d'autre que lui ne pourra les changer (en revanche le serveur
continuera à contrôler des attributs comme l'identité de
l'utilisateur, si cette identité a été certifiée par un protocole
sécurisé, et les dates d'ouverture ou de dernière modification dans ce
groupe ; il ne fera éventuellement qu’exiger que certains autres
attributs soient renseignés dans le groupe de modifications, comme
l'identification suffisante du logiciel utilisé, ou le "user-agent"
d'un navigateur, et quelques autres données comme la langue utilisée
dans le logiciel de l'utilisateur).

Ces objets "groupes de modifications" entrent dans les données
nécessaires pour analyser les historiques, retrouver les auteurs,
comprendre les raisons de certaines données, ou à quoi elles étaient
peut-être destinées; elles sont aussi indispensable pour suivre les
conditions de licence et donc doivent être conservées si les autres
objets qui sont listés dans ce groupe à une version donnée sont encore
présents dans la base. Ces groupes de modification sont aussi à
transporter dans les systèmes de synchronisation, au même titre que
les objets géométriques (neuds et chemins) et les relations (ces
objets les référencent version par version).

Un groupe de modifications peut être mis à jour autant de fois que
nécessaire par un même utilisateur et sans limite de durée — du moins
tant que le même utilisateur n'a pas rouvert un autre groupe
référençant des modifications sur un ou plusieurs des mêmes objets
géométriques ou relations, seul cas où éventuellement on peut admettre
une fermeture automatique. Mais je penche plutôt sur une condition de
fermeture basée sur un volume maximum en nombre d'objets modifiés dans
le groupe (basée davantage sur une politique mise en œuvre par le
logiciel client qu'un contrôle absolu par le serveur), afin que le
client s'assure d'envoyer des données cohérentes et suffisantes dans
un même groupe de modifications, notamment quant il doit créer ou
modifier un chemin, dont les nœuds modifiés/créés/ajoutés devraient
toujours être dans le même groupe de modifications. Le logiciel client
pourra créer automatiquement autant de groupes de modifications que
nécessaire pour respecter correctement les contraintes de volume par
groupe, mais seul l'utilisateur doit en contrôler la fermeture, même
s'il y en a plusieurs, afin qu'il puisse finaliser le commentaire et
les données nécessaires à une licence ou le contrôle ultérieur de
validité de cette licence, telles que la citation d'une source
autorisée, ou encore des commentaires destinés à une maintenance
ultérieure sur des données seulement estimées ou incomplètes, ou
encore pouvoir résoudre un conflit partiel nécessitant de modifier
encore un objet déjà envoyé dans ce groupe de modifications.

En revanche les transactions sur le serveur c'est autre chose ! Cela
ne concerne que les objets individuels (ou presque) et se limite à
assurer qu'il n'y a pas de conflit de versions, ni perte de la
cohérence référentielle de base:
 * un chemin doit toujours associer au moins deux nœuds (quitte à ce
qu'ils soient superposés géométriquement).
 * les nœuds d'un chemin doivent toujours exister, et doivent avoir un
numéro de rang unique dans ce chemin (afin de pouvoir définir un
ordre).
 * les membres d'une relation doivent toujours exister, et doivent
avoir un numéro de rang unique dans la relation (afin de pouvoir
définir un ordre).
 * chaque version d'un noeud/chemin/relation doit toujours référencer
un groupe de modifs existant,
 * une même version d'un noeud/chemin/relation ne peut pas être
référencée par plusieurs groupes de modifs,
 * un groupe de modifs doit toujours référencer un utilisateur
existant et cette référence à un utilisateur ne peut pas être changée
(on ne peut que supprimer un groupe de modifiations et les versions de
nœuds/chemins/relations qui référencent ce groupe).
 * et certains attributs sur ces objets sont obligatoires et respecter
certaines contraintes pour leur valeur ou leur format.

Ces règles de base (purement relationnelles) sont celles servant à
définir les briques minimales de ce qui sera synchronisé entre
serveurs ou miroirs et lors des transactions (même pour les
transactions à validation multiphase). Avec cela on peut sérieusement
envisager un déploiement solide et plus large de serveurs coopérant
entre eux, y compris pour la contribution de leur bande passante, et
avec les utilisateurs, avec un coût partageable qui pourra être réduit
pour le bénéfice de tout le monde pour peu que chacun puisse faire une
contribution, même petite au regard du volume total des transactions
échangées, mais pourtant utile à tous car elle aussi partagée et
offerte aussi aux autres en tant que service supplémentaire.

Toutefois pour que les miroirs fonctionnent réellement, il doit
exister un moyen de vérifier que ceux-ci ne véhiculent pas
d'informations altérées par rapport au serveur central où sont
validées les modifs. La solution simple consiste à ce que le serveur
central calcule une signature numérique des données qu'il a validées,
avec un certificat de sécurité dont il détient seul la clé privée,
tandis qu'il fournit à tous une copie du certificat de sécurité
contenant la clé publique permettant de comparer les signatures
numériques recalculées. Cette signature numérique serait alors un
attribut de tous les objets qui peuvent accessibles et sont distribués
par la base.

La signature numérique d'une version d'un objet étant dépendante de la
date de cette version, ainsi que du certificat utilisé pour la
calculer à cette date, il faut aussi que l'objet contiennent la
référence à ce certificat (devenu un objet relationnel à part entière
dans la base). Ce qui permet aussi plus tard de mettre à jour ou
changer ces certificats et de recalculer les signatures numériques des
autres objets relationnels (et leurs attributs textuels, numériques ou
géométriques) en cas d'expiration du certificat. Bref deux attributs
par objet: la signature numérique (par exemple une chaine hexadécimale
de longueur fixe dans un attribut "Signature:SHA1"), et un URI (URL ou
URN) vers la copie publique du certificat de sécurité (dans un
attribut comme "Signature:Certificate").

Ces attributs seront calculés par le serveur de validation uniquement
et présentés dans toutes les requêtes. Il faut une signature séparée
par objet (nœud, chemin, relation, groupe de modifications,
utilisateur), cette signature exposée publiquement ne devant être
calculée QUE sur les données publiques accessibles (pas les données
privées ou secrètes, par exemple dans un objet de type utilisateur).

De la même façon le serveur central de validation peut aussi calculer
une signature numérique pour un objet représentant un serveur
lui-même, si le système autorise ce serveur à effectuer des
validations locales qui seront ensuite transmises par ce serveur local
au serveur central, "au nom de" ses propres utilisateurs sur le
serveur local. Cela permet un système où la confiance et la
responsabilité peut être déléguée et partagée, de façon limitée, avec
une responsabilité assumée par celui qui gère un serveur local. Cela
peut aussi servir à accorder à un serveur local davantage de droits en
terme de bande passante, car il assure un service pour de nombreux
utilisateurs en soulageant le serveur central de la visite de ces
mêmes nombreux utilisateurs.

Avec un objet dans la base de données représentant un serveur
(probablement représenté par une URL, mais ce peut être aussi un
simple ID numérique vers un objet contenant en attribut cette URL à
priori unique dans la base), une requête à un serveur pourra donner
une réponse contenant la référence à un autre serveur disponible (par
exemple lors d'opérations de maintenance sur l'un d'eux, ou d'un
problème de disponibilité d'une liaison, ou de délai de mise à jour
dans les données en cache d'un serveur DNS utilisé par le client).