Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia

[David Crochet]

Bonjour

Le 01/11/2013 22:46, Ista Pouss a écrit :
Le 1 novembre 2013 20:15, > a écrit :



De: "Ista Pouss" mailto:ista...@gmail.com>>>
Et même la cartopartie dans son ensemble, avec quelque
organisation, pourrait faire l'objet d'un article wikipedia...
(style "Parcours de la place Edmond Maurat") (HEU NON je veux dire
"de la Concorde").

Ça non, l'événement "cartopartie" sera très certainement considéré
comme non admissible dans WP par la grande majorité des
contributeurs (et bien que plutôt inclusionniste, je serais d'accord).


Oui tu as raison c'était une énorme grosse bourde de ma part, honte 
éternelle !


Bon... donc c'est foiré pour wikimedia, par cette approche. Je passe 
mon tour.




Pas aussi fermé, mais à voir avec Wikivoyage.

Cordialement

--
David Crochet

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia

[Ista Pouss]

Le 1 novembre 2013 20:15,  a écrit :

>
> De: "Ista Pouss" > Et même la cartopartie dans son
> ensemble, avec quelque organisation, pourrait faire l'objet d'un article
> wikipedia... (style "Parcours de la place Edmond Maurat") (HEU NON je veux
> dire "de la Concorde").
>
> Ça non, l'événement "cartopartie" sera très certainement considéré comme
> non admissible dans WP par la grande majorité des contributeurs (et bien
> que plutôt inclusionniste, je serais d'accord).
>
>
Oui tu as raison c'était une énorme grosse bourde de ma part, honte
éternelle !

Bon... donc c'est foiré pour wikimedia, par cette approche. Je passe mon
tour.


-- 
Les dérives de rue :
C’est chanter que je veux 

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia

[allegre . guillaume]

- Mail original -
De: "Ista Pouss" 
À: "Discussions sur OSM en français" 
Envoyé: Jeudi 31 Octobre 2013 14:29:18
Objet: Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia



Le 31 octobre 2013 11:52, Jean-Baptiste Holcroft < jb.holcr...@gmail.com > a 
écrit : 

> Je ne crois pas que ça puisse fonctionner dans le cadre des notes, car, pour 
> être importée sur commons, il faut que la photo puisse avoir un usage 
> éducatif, ou puisse avoir une utilisation dans un projet wikimedia : 
> https://commons.wikimedia.org/wiki/Commons:Crit%C3%A8res_d%27inclusion#Objectifs_de_Commons
>  

Je suis d'accord. Si la photo ne sert qu'à mettre en évidence une erreur OSM, 
elle n'a probablement rien à faire sur Commons.



> Par contre, les éventuelles photos d'une cartopartie (et même peut être les 
> traces GPS), pourraient, avec un peu de rigueur, un peu de formalisme 
> encyclopédique, être intégrées à commons : les intérêts encyclopédique et 
> éducatif me paraissent plus défendables. 

Oui, à condition que ce ne soient pas juste des photos de type "bloc-notes" ou 
photo de devanture.

> Et même la cartopartie dans son ensemble, avec quelque organisation, pourrait 
> faire l'objet d'un article wikipedia... (style "Parcours de la place Edmond 
> Maurat") (HEU NON je veux dire "de la Concorde"). 

Ça non, l'événement "cartopartie" sera très certainement considéré comme non 
admissible dans WP par la grande majorité des contributeurs (et bien que plutôt 
inclusionniste, je serais d'accord).

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia

[Ista Pouss]

Le 31 octobre 2013 11:52, Jean-Baptiste Holcroft  a
écrit :

> Pas forcément à créer mais éventuellement à réutiliser, cela permettra une
> collaboration commune wikimedia/OSM.
>

Je ne crois pas que ça puisse fonctionner dans le cadre des notes, car,
pour être importée sur commons, il faut que la photo puisse avoir un usage
éducatif, ou puisse avoir une utilisation dans un projet wikimedia :
https://commons.wikimedia.org/wiki/Commons:Crit%C3%A8res_d%27inclusion#Objectifs_de_Commons

Dans le cadre des notes, c'est un usage interne à OSM, qui n'a pas vocation
à être utile dans un contexte éducatif ou wikimedia.

Par contre, les éventuelles photos d'une cartopartie (et même peut être les
traces GPS), pourraient, avec un peu de rigueur, un peu de formalisme
encyclopédique, être intégrées à commons : les intérêts encyclopédique et
éducatif me paraissent plus défendables. Et même la cartopartie dans son
ensemble, avec quelque organisation, pourrait faire l'objet d'un article
wikipedia... (style "Parcours de la place Edmond Maurat") (HEU NON je veux
dire "de la Concorde").

A+.



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia

[Ista Pouss]

Le 31 octobre 2013 10:23, Jean-Baptiste Holcroft  a
écrit :

> Pour limiter ce système administratif et se réorienter vers la
> volarisation du terrain, je suis surpris que Notes ne permette pas de
> joindre des photos (voir videos) en partenariat avec commons ou d'autres
> acteurs (projet streetview osm). À l'image de ce que fait
> wikilovesmonuments ou commons.
> Chaque utilisateur de rendu pourra y apporter sa vision pour son usge
> final (rendu ou autre).
>

Pour préciser, je ne suis pas contre le système administratif, et encore
moins contre l'open data ! (...mais c'est vrai que je serais plutot POUR le
terrain)

Ce qui me déplait en cette affaire est que les données administratives
tendent à être considérées comme des choses concrètes. Par exemple pour
nombre de gens une limite communale est une chose concrète. Il faut
quasiment qu'ils aillent voir sur le terrain pour se rendre compte qu'il
n'y a aucune ligne entre Paris et Issy les moulineaux... Ce n'est déjà
qu'un rendu : le rendu administratif.

Mais une fois que c'est dit et admis, je n'ai rien contre les données
administratives, bien au contraire. Pour en reparler j'admire par exemple
le travail sur les limites communales mené au sein d'osm.

Cordialement.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia

[Jean-Baptiste Holcroft]

Pas forcément à créer mais éventuellement à réutiliser, cela permettra une
collaboration commune wikimedia/OSM.

Actions OpenStreetMap :
 * Notes doit pouvoir prendre les images Commons et recevoir les éléments
saisis lors de la capture
 * Créer un système officiel d'affichage des images Commons (semble
faisable :
http://toolserver.org/~kolossos/openlayers/commons-on-osm.php?lat=52.516389&lon=13.38&zoom=15
)

