Pour ce qui est de la licence, n'étant pas propriétaire, je ne peux rien
faire d'autre que de demandé au CETE, si ils sont prêt à faire évoluer
la licence, afin que la communauté puisse faire évoluer ce document.
Je ferais passer cette requête en début de semaine.
René-Luc
Le 13/12/2009 15:12, Steven Le Roux a écrit :
2009/12/13 René-Luc D'Hont <[email protected] <mailto:[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]
<mailto:[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] <mailto:[email protected]>
> http://lists.openstreetmap.org/listinfo/talk-fr
>
_______________________________________________
Talk-fr mailing list
[email protected] <mailto:[email protected]>
http://lists.openstreetmap.org/listinfo/talk-fr
--
Steven Le Roux
Jabber-ID : [email protected] <mailto:[email protected]>
0x39494CCB <[email protected] <mailto:[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
_______________________________________________
Talk-fr mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-fr
