Le 22 février 2012 15:49, sly (sylvain letuffe) <[email protected]> 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). _______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
