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

Mer 22 Fév 18:03:43 UTC 2012

C'est pour ça qu'il y a le type gist sous postgresql. Mais je te conseille
vraiment de pousser l'idée sur la mailing list internationale de
développement.

Emilie Laffray

2012/2/22 Philippe Verdy <verdy_p at wanadoo.fr>

> Enfin je me suis expliqué plus longuement pourquoi une requête de
> simple comptage peut être très efficace et soulager énormément le
> serveur.
>
> Car les technologies d'indexation multidimensionnelle dans une base de
> données relationnelle existent depuis longtemps (plusieurs dizaines
> d'années qu'elles sont proposées au départ comme extensions dans les
> SGBD, puis intégrées totalement à ces systèmes qui incluent nativement
> la création de tels index, pour différentes applications y compris les
> "métacubes" qui effectuent des agrégations complexes de données au
> départ purement relationnelles et à valeur simples).
>
> La syntaxe de création de tels index multidimensionels peut être aussi
> simple que:
>
> CREATE INDEX nodes_coords ON nodes ((x, y))
>
> où les parenthèses internes indiquent que les attributs indiqués ne
> privilégient pas un ordre d'indexation d'un attribut par rapport à un
> autre, mais demandent à l'index de maintenir automatiquement un
> parcours équilibré de l'index entre les dimensions indiquées.
>
> En l'absence de tels index multidimensionnels intégrés au moteur SQL,
> il fallait d'abord créer dans la table de noeuds une valeur d'attribut
> supplémentaire, produite par une transformée alternant les bits de
> données successifs de chaque coordonnées, et ensuite créer un index
> basé sur la valeur de cet attribut spécial.
>
> Mais c'était coûteux en espace, et pas optimal non plus car la
> transformation était prédéterminée en fixant dès le départ le mode de
> découpage strictement alterné entre les dimensions, sans tenir compte
> du poids statistique réel de chaque découpe fixée aussi sur des
> valeurs de seuil prédéterminées (sans tenir compte de la densité
> réelle des éléments dans chaque découpe : l'arbre de découpage n'était
> pas bien équilibré à cause justement de cette transformation
> arbitrairement prédéterminée sur des seuils fixes, là où un index
> multidimensionnel détermine localement et automatiquement les seuils
> les plus adéquats pour maintenir le meilleur équilibre statistique et
> une densité à peu près constante dans tous les parcours possibles et à
> tous les niveaux de l'arbre).
>
> Le 22 février 2012 18:31, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :
> > 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
> >>
> >>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20120222/49481150/attachment.htm>