Actions Wikimedia :
* modifier l'application commons pour incorporer le nécessaire à
l'identification d'une photo pour une note et permettre la localisation
manuelle de la note :
https://play.google.com/store/apps/details?id=org.wikimedia.commons&hl=fr
* les critères d'inclusion de commons :
https://commons.wikimedia.org/wiki/Commons:Crit%C3%A8res_d%27inclusion (et
encore, il y a énormément d'articles sur les rues, villes, rivières... Mais
c'est surtout qu'OpenStreetMap n'est pas un projet de la sphère Wikimedia)

Actions communes :
 * Passerelles éventuelles entre les utilisateurs Wikimedia & OpenStreetMap
(OpenID ?)


--
Jean-Baptiste Holcroft


Le 31 octobre 2013 10:38, Christian Quest  a écrit
:

> Voilà l'appli à créer... OSMphotoNotes... prise d'une photo géolocalisée,
> partagée via une note et un lien qui pointe dessus. Ca permet de documenter
> la note bien plus efficacement qu'un texte.
>
> Par contre, il va falloir gérer les dérives...
>
>
> Le 31 octobre 2013 10:23, Jean-Baptiste Holcroft a 
> écrit :
>
> Pour limiter ce système administratif et se réorienter vers la
>> volarisation du terrain, je suis surpris que Notes ne permette pas de
>> joindre des photos (voir videos) en partenariat avec commons ou d'autres
>> acteurs (projet streetview osm). À l'image de ce que fait
>> wikilovesmonuments ou commons.
>> Chaque utilisateur de rendu pourra y apporter sa vision pour son usge
>> final (rendu ou autre).
>> Le 31 oct. 2013 01:15, "Ista Pouss"  a écrit :
>>
>>>  Le 30 octobre 2013 23:55, Guillaume Allegre a 
>>> écrit :
>>>

 > Oui... le modèle "osm est une base de données" ne fonctionne pas,
 c'est ce
 > que je pense. Il pose des problèmes irrésolvables de sémantique et de
 > contrôle, entres autres.

 Tiens, je ne vois pas ce qui te permet de dire ça.

 Moi je trouve que le modèle de la DB est plutôt bien respecté par OSM
 (c'est d'ailleurs le problème des reverts impossibles après une autre
 édition,
 contrairement au modèle des commits de WP, qu'on sait traiter en texte
 depuis belle
 lurette).


>>> Heu je me suis mal exprimé que tu m'as mal compris : ce n'est pas qu'il
>>> soit bien ou mal respecté que je pense, mais que, par conception, il ne
>>> peut pas fonctionner. Certes on arrive toujours à faire des cartes, mais on
>>> va de plus en plus dans un modèle administratif, et de moins en moins dans
>>> une observation terrain, de mon opinion.
>>>
>>> C'est parce que sémantique comme contrôle sont des opérations qui
>>> dépendent d'une vision, donc d'un mode de rendu. Même une chose qu'on croit
>>> exister par elle même dépend d'une vision pour la manipuler, la décrire, la
>>> positionner dans l'espace.
>>>
>>> Or le rendu est considéré comme une sorte d'optionalité, de pluralité
>>> libre, et on en conclus que les données doivent être entrées en dehors de
>>> tout rendu... mais on perd alors leur sémantique et leur contrôle.
>>>
>>> Heu... suis-je plus clair ?
>>>
>>> La solution de mon opinion serait d'interdire purement et simplement
>>> toute entrée de données qui n'ait pas au moins un rendu référent... (Mais
>>> je ne pense pas que ça soit la tendance actuelle dans la communauté :-)
>>>
>>>
>>>

 > Impossible de faire des cartes avec une base de
 > données, c'est mon opinion : pour faire des cartes il faut d'abord
 faire de
 > la cartographie, et à OSM on n'en fait pas, trompé que nous sommes
 par les
 > datas.

 Je ne comprends vraiment pas ce que tu veux dire, si tu pouvais
 développer ?


>>> La cartographie, ce n'est pas seulement des objets géolocalisés : c'est
>>> des objets qu'on projette sur une page blanche, cette projection et ces
>>> objets conservant les propriétés que l'on veut, en général les rapports de
>>> distance.
>>>
>>> Par exemple, je peux suivre une route sur une carte et en déduire la
>>> distance que je vais parcourir dans la réalité. (heureusement).
>>>
>>> En se focalisant sur les datas, on perd cette notion de projection.
>>>
>>> Par exemple le problème des trottoirs, que tantôt on accole à la route
>>> principale, que tantôt on trace comme chemin dissocié, ou tantôt comme
>>> surface, on éprouve les plus grandes difficultés à savoir ce qu'il faut
>>> faire et pourquoi, et encore plus à relier les trottoirs avec les routes,
>>> et même les trottoirs entre eux cela vient (de mon opinion) que l'on
>>> mélange différents types de projection sans en avoir conscience.
>>>
>>> La communauté est bien au courant qu'il existe différent types de

Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia

[Christian Quest]

Voilà l'appli à créer... OSMphotoNotes... prise d'une photo géolocalisée,
partagée via une note et un lien qui pointe dessus. Ca permet de documenter
la note bien plus efficacement qu'un texte.

Par contre, il va falloir gérer les dérives...


Le 31 octobre 2013 10:23, Jean-Baptiste Holcroft  a
écrit :

