Re: [OSM-talk-fr] Google maps condamné en France pour abus de position dominante

[Mikaël Cordon]

Je viens de voir également cet article sur FranceTV.fr et le terme « libre
» dans cette situation m’a également choqué.

Pieren m’a juste devancé de quelques minutes :)

Le 1 février 2012 15:32, Pieren  a écrit :

> Le tribunal de commerce de Paris estimant que Google Maps fausse la
> concurrence en fournissant son service gratuitement, a condamné la
> société Google à 500.000€ de dommages et intérêts au bénéfice de la
> société plaignante "Bottin Cartographes" (et 15.000€ d'amende). Un
> porte-parole de Google s'exprime en réaction pour dire qu' "un outil
> cartographique de haute qualité, libre, et gratuit est bénéfique tant
> pour les internautes que pour les propriétaires de site web". Le terme
> "libre" a été aussitôt corrigé par Camille Gévaudan dans son billet
> sur ecrans.fr (
> http://www.ecrans.fr/Google-Maps-condamne-en-France,13992.html)
> et n'a pas raté - encore une fois - une occasion de citer
> OpenStreetMap. Bravo et merci Camille.
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>


Cartographiquement,
-- 
Mikaël Cordon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Traduction des toponymes et lieux assistée par Wikipedia

[Mikaël Cordon]

salut,

Juste une idée qui m’a traversé l’esprit quand j’ai vu passer les mots «
traduction en plusieurs langues »…
Il existe un projet/site de traduction communautaire basé sur une solution
libre : Tatoeba (http://tatoeba.org/)

Actuellement, les traductions ne concernent par les toponymies, mais
peut-être qu’il y a un sujet à développer autour de ça ?

Qu’en pensez-vous ?

Le 9 février 2012 11:18, Vincent de Chateau-Thierry  a
écrit :

>
> > De : "Pieren"
>
> > 2012/2/9 Ab_fab
> >
> > >
> > > (et qui plus est inutile puisque dans la même langue)
> > >
> > >
> > >
> > Cet outil ne devrait pas ajouter de "name:fr" en France. C'est
> > contre-productif et dangereux (doublon, risque de dichotomie, à
> l'encontre
> > des pratiques actuelles et des éditeurs).
> > Moi, je serais partisan de les supprimer systématiquement dans
> l'hexagone.
> >
>
> Dans l'hexagone d'accord, mais peut-être pas au bord :-)
>
> Taginfo France compte un millier de name:fr :
> http://taginfo.openstreetmap.fr/keys/name:fr#values
>
> et les 3 valeurs les plus récurrentes sont sur des objets frontaliers :
> "Frontière franco-suisse", "Le Rhin" et "La Moselle".
>
> == début de HS ==
> Cela dit, on peut de demander si sur une limite administrative, le tag
> "name" tout court
> est pertinent. Pour moi non, il devrait être déduit des noms des emprises
> administratives auxquelles il participe, et pas stocké en dur. Libre à
> chaque utilisateur
> de construire le nom qu'il veut, dans la langue qu'il veut, et avec le
> niveau
> administratif qu'il souhaite.
> == fin de HS ==
>
> vincent
>
> Une messagerie gratuite, garantie à vie et des services en plus, ça vous
> tente ?
> Je crée ma boîte mail www.laposte.net
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>


Cordialement,
-- 
Mikaël Cordon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Encore du SVG

[Mikaël Cordon]

Excellent…

Ne serait-ce que la carte interactive et ses différentes projections : je
me suis amusé avec pendant plusieurs minutes :)

Le 6 mars 2012 20:30, yvecai  a écrit :

> **
> Effectivement !
>
> Le 06/03/2012 20:01, Ab_fab a écrit :
>
> Prometteur :
> http://kartograph.org/
>
> --
> ab_fab <http://wiki.openstreetmap.org/wiki/User:Ab_fab>
> "Il n'y a pas de pas perdus"
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>

Cordialement,
-- 
Mikaël Cordon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] JOSM : pas de truc pour trackpad ?

[Mikaël Cordon]

Salut,

Avec un autre contributeur (Amargein), on s'est posé la question pour naviguer 
dans la carte de JOSM avec un trackpad d'ordi portable…

On a longtemps cherché, les meilleures solutions du moment fussent :
— installer le plugin « touchscreenhelper » et activer le mode déplacement en 
cliquant dessus (pas de raccourcis clavier possible apparemment)
— brancher une souris USB et utiliser classiquement le clic droit de la souris 
pour naviguer…

Désormais, j'ai une autre solution, la solution qu'on attendait, une 
combinaison de taps permettant d'émuler le clic droit souris et déplacer la 
carte :
— sur le trackpad, à la vitesse du double-clic : clic-droit, clic-gauche (sans 
relâcher) et glisser ; 
— soit donc sur mon trackpad en deux mouvements à la vitesse du double-tap : 
(1) tap-deux-doigts, (2) reposer un doigt et glisser.


Cordialement,
--
mickey86, Mikaël Cordon

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

Re: [OSM-talk-fr] JOSM : pas de truc pour trackpad ?

[Mikaël Cordon]

Ton mouvement ne fonctionne pas chez moi (GNU/Linux + KDE, Synaptiks)…

Le mouvement que j'ai trouvé n'est pas si compliqué, en revanche je l'ai peut-
être mal expliqué. Je retente :

Le mouvement pour déplacer la carte JOSM est sur la même base que le clic&drag 
pour déplacer des objets (une icône ou pour copier un fichier avec le 
pointeur…) à la différence que le clic se fait avec deux doigts.

Cordialement,
--
mickey86, Mikaël Cordon

Le dimanche 13 mai 2012 22:28:04 Philippe Verdy a écrit :
> Pas très facile à faire comme mouvement...
> 
> Personnellement je pense qu'il est plus facile de poser un doigt, le
> laisser posé pendant qu'on pose un second doigt, pour relever le
> premier sans lacher le second, qui sera utilisé pour glisser.
> 
> Sur une échelle de temps, lue de haut en bas, tandis
> qu'horisontalement on visualise les doigts posés, ça donne dans un
> temps assez court mais avec une gestuelle très facile à faire avec
> deux doigts de la même main (par exemple index et majeur, ou pouce et
> index), et c'est compatible pour gauchers ou droitiers :
> 
> :
> :O
> :O
> :O O
> :O O
> :O
> :O
> 
> Rendu à ce point, ce n'est encore considéré que comme un clic droit
> non relaché (à la position du second doigt).
> 
> - Si on relache tout de suite ce second doigt, c'est comme un simple
> clic droit de souris qui active le menu contextuel sur l'objet tapé).
> - On peut continuer à glisser le second doigt pour faire un glissement
> (dans JOSM ce serait faire glisser toute la carte et non pas déplacer
> un objet sur le fond de carte).
> 
> Ça marche bien à condition que la tablette tactile détecte les entrées
> "multitouche" (ce que suppose aussi la gestuelle que tu proposes).
> 
> Sinon, autant appuyer sur une touche du clavier en même temps qu'une
> tape simple sur la tablette.
> 
> -- Philippe.
> 
> Le 13 mai 2012 11:24, Mikaël Cordon  a écrit :
> > Salut,
> >
> > Avec un autre contributeur (Amargein), on s'est posé la question pour 
naviguer dans la carte de JOSM avec un trackpad d'ordi portable…
> >
> > On a longtemps cherché, les meilleures solutions du moment fussent :
> > — installer le plugin « touchscreenhelper » et activer le mode déplacement 
en cliquant dessus (pas de raccourcis clavier possible apparemment)
> > — brancher une souris USB et utiliser classiquement le clic droit de la 
souris pour naviguer…
> >
> > Désormais, j'ai une autre solution, la solution qu'on attendait, une 
combinaison de taps permettant d'émuler le clic droit souris et déplacer la 
carte :
> > — sur le trackpad, à la vitesse du double-clic : clic-droit, clic-gauche 
(sans relâcher) et glisser ;
> > — soit donc sur mon trackpad en deux mouvements à la vitesse du double-tap 
: (1) tap-deux-doigts, (2) reposer un doigt et glisser.
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Smartphone Android avec GPS rapide?

[Mikaël Cordon]

Salut,

Personnellement, j’ai un LG Nexus 4, et le GPS m’impressionne (par rapport
à mon précédent smartphone), il fixe rapidement les satellites (je dirais
pas plus de 10-15 sec selon les conditions en extérieur) et utilise
beaucoup de satellites (toujours par rapport à mon précédent) ! Pour une
précision de 2,5m selon OSMTracker et les conditions.

Cordialement,
--
Mikaël Cordon, mickey86


Le 12 septembre 2013 01:12, Shohreh  a écrit :

> OSMTracker est l'appli Android recommandée comme moyen simple et rapide
> d'ajouter/corriger des données dans OSM, sur place ou une fois connecté à
> un
> ordi?
>
> https://code.google.com/p/osmtracker-android/
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Smartphone-Android-avec-GPS-rapide-tp5777133p5777242.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> 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] Membre du DWG

[Mikaël Cordon]

Salut,


Félicitations pour ton poste de stagiaire dans le mirador d’OSM…


Plus sérieusement, ça fait froid dans le dos… Pour un projet communautaire,
où, à mon avis, devrait régner un sentiment d’équité entre tous les
membres, une autorité pyramidale semble bien établie, et semble aussi être
révélée une fois que tu es dedans : je ne m’imaginais pas que tu serais
aussi contraint une fois admis au sein du groupe clan.

Bon courage, :/

--
Mikaël Cordon, mickey86


Le 13 novembre 2012 16:32, sly (sylvain letuffe)  a
écrit :

> Salut,
>
> En une phrase : ça y est, je suis membre.
>
> En plusieurs :
> - je ne peux pas intervenir pour bloquer pour l'instant (mais ça devrait
> venir
> quand j'aurais un peu mieux compris comment ils fonctionnent)
>
> - je suis membre de la liste privée et du système de suivi par ticket des
> différents cas de problèmes repérés sur les données
>
> - Je suis admis mais n'ai aucune obligation de bloquer des contributeurs en
> france sous le prétexte du 2ème compte pour les imports (eux continuerons
> à le
> faire bien sûr)
>
> - je ne suis pas considéré comme représentant de quoi que ce soit, mais
> j'ai
> bien indiqué que nous avons notre propre groupe de gestion des problèmes,
> que
> sur cette liste ici des cas sont souvent remontés qu'il nous faut gérer et
> ça
> ne semble pas leur poser de problème que je sois le rapporteur de la
> situation
> avec nos conclusions, mais en gros, c'est pas parceque je me pointe en
> disant
> : Lui on ne le bloque pas car 20 personnes dernière moi me soutiennent que
> ça
> fera 20 voix à opposer aux leurs (juste 1)
>
> - Mauvaise nouvelle (que je ne comprends pas et j'ai demandé pourquoi sans
> réponses) : Ils ne veulent pas de christian. C'est un peu con, car j'ai
> l'intention de prendre des vacances des fois et si un cas doit être réglé
> rapidement, ben ça obligera à les contacter eux alors que christian aurait
> pû
> gérer quand je ne suis pas dispo, et moi quand il ne l'est pas.
>
>
>
>
> --
> sly (sylvain letuffe)
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Carte Nokia, le sandwich est offert…

[Mikaël Cordon]

Salut les OSMeurs,

Je viens de le voir passer, alors j’en fais profiter la communauté :

Nokia sort sa carte : here.net

Du vu et revu, sauf peut-être le « sandwich terrien » (sic) :)

Cordialement,
--
Mikaël Cordon, mickey86
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Carte Nokia, le sandwich est offert…

[Mikaël Cordon]

@Nicolas :
Je me doutais que comme l’information n’était pas apparue ce jour dans la
liste de diffusion que ce n’était pas un scoop… Confirmé ;)
(Je n’utilise pas Flickr, ou en tout cas je n’ai pas remarqué)

@Eric :
Oui, c’est clair, il me semble que c’est Navteq qu’il y a derrière ça…
Lorsque j’ai vu la carte, je me suis empressé d’aller voir mon quartier qui
n’apparaît que sur OSM ; et j’ai eu le malsain bonheur de voir que le
quartier était vide ! Ouf :P

Cordialement,
--
Mikaël Cordon, mickey86


Le 14 novembre 2012 12:41, Eric  a écrit :

> Y'a vachement de consanguinité dans tous ces fournisseurs quand même, je
> retrouve chez bcp les mêmes erreurs (des chemins difficilement faisables en
> VTT représentés comme des routes goudronnées). Ca m'amuserait bien de voir
> un "google car", une "mappy car" ou une "navteq car" essayer d'y passer :)
> C'est pas bien de copier.
>
>
> Le 14 novembre 2012 12:34, Nicolas Dumoulin <
> nicolas_openstreetmap@dumoulin63.net> a écrit :
>
> Le mercredi 14 novembre 2012 12:23:04 Mikaël Cordon a écrit :
>> > Salut les OSMeurs,
>>
>> Salut :-)
>>
>> > Je viens de le voir passer, alors j’en fais profiter la communauté :
>> >
>> > Nokia sort sa carte : here.net
>>
>> C'est pas si nouveau, puisque Flickr utilise la carte de Nokia justement.
>>
>> --
>> Nicolas Dumoulin
>> http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Carte Nokia, le sandwich est offert…

[Mikaël Cordon]

@Pierre :
C’est d’ailleurs cet article qui a été à l’origine de ce sujet :)

Comme bien souvent dans ce genre d’article c’est dans les commentaires
qu’on voit apparaître OSM, dommage.
Ceci dit, il me semble que de plus en plus d’articles font mention d’OSM
(dans le coprs de l’article), même si ça reste rare.

Cordialement,
--
Mikaël Cordon, mickey86


Le 14 novembre 2012 15:22, Pierre Béland  a écrit :

> Mikaël Cordon 
> Mercredi 14 novembre 2012 6h23
> **
>
> > Nokia sort sa carte : here.net
>
> Il y a aussi cet article du Figaro où on oublie OSM dans la liste des
> concurrents.
>
>
> http://www.lefigaro.fr/hightech/2012/11/13/01007-20121113ARTFIG00640-nokia-lance-un-rival-de-google-maps-sur-pc-et-smartphones.php
>
>
> Pierre
>
>   --
> *De :* Mikaël Cordon 
> *À :* Discussions sur OSM en français 
> *Envoyé le :* Mercredi 14 novembre 2012 6h23
> *Objet :* [OSM-talk-fr] Carte Nokia, le sandwich est offert…
>
> Salut les OSMeurs,
>
> Je viens de le voir passer, alors j’en fais profiter la communauté :
>
> Nokia sort sa carte : here.net
>
> Du vu et revu, sauf peut-être le « sandwich terrien » (sic) :)
>
> Cordialement,
> --
> Mikaël Cordon, mickey86
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Gérer l'empilement de bâtiments

[Mikaël Cordon]

Salut,

Intuitivement, je dirais en utilisant la balise layer=*… ?

Cordialement,
--
Mikaël Cordon, mickey86


Le 16 novembre 2012 09:22, Jean-Francois Nifenecker <
jean-francois.nifenec...@laposte.net> a écrit :

> Bonjour,
>
> je suis en train de corriger les erreurs de bâtiments se recouvrant. J'ai
> bien avancé (le grand Sud-Ouest est presque complètement traité ;)
> Merci Osmose !
>
> Il me reste un type de bâtiments que je ne sais pas intégrer : les
> bâtiments "empilés". Par exemple, un grand bâtiment en RdC et une portion
> plus petite s'élevant à partir du 1er.
>
> Cas d'espèce : la cité administrative à Bordeaux
> http://www.openstreetmap.org/?**mlat=44.84117&mlon=-0.60185&**
> zoom=17&layers=M<http://www.openstreetmap.org/?mlat=44.84117&mlon=-0.60185&zoom=17&layers=M>
> avec un bâtiment de 3-4 étages sur toute la surface, au-dessus duquel
> s'élèvent deux tours de 20 étages.
>
> Les tours de contrôle des aéroports peuvent aussi faire partie de ces cas.
>
> Ma première option serait de ne considérer que l'emprise au sol et donc
> d'ignorer la partie "tour". Ceci aurait néanmoins un inconvénient en ce que
> la représentation 3D qui pourrait par la suite être ajoutée ne serait plus
> possible/fiable.
>
> Des idées ?
> --
> Jean-Francois Nifenecker, Bordeaux
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr<http://lists.openstreetmap.org/listinfo/talk-fr>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Suppression des tirets cadratins

[Mikaël Cordon]

Je n’ai pas l’habitude de rentrer dans des sujets chauds aussi tôt dans la
conversation… Mais comme je me sens un peu visé par le sujet — en effet,
j’utilise la typographie française aussi précisément que je peux — je me
permets d’intervenir en faveur du cadratin.

>Et je ne vois pas le problème à avoir une typo première version avec les
caractères les plus accessibles à tous (-) et un maniaque derrière qui
remettra une couche avec le beau tiret cadratin.
+1, sachant que ce caractère n’est pas que « beau », mais surtout
sémantique (terme souvent repris dans la base OSM).

De plus, lors d’un traitement automatique de la typographie — qui est
inévitable pour un rendu homogène —, j’imagine tout à fait que l’algorithme
gère les espaces multiples, ou les manques d’espaces ; et dans le cas «
Maisons-Alfort - Stade » il me semble bien plus compliqué de savoir si les
espaces sont trop nombreux ou qu’ils manquent ; alors qu’avec «
Maisons-Alfort — Stade » l’ambiguïté est levée et le traitement des espaces
est trivial.

D’autre part, on a souvent entendu à propos de la base OSM qu’elle doit
être, d’une part uniforme, mais aussi préserver les spécificités ; et là,
il s’agit clairement d’une spécificité de la langue française (je ne
saurais dire si ce caractère a cours dans d’autres langues).

Comme l’a justement fait remarqué Philippe, les balises name=* sont les
noms locaux/officiels (rayez la mention que vous voulez) des objets
auxquels ils sont attachés ; et en tant qu’objets français, ils se doivent
être écrits en français. Et même si ce ne sont pas des « codes », avec la
typographie qui va bien, leur décodage selon les règles de la langue locale
(ici le français) peut tout à fait être systématisé et automatique.

Enfin, je rajouterai que je suis également adepte de l’utilisation des
différentes espaces (fines, insécables, etc…), l’apostrophe française et
des guillemets français.

Ceci dit, je n’imposerai jamais à notre communauté française de
cartographieurs OSM ces subtilités ; mais de l’autre côté, je ne souhaite
pas me voir imposer la non utilisation de ces subtilités, qui, je le
rappelle, lèvent bon nombre d’ambiguïtés !

Cordialement,
--
Mikaël Cordon, mickey86


Le 29 novembre 2012 09:56, JB  a écrit :

