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
        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  <mailto:Talk-fr@openstreetmap.org>
    http://lists.openstreetmap.org/listinfo/talk-fr


    _______________________________________________
    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

Répondre à