> Pour limiter ce système administratif et se réorienter vers la
> volarisation du terrain, je suis surpris que Notes ne permette pas de
> joindre des photos (voir videos) en partenariat avec commons ou d'autres
> acteurs (projet streetview osm). À l'image de ce que fait
> wikilovesmonuments ou commons.
> Chaque utilisateur de rendu pourra y apporter sa vision pour son usge
> final (rendu ou autre).
> Le 31 oct. 2013 01:15, "Ista Pouss"  a écrit :
>
>>  Le 30 octobre 2013 23:55, Guillaume Allegre a 
>> écrit :
>>
>>>
>>> > Oui... le modèle "osm est une base de données" ne fonctionne pas,
>>> c'est ce
>>> > que je pense. Il pose des problèmes irrésolvables de sémantique et de
>>> > contrôle, entres autres.
>>>
>>> Tiens, je ne vois pas ce qui te permet de dire ça.
>>>
>>> Moi je trouve que le modèle de la DB est plutôt bien respecté par OSM
>>> (c'est d'ailleurs le problème des reverts impossibles après une autre
>>> édition,
>>> contrairement au modèle des commits de WP, qu'on sait traiter en texte
>>> depuis belle
>>> lurette).
>>>
>>>
>> Heu je me suis mal exprimé que tu m'as mal compris : ce n'est pas qu'il
>> soit bien ou mal respecté que je pense, mais que, par conception, il ne
>> peut pas fonctionner. Certes on arrive toujours à faire des cartes, mais on
>> va de plus en plus dans un modèle administratif, et de moins en moins dans
>> une observation terrain, de mon opinion.
>>
>> C'est parce que sémantique comme contrôle sont des opérations qui
>> dépendent d'une vision, donc d'un mode de rendu. Même une chose qu'on croit
>> exister par elle même dépend d'une vision pour la manipuler, la décrire, la
>> positionner dans l'espace.
>>
>> Or le rendu est considéré comme une sorte d'optionalité, de pluralité
>> libre, et on en conclus que les données doivent être entrées en dehors de
>> tout rendu... mais on perd alors leur sémantique et leur contrôle.
>>
>> Heu... suis-je plus clair ?
>>
>> La solution de mon opinion serait d'interdire purement et simplement
>> toute entrée de données qui n'ait pas au moins un rendu référent... (Mais
>> je ne pense pas que ça soit la tendance actuelle dans la communauté :-)
>>
>>
>>
>>>
>>> > Impossible de faire des cartes avec une base de
>>> > données, c'est mon opinion : pour faire des cartes il faut d'abord
>>> faire de
>>> > la cartographie, et à OSM on n'en fait pas, trompé que nous sommes par
>>> les
>>> > datas.
>>>
>>> Je ne comprends vraiment pas ce que tu veux dire, si tu pouvais
>>> développer ?
>>>
>>>
>> La cartographie, ce n'est pas seulement des objets géolocalisés : c'est
>> des objets qu'on projette sur une page blanche, cette projection et ces
>> objets conservant les propriétés que l'on veut, en général les rapports de
>> distance.
>>
>> Par exemple, je peux suivre une route sur une carte et en déduire la
>> distance que je vais parcourir dans la réalité. (heureusement).
>>
>> En se focalisant sur les datas, on perd cette notion de projection.
>>
>> Par exemple le problème des trottoirs, que tantôt on accole à la route
>> principale, que tantôt on trace comme chemin dissocié, ou tantôt comme
>> surface, on éprouve les plus grandes difficultés à savoir ce qu'il faut
>> faire et pourquoi, et encore plus à relier les trottoirs avec les routes,
>> et même les trottoirs entre eux cela vient (de mon opinion) que l'on
>> mélange différents types de projection sans en avoir conscience.
>>
>> La communauté est bien au courant qu'il existe différent types de
>> projection pour la terre, mais elle ne semble pas savoir qu'il existe des
>> types de projection pour les trottoirs, et pratiquement tout ce qui existe.
>>
>> Si l'on admet que j'ai à peu près raison et que je puisse proposer un
>> début de solution, je la vois dans le fait que j'entends quelque fois
>> parler d'OSM non pas comme une base de données, mais comme un éco-système
>> de description terrain.
>>
>> Dans cet écosystème, données, rendus, informatique ne sont pas
>> indépendant les uns des autres, mais se nourrissent les uns les autres,
>> pour tendre au résultat... OSM fonctionne déjà un peu comme ça, mais sans
>> le dire vraiment.
>>
>> Cette approche me parait infiniment plus porteuse, et très originale par
>> rapport à wikipedia. (bien qu'il existe qqchose d'un peu similaire entre
>> wikipedia et commons).
>>
>> Bon, et j'ai toujours pas taggué le col de la république, moi... j'y
>> repense demain.
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetm

Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia

[Jean-Baptiste Holcroft]

Pour limiter ce système administratif et se réorienter vers la volarisation
du terrain, je suis surpris que Notes ne permette pas de joindre des photos
(voir videos) en partenariat avec commons ou d'autres acteurs (projet
streetview osm). À l'image de ce que fait wikilovesmonuments ou commons.
Chaque utilisateur de rendu pourra y apporter sa vision pour son usge final
(rendu ou autre).
Le 31 oct. 2013 01:15, "Ista Pouss"  a écrit :

> Le 30 octobre 2013 23:55, Guillaume Allegre  a
> écrit :
>
>>
>> > Oui... le modèle "osm est une base de données" ne fonctionne pas, c'est
>> ce
>> > que je pense. Il pose des problèmes irrésolvables de sémantique et de
>> > contrôle, entres autres.
>>
>> Tiens, je ne vois pas ce qui te permet de dire ça.
>>
>> Moi je trouve que le modèle de la DB est plutôt bien respecté par OSM
>> (c'est d'ailleurs le problème des reverts impossibles après une autre
>> édition,
>> contrairement au modèle des commits de WP, qu'on sait traiter en texte
>> depuis belle
>> lurette).
>>
>>
> Heu je me suis mal exprimé que tu m'as mal compris : ce n'est pas qu'il
> soit bien ou mal respecté que je pense, mais que, par conception, il ne
> peut pas fonctionner. Certes on arrive toujours à faire des cartes, mais on
> va de plus en plus dans un modèle administratif, et de moins en moins dans
> une observation terrain, de mon opinion.
>
> C'est parce que sémantique comme contrôle sont des opérations qui
> dépendent d'une vision, donc d'un mode de rendu. Même une chose qu'on croit
> exister par elle même dépend d'une vision pour la manipuler, la décrire, la
> positionner dans l'espace.
>
> Or le rendu est considéré comme une sorte d'optionalité, de pluralité
> libre, et on en conclus que les données doivent être entrées en dehors de
> tout rendu... mais on perd alors leur sémantique et leur contrôle.
>
> Heu... suis-je plus clair ?
>
> La solution de mon opinion serait d'interdire purement et simplement toute
> entrée de données qui n'ait pas au moins un rendu référent... (Mais je ne
> pense pas que ça soit la tendance actuelle dans la communauté :-)
>
>
>
>>
>> > Impossible de faire des cartes avec une base de
>> > données, c'est mon opinion : pour faire des cartes il faut d'abord
>> faire de
>> > la cartographie, et à OSM on n'en fait pas, trompé que nous sommes par
>> les
>> > datas.
>>
>> Je ne comprends vraiment pas ce que tu veux dire, si tu pouvais
>> développer ?
>>
>>
> La cartographie, ce n'est pas seulement des objets géolocalisés : c'est
> des objets qu'on projette sur une page blanche, cette projection et ces
> objets conservant les propriétés que l'on veut, en général les rapports de
> distance.
>
> Par exemple, je peux suivre une route sur une carte et en déduire la
> distance que je vais parcourir dans la réalité. (heureusement).
>
> En se focalisant sur les datas, on perd cette notion de projection.
>
> Par exemple le problème des trottoirs, que tantôt on accole à la route
> principale, que tantôt on trace comme chemin dissocié, ou tantôt comme
> surface, on éprouve les plus grandes difficultés à savoir ce qu'il faut
> faire et pourquoi, et encore plus à relier les trottoirs avec les routes,
> et même les trottoirs entre eux cela vient (de mon opinion) que l'on
> mélange différents types de projection sans en avoir conscience.
>
> La communauté est bien au courant qu'il existe différent types de
> projection pour la terre, mais elle ne semble pas savoir qu'il existe des
> types de projection pour les trottoirs, et pratiquement tout ce qui existe.
>
> Si l'on admet que j'ai à peu près raison et que je puisse proposer un
> début de solution, je la vois dans le fait que j'entends quelque fois
> parler d'OSM non pas comme une base de données, mais comme un éco-système
> de description terrain.
>
> Dans cet écosystème, données, rendus, informatique ne sont pas indépendant
> les uns des autres, mais se nourrissent les uns les autres, pour tendre au
> résultat... OSM fonctionne déjà un peu comme ça, mais sans le dire vraiment.
>
> Cette approche me parait infiniment plus porteuse, et très originale par
> rapport à wikipedia. (bien qu'il existe qqchose d'un peu similaire entre
> wikipedia et commons).
>
> Bon, et j'ai toujours pas taggué le col de la république, moi... j'y
> repense demain.
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia

[Christian Quest]

Le 30 octobre 2013 12:05, Pieren  a écrit :

> 2013/10/29 Guillaume Allegre :
>
> > Voici donc la suite, un peu plus polémique (forcément), et parfois
> > franchement provoc (et sans doute un peu trop long)
> >
> http://gallaxie.wordpress.com/2013/10/28/openstreetmap-vs-wikipedia-23-differences-et-divergences/
>
> Je ne suis pas contributeur wikipedien et je suis donc mal placé pour
> critiquer ce côté là. Mais concernant OSM, il manque certains points
> importants dans la comparaison:
> - homogénéité : si la longueur des articles sur wikipedia et le niveau
> des détails dans OSM dépendent tous les deux directement du nombre de
> contributeurs s'y afférant, on pardonne beaucoup moins à OSM de tels
> écarts d'informations entre zones géographiques. Ces grands écarts
> entre zones qui ont "tout" (rues, adresses, POI) et celles qui n'ont
> "rien" empêchent toute exploitation à grande échelle. On peut juste
> espérer que ces écarts se comblent avec le temps mais rien n'est moins
> sûr. C'est le principal argument avancé par l'IGN lorsqu'ils parlent
> d'OSM. Et sur ce point, ils ont raison.
>

Homogénéité d'exhaustivité... oui, c'est très variable sur OSM.
En même temps, une parfaite homogénéité d'exhaustivité peut être un énorme
frein pour avancer et innover. Le cas de l'IGN est intéressant. Sa mission
de service public l'oblige à traiter tout les territoires avec le même
niveau de détail (en théorie).
Donc avant de passer à un niveau de détail supplémentaire, il faut un
énorme travail pour l'atteindre à peu près partout.

OSM ne s'embarasse heureusement pas de ce traitement identique des
territoires. Si on avait mis en place une telle logique, on serait bloqués
à de nombreux endroits car d'autres n'ont pas atteint le niveau minimal
pour passer globalement au suivant.

Oui, du coup, rien qu'en France on a des zone hyper détaillées où il ne
manquera pas une bande podo-tactile sur un passage piéton alors un peu plus
loin il manque encore des routes départementales.


- vandalisme : les cas sont peut-être beaucoup plus nombreux qu'on ne
> le pense parce que dans OSM, il est plus difficile d'avoir un suivi
> des transformations sur une zone que wikipedia sur un article. Et les
> outils de contrôle ont aussi des lacunes (voir dernier point) Si, par
> exemple, on peut voir une version T-n_days dans wikipedia en 2 clics
> de souris, retrouver les données d'une zone géographique à T-n_days
> dans OSM nécessite beaucoup de temps, de ressources et connaissances
> informatiques. Et pour le cas où un petit vandalisme ou disons,
> "altération négative" lorsque ça n'est pas volontaire, est détecté, il
> n'y a pas d'outil pour facilement revenir en arrière alors que le
> "undo" sur wikipedia se fait en deux clics de souris. Il y a donc un
> déséquilibre manifeste entre contributions positives et négatives
> puisque les outils manquent pour lutter contre les secondes.  On peut
> alors assister à deux phénomènes : soit le contributeur abandonne le
> projet suite à une frustration légitime. Ou alors, il "délègue" cette
> tâche à d'autres, en passant par cette liste par exemple ou sur un
> forum ou par le DWG. C'est ce qui se passe plus ou moins bien depuis
> les débuts d'OSM et certains sont même satisfait de ce modèle. Mais
> cela ne marche que s'il y a suffisament de volontaires pour prendre en
> charge ces annulations et que si elles se font suffisament tôt
> (techniquement, plus on attends, plus c'est difficile, voire
> impossible). Et si le nombre de vandalismes venait à fortement
> augmenter, ce petit groupe ne sera plus capable de faire face. Un des
> gros points forts de wikipedia est que les annulations sont
> directement et facilement accessibles par tout le monde. C'est un
> point majeur pour les projets collaboratifs qu'OSM ne propose pas.
>

+1 !

Plutôt que de parler de vandalisme, je préfère la notion de dégradation
volontaire ou involontaire.
Les dégradations volontaires sont rares, très rares.
Les involontaires sont fréquentes chez les nouveaux contributeurs, mais pas
que. Il nous arrive à tous de faire des erreurs.

Nous manquons vraiment d'outils à ce niveau pour réparer, mais c'est vrai
aussi que ça limite les guerres d'édition et l'annulation presse-bouton un
peu facile. La principale difficulté étant je pense les données supprimées
et leur impact. Il reste par exemple encore pas mal de zones impactées par
la "redaction".