> **
>
> Bof, est-ce qu'un néophyte de la typo aura plus tendance à écrire «
> Maisons-Alfort - Stade » que « Maisons-Alfort—Stade » ou
> « Maisons-Alfort-Stade » ? Il ne comprendra pas plus la différence entre «
> Maisons-Alfort - Stade » et « Maisons-Alfort-Stade » qu'entre «
> Maisons-Alfort - Stade » et « Maisons-Alfort—Stade ».
>
> Et je ne vois pas le problème à avoir une typo première version avec les
> caractères les plus accessibles à tous (-) et un maniaque derrière qui
> remettra une couche avec le beau tiret cadratin.
>
> On répète à qui veut l'entendre d'utiliser les bons tags et que c'est aux
> moteurs de rendus de s'adapter, je ne vois pas pourquoi on changerait cette
> règle quand on passe à la typographie.
>
> JB
>
>
>
> Le 29.11.2012 09:19, Vladimir Vyskocil a écrit :
>
> On 28 nov. 2012, at 19:20, Pieren  wrote:
>
> Si on veut distinguer deux entités, on peut aussi bien mettre des espaces
> avant et après le tiret pour lever toute ambiguité ("Maisons-Alfort -
> Stade" est assez clair).
>
> Ce compromis me semble tout à fait acceptable car il résout à la fois le 
> problème sémantique et l'utilisation de caractères typographique 
> "ésotériques" pour 99.5% des contributeurs.
>
> Vlad.
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Suppression des tirets cadratins

[Mikaël Cordon]

>Oui cela pourrait être une bonne façon d'entrer les données dans la base,
le "/" serait alors un séparateur de liste et " - " représenterait l'union.
>Ensuite libre au moteur de rendu d'afficher ça de la bonne manière.

Attention, le caractère « / » a sa propre signification. Et pour les
cartographieurs qui reproduisent scrupuleusement les panneaux, « / » a pour
signification dans des version abrégées de « sur ». Exemple : « Argenton /
Creuse » ou « Argenton s/ Creuse », signifiant « Argenton sur Creuse » ;
qui deviendrait alors « Argenton — Creuse » ayant une toute autre
signification.

Cordialement,
--
Mikaël Cordon, mickey86


Le 29 novembre 2012 11:09, Mikaël Cordon  a écrit :

> Je n’ai pas l’habitude de rentrer dans des sujets chauds aussi tôt dans la
> conversation… Mais comme je me sens un peu visé par le sujet — en effet,
> j’utilise la typographie française aussi précisément que je peux — je me
> permets d’intervenir en faveur du cadratin.
>
> >Et je ne vois pas le problème à avoir une typo première version avec les
> caractères les plus accessibles à tous (-) et un maniaque derrière qui
> remettra une couche avec le beau tiret cadratin.
> +1, sachant que ce caractère n’est pas que « beau », mais surtout
> sémantique (terme souvent repris dans la base OSM).
>
> De plus, lors d’un traitement automatique de la typographie — qui est
> inévitable pour un rendu homogène —, j’imagine tout à fait que l’algorithme
> gère les espaces multiples, ou les manques d’espaces ; et dans le cas «
> Maisons-Alfort - Stade » il me semble bien plus compliqué de savoir si les
> espaces sont trop nombreux ou qu’ils manquent ; alors qu’avec «
> Maisons-Alfort — Stade » l’ambiguïté est levée et le traitement des espaces
> est trivial.
>
> D’autre part, on a souvent entendu à propos de la base OSM qu’elle doit
> être, d’une part uniforme, mais aussi préserver les spécificités ; et là,
> il s’agit clairement d’une spécificité de la langue française (je ne
> saurais dire si ce caractère a cours dans d’autres langues).
>
> Comme l’a justement fait remarqué Philippe, les balises name=* sont les
> noms locaux/officiels (rayez la mention que vous voulez) des objets
> auxquels ils sont attachés ; et en tant qu’objets français, ils se doivent
> être écrits en français. Et même si ce ne sont pas des « codes », avec la
> typographie qui va bien, leur décodage selon les règles de la langue locale
> (ici le français) peut tout à fait être systématisé et automatique.
>
> Enfin, je rajouterai que je suis également adepte de l’utilisation des
> différentes espaces (fines, insécables, etc…), l’apostrophe française et
> des guillemets français.
>
> Ceci dit, je n’imposerai jamais à notre communauté française de
> cartographieurs OSM ces subtilités ; mais de l’autre côté, je ne souhaite
> pas me voir imposer la non utilisation de ces subtilités, qui, je le
> rappelle, lèvent bon nombre d’ambiguïtés !
>
> Cordialement,
> --
> Mikaël Cordon, mickey86
>
>
> Le 29 novembre 2012 09:56, JB  a écrit :
>
> **
>>
>> Bof, est-ce qu'un néophyte de la typo aura plus tendance à écrire «
>> Maisons-Alfort - Stade » que « Maisons-Alfort—Stade » ou
>> « Maisons-Alfort-Stade » ? Il ne comprendra pas plus la différence entre «
>> Maisons-Alfort - Stade » et « Maisons-Alfort-Stade » qu'entre «
>> Maisons-Alfort - Stade » et « Maisons-Alfort—Stade ».
>>
>> Et je ne vois pas le problème à avoir une typo première version avec les
>> caractères les plus accessibles à tous (-) et un maniaque derrière qui
>> remettra une couche avec le beau tiret cadratin.
>>
>> On répète à qui veut l'entendre d'utiliser les bons tags et que c'est aux
>> moteurs de rendus de s'adapter, je ne vois pas pourquoi on changerait cette
>> règle quand on passe à la typographie.
>>
>> JB
>>
>>
>>
>> Le 29.11.2012 09:19, Vladimir Vyskocil a écrit :
>>
>> On 28 nov. 2012, at 19:20, Pieren  wrote:
>>
>> Si on veut distinguer deux entités, on peut aussi bien mettre des espaces
>> avant et après le tiret pour lever toute ambiguité ("Maisons-Alfort -
>> Stade" est assez clair).
>>
>> Ce compromis me semble tout à fait acceptable car il résout à la fois le 
>> problème sémantique et l'utilisation de caractères typographique 
>> "ésotériques" pour 99.5% des contributeurs.
>>
>> Vlad.
>> ___
>> Talk-fr mailing 
>> listTalk-fr@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Suppression des tirets cadratins

[Mikaël Cordon]

@Vladimir : je suis d’accord que mon exemple n’était pas le plus réfléchi,
il est limite puisqu’effectivement les abréviations ne sont pas souhaitées.
Ceci dit, il y a beaucoup de choses non souhaitées dans la base OSM :).

Surtout ce que je voulais soulever, c’est que les caractères ont une
signification bien établie ; et qu’il est dommage et risqué quant à en
changer le sens localement. Pourquoi ne pas utiliser directement le bon
caractère ?

J’ai pour habitude, en cas de doute, d’appauvrir l’information plutôt que
mettre une information ambiguë, ou pire, fausse.

Cordialement,
--
Mikaël Cordon, mickey86


Le 29 novembre 2012 11:24, Vladimir Vyskocil
a écrit :

>
> On 29 nov. 2012, at 11:15, Mikaël Cordon  wrote:
>
> > >Oui cela pourrait être une bonne façon d'entrer les données dans la
> base, le "/" serait alors un séparateur de liste et " - " représenterait
> l'union.
> > >Ensuite libre au moteur de rendu d'afficher ça de la bonne manière.
> >
> > Attention, le caractère « / » a sa propre signification. Et pour les
> cartographieurs qui reproduisent scrupuleusement les panneaux, « / » a pour
> signification dans des version abrégées de « sur ». Exemple : « Argenton /
> Creuse » ou « Argenton s/ Creuse », signifiant « Argenton sur Creuse » ;
> qui deviendrait alors « Argenton — Creuse » ayant une toute autre
> signification.
>
> Ok, une autre convention pourrait être trouvée mais l'exemple cité n'est
> pas bon car il ne faudrait pas entrer de versions abrégées des noms dans la
> base car la aussi c'est au moteur de rendu ou de recherche dans les données
> de faire les abréviations à la volée si besoin (autre débat, assez chaud
> chez les américains par exemple...)
>
> >
> > Cordialement,
> > --
> > Mikaël Cordon, mickey86
>
> cordialement,
> Vladimir.
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Suppression des tirets cadratins

[Mikaël Cordon]

Je suis entièrement d’accord du point de la séparation donnée/rendu.

Le but du jeu c’est de pouvoir comprendre la donnée de façon univoque !
On sait que tant que ce seront des humains qui saisiront des données dans
la base, il y aura des erreurs. Et les erreurs sont d’autant plus
nombreuses qu’elles ne sont pas clairement visibles (je parle ici des
espaces) ; ou que les règles sont méconnues.

Beaucoup d’algorithmes automatiques sont justement là pour corriger ou
pallier à ces erreurs. Ils font des merveilles pour rajouter ou supprimer
des espaces ou de la ponctuation devant tel ou tel caractère, changer la
casse (Rue saint-Antoine), même reconnaître des erreurs évidentes telles
que « aveneu » à la place de « avenue ».

Seulement voilà, ces algorithmes ont leurs limites devant une ambiguïté
telle que « Maisons-Alfort - Stade » ; je trouve que tenter de lever une
ambiguïté à l’aide de l’espace qui est un caractère particulièrement enclin
à générer des erreurs n’est pas du tout judicieux.

Les lettres, les articles de journaux, et autres éditions françaises ne
sont pas traités automatiquement comme le sont les données d’OSM ; dans les
journaux, c’est l’humain au final qui lève les ambiguïtés grâce à sa
mémoire colossale et sa capacité de reconnaissance à la volée ; les
algorithmes automatiques d’aujourd’hui ne sont pas capable d’un tel prodige
à moins d’efforts démesurés pour les concevoir (parole de développeur).

La base OSM est tellement grosse, que malgré la puissance du cerveau humain
personne ne peut corriger la base. Et quand bien même il le pourrait, vu
que c’est un humain, il fera des erreurs. Donc, c’est bien un algorithme
qui traitera toutes ces données si on veut supprimer les erreurs.

Je pense qu’on ne peut pas demander aux contributeurs bienveillant
d’appauvrir leurs données sous prétexte que la majorité ne peuvent pas
atteindre cette précision ; d’autant que cette précision est bénéfique et
utilisable. Et là, je ne parle pas que de typographie !

Je pense qu’utiliser les bons caractères au bon endroit est un bonus !

Cordialement,
--
Mikaël Cordon, mickey86



Le 29 novembre 2012 11:53, Pieren  a écrit :

> 2012/11/29 Mikaël Cordon :
>
> > Enfin, je rajouterai que je suis également adepte de l’utilisation des
> > différentes espaces (fines, insécables, etc…), l’apostrophe française et
> des
> > guillemets français.
>
> Ceci explique cela ;-)
> Je remarque qu'il y a parmi le public des contributeurs français une
> très petite minorité d'adeptes de la belle typographie française, qui
> en connaissent les règles et les moyens de saisie. D'ailleurs, ils
> viennent souvent de wikipedia. Mais le tag "name" n'est pas un article
> wikipedia, le tag "name" ne sert pas à imprimer les panneaux de
> signalisation, le tag "name" n'a pas à respecter les règles
> typographiques des imprimeurs. Parce que dans OSM, on sépare donnée
> factuelle et rendu. OSM, c'est de la donnée brute pour le monde
> entier. Et il n'y a qu'en France que je vois autant de tirets longs
> pour faire de la sémantique. Alors que oui, ce caractère existe dans
> tous les pays, même en chinois (—— 破折号) mais il risque de ne pas avoir
> le même emploi !
> On a déjà discuté règles typographiques ici et on a constaté que 1.
> elles étaient en contradiction avec les règles de toponymie ("Rue
> Saint-Antoine" devrait s'écrire "Rue saint-Antoine") 2. qu'il n'y
> avait pas de standard universel même en France puisque l'académie a
> ses règles, les grands journaux ont les leurs, les éditeurs/imprimeurs
> aussi, etc-
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Suppression des tirets cadratins

[Mikaël Cordon]

Se dépatouiller avec des bizarreries… On se demande ce qui est bizarre ou
ce qui est normal.

Il faut savoir que certaines (un certain nombre) implémentations de la
reconnaissance de motifs par expressions régulières dans le monde UTF-8 (en
perl, php, extension SQL et sûrement d’autres langages) permettent de
reconnaître des classes de caractères : les espaces, les séparateurs,
caractères de groupement (parenthèses, crochets, etc…), ponctuations,
chiffres, caractères de citation, les caractères accentués, les caractères
en haut de casse, etc… indépendamment de la langue ; ce sont des propriétés
des caractères.

Et j’insiste sur le fait qu’il serait une erreur d’imposer l’utilisation de
ces fameux caractères, puisque tout le monde ne les connaissent pas, et ne
peuvent les saisir !
Mais dès lors qu’ils enrichissent les données et qu’ils peuvent être
exploités, ils ne doivent pas être bannis.

Cordialement,
--



Le 29 novembre 2012 15:13, Vladimir Vyskocil
a écrit :

>
> On 29 nov. 2012, at 12:45, Philippe Verdy  wrote:
>
> > Ce qui se complique encore quand les toponymes ***officiels*** espagnols
> utilisent le "/" pour séparer les noms ***co-officiels*** issus de
> plusieurs langues, ces deux langues ***devant*** toujours être citées
> ensembles et dans l'ordre indiqué sans qu'on puisse en supprimer un ! C'est
> alors le même toponyme dans les langues d'origine, les différences
> linguistiques étant alors abolies dans la dénomination officielle pour la
> même entité (regardez le Pays Basque espagnol par exemple).
> >
> > Dans ce cas le "/" ne signifie pas non plus "sur", ***même*** en
> Français. Comment alors faire un traitement automatique de substitution
> "pour faire joli" ?
> >
> > Oui effectivement le "/" a sa propre sémantique dans ce cas, mais on ne
> doit PAS l'utiliser comme s'il s'agissait d'une abréviation, même en
> français.
> >
> > Bref en aucun cas "Argenton / Creuse" ne signifie la même chose que
> "Argenton-sur-Creuse" (ne pas oublier non plus les traits d'union ici !)
> >
> > Car en Espagne et même en français, ce "/" est un séparateur, distingué
> de l'autre séparateur trait d'union qui est aussi utilisé pour juxtaposer
> deux termes mais avec une autre signification.
> >
> > L'idée qu'un moteur de rendu peut librement remplacer la ponctuation est
> totalement erronée, chacune a sa signification propre mais on ne peut pas
> la déduire de la seule façon dont cette ponctuation est codée puisque pour
> cela il faudrait coder ***aussi*** la sémantique.
> >
>
> Dans ce cas c'est le schema qui n'est pas bon et on aurait du partir par
> exemple sur un tag name multi-valué alors que l'on est clairement parti sur
> une solution simpliste qui revient a tagguer pour le rendu : on veut que
> les 2 noms s'affichent côte à côte séparés par un caractère lambda sans
> rien a avoir a changer aux moteurs de rendu actuels...
> Il faut également prendre en compte tous les outils de recherche qui vont
> faire comment pour se dépatouiller avec des données formatés avec des
> demi-espaces insécables ou je ne sais quelle curiosité de la langue
> française ?
>
> Vladimir
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Suppression des tirets cadratins

[Mikaël Cordon]

>si je suis d'accord sur le principe, il reste possible aux tenants de la
simplicité (et ça aussi c'est bien, mangez-en) d'utiliser des tirets
simples partout, à condition de les encadrer d'espaces -- ou non -- selon
le cas.

>On peut donc se contenter de : Champs-Élysées - Clemenceau

Évidemment !
Il n’a jamais été question de contraindre ceux qui ne veulent ou ne peuvent
pas à utiliser une typographie avancée.
Mais, comme on est d’accord qu’une typographie avancée enrichi les données,
il ne faut pas contraindre ceux qui le veulent et le peuvent à ne pas
l’utiliser.

Cordialement,
--
Mikaël Cordon, mickey86


Le 29 novembre 2012 22:08, Jean-Francois Nifenecker <
jean-francois.nifenec...@laposte.net> a écrit :

> Bonjour,
>
> Le 28/11/2012 18:29, te...@free.fr a écrit :
>
>   Champs-Élysées — Clemenceau (avenue des Champs-Élysées, place
>> Clemenceau)
>>
>>
> si je suis d'accord sur le principe, il reste possible aux tenants de la
> simplicité (et ça aussi c'est bien, mangez-en) d'utiliser des tirets
> simples partout, à condition de les encadrer d'espaces -- ou non -- selon
> le cas.
>
> On peut donc se contenter de : Champs-Élysées - Clemenceau
>
> A+
> --
> Jean-Francois Nifenecker, Bordeaux
>
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr<http://lists.openstreetmap.org/listinfo/talk-fr>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] relations boundary modifiées par Philippe Verdy – Tirets

[Mikaël Cordon]

Il me semble qu’on en était resté sur un statu quo ante bellum…

Selon moi, pour résumer et sans vouloir relancer les hostilités, chaque
camp a ses raisons que l’autre a compris (en tout cas je l’espère), et que
globalement, utiliser ou non les différents traits d’union ou tirets ne
change pas fondamentalement les choses :
– utiliser ces fameux tirets spécifiques sont, certes, difficiles à saisir
pour une majorité de contributeurs mais suppriment de nombreuses ambiguïtés
;
– ne pas les utiliser, est trivial, mais introduisent des ambiguïtés qui ne
peuvent pas être efficacement et systématiquement levées.

Cordialement,
--
Mikaël Cordon, mickey86


Le 28 décembre 2012 14:06, JB  a écrit :

> **
>
> C'est marrant, je ne me souviens pas avoir vu de majorité se dégager de la
> discussion sur les tirets et les trait d'union… Pieren avait certes sa
> majorité personnelle avant de lancer la discussion, mais ne semblait
> clairement pas majoritaire après les réponses. Sans qu'une majorité nette
> ne se distingue de l'autre coté non plus.
>
> Le 28.12.2012 14:00, Pieren a écrit :
>
> 2012/12/24 Hendrik Oesterlin :
>
> Dans un premier temps je ne veux pas parler des erreurs avérées dans les
> langues qui lui sont étrangères, et pas non plus des tiret particuliers
> qu'il y ajoute
>
>  Si, si. On en a parlé. Je pense qu'il y a une large majorité qui se
> dégage pour dire que ces tirets longs sont à rejeter pour toutes les
> raisons déjà mentionnées.
>
>
> Pieren
>
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Numéro de rue ?

[Mikaël Cordon]

> Je ne met des adresses sur les polygones que pour les bâtiments
> éloignés de la rue, par exemple dans une résidence avec plusieurs
> immeubles où le cadastre met justement un numéro au milieu du bâtiment
> et pas sur l'entrée.

+1, sauf si une ruelle ou une allée mène au bâtiment :)

Cordialement,
--
Mikaël Cordon, mickey86


Le 3 janvier 2013 23:35, Christian Quest  a écrit :

> Le 3 janvier 2013 22:14, Cyrille Giquello  a écrit :
> > Je viens appuyer l'explication de Romain.
> > Mettre le numéro de la rue au plus près de l'entrée du lieu et non pas
> > sur le bâti. C'est plus facile à trouver et plus simple à mapper,
> > surtout quand il y a plusieurs bâtiments pour la même adresse, ou que
> > le bâti se trouve loin de l'entrée, ou ...
>
> Et ça évite des questions existentielles lorsqu'il y a plusieurs
> bâtiments à la même adresse...
>
> Je ne met des adresses sur les polygones que pour les bâtiments
> éloignés de la rue, par exemple dans une résidence avec plusieurs
> immeubles où le cadastre met justement un numéro au milieu du bâtiment
> et pas sur l'entrée.
>
> --
> Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Demande d'informations

[Mikaël Cordon]

Bonjour Monsieur, Madame,

L'Association Poitevine Pour la Promotion de GNU/Linux et du Logiciel
Libre est un groupe d'utilisateurs de logiciels libres basé à Poitiers.
Parmi nos activités, nous organisons des cartoparties afin de
sensibiliser le public sur l'utilisation et la contribution à Open
Street Map. OSM étant un moyen grand public de montrer l'usage d'un
logiciel libre en dehors de la sphère informatique (web, bureautique,
...) tout en gardant un aspect collaboratif, nous recherchons de la
documentation (brochures...) à distribuer au public pour expliquer au
mieux les buts d'OSM à l'image de celle qu'a réalisé Wikimédia France
pour Wikipédia.

Nos recherches sur le wiki d'OSM et sur le site
http://www.openstreetmap.fr ne nous ont rien donné, peut-être que
c'est quelques chose qui est en gestation au sein de votre association ?

En vous remerciant d'avance de votre réponse, voyez aussi dans cette
demande, le respect que notre association porte à vos actions.

Cordialement,
--
Mikaël Cordon,
Secrétaire de l'APP3L
pour
Francis Ganteaume
Vice-President de l'APP3L
http://www.app3l.org
cont...@app3l.org


signature.asc
Description: This is a digitally signed message part.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Demande d'informations

[Mikaël Cordon]

Le 8 février 2013 20:27, Pieren  a écrit :

> 2013/2/7 Mikaël Cordon :
> > Bonjour Monsieur, Madame,
>
> Bonsoir et bienvenue sur OpenStreetMap et votre soutient apporté au projet.
>

Merci,


>
> Pour de la documentation, on peut en trouver dans le döpôt SVN
> d'osm.org mais il n'est pas de toute première fraicheur :(
> http://svn.openstreetmap.org/misc/pr_material


Nous allons regarder cette documentation, et la mettrons à jour si on
l’utilise et si nécessaire !


>
> Sinon, il doit y avoir des choses dans les archives et certains
> lecteurs de cette présente liste de diffusion, actifs en matière de
> présentations, auront surement de la doc à mettre à disposition.
>

Nous espérons aussi :)

Nous reviendrons faire un petit retour sur cette cartopartie qui s’inscrit
dans une manifestation plus grande à propos de l’open data sur Poitiers.

Cordialement,
--
Mikaël Cordon,
Secrétaire de l’APP3L
et
mickey86,
contributeur OSM


> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Opensnowmap.org

[Mikaël Cordon]

Salut,

> Merci les pistes de Cordon sont aussi dans le bon sens !
Et j'en suis tout à fait ravi :P

Cordialement,
-- 
Mikaël Cordon, mickey86

Le lundi 8 avril 2013 10:31:30, Fabien a écrit :
> Le 7 avril 2013 19:35, yvecai  a écrit :
> > Les skieurs de Super-Besse peuvent maintenant prendre les remontées la tête
> > en haut, et utiliser toute la largeur des pistes.
> > Ils sont, semble-t-il, heureux de cette nouvelle situation.
> 
> Merci les pistes de Cordon sont aussi dans le bon sens !
> 
> Fabien
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
> 


signature.asc
Description: This is a digitally signed message part.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] highway=turning_circle ou highway=* + area=yes?

[Mikaël Cordon]

Salut,

À propos de « noexit=yes » au début ou à la fin d’une rue sans issue
ou sur le chemin, j’attire votre attention sur le fait que lorsqu’on
se retrouve dans la situation d’un branche avec des branchioles (une
rue sans issue avec au moins une autre rue sans issue connectée à
elle), mettre en début ou fin de rue n’est pas équivalent !

Je n’ai pas de préférence, sur la place du « noexit=yes », à vrai
dire, je laisse la topologie décider de ce qui est une voie sans issue
ou non : après tout on ne peut raisonnablement pas justifier toutes
les vérités de la base par un tag supplémentaire ; il ne s’agit pas
ici de toutes les vérités mais seulement les voies sans issues, mais
tout de même, ça soulève la légitimité de ce tag, à mon sens.

D’autre part, le concept de voie sans issue est délicat :
– il dépend du mode de locomotion, une voie peut se révéler sans issue
pour une voiture, mais pas pour un piéton ni un vélo
– est une voie sans issue si le seul moyen de revenir à l’entrée de
cette voie est de rebrousser chemin avec le même véhicule
– une voie sans issue peut contenir des voies avec issue : une boucle
dans une voie sans issue

Je pense que mes remarques vont faire un peu débat, mais je les pense
nécessaires.

Cordialement,
--
Mikaël Cordon, mickey86

Le 24 avril 2013 10:43, Vincent de Chateau-Thierry  a écrit :
> Bonjour,
>
>> De : "Christian Quest"
>>
>> C'est bien au nœud d'extremité que ce tag est le plus utile du côté
>> réutilisation par les outils de contrôle qualité, les principaux (les
>> seuls ?) à trouver une utilité à ce tag.
>>
>
> Ce tag est aussi utile pour les moteurs de calcul d'itinéraire. Il permet 
> simplement,
> en éliminant les _ways_ taggués noexit=yes, de construire un graphe de 
> transit, allégé
> des voies strictement de destination.
> Maintenant, au vu des stats, il est nécessaire d'envisager les 2 
> configurations (sur le
> node de fin et sur le way) si on ne veut pas perdre une masse d'info au 
> moment de
> l'exploiter. La relation entre un way et les nodes qui le constituent est 
> connue, au
> moins via les schémas d'import classique (Osmosis, osm2pgsql). Donc pas 
> besoin de se
> battre sur la meilleure modélisation, à mon avis, les deux se défendent, et 
> aucune ne
> mène à une impasse (hum).
>
> vincent
>
> Une messagerie gratuite, garantie à vie et des services en plus, ça vous 
> tente ?
> Je crée ma boîte mail www.laposte.net
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] highway=turning_circle ou highway=* + area=yes?

[Mikaël Cordon]

Je rajouterai également que lorsqu’une voie sans issue devient une
voie avec issue, il est important de remonter toute la branche (de mon
exemple précédent) pour éliminer le tag « noexit=yes », là où il le
faut… Une voie avec issue, marquée comme sans issue, ça ne le fait pas
: un routeur qui manque un raccourci perd beaucoup de point face à la
concurrence qui l’aura trouvé :)

Cordialement,
--
Mikaël Cordon, mickey86

Le 24 avril 2013 11:31, Mikaël Cordon  a écrit :
> Salut,
>
> À propos de « noexit=yes » au début ou à la fin d’une rue sans issue
> ou sur le chemin, j’attire votre attention sur le fait que lorsqu’on
> se retrouve dans la situation d’un branche avec des branchioles (une
> rue sans issue avec au moins une autre rue sans issue connectée à
> elle), mettre en début ou fin de rue n’est pas équivalent !
>
> Je n’ai pas de préférence, sur la place du « noexit=yes », à vrai
> dire, je laisse la topologie décider de ce qui est une voie sans issue
> ou non : après tout on ne peut raisonnablement pas justifier toutes
> les vérités de la base par un tag supplémentaire ; il ne s’agit pas
> ici de toutes les vérités mais seulement les voies sans issues, mais
> tout de même, ça soulève la légitimité de ce tag, à mon sens.
>
> D’autre part, le concept de voie sans issue est délicat :
> – il dépend du mode de locomotion, une voie peut se révéler sans issue
> pour une voiture, mais pas pour un piéton ni un vélo
> – est une voie sans issue si le seul moyen de revenir à l’entrée de
> cette voie est de rebrousser chemin avec le même véhicule
> – une voie sans issue peut contenir des voies avec issue : une boucle
> dans une voie sans issue
>
> Je pense que mes remarques vont faire un peu débat, mais je les pense
> nécessaires.
>
> Cordialement,
> --
> Mikaël Cordon, mickey86
>
> Le 24 avril 2013 10:43, Vincent de Chateau-Thierry  a écrit 
> :
>> Bonjour,
>>
>>> De : "Christian Quest"
>>>
>>> C'est bien au nœud d'extremité que ce tag est le plus utile du côté
>>> réutilisation par les outils de contrôle qualité, les principaux (les
>>> seuls ?) à trouver une utilité à ce tag.
>>>
>>
>> Ce tag est aussi utile pour les moteurs de calcul d'itinéraire. Il permet 
>> simplement,
>> en éliminant les _ways_ taggués noexit=yes, de construire un graphe de 
>> transit, allégé
>> des voies strictement de destination.
>> Maintenant, au vu des stats, il est nécessaire d'envisager les 2 
>> configurations (sur le
>> node de fin et sur le way) si on ne veut pas perdre une masse d'info au 
>> moment de
>> l'exploiter. La relation entre un way et les nodes qui le constituent est 
>> connue, au
>> moins via les schémas d'import classique (Osmosis, osm2pgsql). Donc pas 
>> besoin de se
>> battre sur la meilleure modélisation, à mon avis, les deux se défendent, et 
>> aucune ne
>> mène à une impasse (hum).
>>
>> vincent
>>
>> Une messagerie gratuite, garantie à vie et des services en plus, ça vous 
>> tente ?
>> Je crée ma boîte mail www.laposte.net
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Logo SNCF / aéroports sur rendu FR...

[Mikaël Cordon]

Bonjour,

+1, je suis aussi d’avis de laisser de côté les logos de marque… Même
s’ils ont un effet esthétique certain (et je ne dis pas que c’est un
bel effet ou non :P), je pense que le rendu français (même s’il
n’incombe finalement au(x) gentil(s) développeur(s) qui s’en
occupe(nt) de choisir) devrait rester neutre commercialement : quand
je regarde cette carte on pourrait penser que la carte est sponsorisée
par La Poste et la SNCF…

De plus, je ne sais pas si ces deux entreprises ont donné leur accord
pour utiliser leur logo de la sorte ; quel impact sur leur image le
fait d’apparaître sur cette carte a ? Et quel impact sur notre image
ces logos jouent-ils ? Quid des autres marques (autoroutes Vinci,
centres commerciaux Auchan, Carrefour, Leclerc, etc…) ? Un logo
distinctif du service rendu est probablement plus neutre et surtout
plus simple à mettre en place, il me semble, car générique.

Toutefois, cette carte reste un rendu personnel, une interprétation de
la base OSM… Peut-être que légalement, il n’y a aucun sujet… Mais tout
de même, je me pose des questions.

Pour finir sur une note plus positive, je trouve quand même que ce
rendu, ne serait-ce que par son niveau élevé de zoom et sa réactivité
est très intéressant ! :)

Le 26 avril 2013 08:18, David Crochet  a écrit :
> Bonjour
>
> Il existe un panneau de signalisation signalant une gare, enfin plutôt un
> service de transport à la personne par rail ayant un traffic supérieur à 30
> 000 passager par an.
>
> Pourquoi ne pas utiliser ce logo. Peut-être trop proche d'une sybolique
> rapellant le TGV, mais les  nouvelle rame y ressemble fortement maintenant.
>
> Réservons le logo "SNCF" " Trancilien " " RATP " aux services associés,
> c'est a dire les agences commerciales.
>
> Pour les aéroports, c'est la même choses. On y met pas les logo des
> transporteurs, mais du service rendu (qui peuvent être in situ).
>
> Les centres commerciaux, c'est pareil ? c'est bien le logo du service rendu
> ?
>
> Cordialement
>
> --
> David Crochet
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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

[OSM-talk-fr] Test de routage sous JOSM

[Mikaël Cordon]

Salut,

Depuis quelques temps, je teste OSMAnd et le routage sur carte OSM, et
je me rends compte que le routage n’est pas optimal… Je me demande
s’il n’y a pas des problèmes d’interconnexion de routes…

Je cherche a effectuer des tests de routage rapide, ou même du test
d’interconnexion aux intersections dans JOSM… J’ai tenté plusieurs
plugins, mais je n’ai pas trouvé convenance : ne fonctionne pas, ou
pas pratique du tout.

Il y a-t-il des outils pratiques pour tester la connectivité du réseau
routier (tout véhicule et pédestre) sous JOSM ?

Cordialement,
--
Mikaël, mickey86

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

Re: [OSM-talk-fr] Test de routage sous JOSM

[Mikaël Cordon]

J’avoue ne pas utiliser Osmose suffisamment… Ceci dit, ce n’est pas un
problème de « syntaxe » ou « grammaire » de la carte, mais plutôt de
la sémantique que je cherche à tester…

Autrement dit, les problèmes de routage que je rencontre ne sont pas
dû forcément à des erreurs de tags, osmose ne les voit pas…

Concrètement, j’aimerais disposer d’un outil qui me permet de poser un
point de départ, un point d’arrivée de part et d’autre d’un carrefour
et visualiser rapidement s’il existe un chemin et lequel !
Particulièrement utile pour détecter les déconnexions et les
restrictions de routage mal configurés…

Le 26 avril 2013 09:52, Romain MEHUT  a écrit :
> Le 26 avril 2013 09:48, Mikaël Cordon  a écrit :
>
>> Salut,
>>
>> Depuis quelques temps, je teste OSMAnd et le routage sur carte OSM, et
>> je me rends compte que le routage n’est pas optimal… Je me demande
>> s’il n’y a pas des problèmes d’interconnexion de routes…
>>
>> Je cherche a effectuer des tests de routage rapide, ou même du test
>> d’interconnexion aux intersections dans JOSM… J’ai tenté plusieurs
>> plugins, mais je n’ai pas trouvé convenance : ne fonctionne pas, ou
>> pas pratique du tout.
>>
>> Il y a-t-il des outils pratiques pour tester la connectivité du réseau
>> routier (tout véhicule et pédestre) sous JOSM ?
>
>
> Tu ne trouves pas ton bonheur via http://osmose.openstreetmap.fr ?
>
> Romain
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>

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

