2009/12/13 René-Luc D'Hont <[email protected]> > 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é. > > Je suis d'accord avec toi, Pieren est un peu exigeant, et ce document n'avait pas vocation à être un libre blanc.
Par contre, selon la licence que ta société lui accordera, il pourrait être enrichi/complété afin d'être présenté comme tel. > > René-Luc D'Hont > 3Liz SARL > > > Le 13/12/2009 03:03, Pieren a écrit : > > 2009/12/11 J.-Lys<[email protected]>: > > > > 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 > > [email protected] > > http://lists.openstreetmap.org/listinfo/talk-fr > > > > > _______________________________________________ > Talk-fr mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/talk-fr > -- Steven Le Roux Jabber-ID : [email protected] 0x39494CCB <[email protected]> 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
_______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
