C'est une modélisation très intéressante, mais malheureusement sûrement complexe à appréhender par une majorité de contributeurs.<div><br><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>Serait-il possible d'avoir des extensions à JOSM qui s'occuperaient de maintenir la cohérence de tel ou tel modèle ?</div><div><br></div><div>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...</div>
<div>Imaginez une extension "landuse" qui dès qu'on coupe en deux un polygone créerait un multipolygone et y reporterai les tags...</div><div>Imaginez une extension "coastline" qui empêcherai de casser par mégarde la pointe bretonne ;)</div>
<div><br></div><div>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.</div>
<div><br></div><div>Ca vaut peut être un autre sujet de discussion...</div><div><br></div><div><br><div class="gmail_quote">Le 25 janvier 2013 13:39, Arnaud <span dir="ltr"><<a href="mailto:arnaud.sig@gmail.com" target="_blank">arnaud.sig@gmail.com</a>></span> a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Bonjour à tous,<br>
<br>
Je vais essayer de compléter mon argumentation.<br>
<br>
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.<br>
Chaque changement (ex, passage de 50 à 70) occasionne alors un
découpage et la création d'un tronçon.<br>
<br>
L’idée de départ, étant d'utiliser un concept existant, celui de la
segmentation dynamique, mais adapté à OSM.<br>
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].<br>
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.).<br>
En fonction de la demande (limitation de vitesse, pont, etc.) le
réseau est segmenté dynamiquement (d’où le nom du concept).<br>
Quand j'ai commencé à me renseigner sur ce domaine, j'ai
immédiatement pensé aux potentialités des relations.<br>
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.<br>
Or, les relations nous permettent de conserver à la fois une
cohérence géographique et sémantique.<br>
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.<br>
Mais il a aussi un gain certain en terme de gestion des données,
performance et stockage ! <br>
<br>
<br>
Arnaud<br>
<br>
1 -
<a href="https://ceprofs.civil.tamu.edu/folivera/txaggis/Spring2004/von_Holdt/CVH_project_report.htm" target="_blank">https://ceprofs.civil.tamu.edu/folivera/txaggis/Spring2004/von_Holdt/CVH_project_report.htm</a><div><div>
<br>
<br>
<br>
<div>On 13-01-25 07:29 AM, Francescu GAROBY
wrote:<br>
</div>
<blockquote type="cite">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').<br>
<br>
Francescu<br>
<br>
<div class="gmail_quote">Le 25 janvier 2013 11:55, François
Lacombe <span dir="ltr"><<a href="mailto:francois.lacombe@telecom-bretagne.eu" target="_blank">francois.lacombe@telecom-bretagne.eu</a>></span>
a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
<div class="gmail_quote">Le 25 janvier 2013 11:22, Pieren <span dir="ltr"><<a href="mailto:pieren3@gmail.com" target="_blank">pieren3@gmail.com</a>></span>
a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2013/1/25 François Lacombe <<a href="mailto:francois.lacombe@telecom-bretagne.eu" target="_blank">francois.lacombe@telecom-bretagne.eu</a>>:
<div><br>
Urg, je m'étrangle à chaque fois que je lis ça. OSM est
une base de<br>
données géospatiale. Tous les noeuds et ways sont déjà
positionnés les<br>
uns par rapport aux autres. On ne doit (devrait) ajouter
des tags ou<br>
des relations que lorsqu'il y a ambiguité.<br>
</div>
</blockquote>
<div>Il ne faut pas s'étrangler, ca n'en vaut pas la peine.<br>
<br>
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.<br>
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).<br>
<br>
</div>
</div>
<div>
<div>-- <br>
<b>François Lacombe</b><br>
<br>
francois dot lacombe At telecom-bretagne dot eu<br>
<a href="http://www.infos-reseaux.com" target="_blank">http://www.infos-reseaux.com</a><br>
</div>
</div>
<br>
_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">http://lists.openstreetmap.org/listinfo/talk-fr</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Cordialement,<br>
Francescu GAROBY<br>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Talk-fr mailing list
<a href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a>
<a href="http://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">http://lists.openstreetmap.org/listinfo/talk-fr</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">http://lists.openstreetmap.org/listinfo/talk-fr</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Christian Quest - OpenStreetMap France - <a href="http://openstreetmap.fr/u/christian-quest" target="_blank">http://openstreetmap.fr/u/cquest</a>
</div></div>