Re: [OSM-talk-fr] Test de routage sous JOSM

[Mikaël Cordon]

> il y a
> http://tools.geofabrik.de/osmi/?view=routing&lon=2.32952&lat=48.87269&zoom=11&overlays=islands

Effectivement, c’est un bon outil que je peux utiliser, mais il manque
le test des routages mal configurés (sens interdits et interdictions
de tourner, etc…). Et mieux, pour moi, serait exploitable dans JOSM.

Cordialement,
--
Mikaël

Le 26 avril 2013 10:32, didier2020  a écrit :
> Le vendredi 26 avril 2013 à 10:12 +0200, Mikaël Cordon a écrit :
>> J’avoue ne pas utiliser Osmose suffisamment… Ceci dit, ce n’est pas un
>> problème de « syntaxe » ou « grammaire » de la carte, mais plutôt de
>> la sémantique que je cherche à tester…
>>
>> Autrement dit, les problèmes de routage que je rencontre ne sont pas
>> dû forcément à des erreurs de tags, osmose ne les voit pas…
>>
>> Concrètement, j’aimerais disposer d’un outil qui me permet de poser un
>> point de départ, un point d’arrivée de part et d’autre d’un carrefour
>> et visualiser rapidement s’il existe un chemin et lequel !
>> Particulièrement utile pour détecter les déconnexions et les
>> restrictions de routage mal configurés…
>
> il y a
> http://tools.geofabrik.de/osmi/?view=routing&lon=2.32952&lat=48.87269&zoom=11&overlays=islands
>
>
>>
>> Le 26 avril 2013 09:52, Romain MEHUT  a écrit :
>> > Le 26 avril 2013 09:48, Mikaël Cordon  a écrit :
>> >
>> >> Salut,
>> >>
>> >> Depuis quelques temps, je teste OSMAnd et le routage sur carte OSM, et
>> >> je me rends compte que le routage n’est pas optimal… Je me demande
>> >> s’il n’y a pas des problèmes d’interconnexion de routes…
>> >>
>> >> Je cherche a effectuer des tests de routage rapide, ou même du test
>> >> d’interconnexion aux intersections dans JOSM… J’ai tenté plusieurs
>> >> plugins, mais je n’ai pas trouvé convenance : ne fonctionne pas, ou
>> >> pas pratique du tout.
>> >>
>> >> Il y a-t-il des outils pratiques pour tester la connectivité du réseau
>> >> routier (tout véhicule et pédestre) sous JOSM ?
>> >
>> >
>> > Tu ne trouves pas ton bonheur via http://osmose.openstreetmap.fr ?
>> >
>> > Romain
>> >
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org
>> > http://lists.openstreetmap.org/listinfo/talk-fr
>> >
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Test de routage sous JOSM

[Mikaël Cordon]

>Moi j'utilise souvent http://map.project-osrm.org/ pour tester les différents 
>routage possible...
>
>c'est p-e un peu plus rapide que osmand...

Effectivement, plutôt rapide, c’est ce que je cherche… à 90% : il faut
attendre que la correction ait été prise en compte par OSMR pour
tester la correction :) Je sais, je suis exigeant :p

L’idéal serait cet outil directement dans JOSM… Mais en l’absence d’un
plugin équivalent dans JOSM, c’est ce que j’utiliserai :) Merci !

Cordialement,
--
Mikaël mickey86


Le 26 avril 2013 10:40, eMerzh  a écrit :
> Moi j'utilise souvent http://map.project-osrm.org/ pour tester les
> différents routage possible...
>
> c'est p-e un peu plus rapide que osmand...
>
>
>
> 2013/4/26 didier2020 
>>
>> Le vendredi 26 avril 2013 à 10:12 +0200, Mikaël Cordon a écrit :
>> > J’avoue ne pas utiliser Osmose suffisamment… Ceci dit, ce n’est pas un
>> > problème de « syntaxe » ou « grammaire » de la carte, mais plutôt de
>> > la sémantique que je cherche à tester…
>> >
>> > Autrement dit, les problèmes de routage que je rencontre ne sont pas
>> > dû forcément à des erreurs de tags, osmose ne les voit pas…
>> >
>> > Concrètement, j’aimerais disposer d’un outil qui me permet de poser un
>> > point de départ, un point d’arrivée de part et d’autre d’un carrefour
>> > et visualiser rapidement s’il existe un chemin et lequel !
>> > Particulièrement utile pour détecter les déconnexions et les
>> > restrictions de routage mal configurés…
>>
>> il y a
>>
>> http://tools.geofabrik.de/osmi/?view=routing&lon=2.32952&lat=48.87269&zoom=11&overlays=islands
>>
>>
>> >
>> > Le 26 avril 2013 09:52, Romain MEHUT  a écrit :
>> > > Le 26 avril 2013 09:48, Mikaël Cordon  a
>> > > écrit :
>> > >
>> > >> Salut,
>> > >>
>> > >> Depuis quelques temps, je teste OSMAnd et le routage sur carte OSM,
>> > >> et
>> > >> je me rends compte que le routage n’est pas optimal… Je me demande
>> > >> s’il n’y a pas des problèmes d’interconnexion de routes…
>> > >>
>> > >> Je cherche a effectuer des tests de routage rapide, ou même du test
>> > >> d’interconnexion aux intersections dans JOSM… J’ai tenté plusieurs
>> > >> plugins, mais je n’ai pas trouvé convenance : ne fonctionne pas, ou
>> > >> pas pratique du tout.
>> > >>
>> > >> Il y a-t-il des outils pratiques pour tester la connectivité du
>> > >> réseau
>> > >> routier (tout véhicule et pédestre) sous JOSM ?
>> > >
>> > >
>> > > Tu ne trouves pas ton bonheur via http://osmose.openstreetmap.fr ?
>> > >
>> > > Romain
>> > >
>> > > ___
>> > > Talk-fr mailing list
>> > > Talk-fr@openstreetmap.org
>> > > http://lists.openstreetmap.org/listinfo/talk-fr
>> > >
>> >
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org
>> > http://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>

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

Re: [OSM-talk-fr] Logo SNCF / aéroports sur rendu FR...

[Mikaël Cordon]

Personnellement, je n’attaque pas directement ton travail qui est
apprécié et remarquable. En tant que contributeur OSM, habitué à voir
des cartes officielles neutres commercialement, voir les logos de
seules 2 compagnies m’a interloqué.

Après comme je l’ai souligné, peut-être peut-on considérer ce rendu
comme un travail privé, et dans ce cas tu peux oublier mes remarques.
Mais dès lors que ce travail est disponible via le nom de domaine
openstreetmap.fr, la carte revêt un caractère officiel…

Mais peut-être me trompe-je ? Je ne suis pas toujours le plus fin, ni
le plus mesuré… Je suis un passionné :)

Cordialement,
--
Mikaël mickey86

Le 26 avril 2013 13:22, Christian Quest  a écrit :
> Tout dans la finesse et la mesure... je pense que je vais devoir
> m'auto-flageller en place publique pour faire pénitence pour
> l'inadmissible publicité faite à La Poste et la SNCF !
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Test de routage sous JOSM

[Mikaël Cordon]

>Si tu n'as pas peur de programmer toi-même un petit peu, j'ai déjà beaucoup 
>réalisé avec le plugin scripting en Python:
>
>http://wiki.openstreetmap.org/wiki/Quality_control_with_Python_script_in_JOSM
>
>Jo

Me reste cette option, étant déjà dans la programmation toute la
journée au boulot, j’aime bien varier les plaisirs ^^… Mais j’y
viendrai peut-être.

Cordialement,
--
Mikaël mickey86

Le 26 avril 2013 14:08, Jo  a écrit :
> Si tu n'as pas peur de programmer toi-même un petit peu, j'ai déjà beaucoup
> réalisé avec le plugin scripting en Python:
>
> http://wiki.openstreetmap.org/wiki/Quality_control_with_Python_script_in_JOSM
>
> Jo
>
> 2013/4/26 Mikaël Cordon 
>>
>> Salut,
>>
>> Depuis quelques temps, je teste OSMAnd et le routage sur carte OSM, et
>> je me rends compte que le routage n’est pas optimal… Je me demande
>> s’il n’y a pas des problèmes d’interconnexion de routes…
>>
>> Je cherche a effectuer des tests de routage rapide, ou même du test
>> d’interconnexion aux intersections dans JOSM… J’ai tenté plusieurs
>> plugins, mais je n’ai pas trouvé convenance : ne fonctionne pas, ou
>> pas pratique du tout.
>>
>> Il y a-t-il des outils pratiques pour tester la connectivité du réseau
>> routier (tout véhicule et pédestre) sous JOSM ?
>>
>> Cordialement,
>> --
>> Mikaël, mickey86
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>

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

Re: [OSM-talk-fr] Logo SNCF / aéroports sur rendu FR...

[Mikaël Cordon]

>ne pas représenter les logos mais le nom des enseignes revient un peu au même
>non ?

Ça revient un peu au même… Mais à la différence des logos, le nom des
enseignes sont tous rendus de la même manière : je suppose évidemment
que l’algorithme d’affichage (de filtrage) ne privilégie pas une
enseigne par rapport à une autre.

Cordialement,
--
Mikaël mickey86

Le 26 avril 2013 14:16, Mikaël Cordon  a écrit :
> Personnellement, je n’attaque pas directement ton travail qui est
> apprécié et remarquable. En tant que contributeur OSM, habitué à voir
> des cartes officielles neutres commercialement, voir les logos de
> seules 2 compagnies m’a interloqué.
>
> Après comme je l’ai souligné, peut-être peut-on considérer ce rendu
> comme un travail privé, et dans ce cas tu peux oublier mes remarques.
> Mais dès lors que ce travail est disponible via le nom de domaine
> openstreetmap.fr, la carte revêt un caractère officiel…
>
> Mais peut-être me trompe-je ? Je ne suis pas toujours le plus fin, ni
> le plus mesuré… Je suis un passionné :)
>
> Cordialement,
> --
> Mikaël mickey86
>
> Le 26 avril 2013 13:22, Christian Quest  a écrit :
>> Tout dans la finesse et la mesure... je pense que je vais devoir
>> m'auto-flageller en place publique pour faire pénitence pour
>> l'inadmissible publicité faite à La Poste et la SNCF !
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Logo SNCF / aéroports sur rendu FR...

[Mikaël Cordon]

+1
Je n'ai pas su dire mieux :-)

Mais je rajouterais que si la carte était privée ce rendu ne serait pas un
problème, ou en tout cas pas celui de la communauté OSMFR.

Seulement cette carte est accessible via le nom de domaine openstreetmap.fr

Cordialement,
--
Mikaël mickey86
Le 27 avr. 2013 09:39, "Pierre-Alain Dorange"  a écrit :

> Christian Rogel
>  wrote:
>
> > > Je suis d'avis qu'il ne faut pas trop abuser des logos de marques sur
> > > les tuiles image.
> > >
> >
> > Pour quelle raison : politique? pratique? graphique? Que signifie "ne pas
> > trop abuser"? Car, ou bien, on les met avec des règles ou on ne les met
> > pas.
>
> A mon sens l'usage de logo de marque n'a pas sa place sur une carte
> libre.
>
> Juridiquement c'est déjà probablement limite (droit des marques)
>
> Politiquement (au sens commun et au sens surtout d'OSM) ça me semble pas
> être très raccord avec les notions de partage et de neutralité que nous
> véhiculons.
>
> Pratiquement ensuite, c'est bien trop visible, ça attire l'œil car c'est
> graphiquement pas raccord avec le reste de la carte.
> Et avec la dispariation des services publics, ça n'aura plus de sens
> dans quelques années...
>
> --
> Pierre-Alain Dorange
> OSM experiences : 
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Quelques statistiques sur notre liste de diffusion "talk-fr"

[Mikaël Cordon]

> Mes messages sont courts tant qu'on commence à ne pas y répondre par des 
> messages encore plus longs et rajouter des propos qui virent à l'obsession 
> personnelle contre moi.

C’est ce qu’on appelle de la mauvaise foi, ou de l’inconscience, c’est
selon : il arrive régulièrement que tu te laisses emporter dans des
explications sans fin sur plusieurs messages d’affilée sur le même
sujet !

Ce n’est pas la justesse de tes explications qui est critiquable, mais
plutôt le fait de diluer l’information nécessaire dans un flot à haut
débit ! Décourageant à lire : on cherche l’information utile dans tes
messages, on se force à tout lire pour la débusquer. Totalement contre
productif. Synthétise !

Si on a besoin d’informations plus détaillées on sait que tu pourras
nous les fournir.

Cordialement,
--
Mikaël mickey86

Le 3 mai 2013 08:58, Jean-Francois Nifenecker
 a écrit :
> Bonjour Philippe,
>
> Le 03/05/2013 00:54, Philippe Verdy a écrit :
>>
>> Les grammes de CO2 ne se réduiront pas, quel que soit le volume, tant
>> que cette liste existera. La plus grande partie vient de la seule[...]
>
>
> désolé, je n'avais pas mis  car je pensais que c'était
> évident... /o\
>
> A+
>
> --
> Jean-Francois Nifenecker, Bordeaux
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Quelques statistiques sur notre liste de diffusion "talk-fr"

[Mikaël Cordon]

Bonjour,

J'ai suivi ce fil, parce que j'y ai participé… Et peut-être parce que
j'ai trouvé qu'il y avait des paroles qui semblaient un peu trop
hautes à mon goût, je n'ai pas voulu re-rentrer dans le sujet à ce
moment-là. Mais il me semble que le sujet a mûri.

Je suis plutôt pour les méthodes douces, et dans ce sens je ne pense
pas que virer quelqu'un de la communauté pour ces faits-là soit une
bonne solution, en effet. Je suis aussi pour la discussion, ceci dit,
ainsi qu'il l'a été remarqué, Philippe a été avisé de son «
comportement débordant » et gênant plusieurs fois déjà, sans résultat.

Mais je suis aussi de ceux qui trouvent que son comportement nuit
d'une certaine manière et de manière certaine à la communauté, ne
serait-ce que par cette présente discussion qui nous divise/irrite
(rayer la mention inutile) ; ou encore par le fait que son imbuvable
prose casse complètement la lecture des sujets en noyant les
informations utiles.

Comme dit précédemment, il a des idées qui ne sont pas toutes
mauvaises (comme chaque contributeur), mais il serait mieux (à mon
avis) qu'il les synthétise et attende qu'on demande des précisions
avant d'approfondir les sujets… Non ? (ce paragraphe est à double
emploi : question à la communauté et suggestion à Philippe, s'il nous
écoute)

Je veux bien continuer à faire preuve de patience, mais je pense que
s'il continue insensiblement à déborder ainsi, le présent sujet
reviendra sempiternellement…

Cordialement,
--
Mikaël Cordon, mickey86



Le 6 mai 2013 21:50, Vincent Pottier  a écrit :
> Le 06/05/2013 16:27, Pierre-Alain Dorange a écrit :
>
>> Franchement je supporte pas cet espèce de vendetta en public qui ne montre
>> pas un beau visage de la communauté de cette liste. De plus beaucoup semble
>> confondre, cette liste/forum et le projet OSM.
>
> @Pierre-Alain
> Moi non plus je n'aime pas ce ton. Je suppose et j'espère que personne, au
> bout du compte n'aime.
> Je crois que certains propos ont été excessifs.
> Mais je comprends, et partage en partie, l'exaspération de certains, même
> si, en effet, ces derniers jours, Philippe s'est plus contenu que de
> coutume...
> Ou est-ce parce que j'ai été très occupé par ailleurs et que je n'ai pas
> tout suivi.
>
> Mais je puis attester que nombre de remarques lui ont été faites en privé
> par moi et, je suppose, par d'autres. Remarques qui sont restées vaines.
> Voire même, remarques qui ont été détournées de leur sens.
>
> Il arrive à chacun, il m'est arrivé, de se faire remettre à sa
> place/corriger/recadrer... sur la liste. Habituellement, la personne
> concernée laisse entendre qu'elle a entendu, reconnaît son erreur. Et les
> choses en reste là. Hélas, il est une personne pour laquelle ce genre de
> remarque devient illico une injure, une attaque publique...
>
> Je ne suis pas grand technicien, mais oui, il y a eu moult fois où les
> affirmations de Philippe étaient fausses et ont été démontrées telles. Et il
> a bien fallu que certains répondent avec force pour ne pas laisser traîner
> des erreurs sur la liste.
>
> Il est arrivé aussi que, la communauté étant parvenue à établir certaines
> pratiques cohérentes dans la façon de cartographier des éléments, Philippe
> aille à l'encontre de celles-ci, et malgré des rappels, persiste.
>
> Il est arrivé que, malgré des signalements de grosses erreurs, celles-ci
> soient mal corrigées et qu'il faille passer derrière.
> Certes cela arrive de devoir prêter la main à un débutant pour corriger des
> erreurs. Celui-ci, en général, s'excuse pour les erreurs commises et
> progresse dans la façon de cartographier. Philippe un éternel débutant ? Qui
> en plus ne s'excuse pas (ou je n'ai jamais vu) mais au contraire se
> justifie...
>
> Non, le problème n'est pas que sur la liste. Il est aussi dans la
> cartographie.
> Certes, Philippe a apporté des éléments de discussion. Certes Philippe a
> apporté des éléments à la carte. Mais au prix de quel énervement pour la
> communauté ?
> Que cela vaille bannissement, je ne le crois pas. Il y a probablement des
> moyens intermédiaires.
>
> Oui, il y a eu des excès de ton, mais je comprend les agacements,
> l'exaspération.
>
> Vous connaissez l'histoire du gars sur l'autoroute qui s'exclame : "Il sont
> tous tarés ! Ils roulent tous à contre-sens !" ?
> Non ? Je vous la raconte :
> "Il était une fois un projet de cartographie communautaire et sa liste de
> discussion francophone..."
> --
> FrViPofm
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Ajouts des adresses du cadastre : faisons mieux que simplement "importer"

[Mikaël Cordon]

C'est également ma façon de faire : rapport à la frontière public/privée.
D'autant que si le privé interdit d'entrer sur sa parcelle, on ne pourra
pas accéder jusqu'au bâtiment...

Cordialement,
--
Mikaël Cordon, mickey86
Le 26 juin 2013 18:49, "Pierre-Alain Dorange"  a écrit :

> Pieren  wrote:
>
> > > Entièrement d'accord avec ça. En centre-ville, c'est pertinent de
> > > mettre le point d'adresse sur un noeud du building. Par contre, en zone
> > > résidentielle, bon nombre de maisons ne sont pas collées à la rue, et
> > > dans ce cas, il est, à mon sens, préférable d'avoir le numéro en bord
> de
> > > rue.
> >
> > C'est un peu hors-sujet. Mais avoir le numéro en bord de rue pose
> > aussi des problèmes. Il y a de nombreux cas où il devient difficile,
> > voir impossible, d'identifier le bâtiment du destinataire. Cette façon
> > de faire n'est pas fausse. Mais avoir l'adresse sur le bâtiment
> > lui-même est plus précis. Pensez aux piétons. Le noeud address devrait
> > se situer près de l'entrée du bâtiment.
>
> C'est une discussion qui a déjà eut lieu plusieurs fois mais sans
> consensus.
>
> Mon point de vue et usage personnel est que (pour moi) le détail d'OSM
> s'arrête à la frontière entre le domaine public et le domaine privé. De
> même que je ne met pas les piscines privées, je place le point adresse
> sur la frontière de la propriété privée (l'entrée principale au domaine
> privé).
> J'estime que c'est suffisant pour le piéton qui en franchissant ce point
> entre dans le domaine privé.
>
> C'est parfois délicat, surtout si on va pas sur le terrain, mais le
> cadastre permet de voir clairement les parcelles et souvent les entrées
> et c'est là que je place le point adresse.
>
> Bien sur quand l'adresse n'a pas de terrain (en facade) le point adresse
> se retrouve sur le batiment (et bien évidement comme signalé il faut que
> ce point fasse parti du polygone du bâti), mais dans les autres cas
> (propriété avec terrain) le pont est sur la frontière de la parcelle
> cadastrale.
>
> --
> Pierre-Alain Dorange
> OSM experiences : <http://www.leretourdelautruche.com/map/>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Privé/public (était: Ajouts des adresses du cadastre...)

[Mikaël Cordon]

En fait, je me pose la question…

À l’heure où on pointe du doigt plus que jamais la collecte de données
privées (Google, Facebook, Apple, etc…), peut-être devrions-nous connaître
la/une limite acceptable ?

Attention, malgré que nous sommes vendredi, ceci n’est pas un troll, mais
bien une question légitime :)

Cordialement,
--
Mikaël Cordon


Le 28 juin 2013 08:32, Jean-Marc Liotier  a écrit :

> On 06/28/2013 08:17 AM, Pierre-Alain Dorange wrote:
> > pourquoi pas les allées sur les terrains privés
>
> Ne t'inquiètes pas, je les cartographie aussi:
>
> higway=service
> access=private
>
> Tout ce qui est visible et qui peut potentiellement servir de point de
> repère pour la navigation est à mon avis un objet cartographique légitime.
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Les "access" par défaut pour les "highway=track" en France

[Mikaël Cordon]

Je n'ai pu vérifier ledit tableau (le wiki est inaccessible pour le
moment), mais je suis d'accord sur le principe.

Cordialement,
--
Mikaël Cordon, mickey86
Le 10 juil. 2013 16:11, "Pieren"  a écrit :

> Bonjour,
>
> Etes-vous d'accord pour ajouter "highway=track" dans ce tableau du
> wiki qui définit les accès par défaut sur les highways par pays:
>
>
> http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#France
>
> en le mettant dans la ligne des primary, secondary, etc,, c.à.d. avec
> "yes" sur tous les moyens de locomotion (y compris hgv et psv, du
> moins, du point de vue légal)
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Rendu FR dans OSMand

[Mikaël Cordon]

+1000 ! :)

Cordialement,
--
Mikaël Cordon, mickey86


Le 12 juillet 2013 15:44, Yoann Cornec  a écrit :

> Bonjour à tous,
>
> Est-il possible d'utiliser le rendu FR dans OSMand ?
> Au mieux, dans le rendu vectoriel, sinon en se connectant au tile server
> FR ou avec des tuiles offline.
>
> C'est peut-être récurrent comme question, mais je n'ai trouvé que
> celle-ci, apparemment restée sans réponse :
> http://lists.openstreetmap.org/pipermail/talk-fr/2013-May/058688.html
>
> Merci d'avance :-)
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Réf.: Re: Suivi des opérations du Redaction bot

[Mikaël Cordon]

Pour le suivi des suppressions :
http://harrywood.dev.openstreetmap.org/license-change/botprocessing.php?zoom=7&lat=46.76126&lon=2.66199&layers=00BFTTFF

C’est un autre calque du site de suivi.

Le 18 juillet 2012 09:24, Etienne Trimaille  a
écrit :

> Est-ce que je suis le seul à penser que le bot a été plus ravageur que
> prévu ?
>
> La relation de ma commune a été supprimée, alors que j'étais le créateur
> initial.
> Idem pour les bornes incendies : j'avais rajouté un certain nombre de
> points sur ma commune. Un bot qui a refusé la licence avait modifié juste
> un tag. Et la je vois que mes points ont disparus ! C'était long à
> cartographier ces équipements. Les validateurs de JOSM/Geofabrik Tools
> étaient ok avec les versions (retour à une version antérieur). Mais la,
> c'est carrément une suppression.
>
> Existe-il un outil pour voir les objets supprimés ?
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>

Cordialement,
-- 
Mikaël Cordon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Collecte terrain avec tablette Android sans 3G

[Mikaël Cordon]

OSMTracker est dispo pour une Galaxy Tab 7", c’est très intéressant comme
appli, c’est ce que j’utilise :)

Seulement dans le « cahier des charges » il y a besoin que la trace
s’affiche sur une carte sans 3G… Or OSMTracker nécessite la 3G ou en tout
cas Internet pour afficher la carte.

Le 7 août 2012 09:47, Fabien  a écrit :

> Le 5 août 2012 17:46, Emmanuel Dewaele  a
> écrit :
> > Bonjour,
> >
> > Nouvellement possesseur d'une tablette sous Android, j'apprécie de
> pouvoir
> > utiliser OsmAnd, avec la possibilité d'embarquer les données routières
> sur
> > l'appareil pour consulter la carte sans connexion, puisque l'appareil ne
> > peut se connecter qu'en Wifi. Je suis à la recherche d'un moyen de
> > l'utiliser pour prendre des notes sur le terrain, sachant que dans
> OsmAnd on
> > peut insérer des points d'intérêt OpenStreetBugs, système quelque peu
> > rudimentaire mais plutôt pratique, mais l'enregistrement de signalements
> > OpenStreetBugs nécessite d'avoir une connexion...
> >
> > Qui a une idée ? Existe t'il une autre application sur Android pour
> prendre
> > des notes sur le terrain avec la carte stockée sur l'appareil (a priori,
> je
> > n'en ai pas trouvé) ? Ou vaut t'il mieux tenter d'adapter OsmAnd ?
> >
> > Emmanuel
> >
>
> OSMTracker n'est pas disponible dans le Google Play des tablettes ?
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Mikaël Cordon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Collecte terrain avec tablette Android sans 3G

[Mikaël Cordon]

+1

Moi aussi, la carte ne me sert pas, au pire j’ai OSMAnd qui reste en tâche
de fond et je bascule dessus si j’ai besoin, et OSMTracker reste en tâche
de fond une fois sur OSMAnd…

Le 7 août 2012 10:38, Fabien  a écrit :

