<br><br><div class="gmail_quote">2009/12/13 René-Luc D'Hont <span dir="ltr"><<a href="mailto:rldhont@gmail.com">rldhont@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Bonjour,<br>
<br>
Merci pour ces remarques. Je voulais préciser les points suivants :<br>
* Ce document a été réalisé par notre société à l'occasion d'une commande<br>
du CETE. Nous l'avons donc rédigé dans un temps et un cadre limité (nombre<br>
de pages, etc.) selon nos ressources et d'après notre connaissance et<br>
notre interprétation, forcément subjective, d'OSM.<br>
* L'objectif de ce document n'était pas de faire une présentation<br>
exhaustive ni sans parti pris sur OSM. La commande était de donner des<br>
clés pour comprendre OSM, et de présenter quelques outils comme des<br>
exemples du potentiel d'OSM.<br>
* Les remarques faites ne sont pas des vérités dans le marbre, mais<br>
dépendent bien sûr de l'interprétation du rédacteur.<br>
* Nous n'avons pas souhaité le faire relire par la communauté, car nous ne<br>
souhaitions pas "profiter" du travail des contributeurs bénévoles pour<br>
réaliser une commande privée.<br>
<br>
Il est donc bien normal qu'il soulève les remarques (pertinentes) de la<br>
communauté.<br>
<br></blockquote><div><br>Je suis d'accord avec toi, Pieren est un peu exigeant, et ce document n'avait pas vocation à être un libre blanc.<br><br>Par contre, selon la licence que ta société lui accordera, il pourrait être enrichi/complété afin d'être présenté comme tel.<br>

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

2FF7 226B 552E 4709 03F0  6281 72D7 A010 3949 4CCB<br>