Je regrette aussi que l'API ne soit pas plus regardante sur les données
qu'on lui envoie.
Il n'y a quasiment aucun contrôle, ce qui permet de créer des way avec
moins de 2 nœuds, des ways non conformes (repassant par le même nœud), des
tags vides, etc.

Historiquement ça peut se comprendre sur le plan technique (capacité de
traitement limité sur les premières implémentations), mais cette absence de
tout contrôle ça semble être devenue un principe et je n'en vois pas le
bienfait.


- "sémantique" : les tags sont nombreux dans OSM, trop nombreux. Les
> erreurs de typo ne sont que lentement 

Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia

[Philippe Verdy]

Le 31 octobre 2013 01:15, Ista Pouss  a écrit :

> Heu je me suis mal exprimé que tu m'as mal compris : ce n'est pas qu'il
> soit bien ou mal respecté que je pense, mais que, par conception, il ne
> peut pas fonctionner. Certes on arrive toujours à faire des cartes, mais on
> va de plus en plus dans un modèle administratif, et de moins en moins dans
> une observation terrain, de mon opinion.
>

Le modèle administrtif est juste l'infrstructure de référence de base, sur
laquelle viennent ensuite s'accrocher toutes les autres infos (et
corrections locales), il  l'avantage cependnt d'une couverture à peu près
équitable ou au moins suffisante du territoire.

Cependant il n'est pas exemple d'erreurs dans les sources dont on dispose
pour ces données, ce qui ne signifie pas qu'elles sont sans significations
: cela veut juste dire souvent qu'elles manquent un peu de précision (ou
parfois de mise à jour plus récente) si on veut accrocher autre chose
autour, et c'est là qu'on fait les corrections nécessaires.

Cependant c'est vrai aussi que la modélistion dans les sources n'est pas
toujours très adaptée pour être directement intégrable (on le voit avec le
cadastre, comem aussi avec d'autres sources qui ont des tags spécifiques
assez exotiques à réintégrer en trouvant des mappings intelligents
utilisbles aussi avec d'autres sources :

Ces modélisations tierces ne sont pas à reproduire in extenso, elles sont
soit trop précises, dans un contexte purement adinistratif franco-français
sans équivalent possible ailleurs ou dans d'autres domaines (auquel cas il
faudra passer par des sous-tags d'un autre tag plus générique), soit pas
assez (car dans OSM on a pu généraliser des tags descriptifs plus précis :
le travail d'intégration demande au minimum de ne pas saccger/supprimer ces
sous-classifictions collectives venant d'autres sources, et sinon de
pouvoir indiquer dns les données importées que la sous-clssification n'a ps
été faite et reste encore trop générique : exemple de "building=yes" qui ne
doit pas remplacer d'autres valeurs existantes de "building=*")

Et au final aucune de ces sources administrtaives n'a vocation à être
réutilisées verbatim dans OSM, c'est tout l'intérêt de l'intégration
demandée qui doit chercher à faire cohabiter les différentes sources,
qu'elles soient administratives ou d'origine privée, du terrain ou non
(imagerie par exemple).

Les données de terrain ne sont pas non plus suffisantes :

(1) il n'est pas toujours possible de savoir sans utiliser une base de
données ouverte tierce: pour des raisons de droit d'accès au terrain ou des
raisons légales de protection des données personnelles ou de données
commerciales exclusives, on doit demander la permission à la source, et lui
faire confiance sur les données qu'elle propose.

(2) la couverture du terrain sera toujours très inégale sur le territoire
en fonction de

 * la densité de population, qui influe très directement sur celle des
contributeurs locaux,

 * ou de difficultés locales d'accès à Internet et de défaut d'équipement
chez les particuliers locaux (lié à un certain niveau de développement
économique, ou des prix pratiqués localement chez les fournisseurs sans
grande concurrence locale)

 * des difficultés de déplacement sur place (prendre en compte l'équipement
de transport, privé ou public, et son coût d'usage en argent et en temps)

 * ou de la présence ou pas sur place d'organisations et associations
d'aide et développement au niveau humanitaire (alimentation,
santé, assainisssament), social (logement, aide au travail, handicap,
enfance et vieillesse), éducatif (y compris la formation professionnelle
des adultes), sportif et culturel, ou de sociétés privées en charge de
missions de service public (et qui doivent alors rendre des comptes sur les
données de leur activité) comme les transports ou l'environnement ou les
concessions (voirie, mines, fréquences)...

 * la présence locale et l'intérêt des grands médias.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia

[Ista Pouss]

Le 30 octobre 2013 23:55, Guillaume Allegre  a
écrit :

>
> > Oui... le modèle "osm est une base de données" ne fonctionne pas, c'est
> ce
> > que je pense. Il pose des problèmes irrésolvables de sémantique et de
> > contrôle, entres autres.
>
> Tiens, je ne vois pas ce qui te permet de dire ça.
>
> Moi je trouve que le modèle de la DB est plutôt bien respecté par OSM
> (c'est d'ailleurs le problème des reverts impossibles après une autre
> édition,
> contrairement au modèle des commits de WP, qu'on sait traiter en texte
> depuis belle
> lurette).
>
>
Heu je me suis mal exprimé que tu m'as mal compris : ce n'est pas qu'il
soit bien ou mal respecté que je pense, mais que, par conception, il ne
peut pas fonctionner. Certes on arrive toujours à faire des cartes, mais on
va de plus en plus dans un modèle administratif, et de moins en moins dans
une observation terrain, de mon opinion.

C'est parce que sémantique comme contrôle sont des opérations qui dépendent
d'une vision, donc d'un mode de rendu. Même une chose qu'on croit exister
par elle même dépend d'une vision pour la manipuler, la décrire, la
positionner dans l'espace.

Or le rendu est considéré comme une sorte d'optionalité, de pluralité
libre, et on en conclus que les données doivent être entrées en dehors de
tout rendu... mais on perd alors leur sémantique et leur contrôle.

Heu... suis-je plus clair ?

La solution de mon opinion serait d'interdire purement et simplement toute
entrée de données qui n'ait pas au moins un rendu référent... (Mais je ne
pense pas que ça soit la tendance actuelle dans la communauté :-)



>
> > Impossible de faire des cartes avec une base de
> > données, c'est mon opinion : pour faire des cartes il faut d'abord faire
> de
> > la cartographie, et à OSM on n'en fait pas, trompé que nous sommes par
> les
> > datas.
>
> Je ne comprends vraiment pas ce que tu veux dire, si tu pouvais développer
> ?
>
>
La cartographie, ce n'est pas seulement des objets géolocalisés : c'est des
objets qu'on projette sur une page blanche, cette projection et ces objets
conservant les propriétés que l'on veut, en général les rapports de
distance.

Par exemple, je peux suivre une route sur une carte et en déduire la
distance que je vais parcourir dans la réalité. (heureusement).

En se focalisant sur les datas, on perd cette notion de projection.

Par exemple le problème des trottoirs, que tantôt on accole à la route
principale, que tantôt on trace comme chemin dissocié, ou tantôt comme
surface, on éprouve les plus grandes difficultés à savoir ce qu'il faut
faire et pourquoi, et encore plus à relier les trottoirs avec les routes,
et même les trottoirs entre eux cela vient (de mon opinion) que l'on
mélange différents types de projection sans en avoir conscience.

La communauté est bien au courant qu'il existe différent types de
projection pour la terre, mais elle ne semble pas savoir qu'il existe des
types de projection pour les trottoirs, et pratiquement tout ce qui existe.

Si l'on admet que j'ai à peu près raison et que je puisse proposer un début
de solution, je la vois dans le fait que j'entends quelque fois parler
d'OSM non pas comme une base de données, mais comme un éco-système de
description terrain.

Dans cet écosystème, données, rendus, informatique ne sont pas indépendant
les uns des autres, mais se nourrissent les uns les autres, pour tendre au
résultat... OSM fonctionne déjà un peu comme ça, mais sans le dire vraiment.

Cette approche me parait infiniment plus porteuse, et très originale par
rapport à wikipedia. (bien qu'il existe qqchose d'un peu similaire entre
wikipedia et commons).

Bon, et j'ai toujours pas taggué le col de la république, moi... j'y
repense demain.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia

[Guillaume Allegre]

Le mer. 30 oct. 2013 à 14:11 +0100, Ista Pouss a écrit :

> Oui... le modèle "osm est une base de données" ne fonctionne pas, c'est ce
> que je pense. Il pose des problèmes irrésolvables de sémantique et de
> contrôle, entres autres.

Tiens, je ne vois pas ce qui te permet de dire ça.

Moi je trouve que le modèle de la DB est plutôt bien respecté par OSM 
(c'est d'ailleurs le problème des reverts impossibles après une autre édition, 
contrairement au modèle des commits de WP, qu'on sait traiter en texte depuis 
belle
lurette).


> Impossible de faire des cartes avec une base de
> données, c'est mon opinion : pour faire des cartes il faut d'abord faire de
> la cartographie, et à OSM on n'en fait pas, trompé que nous sommes par les
> datas.

Je ne comprends vraiment pas ce que tu veux dire, si tu pouvais développer ?


-- 
 ° /\Guillaume AllègreOpenStreetMap France
  /~~\/\   allegre.guilla...@free.fr  Cartographie libre et collaborative
 /   /~~\tél. 04.76.63.26.99  http://www.openstreetmap.fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia

[Florian LAINEZ]

"Les pieds-tendres peuvent bien tenter des imports de données (parfois
utiles, il faut bien le dire), ils n’auront jamais la gloire que confère un
*source=GPS survey* judicieusement placé."
ahah tout à fait vrai :)