> Il est vrai que sans 3G le mode carte ne sert pas mais,
> personnellement, je ne me sers presque jamais du mode carte vu que je
> mets le tracé et j'ajoute les points que je vois.
>
> A voir avec l'OP,
> Fabien
>
> Le 7 août 2012 10:34, Mikaël Cordon  a écrit :
> > OSMTracker est dispo pour une Galaxy Tab 7", c’est très intéressant comme
> > appli, c’est ce que j’utilise :)
> >
> > Seulement dans le « cahier des charges » il y a besoin que la trace
> > s’affiche sur une carte sans 3G… Or OSMTracker nécessite la 3G ou en tout
> > cas Internet pour afficher la carte.
> >
> > Le 7 août 2012 09:47, Fabien  a écrit :
> >>
> >> Le 5 août 2012 17:46, Emmanuel Dewaele  a
> >> écrit :
> >> > Bonjour,
> >> >
> >> > Nouvellement possesseur d'une tablette sous Android, j'apprécie de
> >> > pouvoir
> >> > utiliser OsmAnd, avec la possibilité d'embarquer les données routières
> >> > sur
> >> > l'appareil pour consulter la carte sans connexion, puisque l'appareil
> ne
> >> > peut se connecter qu'en Wifi. Je suis à la recherche d'un moyen de
> >> > l'utiliser pour prendre des notes sur le terrain, sachant que dans
> >> > OsmAnd on
> >> > peut insérer des points d'intérêt OpenStreetBugs, système quelque peu
> >> > rudimentaire mais plutôt pratique, mais l'enregistrement de
> signalements
> >> > OpenStreetBugs nécessite d'avoir une connexion...
> >> >
> >> > Qui a une idée ? Existe t'il une autre application sur Android pour
> >> > prendre
> >> > des notes sur le terrain avec la carte stockée sur l'appareil (a
> priori,
> >> > je
> >> > n'en ai pas trouvé) ? Ou vaut t'il mieux tenter d'adapter OsmAnd ?
> >> >
> >> > Emmanuel
> >> >
> >>
> >> OSMTracker n'est pas disponible dans le Google Play des tablettes ?
> >>
> >> _______
> >> Talk-fr mailing list
> >> Talk-fr@openstreetmap.org
> >> http://lists.openstreetmap.org/listinfo/talk-fr
> >
> >
> >
> >
> > --
> > Mikaël Cordon
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-fr
> >
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Mikaël Cordon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bilan opendata RATP... (Christian Quest)

[Mikaël Cordon]

Tant qu’à être précis… Devant les ponctuations hautes, on ajoute l’espace
insécable ; entre les guillemets français et le texte qu’ils entourent il
faut aussi cette espace insécable, les puristes préféreront l’espace fine
insécable.

Ceci dit, peut-être qu’on peut considérer que le type d’espace, voire même
les espaces autour des ponctuations relèvent de la mise ne forme et pas de
la donnée, ainsi pourrait-on laisser le soin de remplacer ces mises en
forme aux moteurs de rendu ?

Le 16 août 2012 08:07, Ista Pouss  a écrit :

> Peut être que l'on peut dire "Une espèce d'espace" ?
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>

Cordialement,
-- 
Mikaël Cordon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nom commun à plusieurs polygones

[Mikaël Cordon]

Salut,

Le 22 août 2012 10:05, Plop76  a écrit :

> Philippe Verdy a écrit :
>
>  Le 21 août 2012 21:38, Plop76  a écrit :
>>
>>> Bonjour,
>>>
>>> En essayant de nommer un bois qui est représenté par deux polygônes
>>> adjacents avec des tags incompatibles
>>> (http://www.openstreetmap.org/**browse/way/177031065<http://www.openstreetmap.org/browse/way/177031065>et
>>> http://www.openstreetmap.org/**browse/way/177031066<http://www.openstreetmap.org/browse/way/177031066>),
>>> je vois que Mapnik
>>> affiche deux fois le nom, ce qui me semble inutile.
>>>
>>> Est-ce la façon correcte de tagguer (en laissant se débrouiller les
>>> logiciels de rendu) ?
>>>
>>> J'ai pensé à faire un multipolygon avec le tag name dessus, mais cela ne
>>> respecterait pas le wiki qui dit que si la relation multipolygon a des
>>> tags,
>>> ceux des polygones extérieurs doivent être ignorés.
>>>
>>
>> C'est pour tant ce qu'il faut faire. Le nom commun pour l'ensemble des
>> polygone va dans la relation multipolygone. Et tu fais une mauvaise
>> interprétation de ce que dit le wiki : ce qu'il faut lire c'est que si
>> les polygones adjascents peuvent avoir leur propre nom, cela ne veut
>> pas dire qu'ils le perdent parce qu'un mutlipolygone qui les inclut en
>> porte un autre. Ce que cela signifie c'est que le multipolygone, s'il
>> definit un nom adopte ce nom pour l'ensemble qu'il représente,
>> indépendamment des noms qui peuvent être définis pour ses composantes.
>>
>> En revanche si les composantes portent le même nom que l'ensemble, le
>> nom donné aux composantes est inutile, souvent, mais pas toujours (par
>> exemple une ville et un canton portent chacun un nom même s'il est
>> identique dans le champ name (mais les autres tags indiquent que ce
>> sont en fait des objets différents par nature, bien qu'homonymes : la
>> ville ne perd pas son nom parce qu'un canton homonyme prend le même
>> nom).
>>
>
> Quand je lis :
>
> «There is more than one outer way:
>
> The relation has tags
>Use the relation tagging. Ignore anything on the ways.»
>
> Je comprends que si je mets le nom dans la relation, les tags "wood" des
> composantes vont être ignorés par exemple (Ça changerait rien avec Mapnik
> de toute façon...)
>
> En fait "ignore anything on the ways" voudrait dire d'ignorer tout ce qui
> est incohérent avec les tags sur la relation ?


Je comprends le contraire…
« The relation has tags » : la relation contient des attributs
« Use the relation tagging » : utilise les attributs sur la relation.
« Ignore anything on the ways » : ignore tout en ce qui concerne les
chemins (les polygones).

En tout cas, je ne sais pas quel logiciel te dis ça, mais ignorer des
attributs, ça me paraît un peu culotté.


>
>
>
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr<http://lists.openstreetmap.org/listinfo/talk-fr>
>


Cordialement,
-- 
Mikaël Cordon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Profession de foi de sly à la candidature au poste de "membre du DWG"

[Mikaël Cordon]

+1 !

Le 26 septembre 2012 09:05, Vincent Pottier  a écrit :

>  +1
>
> Le 26/09/2012 00:32, Vincent Privat a écrit :
>
> Le mien également :)
>
> Le 25 septembre 2012 23:35, Emilie Laffray  a
> écrit :
>
>> Tu as mon soutien
>>  On Sep 25, 2012 6:52 PM, "sly (sylvain letuffe)" 
>> wrote:
>>
>>> Bonjour,
>>>
>>> Suite à ma proposition ici :
>>>
>>> http://lists.openstreetmap.org/pipermail/talk-fr/2012-September/048217.html
>>>
>>> Je confirme présenter ici même ma candidature au poste de "membre du DWG"
>>> http://wiki.openstreetmap.org/wiki/DWG
>>> à la communauté française.
>>> Tout en rappelant que même si l'on m'accepte ici à ce poste, le DWG peut
>>> toujours me refuser.
>>> Rappelons qu'occuper ce poste devrait comprendre :
>>> - La possibilité de discuter avec les autres membres du DWG avec plus de
>>> chance d'être écouté que le reste des contributeurs
>>> - La possibilité d'empécher un utilisateur OSM de continuer à éditer
>>> (blocage)
>>> exemple : http://www.openstreetmap.org/user_blocks/248
>>>
>>> Voici un bref CV de qui je suis :
>>> http://wiki.openstreetmap.org/wiki/User:Sletuffe
>>> Merci de noter en outre que je ne suis pas membre de l'association
>>> osm-fr et
>>> que je ne compte pas le devenir.
>>>
>>> == Discuter ==
>>> En me présentant à ce poste, j'entends surtout présenter auprès du DWG
>>> les
>>> attentes, inquiétudes et spécificité des autres membres de la communauté
>>> française au regard des imports du cadastre tout particulièrement, mais
>>> aussi
>>> d'autre imports ayants lieu sur le territoire français (Métropole +
>>> DOM/TOM)
>>> (imports étant défini par ce que le DWG appel "import" et sur lesquels
>>> ils
>>> entendent imposer des règles par des blocages)
>>> Ce que je souhaite mettre au service de la communauté, c'est mon franc
>>> parlé,
>>> ma capacité d'expression en anglais et ma capacité à relayer les demandes
>>> discutées sur la liste talk-fr, les forums français, ou tout moyen de
>>> communication utilisé par la communauté de contributeurs français.
>>> Je m'efforcerais de faire des comptes rendus de ce qui se dit en haut et
>>> ma
>>> position pourra évoluer au grè des discussions et conclusions de la
>>> communauté française.
>>>
>>> == bloquer ==
>>> Bloquer des contributeurs, ce ne sera ni ma force ni mon plaisir. Je ne
>>> souhaite d'ailleurs jamais le décider moi même, mais uniquement être le
>>> doigt
>>> qui clic, suite à une décision majoritaire de la communauté fr elle
>>> même, ou
>>> du "cadastre task force" si celui-ci m'est désigné.
>>> (Sauf cas d'urgence avérée dont la définition sera laissée à la
>>> communauté sur
>>> acte de vandalisme évident)
>>> Il est donc hors de question que je sois celui qui fasse tout le (sale)
>>> boulot
>>> (surveillance IRC, outils,...) , ni et celui sur qui on tape parce que je
>>> n'ai pas bloqué à temps de mon propre chef ou par excès de blocage alors
>>> que
>>> le dit blocage fût demandé par l'instance ci-avant évoquée.
>>>
>>> En tout état de décision de la communauté française ou "cadastre task
>>> force",
>>> je m'engage à ne jamais bloquer un utilisateur en dehors du territoire
>>> français, défini par la relation n°11980
>>> (http://www.openstreetmap.org/browse/relation/11980)
>>> Je m'engage à ne jamais bloquer un utilisateur sans que quelqu'un lui
>>> ait déjà
>>> envoyé un message lui expliquant qu'il y a un problème (moi ou pas)
>>>
>>> == rupture de contrat ;-) ==
>>> Je ne m'engage sur aucune durée, je suis libre de quitter ce poste à tout
>>> moment et sans préavis
>>> La communauté, sur consultation d'une majorité d'exprimés (à définir ?)
>>> peut
>>> me demander à tout moment de quitter ce poste
>>>
>>> fin
>>>
>>> ps: p'tain de prise de tête ! On dirait que j'ai fais ça toute ma vie
>>> ps2: si pas d'accord, modifications souhaités, me répondre, je ne suis
>>> pas
>>> borné, mais au service de la communauté ;-)
>>>
>>> --
>>> sly
>>> qui suis-je : http://sly.letuffe.org
>>> email perso : sylvain chez letuffe un point org
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Mikaël Cordon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] 850000 membres... et autres stats...

[Mikaël Cordon]

Même si on suspecte un biais, les +1000 km / jour de route, par exemple,
restent impressionnant, satisfaisant et motivant, je trouve.

Cordialement,
--
Mikaël Cordon (mickey86)

Le 15 octobre 2012 11:09, Christophe Merlet  a
écrit :

> Le lundi 15 octobre 2012 à 10:38 +0200, Christian Quest a écrit :
> > En préparation de notre réunion avec l'IGN, j'ai refait quelques
> statistiques...
> >
> > Il y a un an, on avait environ 48 membres, cela fait une
> > croissance de 77%. Ce sont les compte ouverts, mais pas forcément
> > actifs.
> > Le rythme s'est clairement accéléré début juillet.
> >
> > Le nombre de contributeurs actifs a lui aussi augmenté pour passer
> > d'environ 2000/jour à actuellement 3000/jour et la barre des
> > 2/mois est désormais systématiquement franchie depuis début
> > octobre.
>
> > Pour la France, on est toujours entre 200 et 250 contributeurs actifs
> > quotidiennement, ce qui nous place en second derrière l'Allemagne et
> > devant la Russie.
>
> Cette forte augmentation de contributeurs n'a bien sûr rien à voir avec
> la nécessité de posséder plusieurs comptes pour faire des imports de
> données
>
>
>
> Librement,
> --
> Christophe Merlet (RedFox)
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Création du "Groupe d'accompagnement" aka "Cadastre task force" - Liste privée ou liste publique ?

[Mikaël Cordon]

J’ai suivi un peu le sujet. Jusqu’ici, je n’avais pas tellement d’avis sur
la publicité ou non de cette liste…

Désormais, je me dis que si un groupe de gens veut discuter de façon privée
sur comment prendre contact avec un nouveau contributeur, l’aider et
éventuellement rétablir des erreurs qu’il a pû faire, on ne l’empêchera pas
: il y a une multitude de façons de se contacter en dehors des listes de
diffusion.

D’autre part, ce groupe, qui tente de prendre en charge les contributeurs «
saccageurs » (dans le sens défini plusieurs fois dans ce sujet : « qui,
clairement, nuit aux contributions de la communauté et à la base OSM »),
pourrait agir sans en référer à quiconque — ce qui est son droit en tant
que groupe de contributeurs de la communauté — a décidé d’être clair sur
ses intentions.

Moi, je ne vois aucun problème à ce que la liste soit privée, d’autant
qu’il a été plusieurs fois question que l’opacité pourra être changée si
nécessaire.

Et c’est moi qui dis ça, qui, habituellement prône l’ouverture totale :)

De plus, si j’avais plus de temps, je m’engagerais dans ce groupe, mais pas
pour l’instant.

Cordialement,
--
Mikaël Cordon (mickey86)

Le 15 octobre 2012 16:51, Pieren  a écrit :

> 2012/10/15 Sylvain Maillard :
> > je suis plutôt pour l'ouverture de la liste, avec éventuellement une
> > ré-évaluation d'ici quelques temps si il y a vraiment beaucoup
> d'inscrtis:
>
> Ce que je voulais dire par ouverture, c'était dans le sens d'avoir au
> minimum accès aux archives sans avoir à s'inscrire comme c'est le cas,
> par exemple, pour la liste de l'asso. Je n'ai rien contre une
> modération dans les inscriptions pour éviter les hors-sujets (genre
> "untel n'utilise pas le bon tag") ou les polémiques sur le rôle de ce
> groupe, discussions légitimes mais qui devraient se dérouler sur la
> liste talk-fr.
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bâti et éoliennes

[Mikaël Cordon]

Une éolienne étant fixe, est donc immeuble… Sauf erreur de ma part, il me
semble que le corps de l’éolienne est creux et que les gens de la
maintenance grimpent à l’intérieur. Dès lors qu’on peut entrer dans un
immeuble, je le considère comme un bâtiment ; « building » m’apparaît donc
adapté.

Se pose alors la question des éoliennes plus petites, dans lesquelles on ne
peut pas entrer.

D’autre part, question : modélise-t-on l’orientation des éoliennes ? Je ne
sais pas si les éoliennes ont une orientation fixe ou non.

Cordialement,
--
Mikaël Cordon (mickey86)

Le 16 octobre 2012 05:06, Philippe Verdy  a écrit :

> Ce que je veux dire c'est que les "bâtiments" du cadastre tout petits
> de moins de 5 mètres de large dans leur plus grande dimension,
> pourraient être traités dans une liste à part, à valider de meilleure
> façon que de les importer par défaut en tant que "building" (de quoi
> mieux satisfaire le DWG qui nous reproche ces imports "non
> qualifiés").
>
> Cela ne gènerait pas la travail sur les rues et routes, et cela
> permettrait un travail aussi en plusieurs phases, ces petites
> constructions nécessitant une visualisation (imagerie Bing) au minimum
> pour les identifier.
>
> Les bâtiments ronds de plus de 5 mètres ont de grrandes chances d'être
> des châteeaux d'eau ou des tours d'émetteurs, ils sont très repérables
> et essentiels au repérage sur le terrain, on doit les mettre dans OSM,
> mais eux aussi devraient être mieux qualifiés. Ils sont assez peu
> nombreux pour qu'on les mette clairement à part pour qu'ils soient
> identifiés en priorité même sur les autres constructions.
>
> Les petits bâtiments rectangulaires de moins de 5 mètres sont
> effectivemnt assez souvent des postes de transformation ou petits
> locaux techniques similaires. Dans certains cas (quand on les trouve
> dans un terrain résidentiel à côté d'un autre bâtiment) ce sont
> souvent des garages ou appentis. En milieu rural ce peuvent être des
> puits. En ville, ce peuvent être des kiosques, des toilettes
> publiques, des abris bus/taxi en dur.
>
> Dans les gares, difficile de savoir ce que c'est entre les bâtiments
> techniques, postes de transformation, abris, kiosques... Mais je crois
> que les gares sont déjà très bien cartographiées dans OSM et tout y
> est bien répertorié, simpelment car ce sont des lieux connus et très
> visités.
>
> Quand le milieu urbain est dense, avec des tas de bâtiments quasi
> jointifs, l'import en tant que "building" ne me choque pas, car les
> immeubles sont à usages multiples et changeants et ce n'est pas plus
> mal de devoir ensuite les qualifier en positionnant dessus les POIs
> pour les commerces, le reste étant par défaut résidentiel (les zones
> landuse peuvent aider à savoir qu'on est en zone résidentielle ou en
> zone industrielle et commerciale, souvent en périphérie des villes,
> avec des bâtiments souvent très différents en majorité en
> constructions métallique plus légère, plus espacés, rarement jointifs
> entre eux, et avec des tas de parkings autour).
>
> Mais comme on travaille normalement sur des imports localisés par
> quartiers à peu près homogènes, les classifications par défaut pour le
> gros des constructions peuvent être différentes.
>
> Maintenant je DWG ne devrait pas être réellement gêné si les données
> "importées" et intégrées n'ont qu'une partie des données qualifiantes.
> Si elles sont correctes géométriquement et donnent une info utile, le
> reste sera complété aussi au fur et à mesure par la méthode
> incrémentale inhérente au projet collaboratif. Il me semble en
> revanche que ce qu'on demande c'est déviter les doublons et s'assurer
> de la localisation (donc le bon calage initial des feuilles
> cadastrales, en vérifiant aussi le calage des l'imagerie, et vérifiant
> les points géodésiques).
>
> Et ne pas laisser des intersections des bâtiments intégrés avec les
> voies existantes pour que cela soit cohérent en terme de positions
> relatives des objets (souvent c'est une rue ou route qu'il faudra
> ajuster avec plus de précision en zone urbaine). Sinon le
> positionnement ultérieur des POIs sera pénible ou ambigu, ou générera
> ses propres erreurs (si on doit recaler les bâtiments et rues, que
> faire des POIs qui ont été mis dessus par collaboration incrémentale
> ?).
>
> Le 15 octobre 2012 22:31, Romain MEHUT  a écrit :
> > Le 15 octobre 2012 22:29, Rainer Kluge  a écrit :
> >
> >> 15/10/2012 16:35 Philippe Verdy:
> >>
> >>> Un truc rond qui fait 4 mètres de large n'a aucune chance d'être un
> >>> bâtiment ou une tour, quel qu&

Re: [OSM-talk-fr] lieux-dits

[Mikaël Cordon]

Moi aussi, j’en ai placé un bon paquet dans la région poitevine,
d’ailleurs. Ils viennent en grande majorité du cadastre.

Cordialement,
--
Mikaël Cordon (mickey86)

Le 16 octobre 2012 22:02, Cyrille Giquello  a écrit :

> Le 16 octobre 2012 21:18, Eric SIBERT  a écrit :
> >> 4) Concernant le tag place=locality, je l'utilise pour mapper les
> >> lieux-dits par exemple "Vallée de machin-chose", "Plaine des bidules".
> >> Des lieux inhabités mais disposant tout de même de leur propre nom.
> >> Est-ce que ce tag convient ?
>
> Je fait de même.
>
> > Moi, ça me convient.
> >
> > Éric
>
>
> --
> Cyrille.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] lieux-dits

[Mikaël Cordon]

Il est vrai que je n’avais pas percuté sur « vallée » ou « plaine »… Il me
semble qu’effectivement ça ne s’appliquerai pas, ou alors il faut une
liaison hiérarchique pour les inclusions.

Moi, je parlais des lieux-dits « La Pièce de Machin », « Le Clos de Bidule
» et autres « Le Chatrain » ou « Le Chiron Poulet » (un des plus amusant).

Je tiens à faire remarquer que certains de ces lieux-dits se nomment «
Vallée… » ou « Plaine… » et sont bien des lieux-dits notés place=locality ;
comme « La Vallée de la Digue » qui est bien une petite vallée mais trop
petite pour contenir un autre lieu-dit.

Ce dernier paragraphe étant, évidemment, pour souligner la
non-systématisation de l’association « toponymie-tag ».

Cordialement,
--
Mikaël Cordon (mickey86)

Le 17 octobre 2012 14:10, Pieren  a écrit :

> 2012/10/17 Mikaël Cordon :
> > Moi aussi, j’en ai placé un bon paquet dans la région poitevine,
> d’ailleurs.
> > Ils viennent en grande majorité du cadastre.
>
> locality, c'est pour les lieux-dits inhabités mais tout ce qui
> inhabité n'est pas forcément un locality. Beaucoup d'îles sont
> inhabitées et ça n'en fait pas automatiquement des "locality". Une
> vallée ou une plaine ou une forêt n'est pas un lieu-dit. C'est un
> espace trop vaste et qui peut contenir lui-même une multitudes de
> lieux-dits. Alors comment vous allez hiérarchiser le "locality" de  la
> vallée et les "locality" / lieux-dits qui en font partie ? Un lieu-dit
> ne peut pas en contenir d'autres et se limite à un espace
> intra-communal, ce qui est rarement le cas pour une plaine ou une
> vallée.
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Source des données dans OSM

[Mikaël Cordon]

Bonjour,

Je suivais cette affaire sans vraiment m’y impliquer, mais comme des
solutions commencent à faire leur chemin ça m’intéresse un peu plus :)

Le fait de raffiner par des sous-tags les sources me paraît être une bonne
idée ; j’y vais de ma vision des choses :
— source:type = official (reconnue juridiquement par OSM), base (une base
de données non officielle), survey (le reste, les informations apportées
par le contributeur lui-même)
— source:ref = 
— source:import = yes|no
— source:bot = yes|no
— source = 

Quant au fait que ce soit attaché au changeset ou à l’objet… Je n’ai pas
d’avis tranché :
— il est vrai que la redondance est très gênante (pour toutes les mêmes
raisons que la redondance de données (qui n’est pas une référence) est un
problème dans les bases de données relationnelles), mais finalement
nécessaire pour bien discriminer les données émanant de telle ou telle
source.
— je trouve que — par l’intermédiaire des tags source*=* — dire qu’une
donnée vient de telle source alors que ce n’est pas le cas peut être très
gênant pour OSM et la source : imaginez qu’une certaine quantité de
bâtiments tracés à la main soient attribuée au cadastre, la qualité de la
source pourrait être remise en cause. Le contraire (une donnée de meilleure
qualité attribuée à une source qui n’est pas très fiable) peut avoir les
mêmes conséquences : booster l’utilisation d’une source peu fiable. C’est
pourquoi mettre la source sur le changeset est dangereux.
— les données émanant de plusieurs sources (source + modifications)
complexifient énormément les choses et je n’ai pas encore d’avis.
— JOSM n’est pas le seul moyen d’ajouter des données. Faire un patch pour
JOSM c’est bien, ceci dit ce n’est pas la panacée… Et surtout dangereux de
faire un patch sans aller plus loin : les utilisateurs de JOSM se sentiront
en confiance (ils auront assez raison) mais cette confiance déteindra sur
les contributeurs avec un autre éditeur. Et un contributeur confiant
contribue beaucoup…

Autre remarque qui va encore compliquer l’affaire :
— il existe des données émanant de sources officielles qui ne sont pas
géographiques (ou en tout cas pas précisément), or les sources sont
attachées à des objets géographiques… Du coup on se retrouve à avoir des
données géographiques dont la source n’est pas géographique. Par exemple,
l’INSEE est une source de données administratives et non géographiques.
— l’idéal serait d’avoir un attribut de source pour un tag…
— cette remarque ressemble évidemment plus à de la masturbation
intellectuelle, mais si ça peut faire naître une idée sensée… ;)


Cordialement,
--
Mikaël Cordon (mickey86)

Le 23 octobre 2012 11:44, sly (sylvain letuffe)  a écrit
:

> On lundi 22 octobre 2012, Mickaël Guéret wrote:
> > Salut,
> >
> > est-ce qu'on pourrait conseiller d'utiliser le tag source comme
> > 'namespace' (espace de nom ??) ?
> >
> > ex:
> > - source:geometry = Bing 2012
> > - source:ref = survey
> > - source:name = cadastre-dgi-fr source : Direction Générale des Impôts -
> > Cadastre. Mise à jour : 2010
>
> Pourquoi pas, toutefois, si j'avais à le faire, je pense que je ferais
> plusieurs changeset, par soucis de clarté, de simplicité pour moi même et
> de
> meilleur compréhension pour les autres.
>
> En plus, si je suis en train de relever des noms sur le cadastre, en
> général
> je ne fais presque que ça puisqu'il faut basculer de fond de carte, et dans
> ce cas là, je préfère valider mes changements de géométries d'abord, puis
> mettre les noms et valider.
>
> Mais sinon, je n'y vois aucun inconvénient, comme on le fait d'ailleurs
> parfois pour les objets.
> Bien que l'utilisation du tag source=* étant le plus utilisé, je pense que
> je
> mettrais quand même ce tag avec la source "majoritairement utilisée" et
> j'affinerais avec des
> source:name=google maps (j'déconne ;-) )
> source:amenity=survey
> source:place=survey
> source:sac_scale=survey
> source:building=bing
> source:geometry=gps;bing
>
> Mais bon, ça fait un peu bulldozer quand même.
>
>
> --
> sly
> qui suis-je : http://sly.letuffe.org
> email perso : sylvain chez letuffe un point org
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [politique] Conditions demandées pour être membre du DWG

[Mikaël Cordon]

Fiou…

Peste, choléra… ?

Pour résumer (qu’on me dise si je me trompe) : tu dois bloquer les comptes
qui contreviennent les règles du DWG tout en pouvant dire que tu es contre
ce blocage…

En terme de communication, y’a pas un problème… ?

Cordialement,
--
Mikaël Cordon (mickey86)

Le 23 octobre 2012 12:38, sly (sylvain letuffe)  a écrit
:

> Bonjour,
>
> (Le mail d'origine étant en anglais, et en correspondance privée, j'en fais
> une traduction simplifiée et adaptée, le respect de la correspondance
> privée
> étant important pour moi)
>
> J'ai donc une bonne et une mauvaise nouvelle, je commence par la bonne ?
>
> J'ai été contacté par F. Ramm et ils m'acceptent comme membre du DWG, j'ai
> eu
> droit à une pommade de bienvenue : "vous feriez un bon membre de notre
> équipe"
>
> La mauvaise, c'est que les conditions sont en contradictions avec celles
> que
> j'avais exposées dans ma profession de foi pour représenter la communauté
> française (bien sûr, c'est toujours cette histoire de 2ème compte)
>
> En bref, ça donne :
> - Ils souhaitent que je m'investisse dans le traitements de tous les type
> de
> problèmes dont s'occupe le DWG, que ça soit en France ou non. Bien qu'ils
> acceptent qu'étant plus efficace en France, ce sont ces problèmes que je
> serais amenés à régler en particulier/priorité.
>
> - La règle du 2ème compte obligatoire pour les imports cadastre est à
> imposer
> actuellement, mais ils acceptent que je puisse indiquer, tout en bloquant
> les
> gens, que je leur disent que je suis contre cette règle, que la communauté
> française est contre cette règle et que nous comptons, dans l'avenir y
> remédier lorsque des problèmes auront été réglés concernant les imports
> faits
> avec le même compte (l'idée des tags sur les changesets étant accepté sur
> le
> principe)
>
> - Dans tous les cas ou je n'accepterais pas la règle, je suis invité à en
> discuter avec eux, expliquer en quoi elle est inadaptée (ou absurde),
> rapporter un résumé de l'avis de la communauté française, et soit accepter
> de
> ne finalement pas l'appliquer et/ou trouver des solutions à l'avenir pour
> s'en passer, (Le 2ème compte pour les imports cadastre n'étant pas dans ce
> cas actuellement : ça, ok, on a compris, c'est répété tout au long du mail)
>
> - Le refus de rejoindre notre équipe leur serait compréhensible, je
> continuerais à être contacté (ou un autre français, ou la liste [ga]) pour
> la
> communication en français, mais c'est eux qui continueraient à bloquer.
>
> Vos avis ?
> Si à la lecture de ce résumé vous êtes énervés et que votre réponse
> s'apprête
> à impliquer Hitler ou les nazis, je vous recommande d'attendre un peu (on
> réfléchi mieux à tête reposée ;-) )
>
> --
> sly
> qui suis-je : http://sly.letuffe.org
> email perso : sylvain chez letuffe un point org
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] [Cartopartie] orientée vélo le samedi 27 Octobre 2012 à 13h45 au 27 Route de Bignoux 86000 Poitiers

[Mikaël Cordon]

Salut les mappeurs,

Je me rappelle qu’il y a quelques jours/semaines VéloCité 16 souhaitait
s’investir dans le projet OSM…

Dans le mail ci-dessous, une invitation est lancée par VéloCité 86 pour une
cartopartie dédiée aux vélos ce samedi 27 octobre 2012, sur Poitiers.

Nous (APP3L et Vélocité 86) vous (Vélocité 16 et autres) attendons… Pas
trop nombreux, malheureusement, au risque de manquer de place chez
l’adhérent qui reçoit.

Cordialement,
--
Mikaël Cordon (mickey86),
Secrétaire de l’APP3L.

-- Message transféré --
De : App3l Contact 
Date : 24 octobre 2012 22:46
Objet : [app3l] Cartopartie orienté vélo le samedi 27 Octobre 2012 à 13h45
au 27 Route de Bignoux
À : ap...@freelists.org


Velocity 86 organise une catopartie à laquelle se joint l'APP3L.

Venez tous avec vos vélo (ou vos jambes), des crayons/papiers et
éventuellement des ordinateurs ou des smartphones.

Le lieu de rencontre se fera à 13h45 samedi 27 Octobre
Au LIDL
27, Route de Bignoux
86000 Poitiers

Ensuite, nous irons à 14h chez un adhérent de Vélocité 86 où nous
disposerons d'un accès à internet et commencerons à travailler.

Le LIDL n'est pas encore sur OSM, voilà le lien direct vers la carte
pour le retrouver:
http://www.openstreetmap.org/?mlat=46.58482&mlon=0.367607&zoom=16&layers=M

Vous pouvez préciser votre présence dans les commentaires de cette page:
http://www.app3l.org/comment.php?comment.news.123

--
Charles BRISSET
Trésorier de l'APP3L
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [politique] Réflexion sur la manière de choisir des règles

[Mikaël Cordon]

Je suis d’accord avec Sylvain pour mettre sur le Wiki les idées ; ça évite
de perdre les idées dans la conversation (devoir chercher tout au long de
la discussion où est exprimée l’idée de base).

Par contre, je ne fais pas (encore) partie de OSMFR, mais je suis l’affaire
et compte participer au débat… :)

Cordialement,
--
Mikaël Cordon (mickey86)

Le 23 octobre 2012 14:35, Sylvain Maillard  a
écrit :

> Je serais d'avis qu'on mette tout ça bien au clair sur une page de Wiki,
> avec un bon argumentaire et des propositions d'améliorations, puis que la
> question soit soumise sur al liste de discutions osmf-talk: à priori les
> participants à OSM qui ont décider d'adhérer à la fondation, c'est
> justement ceux qui se sentent impliqués par les problématiques de
> gouvernance et de la direction à donner au projet, et c'est le seul endroit
> où on peut initier un vote qui impacterait directement les missions du DWG !
>
>
> Sylvain
>
>
>
>
> Le 23 octobre 2012 14:26, sly (sylvain letuffe)  a
> écrit :
>
> On mardi 23 octobre 2012, Christian Quest wrote:
>> > Si ça finit en bazar, c'est bien qu'il y a un problème... sinon on
>> > serait rapidement d'accord, non ?
>>
>> Tout à fait, je dis juste qu'on peut peut-être en limiter le bazar si on
>> accepte de commencer par du concret avec des propositions, comme une page
>> wiki par exemple.
>> Et puis, comme de toute façon tes tentatives n'ont rien donné, c'est qu'il
>> faut tenter de changer l'angle d'attaque.
>>
>> > Beaucoup de personnes ne réagissent que lorsqu'elles sont impactées.
>> > C'est bien dommage car cela laisse à un trop petit nombre le champ
>> libre.
>> > Ce n'est malheureusement pas spécifique à OSM.
>>
>> Oui, et comme on ne peut pas y faire grand chose, prenons ceux qui
>> s'expriment, tant qu'on a une porte de sortie lorsqu'il y aura problème
>> pour
>> remettre en cause les lois établies, ce qui est le cas de facto.
>>
>>
>> --
>> sly
>> qui suis-je : http://sly.letuffe.org
>> email perso : sylvain chez letuffe un point org
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Mapping d'intérieur

[Mikaël Cordon]

J’y vais de mon petit commentaire aussi…

Le mapping intérieur est évidemment intéressant, mais rajoute énormément de
complexité à la carte, et comme l’a dit Pieren OSM n’est pas adapté pour
cette cartographie.

D’un autre côté, je me suis adonné à l’exercice pour les gros bâtiments
commerciaux : les couloirs dans les galeries marchandes pouvant être vus
comme des « rues » couvertes, et balisés comme des tunnels dans le bâtiment
http://www.openstreetmap.org/?lat=46.55133&lon=0.300235&zoom=18&layers=M

Autre remarque, le mapping intérieur étant intéressant pour les mal-voyants
(messages précédents), ne pas cartographier les intérieurs reviendrait à une
certaine discrimination, qui serait mal vue (sans mauvais jeu de mot)… Mais
il y a probablement d’autres discriminations impliquées par notre façon de
remplir la base dont on n’est pas conscient… Et je ne saurais dire
lesquelles.

Donc je ne suis pas pour interdire, évidemment, mais pas pour faire le
travail aussi fourni dans les bâtiments qu’à l’extérieur. Il y a
probablement un compromis entre le nécessaire et le superflus.

Le 21 juin 2011 10:55, Pieren  a écrit :

> 2011/6/20 Marc Sibert 
>
>> **
>> Il existe un tag "level" qui permet de qualifier le niveau... et en fait,
>> ça renvoie sur une page http://wiki.openstreetmap.org/wiki/Indoor_Mapping;
>> comme ça tombe bien.
>>
>>
> Il faut aussi savoir que le mapping d'intérieur est un sujet controversé
> depuis le début. Les données OSM ne supportent pas la 3D et le tag 'level'
> n'est qu'un pis-aller. Les sources sont rares et difficile à vérifier
> (surtout les parties non publiques). Sans plan, cela reste très imprécis. Et
> la juxtaposition des niveaux va rendre la zone rapidement ingérable dans les
> éditeurs classiques.
> Je vois bien les applications pour les aveugles ou pour les plans "vous
> êtes ici" mais OSM n'est pas forcément le meilleur modèle pour faire des
> plans d'architecte même si je comprends bien que certains trouvent bien
> pratique de pouvoir utiliser la suite d'outils logiciels libres développés
> pour OSM.
> Enfin, n'oubliez pas le disclaimer d'OSM (aucune garantie, blablabla). Je
> ne voudrais pas confier à un aveugle un plan que chacun peut modifier à sa
> guise...
> Dans le genre "données 3D que certains voudraient mettre dans OSM et
> d'autres non", je pense aux infrastructures souterraines qui sont
> disponibles dans certains pays ou localement (réseaux d'eau potable, usée;
> réseau électrique enterré; téléphonique; gaz, etc) et qui n'est pas bien vu
> comme import dans OSM pour les même raisons citées plus haut.
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>

Mes 2 cents.
-- 
Mikaël Cordon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] L'import du bâti...

[Mikaël Cordon]

Le dimanche 10 juillet 2011 22:12:22, keke79390 a écrit :
> Le dimanche 10 juillet 2011 à 22:03 +0200, Eric SIBERT a écrit :
> > Vous connaissiez l'import du bâti avec le cadastre... voici le gars qui 
> > dessine le bâti avec Bing : http://osm.org/go/0CAQDEIKj-
> > 
> > Alors que je traçais les rues avec le cadastre, j'ai été surpris par la 
> > non concordance du bâti avec OSM. C'est alors qu'en consultant 
> > l'historique, j'ai découvert qu'il traçait avec Bing. Sur le coup, ça 
> > m'a fait bien rire. Je trouve que c'est du gâchis d'énergie mais chacun 
> > son truc. Sauf que le même gars semble travailler surtout avec Bing et 
> > fait pas mal d'erreur. Une fois que je lui demandais pourquoi il était 
> > repassé derrière moi sur une zone en chantier, il m'a répondu:
> > "Eric Desolee! - please change Rue Georges Cayrier and correct my 
> > mistake and accept my apologies [...]". Sans parler de ses changset 
> > super explicites :
> > 
> > iweua +date du jour
> > 
> > Bon, y en a qui font du train ;-)
> > 
> > Éric
> > 
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-fr
> 
> Il y a des fous ^^
> Moi , au début , pour mon village j'ai commencé manuellement à partir du
> cadastre 

Et que dire du centre-ville (et un peu autour) de Poitiers ? ^^

Mais dès que le script d’import semi-auto était connu, j’ai quand même freiné… 
Fou, mais pas idiot ^^

> 
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
> 
-- 
Mikaël Cordon.


signature.asc
Description: This is a digitally signed message part.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] L'import du bâti...

[Mikaël Cordon]

Le 11 juillet 2011 11:58, Eric Sibert  a écrit :

> Mais dès que le script d’import semi-auto était connu, j’ai quand même
>> freiné… Fou, mais pas idiot ^^
>>
>
> Là, tu es en train de qualifier le contributeur en question de fou & idiot?
> ;-)
>

Je ne me permets pas de le traiter d’idiot… La remarque était par rapport à
mon travail, je me serais trouvé idiot si j’avais continué à tracer les
bâtiments à la main sachant que le script d’import semi-auto existait.

Là, le contributeur ne sait probablement pas que les bâtiments peuvent être
extraits automatiquement. ;)


>
> C'est vrai que voir des milliers de baraques avec source=cadastre et ne pas
> se demander comment elles sont arrivées là...


>
> Eric
>
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr<http://lists.openstreetmap.org/listinfo/talk-fr>
>



-- 
Mikaël Cordon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Retour arrière du rendu mapnik

[Mikaël Cordon]

Ok, merci pour les précisions.

Cordialement,
-- 
Mikaël Cordon.
Le dimanche 17 juillet 2011 14:48:22, Vincent Privat a écrit :
> C'est bien ça, confirmé sur le bugtracker:
> http://trac.openstreetmap.org/ticket/3908
> Les tuiles affichés sont des "vieilles" copiées avant le début de la
> maintenance.
> Vincent
> 
> Le 16 juillet 2011 12:53, Vladimir Vyskocil  a
> écrit :
> 
> > Hello,
> >
> > J'ai remarqué la même chose.
> > D'apres http://wiki.openstreetmap.org/wiki/Platform_Status le server de
> > tuiles est en maintenance ainsi que d'autres services cela peut, peut etre
> > expliquer ce phénomène...
> > Wait&see...
> >
> > Vlad.
> >
> > On 16 juil. 2011, at 11:28, Mickey86 wrote:
> >
> > > Salut !
> > >
> > > Je surveille la zone [
> > http://www.openstreetmap.org/?lat=46.56041&lon=0.32846&zoom=17&layers=M]
> > que j’avais fort complété ces derniers temps qui était en ligne correctement
> > jusqu’à hier ou avant hier.
> > > Voilà qu’aujourd’hui je constate que les tuiles du niveau 17 et 18 sont
> > revenus à l’état d’il y a plus de 15 jours…
> > >
> > > Une explication ?
> > >
> > > PS : c’est en plus une zone que j’avais cartographié pour l’anniversaire
> > de notre GULL (APP3L, Poitiers), demain ! Déjà que la météo n’est pas avec
> > nous et qu’on a eu des problèmes de réservations d’activité, je vais finir
> > par croire qu’il y a une conspiration…
> > >
> > > --
> > > Mickey86
> > > ___
> > > Talk-fr mailing list
> > > Talk-fr@openstreetmap.org
> > > http://lists.openstreetmap.org/listinfo/talk-fr
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-fr
> >
> 


signature.asc
Description: This is a digitally signed message part.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Les bâtisseurs du désert - Carte des imports de bâtiments sans voies

[Mikaël Cordon]

Tout à fait d’accord également,

Le 19 juillet 2011 09:47, Ophélie PETIT
a écrit :

> Entièrement d'accord,
> De plus, la présence de bâtiments sans route indique qu'il en existe
> obligatoirement une et incite à la tracer ^^
> Ces bâtiments permettent également de se situer dans l'espace.
> Enfin après c'est un point de vue personnel.
>

Un point de vue partagé par moi également et — pour en avoir déjà discuté de
vive voix avec eux — bien d’autres contributeurs.

Et j’ajouterais qu’OSM n’a jamais trop de contributeurs, et que si on
commence à contraindre leur façon de travailler, vu que la plupart font ça
en tant que passe-temps, pour se relaxer ou s’amuser, on perdra des
contributeurs !

Il ne faut pas oublier qu’un projet libre comme celui-là ne contrôle pas ses
ressources humaines ainsi que peuvent le faire des entreprises ou d’autres
projets moins ouverts.

Malgré cela, je trouve qu’OSM est pourtant bien structuré et que la majorité
des contributeurs suivent le même chemin alors qu’ils n’y sont pas obligés…
N’en demandons pas trop ; laissons agir la magie du libre, ou en
l’occurrence, la contribution collective/collaborative/participative
(entourez les mentions applicables).


>
> Le 19 juillet 2011 09:26, ades_f...@orange.fr  a
> écrit :
>
> Effectivement intéressant, cependant j'ai un petit doute quant à l'opinion,
>> souvent exprimée ici, de la nécessité d'avoir les routes avant le bâti.
>> Ça a déjà été discuté, mais je pense que ce n'est pas très grave que le
>> bâti soit importé avant les voies, d'abord parce que ça n'empêche pas de
>> mettre les voies ultérieurement et, ensuite, pour les zones vierges, ça
>> donne une base saine (enfin à peu près, compte tenu des imprécisions
>> topographiques du cadastre) pour le tag des constructions, comme pour
>> l'import de traces gps ou le décalque des voies à partir de Bing par
>> exemple.
>> Ça évite aussi, lorsque les contributeurs ne sont pas au courant de cette
>> possibilité d'import, d'avoir du bâti dessiné (à partir de bing ou du
>> cadastre) déjà  taggé et qu'il faudra mettre en cohérence lors d'un apport
>> ultérieur du cadastre.
>>
>> Le 17 juil. 2011 à 22:22, Vincent Pottier a écrit :
>>
>> > Le 17/07/2011 19:18, Frédéric Rodrigo a écrit :
>> >> Bonjour,
>> >> J'ai réalisé une carte de l'import du bâti en fonction de la présence
>> de highway dans la zone.
>> > Génial !
>> >> [...]
>> >>
>> >> La route est longue, oui très longue.
>> > Mais la voie est libre...
>> > (lu quelque part ;-) )
>> >> Fred
>> > --
>> > FrViPofm qui pense que les routes sont faites pour relier les hommes ;-)
>> >
>> >
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org
>> > http://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Mikaël mickey86 Cordon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Les bâtisseurs du désert - Carte des imports de bâtiments sans voies

[Mikaël Cordon]

Le travail bâclé est regrettable, j’en conviens ; mais c’est un autre
problème… [On ne supprime pas les voitures de la route parce qu’elles sont
dangereuses entre les mains de certains conducteurs.]

D’ailleurs, il existe aussi des contributeurs qui font des erreurs sur les
voies et les POI… Seulement ici, ça effraie parce que les bâtiments sont
entrés en masse ; mais je ne suis pas certains que les erreurs sur les
bâtiments soient plus délétaires à la carte que les erreurs sur les voies de
circulation ou les POI. (C’est un jugement personnel)

Ce n’est évidemment pas une raison pour laisser faire les sagoins du bâtis,
mais ce n’est pas l’import lui-même qu’il faut incriminer.

Et puis je ne suis pas sûr que le terme « écrasante majorité » soit adapté,
c’est trop précis comme terme ; en revanche, « beaucoup trop » c’est
certainement ce que j’utiliserais en tant que OSMeur passionné. :)

Le 19 juillet 2011 15:18, Philippe Pary  a écrit :

> Le mardi 19 juillet 2011 à 09:47 +0200, Ophélie PETIT a écrit :
> > Entièrement d'accord,
> > De plus, la présence de bâtiments sans route indique qu'il en existe
> > obligatoirement une et incite à la tracer ^^
> > Ces bâtiments permettent également de se situer dans l'espace.
> > Enfin après c'est un point de vue personnel.
>
> Oui mais non.
>
> De manière empirique, on constate que dans la plupart des cas, l'import
> du bâti sans voies est le fait de contributeurs qui ne passent même pas
> un coup de validateur (des bourrins quoi) et que les voies
> n'apparaissent que tardivement de la part d'un autre contributeur.
>
> Le bâti seul n'indique pas grand chose ; l'import des zones urbaines de
> CLC indiquait déjà clairement les endroits où devraient se trouver des
> voies.
>
> Quand à la situation dans l'espace, elle n'a de sens, selon moi, que
> pour repérer les usages des bâtiments. Autrement dit quand on se casse
> la tête à indiquer les POI. C'est rarement le cas des gens qui importent
> le bâti sans voirie.
>
> L'opposition que j'ai à l'import du bâti sans voirie tient donc au
> constat que dans l'écrasante majorité des cas, il s'agit de bourrinage
> jamais suivi d'une phase d'affinage.
> Bref, du travail bâclé.
>
> Philippe
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Mikaël mickey86 Cordon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] admin_level = 9

[Mikaël Cordon]

J’ajouterais une méfiance : il arrive que les codes postaux ne correspondent 
pas aux limites administratives… Il existe des communes dans la Vienne (86) 
ayant un code postal commençant par 37 (Indre et Loire) pour des raisons de 
proximité de centre de tri (ceci est sûrement valable ailleurs que dans la 
Vienne).

Par exemple : la commune de Buxeuil [1] se trouvant géographiquement dans la 
Vienne (86) a pour code INSEE 86042, et pour code postal 37160 (37 — Indre et 
Loire).

[1] http://www.openstreetmap.org/?lat=46.97105&lon=0.69518&zoom=16&layers=M

Il existe des bizarreries (probablement d’ordre historique et qui perdurent) 
qui pourraient mettre le « wise » dans nos théories bien carrées :)

Le mardi 13 septembre 2011 17:36:09, Pieren a écrit :
> 2011/9/13 sly (sylvain letuffe) :
> > Le code postale d'un bâtiment à pour valeur celui de la commune dans
> > laquelle il se trouve, sauf s'il existe un polygone administratif
> > (boundary=administrative) entièrement contenu dans la commune et ayant un
> > tag addr:postcode ou s'il porte directement un code postal.
> > 
> > En gros : plus c'est petit, plus ça a raison
> 
> Ca ne peut fonctionner que si les découpages administratifs supérieurs
> à 8 (arrondissements, quartiers) correspondent aussi aux découpages
> postaux. C'est le cas sur Paris, mais est-ce le cas dans les autres
> villes qui ont plusieurs codes postaux ?
> 
> Pieren
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

Cordialement,
-- 
Mikaël Cordon

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

Re: [OSM-talk-fr] admin_level = 9

[Mikaël Cordon]

En revanche, s’il s’avère qu’une zone administrative suffisamment petite n’a 
qu’un seul code postal, il suffit de ne pas interpréter le code postal, et le 
traiter comme un vulgaire numéro à l’instar de la population ou d’une 
coordonnée géographique. Et du coup ça a sa place dans la base OSM. 

Mais ce numéro ne sera pas déductible de l’appartenance à une zone 
administrative, et d’ailleurs les 3 derniers numéros ne l’ont jamais été 
(déductibles), et maintenant on sait que les 2 premiers ne le sont pas non 
plus. Aucun problème donc à le traiter comme un vulgaire numéro. Il n’y a que 
des exceptions, ou autrement dit, il n’y en a pas. :)

Le mardi 13 septembre 2011 18:36:27, sly (sylvain letuffe) a écrit :
> On mardi 13 septembre 2011, Aurélien FILEZ wrote:
> > Je pense qu'il ne faut pas faire de relation entre les codes postaux et
> > les limites administratives, vu que comme dit plus haut, ça n'a rien à
> > voire.
> 
> Moi je pense que si, car ce qui a été dis plus haut est en partie faux.
> Ça n'est certes pas valable tout le temps (il existe des contre exemples)
> mais j'ai l'impression que c'est une grande majorité des cas. Le cadastre
> indique d'ailleurs le code postal en même temps que le code INSEE des
> communes, il y a donc un lien, mais il y'a des exceptions, à nous de les
> traiter (ou pas du tout).
> 
> Après, franchement, si c'est pour importer des pack de polygones postaux
> que nous n'aurions aucun intérêt à toucher et se retrouver avec un super
> tag : "hé-ho-pas-touche=yes", moi je dis que ça n'a rien à faire dans osm
> et autant laisser à à ceux qui le gère ou ailleurs.
> 
> > Aussi, dans le département 59, qu'une ville ait un code 59XXX ou 62XXX,
> > ça change quoi concrètement ?
> 
> ça pas là que ça poser problème en effet.

-- 
Mikaël Cordon

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

Re: [OSM-talk-fr] Reportage TV : demande de conseils

[Mikaël Cordon]

Salut voisin !

Je ne sais pas si ça peut t’aider, mais pour appuyer un argument ou un autre, 
sur Poitiers, suite à l’article de Centre-Presse « Des GPS toujours perdus 
dans la ville » [1], nous (APP3L[2]) avons contacté Centre-Presse pour donner 
écho à cet article qui nous a fait doucement rigoler : « L'association qui 
donne des ailes aux GPS » [3]…


[1] L’article raconte que depuis que le centre ville de Poitiers a changé 
(sens de circulation et fermeture à la circulation) le 1er septembre 2010, 
aucune carte commerciale équipant les GPS-routiers n’était à jour encore le 30 
juillet 2011 (et d’ailleurs toujours pas aujourd’hui)… L’article n’est plus 
disponible gratuitement, dommage.

[2] Association Poitevine pour la Promotion de Linux et des Logiciels Libres

[3] http://www.centre-presse.fr/article-166567-l-association-qui-donne-br-des-
ailes-aux-gps.html … pour l’instant encore gratuit.


