Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Le 27 janvier 2013 00:52, Vincent de Chateau-Thierry v...@laposte.net a écrit : D'accord avec ça. La stabilité, il faut faire sans. Ou plutôt partir du principe qu'elle n'est pas de fait, et s'armer en conséquence. Tu parles des outils de surveillance, ils sont un moyen majeur de cette détection des changements, et surtout, des régressions. Mais mes craintes formulées hier soir étaient, en effet, directement liées à l'étape de contribution : je bouge un node, boum je casse la calibration de mon référentiel. Or j'ai réalisé depuis que ce genre de casse était déjà géré, au moins par JOSM, dans le contexte des relations. Je découpe un way qui appartient à une relation = les nouveaux ways issus de la découpe viennent remplacer l'ancien way unique dans la liste des membres de la relation. Et ça fonctionne. Vu comme ça, il n'y a pas de raison qu'un mécanisme ne puisse être mis en place, qui recalibre à la volée mon réseau au fil de son édition, pour maintenir, relativement, la définition de mes évènements modélisés par segmentation dynamique. Donc de fausses craintes finalement, au prix bien sûr d'un ajout fonctionnel dans les éditeurs pour gérer ce nouveau type de définition relative (mon pont-rail commence à 7.5 km du début du way, etc). Je vois aussi ça comme ça: aux outils d'édition de masquer la complexité de la modélisation. Le problème c'est que ça rend de plus en plus complexe la réalisation d'un éditeur car il doit gérer un modèle de donnée de plus en plus complexe. Or, il y a de nouveaux éditeurs qui sortent (par exemple Go Map! sur iOS) et avant qu'ils gèrent tout cela il va se passer du temps... donc on va avoir des éditeurs qui casseront facilement ces modèles complexes alors que d'autres (peut être un seul pour un bout de temps) les gèrera. Aïe ! -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Le 25/01/2013 21:18, Vincent de Chateau-Thierry a écrit : Bonsoir, Le 25/01/2013 15:44, HELFER Denis a écrit : Je commence à m’intéresser sérieusement à la segmentation dynamique dans le domaine de l’infra ferroviaire où l’on raisonne essentiellement en termes de PK (pour les événements ponctuels ex. Passage à niveau, appareil de voie)ou PK début/Pk fin pour les événements linéaires (ouvrages d’art, chantiers, électrification, …). Je confirme mon intérêt pour cette démarche ! Idéalement, on devrait avoir une consistance topologique au niveau du tracé, la consistance sémantique serait assurée par des relations. Exemple pour un pont-rail Relation X Required Type=ouvrage_art Required Description=pont-rail Optional source=RFF Optional material=metal Optional length=xxx Optional height=xxx Optional name=blabla Required Members : a rôle « from » Required Members : b rôle « to » Required Members : c rôle « on » Optional members : d rôle « under » a=id du point début du pont (son PK debut) b=id du point fin du pont (son PK fin) c=id du tronçon de voie supportant la relation d=id du tronçon de la voie traversée (rivière, chemin, route, …) C’est clair qu’il y a du boulot pour des applications pour transformer ces relations en objets découpés suivant les pointillés. Dans ton exemple, la portion de voie ferrée de type pont-rail est définie par ses bornes, sous forme de nodes : a et b. Une autre manière, même sans node, consiste à définir le pont avec 2 abscisses curvilignes, à partir d'un way dont une extrémité serait le PK 0. Dans ce cas, on pourrait dire : le pont rail commence au PK 7.5 et se termine au PK 7.6, c'est à dire : le pont rail commence à 7.5km du début du way et mesure 100m. Ces 2 manières de dire la même chose souffrent du même bémol : il ne faut pas que la référence (le way) bouge, sinon l'objet pont-rail bouge aussi. Dans le premier modèle, il suffit de bouger par exemple le node a pour déplacer le début du pont-rail. Dans le second, si je raffine la courbure de la voie ferrée, j'augmente la longueur du way, et je déplace l'endroit situé à 7.5 km du début. Dans les deux cas on est face à, j'ai l'impression, une contradiction : la segmentation dynamique requiert une stabilité du référentiel géométrique pour que les objets définis relativement à cette géométrie soient stables, et à l'inverse, dans OSM, chacun est libre de modifier tous les objets, rien n'est figé/vérouillé. Du coup est-ce compatible, au stade des contributions ? C'est différent au stade de la réutilisation, où chacun est libre de définir des objets (des 'évènements') relativement au graphe OSM, dès lors que celui-ci a été extrait une fois et figé pour servir de référence. La stabilité du référentiel géométrique dans le cadre d'un projet collaboratif ouvert relève du domaine de la foi (et non pas de la doctrine). Cela ne concerne pas que cette histoire de segmentation dynamique. Qu'un attribut vienne à disparaïtre, une coordonnée de noeud soit déplacée, de manière intentionnelle ou non, et toute application se servant des données OSM se trouve potentiellement malmenée. Nous disposons d'outils de surveillance qui deviennent de plus en plus efficaces parce qu'à mesure que la taille de la base, les usages -notamment dans des environnement professionnels- croissent, les exigences sont toujours plus prégnantes. La tentation est donc de ne mettre dans la base que le substrat, le terreau sur lequel les réutilisateurs de tous poils viendront planter leurs graines. C'est la vision minimaliste et une question récurrente sur les listes de discussion : jusqu'où aller dans la description du réel, quel niveau de détail, quelle homogénéité, quels usages ? Selon moi, il y a triple réflexion : - organiser la base (ontologie) de la manière la plus rationnelle et consensuelle possible, quitte à innover avec les relations au détriment de l'acception courante des applications ; c'est le modèle de données qui doit être le moteur car il essaie de traduire les visions multiples de nos réalités complexes ; - veiller à ce que la base soit conforme à un minimum de modélisation (documentée) commune. Sans parler de labellisation, on peut chercher à évaluer (donner de la valeur) le niveau de conformité par rapport à nos règles (osmose est probablement un des meilleurs démonstrateurs de cette veille -surveillance-) ; - adapter dans le temps l'ambition de 1 aux ressources nécessaires en 2 : accompagnement au changement. Après avoir enfoncé ces portes ouvertes, et si je t'ai bien compris, réserve-t-on l'ontologie commune (donc minimale) aux contributeurs et les ontologies spécialisées aux réutilisateurs ? Je crois qu'OSM peut être, outre un lieu d'intégration de données, un creuset de savoirs de tous les acteurs, une lunette géante qui corrigerait tous les défauts d'astigmatisme, de myopie, d'ambiopie, etc. et qui serait gratuite pour tous. Denis, pas en charge du budget de la Sécu
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Bonsoir Le 26/01/2013 21:30, DH a écrit : La stabilité du référentiel géométrique dans le cadre d'un projet collaboratif ouvert relève du domaine de la foi (et non pas de la doctrine). Cela ne concerne pas que cette histoire de segmentation dynamique. Qu'un attribut vienne à disparaïtre, une coordonnée de noeud soit déplacée, de manière intentionnelle ou non, et toute application se servant des données OSM se trouve potentiellement malmenée. Nous disposons d'outils de surveillance qui deviennent de plus en plus efficaces parce qu'à mesure que la taille de la base, les usages -notamment dans des environnement professionnels- croissent, les exigences sont toujours plus prégnantes. D'accord avec ça. La stabilité, il faut faire sans. Ou plutôt partir du principe qu'elle n'est pas de fait, et s'armer en conséquence. Tu parles des outils de surveillance, ils sont un moyen majeur de cette détection des changements, et surtout, des régressions. Mais mes craintes formulées hier soir étaient, en effet, directement liées à l'étape de contribution : je bouge un node, boum je casse la calibration de mon référentiel. Or j'ai réalisé depuis que ce genre de casse était déjà géré, au moins par JOSM, dans le contexte des relations. Je découpe un way qui appartient à une relation = les nouveaux ways issus de la découpe viennent remplacer l'ancien way unique dans la liste des membres de la relation. Et ça fonctionne. Vu comme ça, il n'y a pas de raison qu'un mécanisme ne puisse être mis en place, qui recalibre à la volée mon réseau au fil de son édition, pour maintenir, relativement, la définition de mes évènements modélisés par segmentation dynamique. Donc de fausses craintes finalement, au prix bien sûr d'un ajout fonctionnel dans les éditeurs pour gérer ce nouveau type de définition relative (mon pont-rail commence à 7.5 km du début du way, etc). La tentation est donc de ne mettre dans la base que le substrat, le terreau sur lequel les réutilisateurs de tous poils viendront planter leurs graines. C'est la vision minimaliste et une question récurrente sur les listes de discussion : jusqu'où aller dans la description du réel, quel niveau de détail, quelle homogénéité, quels usages ? Selon moi, il y a triple réflexion : - organiser la base (ontologie) de la manière la plus rationnelle et consensuelle possible, quitte à innover avec les relations au détriment de l'acception courante des applications ; c'est le modèle de données qui doit être le moteur car il essaie de traduire les visions multiples de nos réalités complexes ; Dans le cas de la segmentation dynamique, le modèle doit évoluer, les relations telles qu'utilisées pour l'instant sont trop étriquées. Le rôle seul ne suffit plus. Bref, un sujet pour une version d'API post 0.6, et des éditeurs qui devront suivre. - veiller à ce que la base soit conforme à un minimum de modélisation (documentée) commune. Sans parler de labellisation, on peut chercher à évaluer (donner de la valeur) le niveau de conformité par rapport à nos règles (osmose est probablement un des meilleurs démonstrateurs de cette veille -surveillance-) ; - adapter dans le temps l'ambition de 1 aux ressources nécessaires en 2 : accompagnement au changement. Après avoir enfoncé ces portes ouvertes, et si je t'ai bien compris, réserve-t-on l'ontologie commune (donc minimale) aux contributeurs et les ontologies spécialisées aux réutilisateurs ? Avec des thématiques comme, par exemple, le TMC, on dépasse à mon sens largement le périmètre du pot commun. Après, tout celà reste pour l'instant décrit dans un modèle de données simplissime, ce qui fait aussi sa force : des points, des points ordonnés en lignes brisées, des ensembles de points et de lignes brisées,... et point. Rajouter la segmentation dynamique ouvrirait bien sûr le potentiel de modélisation, mais dans le même temps ajouterait une complexité. On n'a pas fini d'en débattre... Je crois qu'OSM peut être, outre un lieu d'intégration de données, un creuset de savoirs de tous les acteurs, une lunette géante qui corrigerait tous les défauts d'astigmatisme, de myopie, d'ambiopie, etc. et qui serait gratuite pour tous. Denis, pas en charge du budget de la Sécu vincent (astigmate, hypermétrope, et enrhumé :-) ) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Le 27 janvier 2013 00:52, Vincent de Chateau-Thierry v...@laposte.net a écrit : Je crois qu'OSM peut être, outre un lieu d'intégration de données, un creuset de savoirs de tous les acteurs, une lunette géante qui corrigerait tous les défauts d'astigmatisme, de myopie, d'ambiopie, etc. et qui serait gratuite pour tous. Denis, pas en charge du budget de la Sécu vincent (astigmate, hypermétrope, et enrhumé :-) ) Philippe (myope, astigmate, un peu presbyte, et deutéranomalien... mais sinon en pleine forme. Mais pour un rhume quand ça m'arrive, je ne prends aucun médoc, juste une boisson chaude, du miel et du curcuma, ça suffit, rien à demander à la Sécu pour ça). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
2013/1/24 Arnaud arnaud@gmail.com: Néanmoins, avez-vous déjà vu des propositions allant en ce sens (ou autres)? Il y a une méthode encore plus simple : représenter le pont lui-même sans toucher à la route. Il y a la méthode du simple way superposé à la route mais c'est mal suporté par les éditeurs (et les contributeurs qui ne les voient pas). Il y a alors la méthode de tracer le tablier du pont avec un polygone. C'est plus facile depuis qu'on dispose d'images aériennes en haute résolution. Mais ça n'est pas le cas partout. L'inconvénient de toutes ces modélisations, c'est qu'elles s'adaptent mal aux tunnels qui, eux, nécessitent pratiquement toujours une segmentation du highway pour identifier les changements d'attributs comme maxspeed et/ou maxheight. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Le 25 janvier 2013 10:37, Pieren pier...@gmail.com a écrit : L'inconvénient de toutes ces modélisations, c'est qu'elles s'adaptent mal aux tunnels qui, eux, nécessitent pratiquement toujours une segmentation du highway pour identifier les changements d'attributs comme maxspeed et/ou maxheight. Tout comme certains ponts nécessitent une segmentation pour un changement de PTAC max ou un changement de largeur de la chaussée (généralement un rétrécissement). Je suis plutôt de l'avis de Philippe, utiliser des relations pour mettre en correspondance plusieurs éléments me semble plus accessible que de mettre plusieurs segments l'un sur l'autre. Il faut qu'il y ai une liaison entre ces composants au niveau de la base de données, sinon rien n'indiquera que la route passe effectivement sur le pont. -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
2013/1/25 François Lacombe francois.laco...@telecom-bretagne.eu: Il faut qu'il y ai une liaison entre ces composants au niveau de la base de données, sinon rien n'indiquera que la route passe effectivement sur le pont. Urg, je m'étrangle à chaque fois que je lis ça. OSM est une base de données géospatiale. Tous les noeuds et ways sont déjà positionnés les uns par rapport aux autres. On ne doit (devrait) ajouter des tags ou des relations que lorsqu'il y a ambiguité. Quant à la remarque de Philippe, je suis désolé, je n'ai pas compris (comme souvent). Ou alors, c'est lui qui n'a toujours pas compris la distinction entre 'roles' et 'tags' dans les relations. Les roles 'from', 'to' sont déjà couramment utilisés dans les turn_restrictions... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Le 25 janvier 2013 05:31, Philippe Verdy verd...@wanadoo.fr a écrit : Le 24 janvier 2013 21:20, Arnaud arnaud@gmail.com a écrit : Peut-être qu'il pourrait être intéressant d'utiliser le potentiel des relations? Je m'explique, en gardant le modèle précédent : N1 - N2 - N3 N4 Relation tunnel : yes from : N2 to : N3 Les avantages sont une cohérence des attributs génériques à la route (nom, type, etc.), un objet géographique unique (plus grande rapidité de traitement?), une maintenance attributaire et géographique facilitée. Les inconvénients sont, je pense, un modèle peu compréhensible pour les débutants ainsi que logiquement une augmentation des relations. L'ennui c'est comment représenter et *stabiliser* les deux tags from=N2 et to=N3 : comment désigner les noeuds si ce ne peut pas être un rang dans le chemin ? Il faudrait alors nommer les noeuds ou utiliser leurs IDs. Et il n'y aura aucune vérification de cela. La segmentation n'est pas réellement un problème : on a des relations pour rassembler les fragments de chemin ensembles et de façon stable. Je n'ai peut-être pas bien compris tes remarques, mais tu penses qu'il faudrait utiliser l'ID des nodes pour les désigner aux tags from et to ? C'est pas déjà ce qu'on fait dans je-ne-sais-combien de types de relations ? Comme stop_areahttps://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_area, où des nodes sont utilisés pour indiquer le stop_position (pour ne citer qu'un exemple). Après, tu parles de stabilisation. Si tu veux dire par là qu'un tel système est à la merci d'une suppression du node qui servait de 'from' ou de 'to', je suis d'accord avec toi, mais le même problème se pose avec des relations composées de bouts de ways : il suffit quelqu'un fusionne 2 ways contiguës pour que la relation soit cassée (cas fréquent pour les frontières). Francescu ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Le 25 janvier 2013 11:22, Pieren pier...@gmail.com a écrit : 2013/1/25 François Lacombe francois.laco...@telecom-bretagne.eu: Urg, je m'étrangle à chaque fois que je lis ça. OSM est une base de données géospatiale. Tous les noeuds et ways sont déjà positionnés les uns par rapport aux autres. On ne doit (devrait) ajouter des tags ou des relations que lorsqu'il y a ambiguité. Il ne faut pas s'étrangler, ca n'en vaut pas la peine. Néanmoins, je vois mal comment peut-être exprimée une quelconque dépendance entre une route et un pont sur lequel elle passe dans la réalité sans relation entre les objets. Je crois que l'API d'OSM ne gère pas les altitudes et que donc même si la route est bien positionnée par rapport au pont, ce dernier peut se trouver 100m en dessous (il y a le tag ele=* mais ca ne compte pas). -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Et actuellement, un tel comportement est considéré comme une erreur : soit pour cause de doublon soit, lorsque 2 ways se croisent, pour absence de node à l'intersection (d'où le tag 'layer'). Francescu Le 25 janvier 2013 11:55, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : Le 25 janvier 2013 11:22, Pieren pier...@gmail.com a écrit : 2013/1/25 François Lacombe francois.laco...@telecom-bretagne.eu: Urg, je m'étrangle à chaque fois que je lis ça. OSM est une base de données géospatiale. Tous les noeuds et ways sont déjà positionnés les uns par rapport aux autres. On ne doit (devrait) ajouter des tags ou des relations que lorsqu'il y a ambiguité. Il ne faut pas s'étrangler, ca n'en vaut pas la peine. Néanmoins, je vois mal comment peut-être exprimée une quelconque dépendance entre une route et un pont sur lequel elle passe dans la réalité sans relation entre les objets. Je crois que l'API d'OSM ne gère pas les altitudes et que donc même si la route est bien positionnée par rapport au pont, ce dernier peut se trouver 100m en dessous (il y a le tag ele=* mais ca ne compte pas). -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Bonjour à tous, Je vais essayer de compléter mon argumentation. Afin d'éviter de partir sur des problèmes de représentation liés a des éléments matériels (pont, tunnel, etc.), prenons l'exemple des limitation de vitesse. Chaque changement (ex, passage de 50 à 70) occasionne alors un découpage et la création d'un tronçon. L'idée de départ, étant d'utiliser un concept existant, celui de la segmentation dynamique, mais adapté à OSM. Je précise que ce concept de segmentation dynamique, ne sort pas de ma caboche mais existe déjà dans les bases de donnes routières [ex 1]. La segmentation dynamique permet d'avoir un réseau routier non segmenté auquel est associé une (ou plusieurs) table complémentaire d'événements (limitation de vitesse, pont, etc.). En fonction de la demande (limitation de vitesse, pont, etc.) le réseau est segmenté dynamiquement (d'où le nom du concept). Quand j'ai commencé à me renseigner sur ce domaine, j'ai immédiatement pensé aux potentialités des relations. En effet, dans un SIG classique les tables étant séparées, la seule relation entre la route et les événements sont leur positions géographiques. Or, les relations nous permettent de conserver à la fois une cohérence géographique et sémantique. Bon voila pour la théorie, maintenant j'ai bien conscience de la difficulté de compréhension d'un tel modèle pour un nouveau contributeur. Mais il a aussi un gain certain en terme de gestion des données, performance et stockage ! Arnaud 1 - https://ceprofs.civil.tamu.edu/folivera/txaggis/Spring2004/von_Holdt/CVH_project_report.htm On 13-01-25 07:29 AM, Francescu GAROBY wrote: Et actuellement, un tel comportement est considéré comme une erreur : soit pour cause de doublon soit, lorsque 2 ways se croisent, pour absence de node à l'intersection (d'où le tag 'layer'). Francescu Le 25 janvier 2013 11:55, François Lacombe francois.laco...@telecom-bretagne.eu mailto:francois.laco...@telecom-bretagne.eu a écrit : Le 25 janvier 2013 11:22, Pieren pier...@gmail.com mailto:pier...@gmail.com a écrit : 2013/1/25 François Lacombe francois.laco...@telecom-bretagne.eu mailto:francois.laco...@telecom-bretagne.eu: Urg, je m'étrangle à chaque fois que je lis ça. OSM est une base de données géospatiale. Tous les noeuds et ways sont déjà positionnés les uns par rapport aux autres. On ne doit (devrait) ajouter des tags ou des relations que lorsqu'il y a ambiguité. Il ne faut pas s'étrangler, ca n'en vaut pas la peine. Néanmoins, je vois mal comment peut-être exprimée une quelconque dépendance entre une route et un pont sur lequel elle passe dans la réalité sans relation entre les objets. Je crois que l'API d'OSM ne gère pas les altitudes et que donc même si la route est bien positionnée par rapport au pont, ce dernier peut se trouver 100m en dessous (il y a le tag ele=* mais ca ne compte pas). -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
C'est une modélisation très intéressante, mais malheureusement sûrement complexe à appréhender par une majorité de contributeurs. Elle me semble intéressante car elle permet d'avoir une sorte de mise en hiérarchie des détails, alors qu'aujourd'hui on a tendance à multiplier les objets pour permettre d'indiquer de plus en plus de détails et du coup il y a un gros manque de hiérarchie dans les données OSM ce qui oblige à repartir dans l'autre sens: regrouper des objets pour avoir une vue plus globale. Je pense que quel que soit le modèle adopté, ce sont aux outils d'édition de masquer le modèle de donné utilisé ce qui n'est pas le cas aujourd'hui. Le modèle se complique petit à petit dans pas mal de domaines (le premier qui me vient à l'esprit est le public_transport), et les outils d'éditions ne sont pas vraiment là. Du coup, on casse facilement des relations surtout quand elles sont complexes. Serait-il possible d'avoir des extensions à JOSM qui s'occuperaient de maintenir la cohérence de tel ou tel modèle ? Imaginez une extension frontière qui feraient automatiquement les vérifications et effectuerai les éventuelles remises en cohérence dès qu'on touche à une limite administrative... Imaginez une extension landuse qui dès qu'on coupe en deux un polygone créerait un multipolygone et y reporterai les tags... Imaginez une extension coastline qui empêcherai de casser par mégarde la pointe bretonne ;) C'est au moment même d'une édition qu'il faut faire les vérifications et signaler les problèmes éventuels créés, peut être qu'une petite modification du fonctionnement du validator pour qu'il agisse plus en live pourrait être un premier pas. Ca vaut peut être un autre sujet de discussion... Le 25 janvier 2013 13:39, Arnaud arnaud@gmail.com a écrit : Bonjour à tous, Je vais essayer de compléter mon argumentation. Afin d’éviter de partir sur des problèmes de représentation liés a des éléments matériels (pont, tunnel, etc.), prenons l'exemple des limitation de vitesse. Chaque changement (ex, passage de 50 à 70) occasionne alors un découpage et la création d'un tronçon. L’idée de départ, étant d'utiliser un concept existant, celui de la segmentation dynamique, mais adapté à OSM. Je précise que ce concept de segmentation dynamique, ne sort pas de ma caboche mais existe déjà dans les bases de donnes routières [ex 1]. La segmentation dynamique permet d'avoir un réseau routier non segmenté auquel est associé une (ou plusieurs) table complémentaire d’événements (limitation de vitesse, pont, etc.). En fonction de la demande (limitation de vitesse, pont, etc.) le réseau est segmenté dynamiquement (d’où le nom du concept). Quand j'ai commencé à me renseigner sur ce domaine, j'ai immédiatement pensé aux potentialités des relations. En effet, dans un SIG classique les tables étant séparées, la seule relation entre la route et les événements sont leur positions géographiques. Or, les relations nous permettent de conserver à la fois une cohérence géographique et sémantique. Bon voila pour la théorie, maintenant j'ai bien conscience de la difficulté de compréhension d'un tel modèle pour un nouveau contributeur. Mais il a aussi un gain certain en terme de gestion des données, performance et stockage ! Arnaud 1 - https://ceprofs.civil.tamu.edu/folivera/txaggis/Spring2004/von_Holdt/CVH_project_report.htm On 13-01-25 07:29 AM, Francescu GAROBY wrote: Et actuellement, un tel comportement est considéré comme une erreur : soit pour cause de doublon soit, lorsque 2 ways se croisent, pour absence de node à l'intersection (d'où le tag 'layer'). Francescu Le 25 janvier 2013 11:55, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : Le 25 janvier 2013 11:22, Pieren pier...@gmail.com a écrit : 2013/1/25 François Lacombe francois.laco...@telecom-bretagne.eu: Urg, je m'étrangle à chaque fois que je lis ça. OSM est une base de données géospatiale. Tous les noeuds et ways sont déjà positionnés les uns par rapport aux autres. On ne doit (devrait) ajouter des tags ou des relations que lorsqu'il y a ambiguité. Il ne faut pas s'étrangler, ca n'en vaut pas la peine. Néanmoins, je vois mal comment peut-être exprimée une quelconque dépendance entre une route et un pont sur lequel elle passe dans la réalité sans relation entre les objets. Je crois que l'API d'OSM ne gère pas les altitudes et que donc même si la route est bien positionnée par rapport au pont, ce dernier peut se trouver 100m en dessous (il y a le tag ele=* mais ca ne compte pas). -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Oui tout à fait, on pourrait ainsi mieux gérer certains éventements ponctuels (ex, travaux en cours, immobilisation temporaire de la rue, etc.). Le désavantage de cette solution étant une modélisation très fortement basée sur les relations. Or celles-ci sont encore assez mal représentées dans les éditeurs. Mais rien n'empêche de les faire évoluer. Ex, dans JOSM, un point de couleur (ex, vert, rouge) pour identifier les noeuds d'un from - to. Ou même une représentation spécifique quand une partie, ou un objet complet est associe a une relation. Mais bon, la je m'écarte du sujet... Après, je n'ai pas une vision aussi complete que certains d'entre vous sur les concepts d'OSM. Il se peut donc que le modèle proposé, soit partiel ou contraire à certains préceptes d'OSM. Arnaud On 13-01-25 09:36 AM, Francescu GAROBY wrote: Le 25 janvier 2013 13:39, Arnaud arnaud@gmail.com mailto:arnaud@gmail.com a écrit : Bonjour à tous, Je vais essayer de compléter mon argumentation. Afin d'éviter de partir sur des problèmes de représentation liés a des éléments matériels (pont, tunnel, etc.), prenons l'exemple des limitation de vitesse. Chaque changement (ex, passage de 50 à 70) occasionne alors un découpage et la création d'un tronçon. L'idée de départ, étant d'utiliser un concept existant, celui de la segmentation dynamique, mais adapté à OSM. Je précise que ce concept de segmentation dynamique, ne sort pas de ma caboche mais existe déjà dans les bases de donnes routières [ex 1]. La segmentation dynamique permet d'avoir un réseau routier non segmenté auquel est associé une (ou plusieurs) table complémentaire d'événements (limitation de vitesse, pont, etc.). En fonction de la demande (limitation de vitesse, pont, etc.) le réseau est segmenté dynamiquement (d'où le nom du concept). Si je comprends bien, on pourrait même imaginer activer des évènements du point N1 au point N2 , sans avoir du coup besoin de redécouper le tronçon à ces 2 points ? Juste en ajoutant une ligne dans la table complémentaire d'évènements ? Et inversement lors de la désactivation de l'évènement ? Ceci limiterait en effet grandement le hachage que subissent certaines ways (entre le nombre de voies qui changent, les bouts empruntés par un itinéraire de bus, les bouts qui servent de frontières, ...). Ce qui permettrait de prendre en compte des évènements ponctuels, courts et à très brève échéance (voire déjà en cours), tels qu'un accident sur une autoroute, qui immobilise une voie. Francescu Quand j'ai commencé à me renseigner sur ce domaine, j'ai immédiatement pensé aux potentialités des relations. En effet, dans un SIG classique les tables étant séparées, la seule relation entre la route et les événements sont leur positions géographiques. Or, les relations nous permettent de conserver à la fois une cohérence géographique et sémantique. Bon voila pour la théorie, maintenant j'ai bien conscience de la difficulté de compréhension d'un tel modèle pour un nouveau contributeur. Mais il a aussi un gain certain en terme de gestion des données, performance et stockage ! Arnaud 1 - https://ceprofs.civil.tamu.edu/folivera/txaggis/Spring2004/von_Holdt/CVH_project_report.htm On 13-01-25 07:29 AM, Francescu GAROBY wrote: Et actuellement, un tel comportement est considéré comme une erreur : soit pour cause de doublon soit, lorsque 2 ways se croisent, pour absence de node à l'intersection (d'où le tag 'layer'). Francescu Le 25 janvier 2013 11:55, François Lacombe francois.laco...@telecom-bretagne.eu mailto:francois.laco...@telecom-bretagne.eu a écrit : Le 25 janvier 2013 11:22, Pieren pier...@gmail.com mailto:pier...@gmail.com a écrit : 2013/1/25 François Lacombe francois.laco...@telecom-bretagne.eu mailto:francois.laco...@telecom-bretagne.eu: Urg, je m'étrangle à chaque fois que je lis ça. OSM est une base de données géospatiale. Tous les noeuds et ways sont déjà positionnés les uns par rapport aux autres. On ne doit (devrait) ajouter des tags ou des relations que lorsqu'il y a ambiguité. Il ne faut pas s'étrangler, ca n'en vaut pas la peine. Néanmoins, je vois mal comment peut-être exprimée une quelconque dépendance entre une route et un pont sur lequel elle passe dans la réalité sans relation entre les objets. Je crois que l'API d'OSM ne gère pas les altitudes et que donc même si la route est bien positionnée par rapport au pont, ce dernier peut se trouver 100m en dessous (il y a le tag ele=* mais ca ne compte pas). -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Le 25 janvier 2013 14:06, Francescu GAROBY windu...@gmail.com a écrit : les bouts qui servent de frontières, ...). Non, pas coller ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Je commence à m'intéresser sérieusement à la segmentation dynamique dans le domaine de l'infra ferroviaire où l'on raisonne essentiellement en termes de PK (pour les événements ponctuels ex. Passage à niveau, appareil de voie)ou PK début/Pk fin pour les événements linéaires (ouvrages d'art, chantiers, électrification, ...). Je confirme mon intérêt pour cette démarche ! Idéalement, on devrait avoir une consistance topologique au niveau du tracé, la consistance sémantique serait assurée par des relations. Exemple pour un pont-rail Relation X Required Type=ouvrage_art Required Description=pont-rail Optional source=RFF Optional material=metal Optional length=xxx Optional height=xxx Optional name=blabla Required Members : a rôle « from » Required Members : b rôle « to » Required Members : c rôle « on » Optional members : d rôle « under » a=id du point début du pont (son PK debut) b=id du point fin du pont (son PK fin) c=id du tronçon de voie supportant la relation d=id du tronçon de la voie traversée (rivière, chemin, route, ...) C'est clair qu'il y a du boulot pour des applications pour transformer ces relations en objets découpés suivant les pointillés. Denis De : Arnaud [mailto:arnaud@gmail.com] Envoyé : vendredi 25 janvier 2013 13:40 À : talk-fr@openstreetmap.org Objet : Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique Bonjour à tous, Je vais essayer de compléter mon argumentation. Afin d'éviter de partir sur des problèmes de représentation liés a des éléments matériels (pont, tunnel, etc.), prenons l'exemple des limitation de vitesse. Chaque changement (ex, passage de 50 à 70) occasionne alors un découpage et la création d'un tronçon. L'idée de départ, étant d'utiliser un concept existant, celui de la segmentation dynamique, mais adapté à OSM. Je précise que ce concept de segmentation dynamique, ne sort pas de ma caboche mais existe déjà dans les bases de donnes routières [ex 1]. La segmentation dynamique permet d'avoir un réseau routier non segmenté auquel est associé une (ou plusieurs) table complémentaire d'événements (limitation de vitesse, pont, etc.). En fonction de la demande (limitation de vitesse, pont, etc.) le réseau est segmenté dynamiquement (d'où le nom du concept). Quand j'ai commencé à me renseigner sur ce domaine, j'ai immédiatement pensé aux potentialités des relations. En effet, dans un SIG classique les tables étant séparées, la seule relation entre la route et les événements sont leur positions géographiques. Or, les relations nous permettent de conserver à la fois une cohérence géographique et sémantique. Bon voila pour la théorie, maintenant j'ai bien conscience de la difficulté de compréhension d'un tel modèle pour un nouveau contributeur. Mais il a aussi un gain certain en terme de gestion des données, performance et stockage ! Arnaud 1 - https://ceprofs.civil.tamu.edu/folivera/txaggis/Spring2004/von_Holdt/CVH_project_report.htm On 13-01-25 07:29 AM, Francescu GAROBY wrote: Et actuellement, un tel comportement est considéré comme une erreur : soit pour cause de doublon soit, lorsque 2 ways se croisent, pour absence de node à l'intersection (d'où le tag 'layer'). Francescu Le 25 janvier 2013 11:55, François Lacombe francois.laco...@telecom-bretagne.eumailto:francois.laco...@telecom-bretagne.eu a écrit : Le 25 janvier 2013 11:22, Pieren pier...@gmail.commailto:pier...@gmail.com a écrit : 2013/1/25 François Lacombe francois.laco...@telecom-bretagne.eumailto:francois.laco...@telecom-bretagne.eu: Urg, je m'étrangle à chaque fois que je lis ça. OSM est une base de données géospatiale. Tous les noeuds et ways sont déjà positionnés les uns par rapport aux autres. On ne doit (devrait) ajouter des tags ou des relations que lorsqu'il y a ambiguité. Il ne faut pas s'étrangler, ca n'en vaut pas la peine. Néanmoins, je vois mal comment peut-être exprimée une quelconque dépendance entre une route et un pont sur lequel elle passe dans la réalité sans relation entre les objets. Je crois que l'API d'OSM ne gère pas les altitudes et que donc même si la route est bien positionnée par rapport au pont, ce dernier peut se trouver 100m en dessous (il y a le tag ele=* mais ca ne compte pas). -- François Lacombe francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.orgmailto:Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.orgmailto:Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Bonsoir, Le 25/01/2013 15:44, HELFER Denis a écrit : Je commence à m’intéresser sérieusement à la segmentation dynamique dans le domaine de l’infra ferroviaire où l’on raisonne essentiellement en termes de PK (pour les événements ponctuels ex. Passage à niveau, appareil de voie)ou PK début/Pk fin pour les événements linéaires (ouvrages d’art, chantiers, électrification, …). Je confirme mon intérêt pour cette démarche ! Idéalement, on devrait avoir une consistance topologique au niveau du tracé, la consistance sémantique serait assurée par des relations. Exemple pour un pont-rail Relation X Required Type=ouvrage_art Required Description=pont-rail Optional source=RFF Optional material=metal Optional length=xxx Optional height=xxx Optional name=blabla Required Members : a rôle « from » Required Members : b rôle « to » Required Members : c rôle « on » Optional members : d rôle « under » a=id du point début du pont (son PK debut) b=id du point fin du pont (son PK fin) c=id du tronçon de voie supportant la relation d=id du tronçon de la voie traversée (rivière, chemin, route, …) C’est clair qu’il y a du boulot pour des applications pour transformer ces relations en objets découpés suivant les pointillés. Dans ton exemple, la portion de voie ferrée de type pont-rail est définie par ses bornes, sous forme de nodes : a et b. Une autre manière, même sans node, consiste à définir le pont avec 2 abscisses curvilignes, à partir d'un way dont une extrémité serait le PK 0. Dans ce cas, on pourrait dire : le pont rail commence au PK 7.5 et se termine au PK 7.6, c'est à dire : le pont rail commence à 7.5km du début du way et mesure 100m. Ces 2 manières de dire la même chose souffrent du même bémol : il ne faut pas que la référence (le way) bouge, sinon l'objet pont-rail bouge aussi. Dans le premier modèle, il suffit de bouger par exemple le node a pour déplacer le début du pont-rail. Dans le second, si je raffine la courbure de la voie ferrée, j'augmente la longueur du way, et je déplace l'endroit situé à 7.5 km du début. Dans les deux cas on est face à, j'ai l'impression, une contradiction : la segmentation dynamique requiert une stabilité du référentiel géométrique pour que les objets définis relativement à cette géométrie soient stables, et à l'inverse, dans OSM, chacun est libre de modifier tous les objets, rien n'est figé/vérouillé. Du coup est-ce compatible, au stade des contributions ? C'est différent au stade de la réutilisation, où chacun est libre de définir des objets (des 'évènements') relativement au graphe OSM, dès lors que celui-ci a été extrait une fois et figé pour servir de référence. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Le 25 janvier 2013 11:51, Francescu GAROBY windu...@gmail.com a écrit : Comme stop_area, où des nodes sont utilisés pour indiquer le stop_position (pour ne citer qu'un exemple). Non c'est différent car les noeuds des stop-position sont ceux qui portent le tag du stop-position. On ne tague pas la relation ou le chemin référençant le noeud en mettant un tag stop_position=id. Les ids sont destinés à servir de références internes à la base pas dans des valeurs de tags qui seront exportés : les ids d'OSM n'ont aucune signification par eux-mêmes et ne sont jamais stables (ce qui est stable ce sont les ref:*=*). Et non je n'ai rien confondu entre tag (couple d'un nom et d'une valeur formant un attribut/une propriété de n'importe quel objet) et rôle (les rôles permettent de créer des listes de membres multiples ayant des usages différents, le même rôle servant à un ou plusieurs membres en principe, sauf que souvent on a un rôle par défaut qui est équivalent à l'absence de rôle indiqué pour un membre). Relis bien ce que j'ai écris tu comprendras, je penses que c'est bien toi qui interprète mal ou veut interpréter ma phrase comme si j'avais fait la confusion des termes. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Le 25 janvier 2013 21:36, Philippe Verdy verd...@wanadoo.fr a écrit : Le 25 janvier 2013 11:51, Francescu GAROBY windu...@gmail.com a écrit : Comme stop_area, où des nodes sont utilisés pour indiquer le stop_position (pour ne citer qu'un exemple). Non c'est différent car les noeuds des stop-position sont ceux qui portent le tag du stop-position. On ne tague pas la relation ou le chemin référençant le noeud en mettant un tag stop_position=id. Les ids sont destinés à servir de références internes à la base pas dans des valeurs de tags qui seront exportés : les ids d'OSM n'ont aucune signification par eux-mêmes et ne sont jamais stables (ce qui est stable ce sont les ref:*=*). Mais quand Arnaud dit from : N2, to : N3, il faut (je suppose) comprendre que ces 2 rôles pointeront vers les nodes dont l'id est respectivement N2 et N3. Pas sur la valeur de ces id proprement dits (donc comme dans mon exemple de stop_area). Et non je n'ai rien confondu entre tag (couple d'un nom et d'une valeur formant un attribut/une propriété de n'importe quel objet) et rôle (les rôles permettent de créer des listes de membres multiples ayant des usages différents, le même rôle servant à un ou plusieurs membres en principe, sauf que souvent on a un rôle par défaut qui est équivalent à l'absence de rôle indiqué pour un membre). Relis bien ce que j'ai écris tu comprendras, je penses que c'est bien toi qui interprète mal ou veut interpréter ma phrase comme si j'avais fait la confusion des termes. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Ce ne sera possible qu'à condition de donner un attribut stable aux noeuds (un nom, une ref, sous la forme d'un tag explicite, mais pas en se contentant de leur ID. Si on veut donc désigner une paire de noeud on pourrait indiquer que sur une route les sections entre les noeuds A et B, ou C et D sont un pont. L'ennui c'est comment s'assurer que les noms utilisés dans le chemin resteront uniques : à la première fusion de deux chemins ce n'est plus garanti. On pourrait utiliser la numérotation du bornage kilométrique (ou hectométrique) sur les routes longues, mais on n'en trouve pas dans les zones urbaines avec des carrefours. En revacnhe en ville on peut mettre les numéros des adresses. Ensuite alors on peut mettre un maxspeed=50; maxspeed:exception=30 pour la limitation temporaire des sections indiquées par exceptions:maxspeed=A B;C D (les espaces sont pour les intervalles, les point-virgules séparent les entrées ponctuelles ou intervalles). L'ennui c'est que le moteur de navigation va devoir chercher les références indiques dans des listes assez longues... Finalement ce sont les relations qui évitent les complications et ambiguités, et problèmes d'homonymies). Les relations n'offrent pas plus de complication, mais elles sont stables et on peut facilement retrouver dans une relation un intervalle de membres entre deux bornes, pour faire des sélections multiples servant à construire d'autres relations. Le 25 janvier 2013 14:06, Francescu GAROBY windu...@gmail.com a écrit : Le 25 janvier 2013 13:39, Arnaud arnaud@gmail.com a écrit : Bonjour à tous, Je vais essayer de compléter mon argumentation. Afin d’éviter de partir sur des problèmes de représentation liés a des éléments matériels (pont, tunnel, etc.), prenons l'exemple des limitation de vitesse. Chaque changement (ex, passage de 50 à 70) occasionne alors un découpage et la création d'un tronçon. L’idée de départ, étant d'utiliser un concept existant, celui de la segmentation dynamique, mais adapté à OSM. Je précise que ce concept de segmentation dynamique, ne sort pas de ma caboche mais existe déjà dans les bases de donnes routières [ex 1]. La segmentation dynamique permet d'avoir un réseau routier non segmenté auquel est associé une (ou plusieurs) table complémentaire d’événements (limitation de vitesse, pont, etc.). En fonction de la demande (limitation de vitesse, pont, etc.) le réseau est segmenté dynamiquement (d’où le nom du concept). Si je comprends bien, on pourrait même imaginer activer des évènements du point N1 au point N2 , sans avoir du coup besoin de redécouper le tronçon à ces 2 points ? Juste en ajoutant une ligne dans la table complémentaire d'évènements ? Et inversement lors de la désactivation de l'évènement ? Ceci limiterait en effet grandement le hachage que subissent certaines ways (entre le nombre de voies qui changent, les bouts empruntés par un itinéraire de bus, les bouts qui servent de frontières, ...). Ce qui permettrait de prendre en compte des évènements ponctuels, courts et à très brève échéance (voire déjà en cours), tels qu'un accident sur une autoroute, qui immobilise une voie. Francescu Quand j'ai commencé à me renseigner sur ce domaine, j'ai immédiatement pensé aux potentialités des relations. En effet, dans un SIG classique les tables étant séparées, la seule relation entre la route et les événements sont leur positions géographiques. Or, les relations nous permettent de conserver à la fois une cohérence géographique et sémantique. Bon voila pour la théorie, maintenant j'ai bien conscience de la difficulté de compréhension d'un tel modèle pour un nouveau contributeur. Mais il a aussi un gain certain en terme de gestion des données, performance et stockage ! Arnaud 1 - https://ceprofs.civil.tamu.edu/folivera/txaggis/Spring2004/von_Holdt/CVH_project_report.htm On 13-01-25 07:29 AM, Francescu GAROBY wrote: Et actuellement, un tel comportement est considéré comme une erreur : soit pour cause de doublon soit, lorsque 2 ways se croisent, pour absence de node à l'intersection (d'où le tag 'layer'). Francescu Le 25 janvier 2013 11:55, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : Le 25 janvier 2013 11:22, Pieren pier...@gmail.com a écrit : 2013/1/25 François Lacombe francois.laco...@telecom-bretagne.eu: Urg, je m'étrangle à chaque fois que je lis ça. OSM est une base de données géospatiale. Tous les noeuds et ways sont déjà positionnés les uns par rapport aux autres. On ne doit (devrait) ajouter des tags ou des relations que lorsqu'il y a ambiguité. Il ne faut pas s'étrangler, ca n'en vaut pas la peine. Néanmoins, je vois mal comment peut-être exprimée une quelconque dépendance entre une route et un pont sur lequel elle passe dans la réalité sans relation entre les objets. Je crois que l'API d'OSM ne gère pas les altitudes et que donc même si la route est bien positionnée par rapport au pont, ce dernier peut se
[OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Bonjour à tous, Petite interrogation de fin de semaine sur la modélisation des routes dans OSM. Aujourd'hui, quand nous souhaitons attacher un nouvel attribut permettant de spécifier des éléments liés aux reseau routier, il est nécessaire de découper le segment correspondant. Exemple, si je souhaite ajouter un pont ou un tunnel à une route, je dois segmenter ma route de la maniere suivante (N est un noeud, les tirets la route, le signe / pour signifier un segment, N2 et N3 étant le tunnel ) : N1 - / N2 - / N3 N4 Cela entraîne une segmentation importante, une maintenance des attributs difficile ainsi que la duplication de nombreuses données. D’où mon interrogation, existe-t-il (peut être cela se fait déjà) d'autres représentations ? Peut-être qu'il pourrait être intéressant d'utiliser le potentiel des relations? Je m'explique, en gardant le modèle précédent : N1 - N2 - N3 N4 Relation tunnel : yes from : N2 to : N3 Les avantages sont une cohérence des attributs génériques à la route (nom, type, etc.), un objet géographique unique (plus grande rapidité de traitement?), une maintenance attributaire et géographique facilitée. Les inconvénients sont, je pense, un modèle peu compréhensible pour les débutants ainsi que logiquement une augmentation des relations. Néanmoins, avez-vous déjà vu des propositions allant en ce sens (ou autres)? merci Arnaud ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Le 24/01/2013 21:20, Arnaud a écrit : Petite interrogation de fin de semaine sur la modélisation des routes dans OSM. Aujourd'hui, quand nous souhaitons attacher un nouvel attribut permettant de spécifier des éléments liés aux reseau routier, il est nécessaire de découper le segment correspondant. Exemple, si je souhaite ajouter un pont ou un tunnel à une route, je dois segmenter ma route de la maniere suivante (N est un noeud, les tirets la route, le signe / pour signifier un segment, N2 et N3 étant le tunnel ) : N1 - / N2 - / N3 N4 Cela entraîne une segmentation importante, une maintenance des attributs difficile ainsi que la duplication de nombreuses données. D’où mon interrogation, existe-t-il (peut être cela se fait déjà) d'autres représentations ? Il existe au moins une autre représentation, utilisée par les fournisseurs de BD commerciales (TomTom, Nokia), et qui de ce fait se pose en quasi convention jusqu'à présent. C'est une représentation qui va exactement à l'inverse de ta proposition : en effet, dans ces bases, non seulement tout changement d'une valeur d'attribut occasionne une découpe (comme dans OSM, cf ton exemple de tunnel), mais au delà, toute intersection occasionne aussi une découpe. Celà donne un graphe assez directement utilisable pour être parcouru par des algorithmes de calcul de chemin. En contrepartie, il est lourd de beaucoup d'enregistrement, bien plus que de ways OSM sur le même réseau routier. Mais il n'y a pas forcément de contradiction entre ce modèle et celui que tu décris ci-dessous : Peut-être qu'il pourrait être intéressant d'utiliser le potentiel des relations? Je m'explique, en gardant le modèle précédent : N1 - N2 - N3 N4 Relation tunnel : yes from : N2 to : N3 Les avantages sont une cohérence des attributs génériques à la route (nom, type, etc.), un objet géographique unique (plus grande rapidité de traitement?), une maintenance attributaire et géographique facilitée. Les inconvénients sont, je pense, un modèle peu compréhensible pour les débutants ainsi que logiquement une augmentation des relations. Néanmoins, avez-vous déjà vu des propositions allant en ce sens (ou autres)? En effet, le modèle dont je parle chez les producteurs commerciaux est le modèle de diffusion de leurs données. Je ne connais rien de leur modèle interne de gestion des mêmes données. Côté OSM, rien n'empêcherait d'avoir, côté contribution, un modèle qui tend vers le tout relation : 0 redondance, maintenance facilité, (mais outils à revoir !) et côté diffusion, un intermédiaire tel aujourd'hui Geofabrik avec ses fichiers Shape, qui façonne la donnée pour faire : - du tout segmenté pour ceux demandeurs de données de type graphe de calcul, - du tout agrégé, ou du moins agrégé comme l'est la donnée en base à la source, ce qui est un modèle mieux vécu par, par exemple, un moteur de rendu comme Mapnik. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Le jeudi 24 janvier 2013 21:20:26, Arnaud a écrit : Bonjour à tous, Salut, Peut-être qu'il pourrait être intéressant d'utiliser le potentiel des relations? (...) Tout à fait, et tu n'es pas le seul à y avoir pensé ;-) Néanmoins, avez-vous déjà vu des propositions allant en ce sens (ou autres)? Oui : la mienne : http://wiki.openstreetmap.org/wiki/Relation:multilinestring Mais aussi une plus ancienne et plus utilisée, mieux supportée, mais plus spécifique et complexe : http://wiki.openstreetmap.org/wiki/Relation:route Toutes ces modélisations se heurtent pour l'instant aux difficultés suivantes : - (très) mal supportées par les rendus bien connus - mal intégrées aux logiciels d'édition (JOSM, qui s'en sort le mieux, t'oblige à passer par le menu assez abscons et dur à appréhender des relations) -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Bonsoir, Soulever des problèmes d'efficacité d'enregistrement est peut-être la meilleure des choses à faire pour la pérennité de la base, ça me branche. Sans forcément avoir des choses très innovantes à proposer, il me vient à l'esprit 2 points: - Tout est réseau, se restreindre à l'infrastructure routière risque de ne pas être profitable à une solution durable, tant en terme de taille que de complexité du problème. J'ai bien conscience que c'est la visée première d'OSM et que c'est une objet qui se prête volontiers à une cartographie collective, aborder le soucis sous une forme plus générale mérite qu'on s'y arrête aussi. - De prime abord, je dirais que la taille et le contenu de la base conditionne aussi ce qu'on peut en faire. Avoir une base compacte car très efficace dans son modèle de représentation peut plomber son utilisation vu le temps de calcul nécessaire rien pour apprêter les données à toute exploitation. Tout de suite, avoir des relations avec des bornes qui ne correspondent plus à celles des objets supports rend la sélectivité beaucoup plus délicate... C'est une réflexion à avoir, peut-être qu'à un moment il ne sera plus possible de favoriser tous les usages sur un pied d'égalité. Aujourd'hui (demain...) qu'est-ce qui coute le plus cher, le stockage ou le temps machine? Bonne soirée. Le 24 janvier 2013 21:55, sly (sylvain letuffe) li...@letuffe.org a écrit : Le jeudi 24 janvier 2013 21:20:26, Arnaud a écrit : Bonjour à tous, Salut, Peut-être qu'il pourrait être intéressant d'utiliser le potentiel des relations? (...) Tout à fait, et tu n'es pas le seul à y avoir pensé ;-) Néanmoins, avez-vous déjà vu des propositions allant en ce sens (ou autres)? Oui : la mienne : http://wiki.openstreetmap.org/wiki/Relation:multilinestring Mais aussi une plus ancienne et plus utilisée, mieux supportée, mais plus spécifique et complexe : http://wiki.openstreetmap.org/wiki/Relation:route Toutes ces modélisations se heurtent pour l'instant aux difficultés suivantes : - (très) mal supportées par les rendus bien connus - mal intégrées aux logiciels d'édition (JOSM, qui s'en sort le mieux, t'oblige à passer par le menu assez abscons et dur à appréhender des relations) -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Le jeudi 24 janvier 2013 23:58:25, François Lacombe a écrit : Bonsoir, Bonne nuit, Soulever des problèmes d'efficacité d'enregistrement est peut-être la meilleure des choses à faire pour la pérennité de la base, ça me branche. Par efficacité d'enregistrement tu sous-entends l'insertion dans la base de nouvelles données ? Donc l'édition avec les éditeurs openstreetmap ? Et si oui, par efficacité tu parles de la qualité de l'IHM pour que l'humain soit efficace ou de la qualité du protocole pour que le transfert soit efficace ? (ou les deux ? gourmand va !) - Tout est réseau, se restreindre à l'infrastructure routière risque de ne pas être profitable à une solution durable, tant en terme de taille que de complexité du problème. J'ai bien conscience que c'est la visée première d'OSM ça, pas de problème, ça fait bien longtemps qu'openstreetmap n'a de street que le nom. Et aucunes des modélisations de base (noeud/way/relation) ne se restreint au routier. Le routage sur chemin de rando, voie fluviale ou en prenant le ferry existent déjà, et si une solution doit s'avancer, il est à parier que le modèle devra pouvoir être suffisament générique. Voir les relations de type route qui modélisent : road / bicycle / foot / hiking / bus / trolleybus / ferry / detour / train / tram / mtb (mountainbike) / horse / ski / snowmobile Ou plus encore, l'autre que j'indiquait qui connecte des bout pour former les frontières entre pays et tout ce qu'inventerons les contributeurs ! peut plomber son utilisation vu le temps de calcul nécessaire rien pour apprêter les données à toute exploitation. De manière constatée, l'exploitation est toujours précédée d'un pré-traitement adapté à l'exploitation visée. L'exploitation n'est donc pas tant le sujet ici il me semble, mais plus de la maintenance, par les contributeurs et des outils qu'ils vont utiliser pour se faire qui sont pour l'instant peu adaptés à une solution de factorisation des tags. Aujourd'hui (demain...) qu'est-ce qui coute le plus cher, le stockage ou le temps machine? Les humains. -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Le 25 janvier 2013 00:13, sly (sylvain letuffe) li...@letuffe.org a écrit : Le jeudi 24 janvier 2013 23:58:25, François Lacombe a écrit : Bonsoir, Bonne nuit, Bonjour :) Par efficacité d'enregistrement tu sous-entends l'insertion dans la base de nouvelles données ? Donc l'édition avec les éditeurs openstreetmap ? Et si oui, par efficacité tu parles de la qualité de l'IHM pour que l'humain soit efficace ou de la qualité du protocole pour que le transfert soit efficace ? (ou les deux ? gourmand va !) Par efficacité d'enregistrement, j'entends la place occupée sur le disque pour représenter x km de route. Il s'agit avant tout de la structure de la base de données et de la structure du modèle au dessus. De là découle nécessairement ce qu'il faut faire pour l'écrire (par les éditeurs, IHM et API) mais aussi pour la lire. - Tout est réseau ça, pas de problème, ça fait bien longtemps qu'openstreetmap n'a de street que le nom. Et aucunes des modélisations de base (noeud/way/relation) ne se restreint au routier. Le routage sur chemin de rando, voie fluviale ou en prenant le ferry existent déjà, et si une solution doit s'avancer, il est à parier que le modèle devra pouvoir être suffisament générique. Voir les relations de type route qui modélisent : road / bicycle / foot / hiking / bus / trolleybus / ferry / detour / train / tram / mtb (mountainbike) / horse / ski / snowmobile Et aussi power, water, wind et j'en passe... bientôt :) Je parlais de la discussion actuelle où le problème est soulevé sur un cas routier. Il y en a des similaires dans tous les domaines. De manière constatée, l'exploitation est toujours précédée d'un pré-traitement adapté à l'exploitation visée. C'est certain. Néanmoins aujourd'hui pour trouver tous les tunnels, on peut encore faire de l'xQuery sur planet.osm (ou une portion évidemment, très gros avantage selon moi). Si le modèle évolue vers quelque chose de plus compact dans la base, on risque de devoir déplier la carte avant de pouvoir la lire, aussi facilement qu'aujourd'hui du moins. L'exploitation n'est donc pas tant le sujet ici il me semble, mais plus de la maintenance, par les contributeurs et des outils qu'ils vont utiliser pour se faire qui sont pour l'instant peu adaptés à une solution de factorisation des tags. C'est aussi vrai et je suis d'accord avec ça. Aujourd'hui (demain...) qu'est-ce qui coute le plus cher, le stockage ou le temps machine? Les humains. Le passage du récent million ne met pas forcément le doigt sur le nombre de contributeur :) -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique
Le 24 janvier 2013 21:20, Arnaud arnaud@gmail.com a écrit : Peut-être qu'il pourrait être intéressant d'utiliser le potentiel des relations? Je m'explique, en gardant le modèle précédent : N1 - N2 - N3 N4 Relation tunnel : yes from : N2 to : N3 Les avantages sont une cohérence des attributs génériques à la route (nom, type, etc.), un objet géographique unique (plus grande rapidité de traitement?), une maintenance attributaire et géographique facilitée. Les inconvénients sont, je pense, un modèle peu compréhensible pour les débutants ainsi que logiquement une augmentation des relations. L'ennui c'est comment représenter et *stabiliser* les deux tags from=N2 et to=N3 : comment désigner les noeuds si ce ne peut pas être un rang dans le chemin ? Il faudrait alors nommer les noeuds ou utiliser leurs IDs. Et il n'y aura aucune vérification de cela. La segmentation n'est pas réellement un problème : on a des relations pour rassembler les fragments de chemin ensembles et de façon stable. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
