Le 16 avril 2013 21:51, <thevenon.jul...@free.fr> a écrit : > > > J aime bien ton idee, tu peux donner un peu plus de details sur le > fonctionnement interne ? ( cf les questions ci dessous ) >
OK, je vais y répondre, en étant conscient que Christian ne semble pas en accord avec cette proposition, il semble vouloir ne pas aller trop vite dans l'implémentation... il voulait du REST, je lui en propose... il est bien le seul qui ait peur que je travaille trop vite :-) J'attire tout de même son attention sur le fait que mon idée de partir, non pas de la notion d'identification, mais de la notion de critères d'égalité, ou critères de reconnaissance si je parle le plus "comme tout le monde" que je puis, est quand même pas du niveau du codage immédiat ! > > > Le serveur rest renvoie une lien vers une page contenant la liste des id > des objets osm correspondant à ce schéma, page et liens qu'il aura fabriqué > lui même. > > Comment il la fabrique ? > > Je vois ça avec l'overpass api. Le système transforme les critères d'égalité en requête overpass, puis numérote simplement les objets osm réponse, les transforme en une liste de liens, etc. L'URL de la page critère sera du type http://machin/CRITERES ( http://machin/PLACES_PIETONNES dans mon exemple) L'URL de chaque objet OSM sera du type http://machin/CRITERES/idobjet ( http://machin/PLACES_PIETONNES/4567 dans mon exemple). > > Donc, dans l'exemple, à partir de la, il existera dans le serveur rest > une base de liens des places piétonnes, et le serveur renverra l'url d'une > page contenant une liste de liens vers les places piétonnes. Cette page > sera une vue de la base OSM, c'est à dire que si on ajoute ou retire une > place piétonne, alors la liste sera dynamiquement modifiée en fonction. > > Comment tu maintiens la coherence entre la vue et le contenu de la base > OSM ? > > Pour chaque objet de la vue, il n'y a pas de problème il me semble ? Là c'est affaire d'implémentation, Christian va rouspéter si j'en parle trop :-) Le seul choix stratégique sera de savoir si je tolère un certain retard de la vue sur le contenu de la base OSM. Ce n'est pas fondamental me semble-t-il. Pour la liste, c'est plus difficile... Là je pense obligatoire qu'il y ait un certain retard, à voir. Chaque fois que le système mettra la liste à jour, il fera une nouvelle requête overpass, et traitera selon les critères. Si un objet osm correspond à un objet déjà identifié selon les critères donnés, alors il conserve l'id. Sinon, on lui donne un nouvel id. Et si un objet enregistré ne correspond plus à aucun objet dans la requête, alors il est supprimé (mais l'id n'est pas réutilisé). > Le serveur garantit que : > > [...] > > - Si quelqu'un change la valeur d'un des critères d'égalité (par exemple > change les coordonnées), alors le serveur changera l'id de cet objet, > l'ancien id devenant invalide, à moins qu'un autre objet osm devienne > "valide" selon cet id. > > Mais dans ce cas la on perd la trace de l objet non ? si il est deplace > pour etre positionne plus finement cela reste le meme objet. est ce que c > est souhaitable que l ID change ? > > Oui, l'objet changera d'id à ce moment là. Du moins si la définition des critères d'égalité contient les coordonnées et que ça sort de la surface de tolérance. Dans le système que je propose, qui je le crois se rapporte très bien aux objets géographiques, et même mieux que le système d'id des bases de données, (sinon je le proposerai pas) c'est l'utilisateur qui distingue les objets, et donc détermine les critères d'identification des objets, et donc les critères d'égalité. C'est le rendu qui fait l'objet. Je sais que cette approche est complètement opposée à celle proposée habituellement, et apparemment opposée à celle de Christian, mais c'est celle que je défends. Par exemple, on mappe un arrêt de bus, et on dit "Les critères de reconnaissance d'un arrêt de bus, c'est sa position géographique selon tel flou, son nom, sa ligne". Le système lui donnera un id selon ces critères. Et puis on s'aperçoit qu'on l'a mal mappé, qu'on s'est trompé de coté de rue, par exemple. Si le décalage sort du flou de position géographique, alors l'arrêt de bus aura un autre id, sinon, non. C'est à l'utilisateur de se donner le mou qu'il veut à l'avance, et de bien penser le jeux de critères. Normalement, pour un arrêt de bus, le couple "nom-ligne" est suffisant, il n'a pas besoin de mettre la coordonnée géographique. S'il a peur que deux arrêts de bus aient le même nom sur la même ligne (ce qui serait déjà fumeux), alors il rajoute la coordonnée. Si, en plus, il se trompe dans le mapping... OSM ne peut plus rien pour lui, son système est merdique, et il est justifié qu'il donne un nouvel id il me semble :-) > - Si quelqu'un change la valeur d'une propriété de l'objet osm non > incluse dans les critères d'égalité, alors l'id de l'objet ne change pas. > > Meme question que precedemment, comment detectes tu les changements ? > Là je vois pas le problème : si j'admets un certain retard je lis simplement les objets correspondant à la requête périodiquement ; si je n'admets aucun retard, et que la synchro est immédiate, alors je fais une requête à l'overpass api sur cet objet et je renvoie l'objet direct. Si je constate à ce moment là que les critères ne sont plus satisfaits, alors je ne renvoie aucun objet, je refabrique la liste des objets, etc. En fait, ce système est une sorte de proxy ciblé. Il est une façon, pour un domaine d'application, de dire : "Parmi tous les objets d'OSM, nous nous intéressons plus particulièrement à tels et tels objets, dont voici les critères de reconnaissance ; fabriquez nous une sorte de proxy de valeurs avec ça, proxy qui fournit par exemple le service d'identification selon nos propres critères." As usual, si ce que je dis est complètement incompréhensible, ou complètement faux, dites moi :-) Cordialement. -- Les dérives de rue : Profession émotion <http://drivrsdu.fr/profession-emotion/>
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