Le lundi 26 septembre 2011 20:09:24, Pierre-Alain Dorange a écrit :
> Bonjour,
> 
> Suite à un article de presse local (Charente Libre) sur mon cas et ma
> passion de la cartographie (et d'OSM bien sur) une journaliste de France
> 3 M'a contacter pour faire un petit documentaire de 3 minutes sur mon
> cas.
> 
> Si j'ai bien compris, il s'agit de mettre en valeur des gens et leur
> passion et de montrer que c'est possible...
> 
> Bon le sujet sera OSM à Cognac, la journaliste veut me voir travailler
> sur site (j'ai choisit un quartier populaire que je connais pas trop et
> ou il faut que je fasse des vérifications) et elle voudrait montrer le
> process : relevé sur le terrain (j'ai pas de GPS je fais tout avec
> WalkingPapers, photos, ipad, etc...) et puis la saisie ensuite dans OSM.
> 
> Si vous avez des conseils, des pistes, des trucs a absolument pas
> oublier ou d'autres a cacher ;-)
> 
> Merci.
> 
> L'article :
> <http://www.charentelibre.fr/2011/08/17/militant-a-la-rue-par-passion,10
> 50372.php>
> 
> Je suis d'avance désolé pour les termes que le journaliste m'attribu en
> disant que "jai réalisé la carte de cognac libre"... c'est bien sur un
> travail collectif, même si sur Cognac je suis quasiment le seul actif
> depuis 2 ans.

Cordialement,
-- 
Mikaël Cordon

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

Re: [OSM-talk-fr] Wacom Bamboo

[Mikaël Cordon]

Bonjour,

Personnellement j’ai une tablette graphique Wacom Graphire4 que j’ai depuis
des années, et je dois dire que placer des points avec la tablette sous JOSM
c’est très confortable, précis et rapide, en revanche ça prend de la place
sur le bureau et il faut tout de même avoir une main à proximité du clavier
pour les touches de raccourcis.

Le 4 octobre 2011 09:56,  a écrit :

> Le 04/10/2011 09:41, Fanny Schertzer a écrit :
>
>  Bonjour,
>>
>> Je suis nouvelle sur cette liste, sur OSM un peu moins. Pour me
>> présenter rapidement, je mappe surtout les routes de France et quelques
>> POIs au gré de mes déplacements.
>>
>> J'ai une vieille tablette graphique Wacom qui ne convient pas vraiment
>> pour éditer, je travaille surtout à la souris et au trackpad, sous JOSM
>> et Potlatch. Il y a une Bamboo Fun Small en vente flash aujourd'hui sur
>> http://qoqa.ch et je voudrais savoir si certains d'entre vous
>> connaissent, et ce qu'ils en pensent pour la carto.
>>
>
> pour moi la question n'est pas de savoir si c'est pour de la carto ou autre
> mais de savoir pour quel type de graphisme
>
> pour dessiner, c'est a dire faire des traits avec tout le travail des
> courbes et la souplesse du poignet qui correspond au dessin artistique, les
> tablettes graphiques sont un tres bon outil
>
> quand on edite OSM on ne fait que placer des points, le travail n'est pas
> la ligne et l'esthetique de la courbe mais bien de viser precisement des
> points, et pour ce travail la rien de tel que la souris
>
> je pense que les ecrans tactiles sur lesquels on pointe avec un stylet ont
> des chances d'etres efficaces, mais a condition que le stylet permette un
> pointage precis, au pixel pres, mais dans ce qui existe (genre ipad) on a
> pas cette precision
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr<http://lists.openstreetmap.org/listinfo/talk-fr>
>


Cordialement,
-- 
Mikaël Cordon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] fdg près de Poitiers ???

[Mikaël Cordon]

Salut,

Je suis de Poitiers et j’ai des collègues qui habitent tout près de
l’endroit où apparaissait ce fameux « fdg ». Je leur ai demandé si ça leur
évoquait quelque chose, mais personne ne sait d’où ça vient ni à quoi ça
pourrait correspondre.

Donc, je pense que l’information était soit une erreur ou une annotation
personnelle mal « taguée ».

Le 28 novembre 2011 17:37, Maetma 91  a écrit :

> Le 28 novembre 2011 17:34, Vincent Pottier  a écrit :
>
> Le 28/11/2011 16:57, Marc SIBERT a écrit :
>>
>>> Testé rapidement sur la XAPI de Mapquest sans succès :
>>>
>>> http://open.mapquestapi.com/**xapi/api/0.6/node[name=fdg]<http://open.mapquestapi.com/xapi/api/0.6/node%5Bname=fdg%5D>
>>> http://open.mapquestapi.com/**xapi/api/0.6/way[name=fdg]<http://open.mapquestapi.com/xapi/api/0.6/way%5Bname=fdg%5D>
>>> http://open.mapquestapi.com/**xapi/api/0.6/relation[name=**fdg]<http://open.mapquestapi.com/xapi/api/0.6/relation%5Bname=fdg%5D>
>>>
>>> en plus cette xapi n'aime pas les "*".
>>>
>>> A voir ce soir sur un planet en sqlite...
>>>
>>> A+
>>>
>>
>> Pas trouvé sur ma base France en local (qui n'est pas toute fraîche : ~
>> 10 jours) avec
>>
>> SELECT osm_id, name
>> FROM france_polygon
>> WHERE
>>ST_WITHIN(ST_SetSRID(ST_POINT(**0.39928795776361,
>> 46.519490016171),4326), way)
>>
>> -7377;"Vienne"
>> -8652;"Poitou-Charentes"
>> -1662877;"Poitiers"
>> -140475;"Nouaillé-Maupertuis"
>> 41785320;""
>>
>>
>> Une nouvelle forme d'OVNI ?
>> --
>>
>> Les tuiles en question dataient du 5 novembre. Après avoir forcé un petit
> rafraichissement tout est rentré dans l'ordre.
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>

Cordialement,
-- 
Mikaël Cordon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import des bâtiments, Adresses des bâtiments, et plugin

[Mikaël Cordon]

+1

Le 2 avril 2010 14:51, Etienne Trimaille  a écrit :
> C'est vrai que les relations, c'est plus propre au niveau de la
> modélisation. Cela évite la redondance du nom de la rue. Avec une relation,
> si le nom de la rue change(erreur de toponymie ou autre), il n'y a pas de
> problème de mise à jour pour chaque bâtiment.
>
> Le top serait un plugin : on sélectionne les bâtiments taggés avec le
> housenumber, on sélectionne en même temps les morceaux de rues concernées,
> et on clique sur un bouton (ou raccourcie clavier) "création relation
> associatedStreet", et hop, tout automatique : type=associatedStreet,
> name=nom de la rue, avec les membres et les rôles respectifs aux highways et
> aux buildings.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>



-- 
Mikaël Cordon

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

Re: [OSM-talk-fr] Présentation OpenStreetMap à l 'UNESCO

[Mikaël Cordon]

Plutôt encourageant, alors ! Impeccable :)

Le 27 avril 2010 15:06, RatZilla$  a écrit :
> Bonjour à tou[te]s
>
> J'ai rencontré des équipe de l'UNESCO vendredi matin, elle sont
> emballées par les possibilités d'OSM.
> En plus des questions classiques sur la qualité des données j'ai eu
> des questions que je détaillerai ci-dessous.
> Je vais discuter dans les semaines à venir dans quelles mesures les
> données géographiques propriétaires de l'UNESCO peuvent être données à
> OSM.
>
> -Il n'y a pas de réticences particulières pour le triplet (Nom du site
> / Latitude / Longitude) en revanche les commentaires associés sont
> propriétaires (ce n'est pas grave ;-)
> -Quid de la charge des serveurs si OSM est utilisé pour valoriser le
> patrimoine référencé à 'UNESCO je n'ai pas encore de chiffre mais il y
> a des données planète entière dans beaucoup de domaines.
> -Pour l'instant c'est Google qui a à sa charge la gestion de la bande
> passante, l'UNESCO n'a pas forcément les ressources (Bande passante,
> personnel, etc ... pour gérer ça ... un piti don ... à voir)
> -Certains états de veulent pas voir apparaitre leurs frontières
> (Openlayers pourrait régler ça ???)
> -Il y a des tonnes de cartes dans des tonnes projections à numériser
> (OSGéo / Qgis / Gdal / OpenStreetMap pour monter une méthode
> "industrielle"?)
> -Il y a des données qui leurs posent des problèmes de représentation
> là aussi j'attends nos futurs rencontres pour en avoir le détail.
>
> Dans l'ensemble IL Y A UN BOULOT ÉNORME et des volontés pour libérer
> et transmettre.
> Je reviendrai vers vous au fur et à mesure de la remontée des projets.
>
> Gaël
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Mikaël Cordon

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

Re: [OSM-talk-fr] HELP les polygones CLC ont bougés au ssi

[Mikaël Cordon]

Hum,

http://www.openstreetmap.org/?lat=46.595&lon=0.194&zoom=11&layers=B000FTF
[un polygone CLC (je suppose) « étiré » vers le sud.]

Je pense que cet effet artistique (douteux certes :p) est lié… Peut-on 
confirmer ?

Hier j’ai édité la carte juste à côté de cette zone, je n’ai touché qu’à la 
voirie, je doute y être pour quelque chose.

Cordialement,
-- 
Mikaël Cordon
mikael.cor...@gmail.com
06 74 92 69 43 — 09 52 89 02 08
30 rue Saint-Hilaire 86000 Poitiers
Le mercredi 30 juin 2010 03:51:59, Benoît ROUSSEAU a écrit :
> Bonjour,
> 
> Alors là je ne sais pas quoi faire ! Malgré le filtrage, sous JOSM, des
> polygones CLC, ils étaient pris dans le déplacement... Je ne comprends pas.
> 
> Mon revert n'a pas fonctionné, le décalage est beaucoup plus important,
> et les polygones CLC ont été pris dans le mouvement... J'en était à
> supprimer les bâtiments pour refaire un import quand j'ai vu ça.
> 
> Si qqun à une solution simple pour remettre en ordre... Sinon je vais
> peaufiner mon revert en transférerant la zoneconcernée  sur le serveur
> de dev.
> 
> J'enrage ! D'autant plus que l'API sera indispo plusieurs jours.
> 
> A demain...
> Benoît R.
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] [Tech] Extraction des adresses...

[Mikaël Cordon]

Le 19 juillet 2010 08:24, Benoît ROUSSEAU  a écrit :
> Mickey86 a écrit :
>
> Le lundi 19 juillet 2010 07:31:03, hamster a écrit :
>
>
>  Benoît ROUSSEAU a écrit :
>  Les adresses sont maintenant déplacées à x mètres du centre de la voie
> tracée dans OSM (plus propre) et notées sur les erreurs potentielles
>
>
>  et mettre l'adresse en question sur le batiement le plus proche et non pas
> a x metre de la voie, ca serait faisable ? variante : mettre l'adresse
> sous forme d'un noeud sur le chemin du batiment le plus proche, en
> positionnant du cote ou le chemin du batiment est le plus proche de la rue
>
>
> C'est possible, mais le risque d'erreur me semble beaucoup trop élévé. Pour
> ce qui est d'un nœud ou le bâtiment c'est du pareil au même côté
> programmation.
>
> Ou à la limite de la parcelle si le bâtiment est trop loin.
>
>
>
> C'est possible aussi mais là encore, le risque d'erreur me semble trop
> élevé.
>
> Beaucoup de parcelles ou de bâtiments sont loin de leur n° de voie (allées
> privées, bât imbriqués, ...) ou proches d'une autre (toutes les
> intersections, ..).  Les bâtiments sont parfois nombreux pour une adresse.
> Faut-il tous les n°ter, faut-il risquer de n°ter la grange ? A avoir bossé
> sur les adresses, j'ai changé d'avis sur les méthodes de numérotation. J'ai
> essayé les deux systèmes de n°tation bât et plaques. La signification
> première de ces numéros c'est un repérage lié à et dans la rue. Donner un n°
> à un bâtiment à moins de sens et quand on cherche un n° de rue on cherche à
> se positionner au sein de cette rue. Et penser aux bâtiments à plusieurs
> adresses (aux croisements, ceux qui donnent sur deux rues devant derrière,
> ...). Finalement les plaques de n° sont les plus utiles et ce qui fait le
> plus sens, le n° est bien lié à la rue.

Je suis tout à fait d’accord ! :)

En fait, ma proposition de mettre sur la limite de parcelle était dans
un soucis de placement automatique sachant que la parcelle le plus
souvent colle la rue, plutôt qu’une distance arbitraire par rapport au
centre de la rue (ce qui dépend de la largeur de la rue).
Et dans les faits, lorsque le bâtiment ne colle pas la limite de la
parcelle et si le bâtiment est assez éloigné, à la main je positionne
le numéro sur la limite de la parcelle. Mais c’est une méthode
personnelle.

>
> Benoît R.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>



-- 
Mikaël Cordon

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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel

[Mikaël Cordon]

J’ai suivi un peu ce fil de discussion, et j’ai effectivement l’impression 
qu’une certaine obscurité reigne chez certains.

Ceci dit, je n’ai pas encore pris la peine de cartographier les pistes et 
bandes cyclables. Aussi, c’est avec un œil assez neuf et intuitif (je n’ai pas 
lu précisément le wiki à ce sujet, mais en dehors des vélos, j’ai une certaine 
expérience). Alors j’ai répondu au QUIZZ avec la sensation d’avoir des 
réponses et une modélisation cohérentes. J’ai lu les questions, posé les 
balises modélisant chaque objet et condition, et je les ai combiné.

1. Une rue à double-sens (highway=*) dispose d'une bande cyclable 
(cycleway=lane) que d'un côté,

highway=* ; cycleway=lane (on pourrait préciser :left ou :right)


2. Une rue à sens unique (highway=* ; oneway=1) dispose d'une bande cyclable 
(cycleway=lane) pour aller du Sud vers le Nord (oneway:bicycle=1) et d'une 
piste (cycleway=track) pour aller du Nord vers la Sud (oneway:bicycle=-1). Je 
mappe :

highway=* ; oneway=1 ; cycleway=lane,opposite_track ; oneway:bicycle=1


3. Une rue, à double-sens (highway=*), dispose d'une piste cyclable de chaque 
côté (cycleway:left=track ; cycleway:right=track).

si le sens des pistes n’est pas précisé :
highway=* ; cycleway:left=track ; cycleway:right=track
si il est implicite qu’il y a un seul sens par piste :
highway=* ; cycleway:left=track ; cycleway:right=opposite_track ; 
oneway:bicycle=1 (ou -1 selon le sens à donner alors)


4. Une rue (highway=*), à sens unique (oneway=1), dispose d'une bande cyclable 
(cycleway=lane) pour aller du Sud vers le Nord (oneway:bicycle=1), placée côté 
gauche (cycleway:left=lane). Je mappe :

highway=* ; oneway=1 ; cycleway:left=lane ; oneway:bicycle=1


5. Je suis en Angleterre (on s’en moque). Une rue (highway=*), à sens unique 
(oneway=1), dispose d'une bande cyclable (cycleway=lane) en contre-sens 
(oneway:bicycle=-1). Je mappe :

highway=* ; oneway=1 ; cycleway=lane ; oneway:bicycle=-1
ou
highway=* ; oneway=1 ; cycleway=opposite_lane ; oneway:bicycle=1


6. Une rue à sens unique (highway=* ; oneway=1) dispose de marquages répétés 
au sol, chevrons+sigle cycliste (bicycle=yes), dans le même sens de 
circulation (oneway:bicycle=1). Je mappe :

highway=* ; oneway=1 ; bicycle=1 ; oneway:bicycle=1
Comme cycleway n’apparaît pas on pourrait le faire apparaître comme 
suit :
highway=* ; oneway=1 ; cycleway=share_highway ; oneway:bicycle=1


7. Une rue à sens unique (highway=* ; oneway=1) dispose de marquages répétés 
au sol, chevrons+sigle cycliste (bicycle=yes), dans le sens contraire de 
circulation (oneway:bicycle=-1). Je mappe :

Même chose que 6. mais le sens des cyclistes est opposé :
highway=* ; oneway=1 ; bicycle=1 ; oneway:bicycle=-1
Comme cycleway n’apparaît pas on pourrait le faire apparaître comme 
suit :
highway=* ; oneway=1 ; cycleway=share_highway ; oneway:bicycle=-1


8. Une rue à sens unique (highway=* ; oneway=1) dispose d'une bande cyclable 
(cycleway=lane) en sens contraire (oneway:bicycle=-1) à ses extrémités, sur 
10m (je découpe le « way »), puis de marquages répétés au sol, chevrons+sigle 
cycliste, sur le reste de la rue (bicycle=yes). Je mappe :

sur les extrémités coupées :
highway=* ; oneway=1 ; cycleway=lane ; oneway:bicycle=-1
ou
highway=* ; oneway=1 ; cycleway=opposite_lane ; oneway:bicycle=1
sur le reste :
highway=* ; oneway=1 ; bicycle=1 ; oneway:bicycle=-1
ou
highway=* ; oneway=1 ; cycleway=share_highway ; oneway:bicycle=-1


9. Une rue à sens unique (highway=* ; oneway=1) dispose d'un couloir de bus 
(busway=lane) en sens contraire (oneway:bus=-1) autorisé au vélo 
(bicycle=yes). Je mappe :

highway=* ; oneway=1 ; busway=lane ; oneway:bus=-1 ; bicycle=1 ; 
oneway:bicycle=-1 (ici on ne voit pas que le vélo partage la voie des bus)
ou
highway=* ; oneway=1 ; busway=lane ; oneway:bus=-1 ; 
cycleway=share_busway 
; oneway:bicycle=-1


10. Une rue (highway=*), à sens unique (oneway=1), dispose d'un couloir de bus 
(busway=lane) pour aller du Sud vers le Nord (oneway:bus=1), placée côté 
gauche (busway:left=lane). Laquelle bande de bus dispose d'une bande cyclable 
(cycleway=share_busway), placée côté gauche sur cette même bande 
(cycleway:left=lane). Je mappe :

highway=* ; oneway=1 ; busway:left=lane ; oneway:bus=1 ; 
cycleway=share_busway ; cycleway:left=lane ; oneway:bicycle=1 (ici c’est la 
combinaison de cycleway=share_busway et cycleway:left=lane qui permet de 
déduire que la bande cyclable est sur la voie de bus)


11. Un couloir de bus à double-sens (busway=lane) n'autorise les vélos 
(bicycle=yes) dans le sens sud->nord (oneway:bicycle=1). Je mappe :

busway=lane ; bicycle=1 ; oneway:bicycle=1
ou
busway=lane ; cycleway=share_busway ; oneway:bicycle=1


12

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel

[Mikaël Cordon]

es sens et les placements sont dépendants du tracé seulement, ainsi 
pas 
de torture d’esprit lorsqu’on change la valeur d’un oneway
— international (le sens est directement déduit du schéma, et pas 
interprêté selon les lois-en-vigueur-du-pays-traversé-que-personne-ne-connaît-
totalement, visiblement)
— décrit une large gamme de situations de manière univoque (1 schéma ⇒ 
un 
ensemble de tags ; ce même ensemble de tags ⇒ le même schéma)
— on connaît déjà ce schéma, on l’utilise pour les highways !


Inconvénients :
— nécessite probablement l’utilisation de plus (1 voire 2 de plus par 
situation) de balises que ce qui est décrit dans le wiki, (mais nécessaires 
pour lever les ambiguïtés)
— vu que chacun y va de son interprétation du wiki, il y aura des 
remaniments à faire, mais ce n’est pas propre à ce modèle.


À propos de dupliquer les tracés pour modéliser des voies supplémentaires : 
— mauvaise idée : 
— topologiquement c’est une erreur de séparer deux voies qui 
suivent 
le même tracé.
— allourdissement du schéma, et de la base (mais c’est 
secondaire)
— masque aux utilisateurs (calculateurs, GPS, etc.) qu’ils 
peuvent 
éventuellement passer d’une voie à l’autre (si nécessaire ; par ex. travaux 
sur une voie et passer sur celle d’à côté)
— pas si mauvaise idée pour les cas vraiment complexes, ou les voies 
physiquement séparées (tracks).


Voulons-nous une carte qui soit faite de brics et de brocs dont il faut 
deviner la signification ou une carte utilisable et non ambigüe ?


Dites-moi si je suis complètement à côté de la plaque. :)
> 
> 
> Jocelyn
> 
> 
> 
> (excusez pour l'erreur de manip'...)

Cordialement,
-- 
Mickey86
Mikaël Cordon

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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel

[Mikaël Cordon]

Le mardi 27 juillet 2010 23:26:01, Lapinos03 a écrit :
> Ouille ouille! Stop les oneway:=1/-1 à gogo! Le but du jeu, c'est de
> faire simple et dans la concision, mais sans rogner sur la qualité et la
> précision.

Faire simple pour qui ? Pour nous ? Pour les futurs utilisateurs (lecteurs, 
développeurs, GPS) ?

Mais alors comment indiquer les sens de circulation de chacune des voies alors 
? En faisant tout hériter les sens de circulation des unes des autres ? En 
jouant avec les opposite_* ?

Évidemment, si on veut préciser le sens des voies dans un système multiple, il 
faut un moyen d’identifier le sens de chacune des voies du groupe, sachant 
qu’on ne peut pas déduire le sens dans toutes les situations, ou alors il faut 
jouer avec les « opposite_* », mais alors ça revient à multiplier les valeurs 
plutôt que les tags ; c’est un choix, mais si on veut rester cohérent avec le 
modèle des highways…

Je trouve que les oneway ont le mérite d’être simple et sans équivoque : 
oneway=1 ou yes ⇒ dans le sens du tracé, point.
oneway=-1 ou no ⇒ dans le sens opposé du tracé, point.
Si oneway n’est pas précisé, alors aucun sens privilégié ⇒ les deux sens, 
point.

Je ne vois pas ce qu’il y a de compliqué là-dedans, il suffit de préciser. Il 
n’y a aucun calcul d’héritage de sens circulation ou de déduction, il suffit 
de lire.

Ne me dites pas que vous êtes flemmard pour 1 tag par voie ? Vous qui avez 
déjà créé des milliers de tracés et de nœuds :)

> 
> Mikaël Cordon a écrit :
> > J’ai suivi un peu ce fil de discussion, et j’ai effectivement
> > l’impression qu’une certaine obscurité reigne chez certains.
> > 
> > Ceci dit, je n’ai pas encore pris la peine de cartographier les pistes et
> > bandes cyclables. Aussi, c’est avec un œil assez neuf et intuitif (je
> > n’ai pas lu précisément le wiki à ce sujet, mais en dehors des vélos,
> > j’ai une certaine expérience). Alors j’ai répondu au QUIZZ avec la
> > sensation d’avoir des réponses et une modélisation cohérentes. J’ai lu
> > les questions, posé les balises modélisant chaque objet et condition, et
> > je les ai combiné.
> > 
> > 1. Une rue à double-sens (highway=*) dispose d'une bande cyclable
> > (cycleway=lane) que d'un côté,
> > 
> > highway=* ; cycleway=lane (on pourrait préciser :left ou :right)
> > 
> > 2. Une rue à sens unique (highway=* ; oneway=1) dispose d'une bande
> > cyclable (cycleway=lane) pour aller du Sud vers le Nord
> > (oneway:bicycle=1) et d'une piste (cycleway=track) pour aller du Nord
> > vers la Sud (oneway:bicycle=-1). Je
> > 
> > mappe :
> > highway=* ; oneway=1 ; cycleway=lane,opposite_track ; oneway:bicycle=1
> > 
> > 3. Une rue, à double-sens (highway=*), dispose d'une piste cyclable de
> > chaque côté (cycleway:left=track ; cycleway:right=track).
> > 
> > si le sens des pistes n’est pas précisé :
> > highway=* ; cycleway:left=track ; cycleway:right=track
> > si il est implicite qu’il y a un seul sens par piste :
> > highway=* ; cycleway:left=track ; cycleway:right=opposite_track ;
> > 
> > oneway:bicycle=1 (ou -1 selon le sens à donner alors)
> > 
> > 
> > 4. Une rue (highway=*), à sens unique (oneway=1), dispose d'une bande
> > cyclable (cycleway=lane) pour aller du Sud vers le Nord
> > (oneway:bicycle=1), placée côté
> > 
> > gauche (cycleway:left=lane). Je mappe :
> > highway=* ; oneway=1 ; cycleway:left=lane ; oneway:bicycle=1
> > 
> > 5. Je suis en Angleterre (on s’en moque). Une rue (highway=*), à sens
> > unique (oneway=1), dispose d'une bande cyclable (cycleway=lane) en
> > contre-sens
> > 
> > (oneway:bicycle=-1). Je mappe :
> > highway=* ; oneway=1 ; cycleway=lane ; oneway:bicycle=-1
> > ou
> > highway=* ; oneway=1 ; cycleway=opposite_lane ; oneway:bicycle=1
> > 
> > 6. Une rue à sens unique (highway=* ; oneway=1) dispose de marquages
> > répétés au sol, chevrons+sigle cycliste (bicycle=yes), dans le même sens
> > de
> > 
> > circulation (oneway:bicycle=1). Je mappe :
> > highway=* ; oneway=1 ; bicycle=1 ; oneway:bicycle=1
> > Comme cycleway n’apparaît pas on pourrait le faire apparaître comme suit
> > : highway=* ; oneway=1 ; cycleway=share_highway ; oneway:bicycle=1
> > 
> > 7. Une rue à sens unique (highway=* ; oneway=1) dispose de marquages
> > répétés au sol, chevrons+sigle cycliste (bicycle=yes), dans le sens
> > contraire de
> > 
> > circulation (oneway:bicycle=-1). Je mappe :
> > Même chose que 6. mais le sens des cyclistes est opposé :
> > highway=* ; oneway=1 ; bicycle=1 ; oneway:bicycle=-1
> &

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel

[Mikaël Cordon]

circulation des 
voitures pour déduire les autres voies me paraît assez déplacé.

Autre remarque, ce modèle n’est pas si éloigné de l’actuel, il entre rarement 
en conflit, et souvent même, lève les ambiguïtés.

Évidemment, vous aurez remarqué qu’il y a plus de tags, jusqu’à 3 par voies ! 
Ceci dit il n’est dit nulle part que le monde pouvait être modélisé avec 1 ou 
2 tags :)

> 
> 
> Ensuite, si on s'intéresse au tag non recommandé, mais reconnu valide, on
> s'aperçoit que cette bande de contresens cyclable placée à droite, peut
> être décrite avec oneway=yes + cycleway:right=lane + oneway:bicycle=yes.
> 
> Ce dont on peut déduire que, pour les sens uniques en tout cas, le sens de
> circulation des vélos n'est pas donné forcément par les suffixes
> :right/:left (puisque là on est en cycleway:right et que pourtant on ne
> roule pas dans le sens du way), ni non plus par les valeurs
> lane/opposite_lane (puisque là on est en lane et que pourtant on ne roule
> pas dans le sens du way), ni non plus par le sens de circulation des
> voitures (on a mis lane alors qu'on est en contresens).
> 
> 
> 
> Dans les sens uniques, ce qui donne le sens de circulation des vélos en
> dernière instance, apparement, c'est le tag oneway:bicycle=no/yes. Ca
> c'est réglé.
> 
> 
> 
> Reste un problème quand même : c'est que ce tag n'est pas utilisable dans
> les voies à double sens de circulation voiture.
> 
> Du coup, encore cette question pénible : qu'est-ce qui définit le sens de
> circulation des vélos (ou des bus) dans les voies à double sens ?
> 
> 
> 
> Il faut choisir :
> 
> 
> 
> Est-ce que ce sont les suffixes :right/:left qui donnent le sens de
> circulation implicite (ce qui est la tendance de la page
> http://wiki.openstreetmap.org/wiki/Bicycle), mais alors on doit se
> contenter de décrire un  schéma de circulation plutôt qu'une configuration
> précise de la voirie ?
> 
> ou bien
> 
> Est-ce que ce sont les valeurs lane/opposite_lane qui peuvent seules
> définir le sens de circulation des vélos en fonction du tracé du way (ce
> qui est en contradiction avec la tendance de la page
> http://wiki.openstreetmap.org/wiki/Bicycle, et particulièrement avec B3,
> mais en accord avec ce qui semble être indiqué dans l'exemple de la page
> http://wiki.openstreetmap.org/wiki/Proposed_features/right_left), mais
> alors on est bien embété pour taguer la configuration précise de B1 et B2
> de la page http://wiki.openstreetmap.org/wiki/Bicycle ?
> 
> 
> 
> Qu'est-ce qu'on choisit ?

Cordialement,
-- 
Mickey86
Mikaël Cordon


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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel

[Mikaël Cordon]

Le jeudi 29 juillet 2010 02:13:39, Pieren a écrit :
> 2010/7/28 Mikaël Cordon 
> 
> > Avec le modèle des xxxway, on peut même modéliser des extras :
> > — C1 : (c : cycliste ; v : voiture ; b : bus)
> > 
> >|↓:↑| ↓ : ↑ | ↓ : ↑ |
> >|c:c| v : v | b : b |
> >
> >highway=* ;
> >cycleway:left=lane ;
> >busway:right=lane
> 
> Mais avec ce système, comment tu taggues une route:
> :c:v:v:c:
highway=* ; cycleway:left=opposite_lane ; cycleway:right=lane ; 
oneway:bicycle=1
> et
> 
> :c:v:v:
highway=* ; cycleway:left=opposite_lane ; oneway:bicycle=1
ou
highway=* ; cycleway:left=lane ; oneway:bicycle=-1 (pour s’économiser 
quelques caractères)


> ?
> 
> Pieren

Cordialement,
-- 
Mickey86
Mikaël Cordon

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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel

[Mikaël Cordon]

Le jeudi 29 juillet 2010 11:36:39, Lapinos03 a écrit :
> Mikaël Cordon a écrit :
> > Le jeudi 29 juillet 2010 02:13:39, Pieren a écrit :
> >> 2010/7/28 Mikaël Cordon 
> >> 
> >>> Avec le modèle des xxxway, on peut même modéliser des extras :
> >>> — C1 : (c : cycliste ; v : voiture ; b : bus)
> >>> 
> >>>|↓:↑| ↓ : ↑ | ↓ : ↑ |
> >>>|c:c| v : v | b : b |
> >>>
> >>>highway=* ;
> >>>cycleway:left=lane ;
> >>>busway:right=lane
> >> 
> >> Mais avec ce système, comment tu taggues une route:
> >> :c:v:v:c:
> > highway=* ; cycleway:left=opposite_lane ; cycleway:right=lane ;
> > 
> > oneway:bicycle=1
> 
> Entièrement d'accord avec cycleway:left=opposite_lane ;
> cycleway:right=lane. Mais que vient faire oneway:bicycle=1 ?

Pour indiquer que le sens de circulation est unique sur chacune des cycleway, 
et que le sens donné est dans le sens du tracé… Opposite venant opposer le 
sens de la voie cyclable de gauche (puisque le tracé est dans le sens bas→haut 
et oneway:bicycle=+1).

> Si tu veux utiliser oneway:bicycle pour indiquer un sens de circulation
> propre aux vélos, CYCLEWAY devrait se cantonner à une description
> physique, et non pas combiner les deux (opposite_lane)... Cela devient
> confus.

J’aimerais qu’on m’explique ce que vous appelez une représentation physique… 
Puisque le modèle que le propose est justement une description bête et 
méchante de la réalité : une voie à gauche, une voie à droite, en sens unique, 
et celle de gauche à rebour (par rapport au tracé).

Le « truc » c’est que je considère cycleway=lane comme une voie cyclable à 
double sens si on ne précise pas oneway:bicycle={-1,1} (quelque soit la voie 
pour voitures adjacente). Mais ça, on n’en parle plus bas dans ce message.

> 
> Soit :
> 
> highway=* ; cycleway:left=opposite_lane ; cycleway:right=lane ;
> (recommended)
> 
> 
> soit :
> 
> highway=* ; cycleway:left=lane ; cycleway:right=lane ; oneway:bicycle=0
> 
> >> et
> >> 
> >> :c:v:v:
> > highway=* ; cycleway:left=opposite_lane ; oneway:bicycle=1
> > ou
> > highway=* ; cycleway:left=lane ; oneway:bicycle=-1 (pour s’économiser
> > 
> > quelques caractères)
> > 
> >> ?
> >> 
> >> Pieren
> 
> Là aussi, soit :
> 
> highway=* ; cycleway:left=opposite_lane ;
> 
> 
> soit :
> 
> highway=* ; cycleway:left=lane ; oneway:bicycle=-1
> 
> 
> Et pour revenir au cas C1 énoncé plus haut, l'attribut LANE me fait
> penser qu'il n'y a qu'1 seule voie de circulation. Peut-être qu'une
> nouvelle valeur LANES (avec un S) dissiperait tout ambiguïté.

+1 !

Je me suis fait la même réflexion, mais j’ai voulu réutiliser le vocabulaire 
déjà en place vu que l’ambiance générale est à la frilosité quant à l’ajout de 
vocabulaire :) Mais ce serait plus cohérent, d’autant que par défaut, je 
considère les voies à double sens.

> 
> highway=*
> cycleway:left=lanes
> busway:right=lanes
> 
> Là, ça devient tout de suite plus évident, n'est-ce pas?

Tout à fait.
> 
> 
> Et dans les cas suivants, pour reprendre ton modèle, ai-je tout bon?
> 
> |↑| ↑ |
> |c | v |
> 
> highway=*
> oneway=1
> cycleway:left=lane

Avec la convention lanes == 2 × lanes (↓↑) j’aurais fait ça aussi.

> 
> |↓| ↑ |
> |c | v |
> 
> highway=*
> oneway=1
> cycleway:left=lane
> oneway:bicycle=-1

Itou.

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

-- 
Mickey86
Mikaël Cordon

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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel

[Mikaël Cordon]

Le jeudi 29 juillet 2010 11:42:44, Pieren a écrit :
> 2010/7/29 Mikaël Cordon 
> 
> > > Mais avec ce système, comment tu taggues une route:
> > > :c:v:v:c:
> >highway=* ; cycleway:left=opposite_lane ; cycleway:right=lane ;
> > 
> > oneway:bicycle=1
> > 
> > > et
> > > 
> > > :c:v:v:
> >highway=* ; cycleway:left=opposite_lane ; oneway:bicycle=1
> >ou
> >highway=* ; cycleway:left=lane ; oneway:bicycle=-1 (pour
> > 
> > s’économiser
> > quelques caractères)
> 
> Oui, je pensais bien qu'avec ces deux cas qui sont quand même les plus
> courants, ton système nécessitait plus de tags que celui actuellement en
> place. 

C’est sûr, c’est, à mon avis, le point qui fâche avec ce modèle ; mais d’un 
autre côté on gagne beaucoup en modélisation et en compréhension du modèle vu 
que c’est déjà ce qu’on utilise avec highway ; il permettrait d’unifier tous 
les types de voies.

Ceci dit, autant ce modèle est bête (systématique) quand on utilise les tags 
oneway à chaque fois qu’il y a une voie indépendante à sens unique ; il 
pourrait peut-être être amélioré par des raccourcis syntaxiques, tant que ça 
ne rend pas le modèle confus ou ambigu.

Si on reprend le message précédent de Lapinos03 auquel je réponds, 
l’utilisation de la valeur cycleway=lanes (avec le « s ») permettrait sans 
doute d’éviter la lourdeur des oneway:bicycle dans le cas le plus courant :
|↓|↓:↑|↑|
|c|v:v|c|
Et aller un peu plus loin dans la précision avec :both :
highway=* ; cycleway:both=lanes

Et pour :
| ↑ |↑|
| v |c|
highway=* ; cycleway:right=lane
voire même (si la position droite de la bande cyclable est clairement 
majoritaire)
highway=* ; cycleway=lane
(ce qui commence à se rapprocher sérieusement du modèle actuel :))

Mais de manière générale, un modèle digne de ce nom, ne devrait être jamais 
ambigu, comporter le moins d’exceptions possible, et les exceptions devraient 
porter soit sur le cas vraiment majoritaire à des fins de raccourcis, ou les 
cas les plus rares. 

À mon sens, un modèle qui décrit unitairement quelques situations et change la 
signification de ses composants à chaque situation (autrement dit, un modèle 
qui n’est fait que d’exceptions) est à proscrire.



> Et on voit que quel que soit le système choisi, il arrive que des
> cas posent questions et auront différentes interprétations.
> 
> Pieren

Cordialement,
-- 
Mickey86
Mikaël Cordon

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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel

[Mikaël Cordon]

Le jeudi 29 juillet 2010 18:50:41, Pieren a écrit :
> 2010/7/29 Mikaël Cordon 
> 
> > > penser qu'il n'y a qu'1 seule voie de circulation. Peut-être qu'une
> > > nouvelle valeur LANES (avec un S) dissiperait tout ambiguïté.
> > > 
> > > Et pour revenir au cas C1 énoncé plus haut, l'attribut LANE me fait
> > 
> > +1 !
> > 
> > Je me suis fait la même réflexion, mais j’ai voulu réutiliser le
> > vocabulaire
> > déjà en place vu que l’ambiance générale est à la frilosité quant à
> > l’ajout de
> > vocabulaire :) Mais ce serait plus cohérent, d’autant que par défaut, je
> > considère les voies à double sens.
> 
> On a déjà un 'lanes' pour le nombre total de voies (
> http://wiki.openstreetmap.org/wiki/Lanes). Pas sûr que rajouter un autre
> tag 'lanes' simpifie les choses...

Je suis assez d’accord pour limiter le vocabulaire au strict nécessaire.

Ceci dit, le lanes qu’on connaît déjà est une balise et non une valeur de 
balise. On rencontre ce schéma bien des fois, par exemple : type=junction ; 
junction=traffic_signals.


> 
> Pieren
Cordialement,
-- 
Mickey86
Mikaël Cordon

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

Re: [OSM-talk-fr] Suffixes :left/:right - piqûre d e rappel

[Mikaël Cordon]

Le jeudi 29 juillet 2010 19:41:53, simon a écrit :
> ok, refaisons entièrement le schéma du tag bicycle entre français, par
> contre ne conter pas sur moi pour argumenter auprès des autres pays pour
> imposer le nouveau schéma. Ni pour changer manuellement avec
> vérification sur le terrain les 78085 cycleway=track, 36778
> cycleway=lane, 10558 cyclaway=opposite, 2988 cycleway=opposite_lane
> (chiffre au 27 juillet 2010). Comment vont faire les personnes utilisant
> les données OSM si les schémas de tag changes tous les ans ?
> 
> il serait peut être judicieux de juste documenter les quelque cas qui
> nous manque avec le schéma actuelle et changer la photo sur la page
> http://wiki.openstreetmap.org/wiki/Proposed_features/right_left pour
> éviter toutes confusions.
> 
> 
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

Rien n’est décidé encore, ce n’est qu’une proposition.

Ensuite, ce modèle est souvent compatible avec l’actuel et met à plat le 
problème des directions. Il est évident qu’il faudra un consensus avant toute 
adoption.

Ceci dit il y a des problèmes avec le modèle actuel : imprecisions, 
incompréhensions, et des situations qu’on ne peut pas modéliser. C’est 
difficile pour les cartographieurs (interprétation des imprécisions), ainsi 
que pour les réutilisateurs des données (réinterprétation des imprécisions).

Comme la tendance est à la précision de la carte (c’est un de ses fers de 
lance), et dans les villes à mettre des voies spécialisées dans tous les sens, 
il serait vraiment dommage de laisser pourrir une situation qui entache la 
réputation d’OSM.

Si le modèle doit changer c’est le moment de le faire avant qu’il y ait encore 
plus de données à changer. D’autant que on se rend compte que certaines 
situations sont difficiles à cartographier ; on espère que les gens n’ont pas 
fait n’importe quoi. Ainsi sans les situations critiques, le modèle actuel est 
assez cohérent et alors le passage d’un modèle à l’autre pourrait être fait 
automatiquement.

Mais je répète, rien n’est décidé. On discute parce qu’il y a des soucis.

Cordialement,
-- 
Mickey86
Mikaël Cordon

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

Re: [OSM-talk-fr] Présentation

[Mikaël Cordon]

Salut charentais-maritime !

Et bienvenue !

Le mercredi 04 août 2010 10:42:25, Sébastien KALT a écrit :
>  Bonjour,
> 
>  Cela fait quelques semaines que je suis cette liste, aussi avant de poser
> quelques questions, je vais me présenter.
> 
>  J'ai découvert OSM en 2008 il me semble, mais à l'époque je n'avais pas de
> GPS, et le greffon du cadastre n'existait pas.
> 
>  J'ai eu l'occasion de pouvoir emprunter un GPS à mon boulot (un simple
> enregistreur Garmin), et depuis fin 2009 j'ai fait quelques traces dans
> mon coin, avec le travail de cartographie kivabien avec josm.
> 
>  J'interviens autour de La Rochelle (Charente-Maritime), soit en voiture,
> soit à pied, et bientôt en vélo.
> 
>  J'ai eu besoin d'un fond de carte des communes, et du coup j'ai vu qu'il
> était possible de le récupérer à partir des données OSM. La
> Charente-Maritime n'étant pas complètement couverte, j'ai découvert les
> joies du cadastre non numérisé, et de ses feuilles non géoréférencées ...
> que du bonheur  :-P .
> 
>  Sinon dans la vie je suis agronome, et curieux  ;-) .
> 
>  A bientôt, pour quelques questions !
> 
>  Sébastien

De la part d’un charentais-maritime d’origine :),
-- 
Mickey86
Mikaël Cordon

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

Re: [OSM-talk-fr] passage sous un porche

[Mikaël Cordon]

Le 24 août 2010 10:00, Pierre-Alain Dorange  a écrit :
> Mickey86  wrote:
>
>> [...]
>> Après tout, le concept c'est de faire passer un chemin sous quelque chose, la
>> balise tunnel=yes exprime très bien celà.
>
> C'est là que je suis pas tout à fait d'accord. Le chemin ne passe
> justement pas *sous* quelque chose (concept tunnel, underground), mais
> plutot "à travers" quelquec hose (concept covered, même si la mot peut
> sembler mal choisit)
>
> Si le passage se faisait "sous" le batiment alors tunnel serait
> approprié, AMHA.

Si le passage se faisait « sous » le bâtiment alors j’utiliserais «
layer=-1 » qui indique qu’on « change de plan ».

> --
> Pierre-Alain Dorange
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Mikaël Cordon

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

Re: [OSM-talk-fr] article dans la Nouvelle République

[Mikaël Cordon]

\o/

on ne l’arrête plus ce Simon ^^

Cordialement,
-- 
Mikaël Cordon, Mickey86
06 74 92 69 43 — mikael.cor...@gmail.com
Président de l'APP3L
-
Association Poitevine pour la Promotion de Linux et des Logiciels Libres
64 rue Gambetta 86000 Poitiers
http://www.app3l.org
Le mardi 12 janvier 2010 21:42:50, simon a écrit :
> Bonjour,
> 
> Un peut de pub pour OpenStreetMap en Indre et Loire
> 
> http://www.lanouvellerepublique.fr/dossiers/journal/index.php?dep=37&num=15
> 08043&PHPSESSID=c59ee73d4a485e49f5fd24f7b95b71ea
> 
> 
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
> 

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

Re: [OSM-talk-fr] langues ?

[Mikaël Cordon]

Bonjour, (Saluton)

Je parle aussi un peu espéranto. J'avoue que l'adoption de l'espéranto par
OSM me ravirait beaucoup !

Ceci dit je soulève quelques questions ou remarques quant à l'adoption de
l'espéranto par OSM ; ce qui ne constitue pas une dissuasion ou une
persuasion.

--- Que fait-on des termes déjà en utilisation ?

--- Si on bascule en espéranto, la masse de travail de traduction sur la
base OSM c'est une chose, mais il y a aussi tous les interpréteurs de la
carte (les convertisseurs, maposmatic) et les éditeurs (JOSM, Merkartor,
etc.)...

 --- Alors que l'anglais permettait l'utilisation de tables de caractères
anciennes, l'espéranto requerra l'adoption d'une table de caractère
internationale -- UTF8, par exemple -- pour les consonnes accentuées (c, g,
j, h, et s), à moins d'utiliser les méthodes cx et ch.

 --- La traduction dans les langues locales serait alors univoque à partir
de l'espéranto (langue relativement neutre) pour les applications. Et c'est
une langue très simple à apprendre et dépourvue de dialectes (uniforme sur
la planète).

--- L'espéranto dispose-t-il suffisamment de vocabulaire pour couvrir toutes
les subtilités des objets sur les cartes ?

--- De part le fait que les substantifs finissent par o et les adjectifs par
a, il y aurait peut-être là un moyen efficace pour classer les tags de
désignation et de qualification ?

--- etc.

Je trouve que cette langue serait bonne alternative à l'anglais pour l'OSM.
Et ce serait un nouveau vecteur de promotion de cette langue encore
minoritaire et pourtant pleine d'avantage !

--
Mickey86

Le 25 janvier 2010 09:11, Nicolas Dumoulin  a écrit :

> Le Monday 25 January 2010 01:20:27 hamster, vous avez écrit :
> > Emilie Laffray a crit :
> > > Soit. Quelle langue proposes tu?
> >
> > l'esperanto n'est pas parfait mais ca corresponds deja beaucoup mieux a
> > une langue internationale que l'anglais
> >
> > > Je crois bien que ca soit un probleme
> > > insoluble dans ce cas la. On pourrait parler de la difficulte
> > > d'apprentissage des langues, mais je ne suis pas sure que le debat
> > > avancerait beaucoup. Quelqu'un a suggere l'esperanto mais j'ai bien
> peur
> > > que ca n'aide pas beaucoup vu le nombre de personnes parlant cette
> > > langue.
> >
> > si on compte au nombre de personne qui l'utilise on pouvait en dire
> > autant de linux et freebsd en 1995, on pouvait en dire autant d'OSM en
> > 2006, d'ailleurs je crois bien qu'on peut toujours en dire autant
> >
> > > Je crois que par definition une langue est discriminante, car tu
> > > auras toujours ceux qui parlent la langue et ceux qui ne la parlent
> pas.
> > > L'anglais en comparaison de beaucoup de langues est facile a apprendre.
> >
> > alors la il faudra que tu m'explique comment tu fais tes comparaisons
> > toujours en comparant on peut aussi trouver beaucoup de langues plus
> > faciles a apprendre que l'anglais avec sa kirielle d'exceptions et
> > irregularites, et meme des langues beaucoup plus faciles a apprendre
> > par exemple "L'esperanto s'apprend en moyenne cinq fois plus rapidement
> > que n'importe quelle langue nationale ou ethnique (francais, anglais,
> > chinois, etc.)" [1]
>
> Bonjour,
>
> Le débat commence à faire du bruit et n'est pas facile à suivre. Je ne
> parle
> pas l'esperanto, et je ne sais pas si c'est la meilleur solution au
> problème,
> mais ce serait en tout cas moins pire.
> Je déteste devoir apprendre la langue de Shakespeare (langue littéraire
> avec
> effectivement beaucoup de subtilité) uniquement pour me faire comprendre
> d'autres personnes (souvent non anglophones).
>
> Voilà, +1 quoi
>
> --
> Nicolas Dumoulin
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] langues ?

[Mikaël Cordon]

Le 27 janvier 2010 02:43, hamster  a écrit :
>
> Mikaël Cordon a écrit :
> > Bonjour, (Saluton)
> >
> > Je parle aussi un peu espéranto. J'avoue que l'adoption de l'espéranto
> > par OSM me ravirait beaucoup !
> >
> > Ceci dit je soulève quelques questions ou remarques quant à l'adoption
> > de l'espéranto par OSM ; ce qui ne constitue pas une dissuasion ou une
> > persuasion.
> >
> > --- Que fait-on des termes déjà en utilisation ?
>
> on les garde : il faut pas vouloir etre plus royaliste que le roi
>
> > --- Si on bascule en espéranto, la masse de travail de traduction sur la
> > base OSM c'est une chose, mais il y a aussi tous les interpréteurs de la
> > carte (les convertisseurs, maposmatic) et les éditeurs (JOSM, Merkartor,
> > etc.)...
>
> je n'ai jamais parle de traduire le contenu actuel de la base, mais de
> se demander quelle langue on utilise pour les nouveaux tags
> a l'origine j'ai reagi dans une discussion sur le choix du tag pour les
> defibrillateurs

Personnellement, je doute que mélanger les langues soit une bonne chose !
Si on choisit une langue commune c'est bien pour qu'elle soit unique.
Si on mélange, on perd l'avantage de déduire et de se rappeler
logiquement le vocabulaire : à moins que l'on décide d'avoir une
langue pour une catégorie d'objet, ce sera difficile de se rappeler la
langue de chaque terme de vocabulaire.

>
> >  --- Alors que l'anglais permettait l'utilisation de tables de
> > caractères anciennes, l'espéranto requerra l'adoption d'une table de
> > caractère internationale -- UTF8, par exemple -- pour les consonnes
> > accentuées (c, g, j, h, et s), à moins d'utiliser les méthodes cx et ch.
>
> l'esperanto est loin d'etre parfait, et les accents ne sont pas son seul
> defaut

Mais aucune langue n'est parfaite, il s'agit là de savoir quelle
langue offre plus d'avantages que d'inconvénients !

> on trouve beaucoup d'esperantistes qui veulent conserver l'esperanto tel
> qu'il a ete invente par Zamenhof, je trouve que ca revient a en faire
> une langue morte et qu'il est nettement preferable de se l'approprier et
> donc pas hesiter a le modifier la ou on en ressent le besoin
>
> une langue vit en evoluant au gre des usages

C'est pareil pour toute langue. En ce qui concerne l'espéranto, la
philosophie de base étant la simplicité et la communauté, c'est une
langue qui, si elle évolue, restera stable quant à sa philosophie,
sinon, elle perdra ses avantages et mourra alors.
Elle évoluera dans son vocabulaire, dans ses constructions de phrases
peut-être, dans la culture qu'elle engendre ; ce qui n'est pas
incompatible avec OSM, il me semble.

>
> >  --- La traduction dans les langues locales serait alors univoque à
> > partir de l'espéranto (langue relativement neutre) pour les
> > applications. Et c'est une langue très simple à apprendre et dépourvue
> > de dialectes (uniforme sur la planète).
>
> si c'est largement adopte par la communaute internationale est-ce que ca
> va rester longtemps depourvu de dialectes ?
> la question que je pose c'est plutot est-ce que l'esperanto (ou une
> autre langue remplissant la meme fonction) va rester, de par sa
> structure, plus facile a apprendre malgre l'evolution de l'usage qu'une
> langue issue d'une culture et evoluant elle aussi avec l'usage ?
>
> > --- L'espéranto dispose-t-il suffisamment de vocabulaire pour couvrir
> > toutes les subtilités des objets sur les cartes ?
>
> rien ne nous interdit de contribuer a l'esperanto en rajoutant des mots

Tout à fait !
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] langues ?

[Mikaël Cordon]

Le 27 janvier 2010 09:40, Dominique Rousseau  a écrit :
> Le Mon, Jan 25, 2010 at 10:05:40AM +0100, Mikaël Cordon 
> [mikael.cor...@gmail.com] a écrit:
>>  --- Alors que l'anglais permettait l'utilisation de tables de caractères
>> anciennes, l'espéranto requerra l'adoption d'une table de caractère
>> internationale -- UTF8, par exemple -- pour les consonnes accentuées (c, g,
>> j, h, et s), à moins d'utiliser les méthodes cx et ch.
>
> Pour autant que je sache, la base d'OSM est entièrement en UTF8, puisque
> de toute façon, tu peux avoir des accents, du chinois, ... dans les
> "valeurs" de chacun des attributs.

En fait, je ne parlais pas que de la base OSM, mais aussi de tous les
outils afférents.

Mais à vrai dire ce n'est pas un réel problème, la partie ASCII étant
commune, l'espéranto loge tout à fait dans chaque table moyennant les
méthodes cx et ch qui pourront être reconverties en caractères unicode
accentués à la volée.

>
> --
> Dominique Rousseau
> d...@lee-loo.net - 06 82 43 12 27
>
> Si cinquante millions de gens disent une sottise,
> ça n'en reste pas moins une sottise.  -- Anatole France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>

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

Re: [OSM-talk-fr] Re : "Prestataires" OpenStreetMap

[Mikaël Cordon]

+1

Le 29 janvier 2010 09:59, Robin PREST  a écrit :

> Hello,
>
> Désolé pour la réponse tardive. Encore une fois, je crois que nos
> communautés gagneraient à se rapprocher !
>
> Jean, tu peux aller voir sur ce listing :
> http://georezo.net/geo-entreprise/ . C'est un annuaire des professionnels
> de l'information géographique que nous avons mis en place avec 
> l'Afigéopour pouvoir répondre à ce genre de 
> question. Tu y trouveras notamment une
> carte pour trouver le professionnel le plus proche si tu choisis la voie
> d'un prestataire privé.  J'en profite pour suggérer à Michael Douchin d'y
> enregistrer sa société 3liz si ce n'est pas déjà fait, c'est gratuit :o)
>
> *Pieren> C'est ça ce que j'appelle l' "esprit OSM" : construire une* 
> *communauté
>> de contributeurs. Payer des gens pour le faire, c'est revenir à**l'ancien 
>> modèle.
>> *
>>
>
> Je rappelle que les données d'OSM dans les pays les plus "fournis" en data
> viennent de société privées (ou de gouvernement local) qui ont "libérées"
> leur données, de même que certaiens appli très utilisées dans le monde du
> logiciel libre viennent de sociétés privées à l'origine. Fustiger le
> commerce est une chose, ne pas reconnaître que la synergie peut être plus
> enrichissante en est une autre. Il existe aussi un modèle économique avec le
> libre (cf 3liz par exemple).
>
> Pour rappel 
> (Source)
> et exemple :
>
> *Les Pays-Bas ont aussi pu bénéficier d’un geste plutôt inattendu de la
>> part de la compagnie AND , une société productrice
>> de données cartographiques numériques, basée à Rotterdam (Pays-Bas), qui a
>> décidé en 2007 de faire le don à OSM de 
>> toute la cartographie du réseau routier du pays. Faisant face à une
>> concurrence féroce, et particulièrement aux Pays-Bas, aussi le pays hôte de
>> Tele Atlas, la compagnie s’est offerte ce coup d’éclat qui a grandement
>> servi la communauté OSM. Le communiqué émis par AND à l’époque mentionnait
>> aussi le don à OSM des artères principales de la Chine et de l’Inde.*
>>
>
> Je ne pense pas que ca ait freiné la communauté OSM dans ce pays, au
> contraire. Le fait d'avoir une base existante peut aussi donner envie de
> s'impliquer pour que la carte soit à jour (un peu comme quand le ménage est
> fait, c'est plus facile à entretenir :P)
>
> Je suis très intéressé par des retours d'expérience vis à vis des communes
> qui ont lancé ces démarches de diffusion(ou même de société dans le même
> esprit). Dans le cadre de mon boulot, je serais ravi de promouvoir OSM +
> accélérer le processus dans les zones rurales en proposant aux communes de
> diffuser sur OSM les données que nous avons créé pour elles. Celles ci ne se
> rendent souvent pas compte des possibilité d'OSM (voire ne connaissent pas)
> Ce ne serait pas forcément une prestation payante mais plutôt une sorte de
> bonus pour passer devant nos concurrents, par exemple. L'opposition société
> commerciale/communauté citée plus haut n'est pas si binaire que ça...
>
> My 2 cents,
> Robin.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] indication de zoom de rendu ?

[Mikaël Cordon]

Sur Poitiers, j'ai le problème de priorité : des POI se masquent les uns les
autres sans que l'un ait pourtant une priorité évidente sur l'autre ; en
clair le système choisit d'afficher un POI au détriment de l'autre et
pourtant l'un et l'autre sont de même importance. De même, à un niveau de
zoom le nom d'un POI est affiché, au suivant, il ne l'est plus, c'est assez
déroutant (ironique pour une carte).

Je me pose plusieurs questions :
--- qui va décider de l'importance de tel ou tel POI ?
--- je crains que le fait de donner la possibilité de prioritariser les POI,
certains se basent sur le rendu pour déterminer l'importance du POI...
--- la prioritarisation ne ressemble-elle pas à au détournement du concept
"compléter la carte sans se préoccuper du rendu" ?

Je pose d'autres questions-propositions :
--- ne serait-il pas le moment de développer une carte multi-plan :
permettant d'afficher ou non des éléments qui se superposent ?
--- j'imagine que ça remet en cause le fondement du moteur de rendu...
--- quid alors de la licence ? Le fait de séparer les données par des
plans...

Librement,
--
Mikaël, Mickey86

Le 22 février 2010 09:07, Guillaume Allegre  a
écrit :

> Le Sun 21 Feb 2010 à 22:48 +0100, Pieren a ecrit :
> > 2010/2/21 Guillaume Allegre 
> >
> > >
> > > Elle n'apparait qu'aux zoom 17 et 18, ce qui parait normal pour un POI
> de
> > > ce type
> > > en milieu urbain. Mais "au milieu du désert", il serait justifié de la
> voir
> > > jusqu'au
> > > zoom 9 ou 10, je pense.
> > >
> > >
> > Techniquement, ça ne serait pas très compliqué. Il faudrait juste
> informer
> > le moteur de rendu sur les critères qui feraient changer les niveaux de
> zoom
> > minimum et maximum de certains POI. Ou plus simplement de faire un
> > post-traitement des données OSM en y ajoutant un tag spécial qui serait
> > fonction de la distance avec ses POI voisins de même type.
> > Mais tout cela ne serait faisable que sur un rendu particulier qu'il
> > faudrait mettre soi-même en place, le rendu standard d'OSM n'offrant pas,
> à
> > ma connaissance, cette possibilité.
>
>
> Merci de ta réponse.
>
> Il me semble que c'est une question qui demanderait vraiment de
> l'attention.
>
> Je suis partagé entre la méthode "calcul automatique" que tu évoques, et
> qui demanderait sans doute des ressources de calcul assez importantes
> dans le moteur de rendu, et l'évaluation manuelle de l'"importance" d'un
> POI,
> qui justifierait de forcer les niveaux de zoom.
> Le risque serait évidemment une sorte de spam (je mets un zoom mini plus
> faible sur "mon" bar), mais si les contributeurs restent honnêtes, le degré
> d'importance d'un POI pourrait se justifier, indépendamment de la distance
> aux voisins.
> Par exemple, dans une grande ville, il y a généralement une "poste
> centrale",
> et des bureaux de poste de quartier. Actuellement, je ne connais rien qui
> permette
> de les différencier pour le moteur de rendu (sauf la taille du bâtiment,
> certes).
> Pourtant, cela serait utile.
>
> Donc en y réfléchissant, il me semble qu'on peut distinguer deux critères :
> - POI important intrinsèquement
> - POI important car isolé
>
> Le premier se rapproche vraiment de la classification des routes
> (primary...).
> Serait-il envisageable d'avoir une notion d'importance générique pour tous
> les
> tags (ou au moins tous les tags de "type" POI) ?
> J'imagine que ça a déjà été évoqué quelque part ?
>
> Pour fixer un peu les idées, on pourrait partir de la proposition :
> importance = lowest, lower, normal (default), higher, highest
> (ou quelque chose dans ce genre)
> qui pourrait être prise en compte pour le calcul du zoom limite.
>
>
> --
>  ° /\Guillaume AllègreMembre de l'April
>  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel
> libre
>  /   /~~\tél. 04.76.63.26.99  http://www.april.org
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] indication de zoom de rendu ?

[Mikaël Cordon]

Oui, pour le rendu de base, puisque c'est celui de la carte principale qui
est sans doute utilisée par la majorité (moi en  tout cas). Mais sûrement
que le problème se retrouve sur toute autre carte mono-plan.

Une solution alternative mais pas parfaite au problème de superposition
serait d'avoir des zooms plus importants : cela permet de ne pas avoir
plusieurs plans, et assez d'espace sur la carte pour tout afficher.
Mais je crois que cette solution n'est que temporaire, plus on a d'espace
sur un bureau, plus on met de papiers, jusqu'à ce que le bureau soit trop
petit.

Le 22 février 2010 12:28,  a écrit :

>
> > Je me pose plusieurs questions :
> > --- qui va décider de l'importance de tel ou tel POI ?
> > --- je crains que le fait de donner la possibilité de prioritariser les
> > POI,
> > certains se basent sur le rendu pour déterminer l'importance du POI...
>
> Ca me fait penser à la personne qui avait mis un commerce en "peak" pour
> avoir une icône sur la carte ;)
>
> > --- la prioritarisation ne ressemble-elle pas au détournement du
> > concept "compléter la carte sans se préoccuper du rendu" ?
>
> Sans compter qu'un POI "important car au milieu du desert" devient moins
> important si plusieurs autres apparaissent dans la zone.
>
> > Je pose d'autres questions-propositions :
> > --- ne serait-il pas le moment de développer une carte multi-plan :
> > permettant d'afficher ou non des éléments qui se superposent ?
>
> Tu veut dire pour le rendu "de base" d'OSM ?
>
> --
> JB
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] indication de zoom de rendu ?

[Mikaël Cordon]

http://www.openstreetbrowser.org et http://poitools.openstreetmap.de/

C’est effectivement ce à quoi je pensais :)

Avec notre ami Simon (à Tours), nous avons fait quelques « grapho-parties » 
dans les centre-ville et à chaque fois les nouveaux « mappeurs » sont frustrés 
de ne voire qu’une petite partie de leur travail s’afficher sur la carte… 
Frustrant, et pas très encourageant.

Maintenant, c’est une autre affaire ^^

Le mercredi 24 février 2010 00:29:27, eMerzh a écrit :
> dans le même genre je préfère http://poitools.openstreetmap.de/ bien que
> moins complet :)
> 
> il serait effectivement intéressant d'élargir ces possibilitiés et de le
> coupler à nominatim
> 
> 2010/2/24 Etienne Trimaille 
> 
> > Le 22 février 2010 10:36, Mikaël Cordon  a écrit
> >
> >> Je pose d'autres questions-propositions :
> >> --- ne serait-il pas le moment de développer une carte multi-plan :
> >> permettant d'afficher ou non des éléments qui se superposent ?
> >> --- j'imagine que ça remet en cause le fondement du moteur de rendu...
> >> --- quid alors de la licence ? Le fait de séparer les données par des
> >> plans...
> >
> > Et bien voila : http://www.openstreetbrowser.org
> >
> > C'est juste assez long à charger. ;-)
> >
> >
> >
> > ___________
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-fr
> 

Librement,
-- 
Mikaël Cordon, Mickey86
06 74 92 69 43 — mikael.cor...@gmail.com
Président de l'APP3L
-
Association Poitevine pour la Promotion de Linux et des Logiciels Libres
64 rue Gambetta 86000 Poitiers
http://www.app3l.org

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

[OSM-talk-fr] Fwd: La communauté OpenStreetMap f rançais en quêtes d'informations

[Mikaël Cordon]

J'ai essayé d'en savoir un peu plus ce qu'il se passe au plus près de
l'équipe en charge du SCPC (Service de Consultation des Plans Cadastraux)

-- Message transféré --
De : G. Cyrille (75)
Date : 26 février 2010 11:06
Objet : Re: La communauté OpenStreetMap français en quêtes d'informations
À : Mikaël Cordon 


 Bonjour,

Suite à votre message de ce jour, les précisions suivantes sont apportées :

- en France métropolitaine, les projections dans lesquelles sont exprimés
les plans cadastraux au format vecteur sont, depuis mars 2009, les "coniques
conformes 9 zones" (auparavant, il s'agissait des projections "Lambert
zones"). La migration des données cartographiques au format vecteur du
Lambert zones vers les coniques conformes 9 zones s'explique par la
nécessité de se conformer au décret n° 2006-272 du 3 mars 2006 (RGF93) ;

- pour les plans cadastraux au format Image, selon les feuilles de plan et
les communes concernées, l'on peut trouver diverses projections : lambert
zones, lambert 93, coniques conformes 9 zones, ou aucun système légal de
projection. Par ailleurs, les plans cadastraux de certaines communes qui
étaient gérés au format Image peuvent passer au format Vecteur et, par
conséquent, voir désormais leur projection exprimée en coniques conformes ;

- s'agissant des temps d'accès, nous constatons depuis le début de l'année
un nombre croissant d'utilisateurs du site cadastre.gouv.fr ce qui peut
entraîner une dégradation des temps de réponses aux heures de pointe. Nous
travaillons actuellement avec les services informatiques pour trouver le
plus rapidement possible une solution ;

- s'agissant du service WMS, nous souhaiterions l'ouvrir de manière visible
à compter de la fin de cette année. Les études informatiques nécessaires à
ce projet se poursuivent. Je devrais être en mesure de vous apporter des
précisions qu'au cours du second semestre.
En espérant avoir répondu à vos interrogations.
Cordialement,



--


[image: DGFIP]  *Cyrille G.*
 *Inspecteur Principal*
 *Bureau GF3A*
 *86/92 allée de Bercy*
 *75572 PARIS 12ème*
 *Tél : 00 00 00 00 00*
*_*


 Message original ----
Sujet : La communauté OpenStreetMap français en quêtes d'informations
De : Mikaël Cordon  
Pour :
Date : 26/02/2010 09:52

 Bonjour,

Je fais partie de la communauté des contributeurs au projet
OpenStreetMap (http://wiki.openstreetmap.org/wiki/FR:Main_Page), et
depuis quelques mois je suis en mission à la DGFiP (CSI de Poitiers,
projet OPERA-TOSCANE, service CCOT). Je vous contacte en tant
contributeur OpenStreetMap.

Depuis quelques temps, la communauté OSM française éprouve des
difficultés quant à la récupération de certaines données cadastrales
lui permettant de compléter sa chère carte libre ; frustration.

Il semblerait qu'il y ait des changements de projection sur certaines
communes. Nous observons également des temps accès plutôt long et
irréguliers au serveur WMS.

Nous ne sommes pas là pour nous plaindre, mais plutôt savoir (sans
rentrer dans l'indiscrétion) ce qu'il se passe et ce qu'il est prévu à
plus ou moins long terme à propos du service WMS.

Cela nous permettrait de pouvoir éventuellement anticiper certains
changements (types de projections, changement de format des tuiles
cadastrales, etc.) et patienter en toute quiétude.

En espérant que j'aie contacté un bon interlocuteur, et dans l'attente
d'une réponse de votre part, nous vous prions d'accepter toute notre
reconnaissance quant aux services forts intéressants que vous
fournissez.

PS : Pour éviter d'être assailli de questions, et dans le cas où
d'autres échanges soient à venir, je me propose de faire
l'intermédiaire entre la communauté OSM et vous.
<>___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Contact sur Poitiers ?

[Mikaël Cordon]

Salut Christian (et la liste talk-fr),

Je transmets ta demande à l’APP3L (/http://www.app3l.org/[1] - GULL de 
Poitiers, dont je fais partie). C’est un sujet (contacter le SIG) qui nous 
intéresse !

Librement,
--
Mikaël Cordon
Le vendredi 6 juin 2014, 12:03:38 Christian Quest a écrit :
> Est-ce que quelqu'un de Poitiers est disponible pour établir un contact
> avec le SIG de la Ville que je viens de rencontrer lors des rencontres de
> l'Afigéo ?
>
> Je leur ai laissé ma carte donc à suivre dans les semaines qui viennent...
>
>



[1] http://www.app3l.org


signature.asc
Description: This is a digitally signed message part.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Re : theme de couleurs dans JOSM

[Mikaël Cordon]

Pour les derniers écrans qui sont rétroéclairés avec des leds en matrice (full 
led et pas edge) lorsqu’une zone est sombre ou noire, la led de rétroéclairage 
s’éteint, donc des noirs plus profonds et moins de consommation.

En ce qui concerne la couleur de fond, choisir blanc ou noir n’est pas 
vraiment la question, c’est surtout le rapport entre luminosité ambiante et 
luminosité de l’écran… Dans l’idéal ce rapport devrait être de 1. Plus la 
lumière ambiante est vive plus l’écran doit être lumineux, et plus on est dans 
un environnement sombre moins l’écran doit être lumineux. En revanche, plus 
l’écran est bigarré plus c’est fatiguant.

En résumé, choisir une config d’écran plutôt contrastée, mais sans couleurs 
trop pures, et la luminosité doit suivre la lumière ambiante.

De plus, il est recommandé de ne pas être trop près de son écran (ne pas 
tourner la tête pour suivre le pointeur de la souris), ni trop éloigné 
(pouvoir tout lire sans forcer), et idéalement lorsque les yeux regardent à 
l’horizontale, le centre de la vision vise le haut de l’écran. Et l’écran 
vertical, évidemment.

Le vendredi 10 septembre 2010 16:59:46, Julien Balas a écrit :
> Le 10 septembre 2010 16:53, Vincent Pottier  a écrit :
> >  On 10/09/2010 16:30, THEVENON Julien wrote:
> >  
> >  en plus de ca il y a aussi les considerations ecologiques qui font qu
> > 
> > afficher du noir ca consomme moins
> > 
> >  Ça c'était vrai sur des tubes cathodiques, pas de lumière donc pas
> > 
> > d'émission d'électrons donc pas de consommation de courant.
> > Je suis nettement moins sûr pour les écrans LCD où la couche LCD varie en
> > opacité, pas en émission. Mais je ne suis pas spécialiste...
> 
> Peut-etre même que le fait d'activer les filtres pour que la lumière ne
> sorte pas fait consommer plus si on affiche du noir

Cordialement,
-- 
Mikaël Cordon
mikael.cor...@gmail.com
06 74 92 69 43 — 09 52 89 02 08
30 rue Saint-Hilaire 86000 Poitiers

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

Re: [OSM-talk-fr] Rencontre mappers

[Mikaël Cordon]

Le dimanche 12 septembre 2010 20:01:41, julien balas a écrit :
> On 09/12/2010 05:33 PM, Stéphane Brunner wrote:
> > Hello,
> 
> salut
> 
> > Avec quelque mappeur on va ce retrouver le samedi 18 vers 13h, pour
> > l'instant le lieux n'est pas encore défini, mais il va être quelque part
> > entre Montreux et Villeneuve.
> 
> ca se situe dans quel pays ?

Entre la Belgique et l’Espagne :P

Cordialement,
-- 
Mikaël Cordon, Mickey86
06 74 92 69 43 — mikael.cor...@gmail.com
Président de l'APP3L
-
Association Poitevine pour la Promotion de Linux et des Logiciels Libres
64 rue Gambetta 86000 Poitiers
http://www.app3l.org

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

Re: [OSM-talk-fr] orthophoto Tours

[Mikaël Cordon]

\o/

--
Mikaël Cordon

Le samedi 13 novembre 2010 11:15:49, simon a écrit :
> Bonjour,
> 
> Je viens de recevoir un DVD de l'orthophoto de l'Agglomération de Tours
> http://reau.simon.perso.neuf.fr/Ortho_tours_plus.jpg
> 
> Je dois faire préciser quelques détail au niveau du tag source et de
> l'utilisation que nous allons en faire et ensuite je vais avoir besoin
> d'aide technique pour la diffuser.
> 
> Librement
> 
> Monsieur a
> 
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Voies bus synthèse

[Mikaël Cordon]

Bonjour,

Je sens mon mal de tête revenir…

Il y a quelques temps sur cette liste, on a abordé un sujet épineux : la 
modélisation des voies pour cycles, mal comprise (c’est un fait), fouillie et 
comportant des soucis non négligeables ; la discussion s’est terminée sans 
statuer réellement. Mais je vois que la discussion revient d’elle-même, et 
c’était à prévoir ; sauf que là, ça s’empire (en un seul mot évidemment) : il 
y a les voies de bus, les voies piétonnes en plus.

On entend ici et là qu’il faut simplifier la modélisation, que les « newbies » 
sont rebutés par certaines modélisations, et particulièrement des voies pour 
cycles, et je vois qu’on insiste à appliquer ce modèle pour les bus et les 
piétons !

Problèmes majeurs de la modélisation actuelle des voies pour cycles :

— la direction des voies est dépendante du sens de circulation de la voie 
principale : lorsque la voie principale n’est plus affectée (plus de voiture, 
par exemple), il faut changer de modèle (donc en fait, ce n’est pas 1 modèle, 
mais 2) ; de la même manière il faut être particulièrement attentif à ce qu’il 
se passe lorsque le sens principal change et pas les autres voies

— le modèle propose de séparer en plusieurs tracés parallèles les voies : on 
crée des données redondantes, donc espace perdu et maintenabilité difficile

— les voitures, les vélos, les bus et par extrapolation, les piétons sont des 
véhicules qui peuvent avoir chacun sa voie (partagée ou non avec les autres) 
et pourtant on modélise toutes ces voies de manière différente ! Pourquoi ? 
Alors que le principe est le même, seul le nom du véhicule (et de sa voie) 
différent.

Pourtant, il existe déjà un modèle qui est efficace, qui est largement 
utilisé, connu du tout le monde et qui ne pose pas vraiment de problème : les 
voies pour voitures (highway=*) attaché à un tracé (way).

On pourrait étendre cette modélisation aux autres véhicules.
Pour les cycles : cycleway=* ; pour les bus : busway=* ; pour les piétons : 
footway=*. Ces voies n’ont plus qu’a rester attaché au tracé et ne pas être 
interdépendants.
Le seul point à éclaircir, reste la position des voies : :left/:right (sur le 
point d’être adopté) pour 2 voies supplémentaires, et éventuellement un indice 
(:2, :3) supplémentaire pour les voies supplémentaires.

Il faut que le modèle reste simple pour les situations simples (il peut se 
compliquer pour les situations compliquées), facile à se rappeler et à 
retrouver (donc un modèle générique est bienvenu).

J’avais déjà démontré (dans la ML) que le modèle que je propose modélise bien 
toutes les situations de façon systématique et laisse les voies indépendantes 
quant à leur sens de circulation.



De plus, je dois dire que je me suis refusé jusque là à modéliser les voies 
cyclables sur Poitiers parce que le modèle actuel comporte des problèmes que 
j’aurai du mal à résoudre. Pareil pour les bus, je me suis contenté de faire 
des lignes (relation route) et pas les voies.

Ceci dit, une association de cyclistes nous (des contributeurs OSM sur 
Poitiers) a contacté pour remplir la carte avec les pistes cyclables : vous 
imaginez le stress… Enseigner une modélisation à laquelle nous n’adhérons pas, 
et ainsi probablement ne pas faire de bons contributeurs, ou alors ne pas 
contribuer du tout.


Il y a, à mon humble avis, à discuter encore sur ces points avant d’adopter un 
modèle qui montrera vite ses limites et mettra tout le monde dans l’embarras. 
Je ne dis pas que le modèle que je propose est le meilleur, mais il semble 
avoir plus d’avantages que d’inconvénients à être adopté.

Cordialement,
--
Mikaël Cordon, Mickey86

Le dimanche 14 novembre 2010 10:33:47, esperanza a écrit :
> Afin de proposer un "Proposed feature" sur le wiki concernant les voies
> de bus et avant d'envoyer cette synthèse sur la liste tagging, j'ai
> essayé de faire une synthèse des différentes discussions sur la liste et
> des pratiques dans certaines villes.
> Merci d'indiquer vos avis afin de compléter par la suite la page wiki :
> http://wiki.openstreetmap.org/wiki/Bus
> (qui n'indique pour l'instant que les rares "bus_guideway" et non les
> classiques voies bus)
> sur le modèle de ce qui se fait déjà ici :
> http://wiki.openstreetmap.org/wiki/Bicycle
> Il en ressort qu'il y a deux options pour tracer les voies bus séparées
> de la chaussée comme le montre les cas 1 et 7 et B4 (highway=service ou
> highway=busway)
> 
> Par ailleurs, nous sommes au dernier jour pour la consultation ("vote")
> sur les attributs :left/:right sur le wiki :
> http://wiki.openstreetmap.org/wiki/Proposed_features/right_left
> 
> Les différents cas rencontrés :
> (1) Dans le cas d'une voie bus séparée par un potelet ou bien sur une
> voie bien à part :
> 
> highway=service
> service=bus
> access=no
> psv=yes
> bicycle=yes/no
> 
> ou bien
>

Re: [OSM-talk-fr] Présentation

[Mikaël Cordon]

Salut,

Oui, c’est moi qui ai classé (puis reclassé) les rues de Poitiers, et je dois 
dire que j’ai pas mal de difficulté à classer… Les primaires ne me posent pas 
de problème… En ce qui concerne les autres classes, c’est plus compliqué je 
suis partagé entre suivre la classification en fonction des numéros des voies 
(D 147, C 6, etc.), et le traffic réel. Certaines voies non numérotées sont 
tellement passagères qu’il est plutôt mal venu de les classer mineures ou 
résidentielles. De plus visuellement (je sais qu’on ne tague pas pour le 
rendu), voir une voie qui se détache du reste laisse penser à une voie plutôt 
principale, c’est dans cette optique j’ai surclassé certaines rues alors 
qu’officiellement elles n’ont pas plus de classe que ces voisines :)

De ce fait, les classes « officielles » peuvent être suivies par rapport au 
ref=* et l’importance réelle via les classes highway=*, non ?

Quant aux rues classées qui débouchent sur des voies de classe inférieures, 
c’est dû au fait que le traffic est dévié progressivement dans les rues 
connexes et qu’au bout d’un moment il faut déclasser un bout de la rue pour 
coller au traffic effectif.

Ceci dit, il ya peut-être des erreurs tout de même.

Le dimanche 19 décembre 2010 16:57:05, Pieren a écrit :
> 2010/12/19 
> 
> > Bonjour à tous,
> > 
> > Je m'interesse à OSM depuis un peu plus d'un 1 an, mais c'est seulement
> > depuis 6 mois que je contribue. Je suis impressioné par l'ampleur du
> > projet
> > 
> > : la tâche est tout bonnement colossale mais les outils mis à disposition
> > 
> > sont d'une qualité remarquable ce qui a permis au projet d'avancer à
> > grand pas. Ce qui a déjà été fait est grandiose !
> > 
> > bravo et bon courage à tous !!
> 
> Bienvenue sur la liste !
> Je viens de voir la page d'acceuil de l'ap3l qui montre la carte OSM sur
> Poitiers. Il semble que sur cette ville comme dans d'autres en France, nous
> ayons un problème de classification des highway urbains. On voit souvent
> des classifications secondary/tertiary ou même parfois primary terminer en
> cul-de-sac (c.à.d vers des rues residential/unclassified) ou même être
> complétement isolés alors que ces axes routiers doivent en principe former
> un réseau. Imaginez que ces classifications supérieures peuvent être
> utilisées par des logiciels de navigation qui peuvent, par exemple, y
> envoyer le trafic routier de transit. Ce genre de voie ne devrait terminer
> qu'exceptionnellement en impasse.
> 
> Bon mapping sur Poitiers et sa région,
> Pieren

Cordialement,
--
Mickey86

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