[OSM-talk-fr] Le CETE s'intéresse à OSM

[René-Luc D'Hont]

Bonjour,

Merci pour ces remarques. Je voulais préciser les points suivants :
* Ce document a été réalisé par notre société à l'occasion d'une commande
du CETE. Nous l'avons donc rédigé dans un temps et un cadre limité (nombre
de pages, etc.) selon nos ressources et d'après notre connaissance et
notre interprétation, forcément subjective, d'OSM.
* L'objectif de ce document n'était pas de faire une présentation
exhaustive ni sans parti pris sur OSM. La commande était de donner des
clés pour comprendre OSM, et de présenter quelques outils comme des
exemples du potentiel d'OSM.
* Les remarques faites ne sont pas des vérités dans le marbre, mais
dépendent bien sûr de l'interprétation du rédacteur.
* Nous n'avons pas souhaité le faire relire par la communauté, car nous ne
souhaitions pas "profiter" du travail des contributeurs bénévoles pour
réaliser une commande privée.

Il est donc bien normal qu'il soulève les remarques (pertinentes) de la
communauté.


René-Luc D'Hont
3Liz SARL


Le 13/12/2009 03:03, Pieren a écrit :
> 2009/12/11 J.-Lys<jacques at famille-lys.com>:
>
> Oui, c'est vrai, c'est un bon rapport assez bien balancé. Mais
> j'aimerais ajouter quelques remarques sur certains points:
>
> 2.1 "Les données géographiques présentes dans le projet OpenStreetMap
> sont disponibles librement, sans restriction".
> Attention, il y a quand même le share-alike et l'attribution qui sont
> rappelés au 2.3. "sans restriction" = "domaine public".
>
> 3.1 "il est primordial de se rendre sur place". Disons qu'il est
> "conseillé" de se rendre sur place pour avoir l'information la plus à
> jour possible mais ça n'est pas indispensable.
>
> 3.1 Walking Papers peut aussi être exploité sur JOSM.
>
> 3.2 "Un effort particulier a été entrepris par la fondation ../.. pour
> faciliter la traduction du site". Euh, j'e cherche encore ce que la
> fondation a fait en matière de traductions...
>
> 3.3 "fédérer les contributeurs autour d'une mission de cartographie
> ciblée". Les wikiprojects servent de support aux contributeurs ayant
> un centre d'intérêt commun autre que l'habituel "cartographier ma
> ville". Les "lieux" ne sont pas des wikiprojects mais de nombreuses
> villes possèdent leur page dédiée sur le wiki.
>
> 3.5 Toute la section n'est qu'une traduction de la procédure expliquée
> dans le wiki et suggère que tous les tags s'adoptent de cette façon
> alors que ça n'est pas vrai. Une partie non négligeable des tags sont
> adoptés par usage et sans "vote", le wiki ne servant que dans la
> recherche de la meilleurs définition (mais ça n'est pas le seul moyen
> comme par exemple le schéma des tags address créé suite à une réunion
> de contributeurs allemands à Karlsruhe).
>
> 4.1 Dommage que osmarender soit oublié. De plus, il est basé sur du
> crowd computing. Et aussi la carte cyclemap qui est pourtant
> accessible depuis le site principal et qui a même reçu plusieurs
> récompenses internationales.
>
> 4.1 Il semble qu'Osmosis ne soit plus le programme qui serve à faire
> les planets mais comme le wiki n'est pas à jour.
>
> 4.1 C'est vrai que Geofabrik distribue des extraits du planet. Mais
> comme Cloudmade et d'autres, donc pourquoi citer celui-là.
>
> 5.2 Dommage que le terme "cartopartie" soit repris ici alors que la
> communauté s'est fortement exprimée en faveur du terme "mapping party"
> (http://doodle.com/cye4t5wve9h3v6ky)
>
> 6.1.1 "cette légèreté et cette simplicité sont battues en brèche (par
> les relations)". Je dirais le contraire, les relations permettent de
> résoudre de nombreux problèmes de manière "légère et simple".
>
> 6.1.2 Attention, un chemin fermé n'est pas forcément un polygone.
> C'est par sémantique (choix des attributs) qu'on peut faire la
> distinction entre une surface (area=yes) ou un périmètre
> (junction=roundabout). C'est peut-être quelque chose qui changera avec
> l'API 0.7
>
> 6.1.2 Chaque primitive (noeud, chemin ou relation) peut porter ses
> propres tags. Seuls les noeuds possèdent une information de
> positionnement.
>
> 6.1.3 Enfin, dans cette section ou ailleurs, rien n'est dit sur les
> outils de statistique comme tagwatch ou osmdoc qui sont pourtant aussi
> importants que la documentation (puisqu'ils déterminent la popularité
> d'un tag, ce qui est plus déterminant qu'un vote sur le wiki).
>
> 6.1.4 La 3e dimension (altitude) est absente de l'API. Chaque élément
> porte le nom du contributeur et la date de modification. Un historique
> est disponible depuis l'API ce qui permet d'éventuellement revenir en
> arrière (revert). Rien n'est dit sur les changeset.
>
> 6.2 Il n'y a pas d'accord de la communauté sur les noms des voies de
> circulation hors agglomération. En fait, si certains mettent "Route de
> A vers B", c'est parce qu'ils copient le cadastre mais il n'y a jamais
> eu à ma connaissance de consensus sur le sujet.
>
> 6.2 "décalage spatial dû à l'exploitation du cadastre". Oups, je me
> sens visé là. Pour être honnête, le décalage a disparu du plugin
> depuis novembre (sur les deux projections Lambert) mais il doit encore
> être présent sur toutes les données créées à partir du cadastre entre
> janvier 2009 et cette date.
>
> 6.2 Il n'y a pas de "principe de la source" sauf pour le cadastre
> parce que ce'st une obligation. Pour le reste, certains "souhaitent"
> indiquer que leur source est le GPS ou Yahoo mais ça reste facultatif
> et n'est nul part présenté comme une obligation (même si certains en
> rêvent).
>
> 6.2 "voie urbaine « highway=residential », rue résidentielle «
> highway=living_street »". Non, residential est une voie en zone
> résidentielle. Mais il y a aussi beaucoup de unclassified en voies
> urbaines. Et "living_street" ne s'applique qu'aux zones de rencontres,
> qui n'ont un statut légal en France que depuis cette année.
>
> 6.4.2 Le fait d'ajouter "cycleway" à la voie de circulation principale
> n'a rien à voir au fait que la piste cyclable est contigüe ou
> confondue avec elle. Si elle l'est, on utilise le tag "cycleway=lane".
> La manière décrite se fait lorsqu'on ne dispose pas du tracé de la
> piste cyclable (parce que le relevé s'est fait en voiture par
> exemple). Mais la recommandation est de tracer un chemin séparé et
> parallèle à la voie principale autant que possible.
>
> 6.4.2. Une autre recommandation est d'éviter d'utiliser "true/false"
> mais plutôt "yes/no".
>
> 7.3 L'exemple du rond-point est intéressant mais la conclusion d'assez
> mauvaise foi. Un cercle fermé décrit un rond-point, c'est l'aspect
> physique. Si quelqu'un veut y faire figurer un parcours ou itinéraire,
> il peut très bien y inclure le rond-point dans son ensemble. Au le
> logiciel de routage d'en tenir compte. S'il ne veut en afficher qu'une
> partie sur une carte (la section la plus courte entre l'entrée et la
> sortie), c'est un problème de rendu. Segmenter un rond-point pour un
> itinéraire, c'est comme "tagguer pour le rendu".
>
>
> Ce qui manque:
> - l'impasse totale sur les nombreuses applications et éditeurs
> embarqués (PDA, téléphones)
> - la volonté de conserver un minimum de cohérence internationale (les
> tags sont en anglais)
> - aucune mention n'est faite de l'authentification des utilisateurs et
> l'historique des éléments.
> - aucune mention sur les limites administratives communales (ou alors
> en apparté au chap. 3.4), le wikiproject le plus important (symbole de
> l'absence de libération des données publiques) et aux nombreuses
> applications qui en suivront (géolocalisation, stats).
> - une plus grande place pour la prochaine (possible) licence Odbl qui
> aura un impact sur le statut des travaux composés ou dérivés.
>
>
> Voila, en espérant que toutes ces remarques seront utiles à une
> prochaine version du document,
>
> amicalement
> Pieren
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>