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

Mer 22 Fév 17:31:19 UTC 2012

Non, la signature numérique ne modifie pas du tout l'API car cela
n'apparaîtra que comme des attributs de plus parmi d'autres.

Le 22 février 2012 18:29, Emilie Laffray <emilie.laffray at gmail.com> a écrit :
> Salut,
>
> c'est fort intéressant mais plutôt que nous abreuver de ce genre de détails
> peut être faudrait il en parler sur la liste de Développement en anglais, la
> ou toutes les réelles discussions techniques ont lieu.
> De plus, il y a des raisons historiques et de performances pour le
> comportement de l'API. Déjà, c'est un choix volontaire de réduire la taille
> car c'est une API pour les contributeurs. Quand le point est soulevé, on
> pointe vers le fichier planète avec synchronisation.
> Ce que tu offres c'est un peu un raisonnement un peu déconnectée de la
> réalité. De plus, la réplication est déjà possible. Passer vers une solution
> décentralisée avec une signature ne résoudra pas grand chose et le coup de
> calcul des signatures sera important, sans parler le coup de la
> synchronisation (il suffit de demander aux gens qui ont des miroirs ici)
> rend une vrai solution décentralisée extrêmement compliquée.
> Ta solution de la signature si elle n'est pas valide obligerait de rappeler
> l'API et donc de rajouter une charge supplémentaire.
>
> Emilie Laffray
>
> 2012/2/22 Philippe Verdy <verdy_p at wanadoo.fr>
>>
>> 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).
>>
>> _______________________________________________
>> Talk-fr mailing list
>> Talk-fr at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>
>