Le 30 octobre 2013 13:11, Ista Pouss  a écrit :

> Le 30 octobre 2013 12:05, Pieren  a écrit :
>
>> - homogénéité : si la longueur des articles sur wikipedia et le niveau
>> des détails dans OSM dépendent tous les deux directement du nombre de
>> contributeurs s'y afférant, on pardonne beaucoup moins à OSM de tels
>> écarts d'informations entre zones géographiques. Ces grands écarts
>> entre zones qui ont "tout" (rues, adresses, POI) et celles qui n'ont
>> "rien" empêchent toute exploitation à grande échelle. On peut juste
>> espérer que ces écarts se comblent avec le temps mais rien n'est moins
>> sûr. C'est le principal argument avancé par l'IGN lorsqu'ils parlent
>> d'OSM. Et sur ce point, ils ont raison.
>>
>
> Oui.
>
> Mais ça ne dépend pas seulement du nombre de contributeurs : l'homogénéité
> dépend aussi des règles que tu te donnes.
>
> Par exemple à wikipedia l'arrivée de l'éditeur wisiwig provoque la
> révision de nombre de modèles incompatibles, augmentant du coup
> l'homogénïté.
>
> Cependant il n'est pas complètement clair pour moi que l'homogénéïté, ou
> des notions proches telles que la cohérence, soient des fins en soi dans
> les projets collaboratifs. Ce qui est sûr est que ce sont des propriétés
> intéressantes à suivre, à améliorer, pouvant donner naissances à des règles
> faisant consensus.
>
>
>
>> - vandalisme : les cas sont peut-être beaucoup plus nombreux qu'on ne
>> le pense parce que dans OSM, il est plus difficile d'avoir un suivi
>> des transformations sur une zone que wikipedia sur un article. Et les
>> outils de contrôle ont aussi des lacunes (voir dernier point) Si, par
>> exemple, on peut voir une version T-n_days dans wikipedia en 2 clics
>> de souris, retrouver les données d'une zone géographique à T-n_days
>> dans OSM nécessite beaucoup de temps, de ressources et connaissances
>> informatiques. Et pour le cas où un petit vandalisme ou disons,
>> "altération négative" lorsque ça n'est pas volontaire, est détecté, il
>> n'y a pas d'outil pour facilement revenir en arrière alors que le
>> "undo" sur wikipedia se fait en deux clics de souris. Il y a donc un
>> déséquilibre manifeste entre contributions positives et négatives
>> puisque les outils manquent pour lutter contre les secondes.  On peut
>> alors assister à deux phénomènes : soit le contributeur abandonne le
>> projet suite à une frustration légitime. Ou alors, il "délègue" cette
>> tâche à d'autres, en passant par cette liste par exemple ou sur un
>> forum ou par le DWG. C'est ce qui se passe plus ou moins bien depuis
>> les débuts d'OSM et certains sont même satisfait de ce modèle. Mais
>> cela ne marche que s'il y a suffisament de volontaires pour prendre en
>> charge ces annulations et que si elles se font suffisament tôt
>> (techniquement, plus on attends, plus c'est difficile, voire
>> impossible). Et si le nombre de vandalismes venait à fortement
>> augmenter, ce petit groupe ne sera plus capable de faire face. Un des
>> gros points forts de wikipedia est que les annulations sont
>> directement et facilement accessibles par tout le monde. C'est un
>> point majeur pour les projets collaboratifs qu'OSM ne propose pas.
>>
>
> Oui. Espérons.
>
>
>
>>  - "sémantique" : les tags sont nombreux dans OSM, trop nombreux. Les
>> [couic]
>> - le "contrôle" : bien peu sont ceux qui contrôlent les données OSM en
>> [couic]
>>
>>
> Oui... le modèle "osm est une base de données" ne fonctionne pas, c'est ce
> que je pense. Il pose des problèmes irrésolvables de sémantique et de
> contrôle, entres autres. Impossible de faire des cartes avec une base de
> données, c'est mon opinion : pour faire des cartes il faut d'abord faire de
> la cartographie, et à OSM on n'en fait pas, trompé que nous sommes par les
> datas.
>
> Toutefois, en attendant que j'ai raison, je continue à contribuer :-)
>
> Ainsi, .en parcourant wikipedia, et en suivant les discussions osm, j'ai
> repéré à ma surprise que l'ultra-fréquenté col de la République (
> https://fr.wikipedia.org/wiki/Col_de_la_R%C3%A9publique), théâtre d'un
> des plus tristes événements du Tour de France, n'était pas enregistré dans
> OSM !? Problème manifeste de homogénéité ! je compte l'y mettre dans la
> semaine :-) ...je suis surtout un petit contributeur qui parle beaucoup :-)
>
> 
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 

*Florian Lainez*
@overflorian 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia

[Ista Pouss]

Le 30 octobre 2013 12:05, Pieren  a écrit :

> - homogénéité : si la longueur des articles sur wikipedia et le niveau
> des détails dans OSM dépendent tous les deux directement du nombre de
> contributeurs s'y afférant, on pardonne beaucoup moins à OSM de tels
> écarts d'informations entre zones géographiques. Ces grands écarts
> entre zones qui ont "tout" (rues, adresses, POI) et celles qui n'ont
> "rien" empêchent toute exploitation à grande échelle. On peut juste
> espérer que ces écarts se comblent avec le temps mais rien n'est moins
> sûr. C'est le principal argument avancé par l'IGN lorsqu'ils parlent
> d'OSM. Et sur ce point, ils ont raison.
>

Oui.

Mais ça ne dépend pas seulement du nombre de contributeurs : l'homogénéité
dépend aussi des règles que tu te donnes.

Par exemple à wikipedia l'arrivée de l'éditeur wisiwig provoque la révision
de nombre de modèles incompatibles, augmentant du coup l'homogénïté.

Cependant il n'est pas complètement clair pour moi que l'homogénéïté, ou
des notions proches telles que la cohérence, soient des fins en soi dans
les projets collaboratifs. Ce qui est sûr est que ce sont des propriétés
intéressantes à suivre, à améliorer, pouvant donner naissances à des règles
faisant consensus.



> - vandalisme : les cas sont peut-être beaucoup plus nombreux qu'on ne
> le pense parce que dans OSM, il est plus difficile d'avoir un suivi
> des transformations sur une zone que wikipedia sur un article. Et les
> outils de contrôle ont aussi des lacunes (voir dernier point) Si, par
> exemple, on peut voir une version T-n_days dans wikipedia en 2 clics
> de souris, retrouver les données d'une zone géographique à T-n_days
> dans OSM nécessite beaucoup de temps, de ressources et connaissances
> informatiques. Et pour le cas où un petit vandalisme ou disons,
> "altération négative" lorsque ça n'est pas volontaire, est détecté, il
> n'y a pas d'outil pour facilement revenir en arrière alors que le
> "undo" sur wikipedia se fait en deux clics de souris. Il y a donc un
> déséquilibre manifeste entre contributions positives et négatives
> puisque les outils manquent pour lutter contre les secondes.  On peut
> alors assister à deux phénomènes : soit le contributeur abandonne le
> projet suite à une frustration légitime. Ou alors, il "délègue" cette
> tâche à d'autres, en passant par cette liste par exemple ou sur un
> forum ou par le DWG. C'est ce qui se passe plus ou moins bien depuis
> les débuts d'OSM et certains sont même satisfait de ce modèle. Mais
> cela ne marche que s'il y a suffisament de volontaires pour prendre en
> charge ces annulations et que si elles se font suffisament tôt
> (techniquement, plus on attends, plus c'est difficile, voire
> impossible). Et si le nombre de vandalismes venait à fortement
> augmenter, ce petit groupe ne sera plus capable de faire face. Un des
> gros points forts de wikipedia est que les annulations sont
> directement et facilement accessibles par tout le monde. C'est un
> point majeur pour les projets collaboratifs qu'OSM ne propose pas.
>

Oui. Espérons.



> - "sémantique" : les tags sont nombreux dans OSM, trop nombreux. Les
> [couic]
> - le "contrôle" : bien peu sont ceux qui contrôlent les données OSM en
> [couic]
>
>
Oui... le modèle "osm est une base de données" ne fonctionne pas, c'est ce
que je pense. Il pose des problèmes irrésolvables de sémantique et de
contrôle, entres autres. Impossible de faire des cartes avec une base de
données, c'est mon opinion : pour faire des cartes il faut d'abord faire de
la cartographie, et à OSM on n'en fait pas, trompé que nous sommes par les
datas.

Toutefois, en attendant que j'ai raison, je continue à contribuer :-)

Ainsi, .en parcourant wikipedia, et en suivant les discussions osm, j'ai
repéré à ma surprise que l'ultra-fréquenté col de la République (
https://fr.wikipedia.org/wiki/Col_de_la_R%C3%A9publique), théâtre d'un des
plus tristes événements du Tour de France, n'était pas enregistré dans OSM
!? Problème manifeste de homogénéité ! je compte l'y mettre dans la semaine
:-) ...je suis surtout un petit contributeur qui parle beaucoup :-)


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia

[Pieren]

2013/10/29 Guillaume Allegre :

> Voici donc la suite, un peu plus polémique (forcément), et parfois
> franchement provoc (et sans doute un peu trop long)
> http://gallaxie.wordpress.com/2013/10/28/openstreetmap-vs-wikipedia-23-differences-et-divergences/

Je ne suis pas contributeur wikipedien et je suis donc mal placé pour
critiquer ce côté là. Mais concernant OSM, il manque certains points
importants dans la comparaison:
- homogénéité : si la longueur des articles sur wikipedia et le niveau
des détails dans OSM dépendent tous les deux directement du nombre de
contributeurs s'y afférant, on pardonne beaucoup moins à OSM de tels
écarts d'informations entre zones géographiques. Ces grands écarts
entre zones qui ont "tout" (rues, adresses, POI) et celles qui n'ont
"rien" empêchent toute exploitation à grande échelle. On peut juste
espérer que ces écarts se comblent avec le temps mais rien n'est moins
sûr. C'est le principal argument avancé par l'IGN lorsqu'ils parlent
d'OSM. Et sur ce point, ils ont raison.
- vandalisme : les cas sont peut-être beaucoup plus nombreux qu'on ne
le pense parce que dans OSM, il est plus difficile d'avoir un suivi
des transformations sur une zone que wikipedia sur un article. Et les
outils de contrôle ont aussi des lacunes (voir dernier point) Si, par
exemple, on peut voir une version T-n_days dans wikipedia en 2 clics
de souris, retrouver les données d'une zone géographique à T-n_days
dans OSM nécessite beaucoup de temps, de ressources et connaissances
informatiques. Et pour le cas où un petit vandalisme ou disons,
"altération négative" lorsque ça n'est pas volontaire, est détecté, il
n'y a pas d'outil pour facilement revenir en arrière alors que le
"undo" sur wikipedia se fait en deux clics de souris. Il y a donc un
déséquilibre manifeste entre contributions positives et négatives
puisque les outils manquent pour lutter contre les secondes.  On peut
alors assister à deux phénomènes : soit le contributeur abandonne le
projet suite à une frustration légitime. Ou alors, il "délègue" cette
tâche à d'autres, en passant par cette liste par exemple ou sur un
forum ou par le DWG. C'est ce qui se passe plus ou moins bien depuis
les débuts d'OSM et certains sont même satisfait de ce modèle. Mais
cela ne marche que s'il y a suffisament de volontaires pour prendre en
charge ces annulations et que si elles se font suffisament tôt
(techniquement, plus on attends, plus c'est difficile, voire
impossible). Et si le nombre de vandalismes venait à fortement
augmenter, ce petit groupe ne sera plus capable de faire face. Un des
gros points forts de wikipedia est que les annulations sont
directement et facilement accessibles par tout le monde. C'est un
point majeur pour les projets collaboratifs qu'OSM ne propose pas.
- "sémantique" : les tags sont nombreux dans OSM, trop nombreux. Les
erreurs de typo ne sont que lentement corrigés, voir pas du tout. Il y
a, par exemple, 910 valeurs différentes de "highway" et 983 valeurs
différentes de "landuse" alors qu'il y en a 20 fois moins de
documentés. Un autre point est que les tags sont facilement mal
interprétés d'un pays à l'autre ("amenity=college" , "power=station"),
mal utilisés ("leisure=park" pour une plate-bande de fleurs) ou ne
sont pas cohérents, même à l'intérieur d'une zone géographique (chacun
a sa propre interprétation d'un "highway=tertiary" ou du
"highway=path"). Ainsi, si dans wikipedia, on appelle un chat "un
chat", dans OSM, une voie se verra affubler d'un
"highway=residential", "highway=unclassified", "highway=track" ou même
dans certains cas "highway=service" au choix et suivant le
contributeur sans que cela ne soulève de protestations. J'ajouterais
qu'une grande partie de ces problèmes ne sont pas détectables par des
outils de qualité et qu'il faut mettre son nez dedans pour les trouver
et ne pas tout voir au travers de la lorgnette d'osmose ou de
keepright.
- le "contrôle" : bien peu sont ceux qui contrôlent les données OSM en
les téléchargeant dans JOSM. Alors que dans wikipedia, tout ce qui
ajouté "se voit" immédiatement par tout lecteur, la plupart des
erreurs dans OSM ne sont corrigées que si elles sont "visibles" donc
"rendues" sur la carte principale. Les autres sont ignorées jusqu'à ce
qu'un contributeur s'y intéresse, souvent par hasard, en passant en
mode "édition" et qu'il voit soudainement l'ensemble des données.

Pieren

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia

[Ista Pouss]

Le 29 octobre 2013 19:44, Guillaume Allegre  a
écrit :

> Merci pour vos encouragements.
> Voici donc la suite, un peu plus polémique (forcément), et parfois
> franchement provoc (et sans doute un peu trop long)
>
> http://gallaxie.wordpress.com/2013/10/28/openstreetmap-vs-wikipedia-23-differences-et-divergences/
>
>
BIEN. VIFS ENCOURAGEMENTS.


-- 
Les dérives de rue :
C’est chanter que je veux 

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Discussions WMFr] Re: OpenStreetMap vs Wikipedia

[Guillaume Allegre]

Le lun. 21 oct. 2013 à 10:21 +0200, Florence Devouard a écrit :
> On 10/20/13 7:54 PM, Guillaume Allegre wrote:

> Twitté car un excellent résumé. J'attend avec impatience la deuxième
> partie du tryptique !
> 
> Flo


Le lun. 21 oct. 2013 à 10:43 +0200, Nicolas Moyroud a écrit :
> Merci pour cet excellent article Guillaume. D'une manière générale,
> je trouve que ce blog démarre fort ! J'aime le ton décalé qui fait
> qu'on apprend des choses en s'amusant. J'ai aussi lu le billet sur
> l'unicode et les 5 libertés du logiciel libre. Excellent le tableau
> de synthèse des libertés atomiques.
> On veut plus de billets !! ;-)
> 

Merci pour vos encouragements. 
Voici donc la suite, un peu plus polémique (forcément), et parfois
franchement provoc (et sans doute un peu trop long)
http://gallaxie.wordpress.com/2013/10/28/openstreetmap-vs-wikipedia-23-differences-et-divergences/



-- 
 ° /\Guillaume AllègreOpenStreetMap France
  /~~\/\   allegre.guilla...@free.fr  Cartographie libre et collaborative
 /   /~~\tél. 04.76.63.26.99  http://www.openstreetmap.fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr