Re: [OSM-talk-fr] Tagguer un bâtiment à usage multiple (était: Re: Quelques questions d'un débutant OSM)

[Éric Gillet]

Il me semble que la manière la plus correcte est de donner à chaque
batiment son nom (ex : Bat. B), de faire un périmètre si la résidence en a
une, et de tout englober dans une relation de type site, nommé selon la
résidencce (résidence Machin par exemple)  [1]

Vous pouvez trouver un exemple de cette méthode ici [2]

[1] http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site
[2]
http://www.openstreetmap.org/?lat=43.517022&lon=5.456052&zoom=18&layers=M

2012/7/27 Mathieu Rajerison 

> Bonjour,
>
> Concernant encore les bâtiments, je me pose la question du tag de
> bâtiments.
>
> Lorsque plusieurs bâtiments appartiennent à une même résidence, doit-on
> donner name=[nom de la résidence] à chaque bâtiment ou bien mettre un point
> seulement, au milieu de la résidence, muni de son nom?
>
> Le 26 juillet 2012 14:54, Mathieu Rajerison a 
> écrit :
>
> Bonjour Gilles,
>>
>> C'est bien ce que je me disais. Cette approche me semble beaucoup plus
>> intelligente.
>>
>> Merci
>>
>> Le 26 juillet 2012 14:45, Gilles Bassière  a écrit :
>>
>> Bonjour Mathieu,
>>>
>>> On jeu., 2012-07-26 at 13:51 +0200, Mathieu Rajerison wrote:
>>> > - Aussi, comment indiquer qu'un bâtiment abrite à la fois des
>>> > activités commerciales et des logements?
>>>
>>> Ça peut se faire au niveau de la clé building. Par exemple :
>>>building=retail;residential
>>>
>>> Je l'ai rarement vu. En général, un tel niveau de détail n'est pas
>>> atteint : le bâtiment est simplement building=yes et on y rajoute les
>>> clé shop=* qui vont bien.
>>>
>>> De plus en plus souvent, je laisse le bâtiment tel quel et j'ajoute un
>>> node portant les tags du lieu, par exemple shop=...
>>>
>>> Cordialement
>>> --
>>> Gilles Bassière - Web/GIS software engineer
>>> http://gbassiere.free.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] Tagguer un bâtiment à usage multiple (était: Re: Quelques questions d'un débutant OSM)

[Mathieu Rajerison]

Bonjour,

Concernant encore les bâtiments, je me pose la question du tag de bâtiments.

Lorsque plusieurs bâtiments appartiennent à une même résidence, doit-on
donner name=[nom de la résidence] à chaque bâtiment ou bien mettre un point
seulement, au milieu de la résidence, muni de son nom?

Le 26 juillet 2012 14:54, Mathieu Rajerison  a
écrit :

> Bonjour Gilles,
>
> C'est bien ce que je me disais. Cette approche me semble beaucoup plus
> intelligente.
>
> Merci
>
> Le 26 juillet 2012 14:45, Gilles Bassière  a écrit :
>
> Bonjour Mathieu,
>>
>> On jeu., 2012-07-26 at 13:51 +0200, Mathieu Rajerison wrote:
>> > - Aussi, comment indiquer qu'un bâtiment abrite à la fois des
>> > activités commerciales et des logements?
>>
>> Ça peut se faire au niveau de la clé building. Par exemple :
>>building=retail;residential
>>
>> Je l'ai rarement vu. En général, un tel niveau de détail n'est pas
>> atteint : le bâtiment est simplement building=yes et on y rajoute les
>> clé shop=* qui vont bien.
>>
>> De plus en plus souvent, je laisse le bâtiment tel quel et j'ajoute un
>> node portant les tags du lieu, par exemple shop=...
>>
>> Cordialement
>> --
>> Gilles Bassière - Web/GIS software engineer
>> http://gbassiere.free.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] Traduction de "redaction" en français

[Christian Rogel]

Le 26 juil. 2012 à 19:10, Philippe Verdy a écrit :

> D'abord il faut séparer :
> - l'action du robot de "rédaction" qui peut être aussi bien celle de
> masquer que de démasquer certaines infos;
> - de son résultat : le fait que la version est effectivement masquée
> dans son état actuel.

C'est le point de désaccord que j'ai déjà exprimé :
la version anglaise ne mentionne que le processus de révision, et ne le 
détaille pas.
Il n'est donc pas question de traduction, mais d'amplification.
Il suffit donc d'être plus complet.
On pourrait, peut-être, dire qu'il y a une révision et ajouter "qui a pour 
effet de masquer les données…".


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

Re: [OSM-talk-fr] Opendata : préfecture de Paris

[Pieren]

2012/7/25 Axel Simon :
> - Quelqu'un a-t-il déjà de l'expérience dans l'import de ce genre de données ?

Quelqu'un a déjà importé les sources d'eau potable publiques
(fontaines) sur Paris. Et le moins que l'on puisse dire, c'est que
c'était du positionnement très, très approximatif. Il faut donc
vérifier avant un import la qualité des données. Et aussi à tout prix
les doublons, surtout sur Paris où les données sont déjà très
fournies. Il faut donc mieux parler d' "intégration avec l'existant"
que d'"import".

Pieren

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

Re: [OSM-talk-fr] Traduction de "redaction" en français

[Philippe Verdy]

D'abord il faut séparer :
- l'action du robot de "rédaction" qui peut être aussi bien celle de
masquer que de démasquer certaines infos;
- de son résultat : le fait que la version est effectivement masquée
dans son état actuel.

Ici le message est destiné à avertir qu'une version n'est pas visible.
Il ne s'agit pas réellement de dire que le bot a pris une décision
quelle qu'elle soit ni qui l'a prise et pour quelle raison (la raison
est donnée en suivant le lien).

Le message étant générique, il n'y a pas nécessité de dire que c'est à
cause du changement de licence (ce qui n'est pas vrai pour tout le
monde, car des utilisateurs ont ben accepté la seconde licence mais
ont malgré tout été masqués, ce qui me semble excessif quand en même
temps on accepte des imports de sources à qui on demande de passer en
ODbL sans les obliger pour autant à accepter pour elles-mêmes des
"Contributor Terms" qui ne les concerne pas et à laquelle elles n'ont
pas à s'engager (c'est plutôt à ceux qui effectuent des modifs ou
imports dans la base de s'engager à respecter les licences et
attributions).

Pour moi la décision de masquer les contributions de ceux qui ont
accepté la licence mais refusé les CT est excessive (et inutile). Il
suffisait juste de leur bloquer l'accès en modification sans impacter
les données existantes qui ont été saisies en acceptant alors des
termes parfaitement valides auparavant. Il n'y a pas de changement de
licence pour ceux là, il n'y avait aucune raison de les masquer.

Je note que des exceptions ont été mises mais uniquement pour
certaines sources comme UMP-PL, mais pas en tenant compte de la lience
ODbL déjà acceptée ni du fait que les CT ont été refusés par un
utilisateur, et de fait certaines seulement de leurs contributions ont
été restaurées après avoir vérifié l'origine ou la compatibilité des
données qu'ils avaient bien indiqué correctement, mais on continue à
masquer toutes les autres contributions faites ailleurs par ces mêmes
utilisateurs.

Pour moi ce problème a été résolu à l'envers et en dépit du bon sens,
car avant meêm de commencer la "rédaction" de leurs contributions, on
ne leur a même pas demandé si ils plaçaient leurs anciennes
contributions ou non sous une nouvelle licence additionelle afin de
pouvoir les garder même en leur absence pour la suite du projet.

Pour moi il y a des tas de trucs totalement inutiles dans les CT. La
seule application du droit normal du copyright et des licences
suffisait. Mais les engagements demandés aux contributeurs sont
supérieurs à ceux que l'on demande aux sources (qu'on importe sans
réserve), et on les prive inutilement de leurs droits (et de leurs
mérites passés sur le projet, comme si tout d'un coup ils étaient
totalement indésirables alors qu'ils étaient les bienvenus avant).

Enfin tant pis pour les morts qui n'ont pas pu répondre, on les a
oublié et enterrés définitivement. Aucun respect. Et cela va à
l'encontre de l'objectif à long terme du projet qui ne devrait pas
renier son héritage (sachant qu'on pourra toujours modifier ce qui
devra l'être au moment utile, mais pas ainsi de façon aussi
massacrante et mal perçue par ceux qu'on a trop vite oubliés mais qui
ne sont plus là pour seulement pouvoir répondre).

Pour moi il était entièrement suffisant de mettre en place dans la
base un filtre sur la compatibilité des licences, sans ôter aucune
donnée. On en revient au problème initial qui est qu'OSM veut tout
mélanger dans la même base comme si c'était une seule et même couche,
et qui ne permet pas de clairement séparer les sources et de les
sélectionner à la demande en fonction des usages, avec une bien
meilleure cohérence des données au sein de chaque source (ou de chaque
projet collectif qui aurait pu se créer autour d'une thématique plus
facile à suivre et à éditer, ainsi qu'à évaluer au plan qualité sur un
jeu de données plus facile à analyser par des outils automatiques, et
permettant même ensuite des outils facilitant les transitions ou
adaptations de données d'un jeu de données à l'autre).

Pour moi l'OpenData ne consiste pas à mélanger toutes les données car
les modèles uniformes ne satisferont jamais aux besoins de tout le
monde en même temps et introduiront toujours des ambiguïtés si on
prend l'ensemble comme un tout indivisible, alors que la plupart des
problèmes sont facilement résolus sur le rapprochement de seulement un
ensemble réduit de jeux de données, chacun ayant des conventions qu'on
fait progressivement converger autant que possible mais sans imposer
nécessairement une solution unique tout de suite qui changera le
lendemain pour correspondre aux besoins d'un autre groupe devenu plus
influent mais qui n'a pas participer aux traveaux de convergence avec
d'autres jeux de données.

La conséquence de cela est la grande difficulté à traiter de façon non
ambiguë des tas de données dans la base, mais aussi leur
sous-utilisation effective au final (pour les rendus ou l'analyse ou
les applications dérivées) quand les rapprochement

Re: [OSM-talk-fr] Traduction de "redaction" en français

[Christian Rogel]

Le 26 juil. 2012 à 14:41, Philippe Verdy a écrit :
> 
> 
> J'approuve aussi le terme "masqué" qui répond bien à ce que fait
> effectivement le bot (qui se charge de cacher toutes les contributions
> d'un ou plusieurs utilisateurs, pour un ou plusieurs motifs qui seront
> précisés dans la page accessible par le lien %{redaction_link}.

On peut mettre "masqué" pour être très pédagogique, mais, il ne s'agit plus de 
traduction, mais d'extraction d'une propriété occasionnelle du bot, parmi 2 ou 
3 autres.

"Redacted" ne signifie pas "masqué", par quelque bout qu'on le prenne et la 
focale est alors complètement décalée. Pourquoi pas.

J'avais cru qu'il s'agissait de traduire.


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

Re: [OSM-talk-fr] OSMTransport change de peau

[rldhont]

Au début du projet n'importe qui et sans contrôle pouvait créer une 
localisation d'où toutes les erreurs que tu peux avoir noté.


L'objectif de départ est d'afficher la donné OSM dans sa structure la 
plus brutes afin d'aider les contributeurs à visualiser des erreurs, des 
manques, etc.


Ensuite j'aime bien l'idée d'afficher les terminus, mais existent-il un 
rôle pour cela ?



Le 26/07/2012 18:13, Philippe Verdy a écrit :

Pour les couleurs de lignes, certaines agglomération ont un schéma
uniforme aussi bien dans la signalisation, les panneaux des arrpet
comme les bus, et les plans papier diffusés ou affichés. LA couleur
concerne autant la couleur de fond de l'étiquette que celle des
caractères, la couleur de fond devant correspondre si possible à la
couleur du tracé sur la carte comme tu le fais.

Sans aller jusqu'à reproduire aussi les logos, il y a aussi des
différences de forme pour ces numéros (par exemple dans un cercle ou
un carré). Enfin il ne serait pas inutile de repérer les terminus sur
la carte (ce sont des arrêts où le bus change de sens ou bien où il
dépose tout le monde et poursuit sans passagers vers son dépôt) en
affichant les numéros de ligne sur la carte. Cela demanderait une
collection de petites icônes (faciles à générer de façon vectorielle à
partir d'une forme de base, des couleurs de fond, de bordure et de
texte et le numéro ou à défaut une abbréviation du nom ou un symbole
générique) en mettant en libellé le nom de la destination à partir de
ce terminus (si la ligne est jsute un cycle, un seul point est
rensiegné, le point d'arrêt principal, souvent sur une place centrale
d'échange, et en libellé on mettrait le nom de la ligne.

Selon les références que tu trouves, on pourrait avoir pour ton rendu,
dans ta propre base, des noms adaptés à ta carte pour remplacer ceux
trouvés dans la base quand ils ne conviennent pas bien (pas besoin
forcément de mettre à jour la base OSM), dans la délimitation
géographique de l'agglomération que tu as définie.

Note: une des villes est nommée avec le préfixe abrégé "Agglo", à mon
avis inutile et perturbant dans la liste. Tout dans cette liste de
sélection concerne une agglomération (parfois un peu plus sur des
réseaux étendus tels que "Paris Est", où on se demande pourquoi on n'a
pas aussi "Paris Ouest" pour tout ce qui est autour du réseau au
départ de Saint-Lazare et des lignes de bus en correspondance dans les
villes traversées, et "Paris Sud" depuis Montparnasse ou la Gare de
Lyon).

Enfin certaines villes manquent de traits d'union dans la liste affichée.

Le 26 juillet 2012 17:53, rldhont  a écrit :

Bonjour Philippe,

Tout d'abord OSMTransport a été construit il y a 3 ans, à l'époque il n'y
avait qu'un seul modèle pour les lignes de bus un seul relations par ligne
et il n'était pas question de s'amuser à définir une relation par sens de
circulation ni de super-relation par ligne référence toutes les relations
formant toutes les variations d'une ligne. Sachant cela :
* la référence est pour moi la clef d'identification d'une ligne donc si il
y a plusieurs relations portant le même tag ref, je les colles ensembles
* l'affichage du tag name vient d'être ajouté pour voir, celui-ci comme la
couleur de la ligne est extrait de la première relation que je rencontre
avec ce ref en particulier

Donc tout problème de répétition de la référence dans le nom est à mettre à
l'actif des contributeurs.

Enfin la sélection en se fait pas par operator mais par emprise
géographique.

René-Luc


Le 26/07/2012 17:44, Philippe Verdy a écrit :

Petits commentaires suppélmentaires.

Les noms des lignes sont assez bizarre à Rennes. Par exemple:

64: Bus Rennes Ligne 64 Direction Rennes
65: Bus Rennes Ligne 65 Direction Rennes

->  Il semble qu'il y ait confusion entre le nom du sens de
circulation et le nom de la ligne (quand les deux parcours ne passent
pas par le même chemin, les deux sens sont regroupés dans une même
relation donnant le nom de l'ensemble).
-> Est-ce utile aussi de rappeler le numéro de la ligne dans le nom
alors que le numéro est affiché dans un rectangle en tête ?
-> Ces mêmes cas se rencontrent aussi dans d'autres villes.

52 Bus Rennes Ligne 52 Direction Saint-Gilles

-> Là cela ne nomme que la moitié de la ligne (la partie ouest mais
pas la partie nord, Rennes n'étant que le milieu de la ligne à la
station de métro, si tu prends un des deux terminus, l'autre n'est
même pas nommé, Rennes n'est pas le terminus)
-> Ces mêmes cas se rencontrent aussi dans d'autres villes.


Comment as-tu dressé la liste des lignes et des réseaux de transport
(recherche sur "operator=*") ? Si tu te bases uniquement sur les
données présentes dans la base, est-ce que le modèle est adapté, et
comment faudrait-il le changer pour que ça marche (si on doit le
changer ou si c'est ton outil qu'il fait modifier) ?

Derniers cas à analyser :

-> certaines lignes n'ont PAS de numéro, juste un nom (exemple le
CityTAN à Niort, qui est forme une double boucle en huit sans t

Re: [OSM-talk-fr] OSMTransport change de peau

[Philippe Verdy]

Pour les couleurs de lignes, certaines agglomération ont un schéma
uniforme aussi bien dans la signalisation, les panneaux des arrpet
comme les bus, et les plans papier diffusés ou affichés. LA couleur
concerne autant la couleur de fond de l'étiquette que celle des
caractères, la couleur de fond devant correspondre si possible à la
couleur du tracé sur la carte comme tu le fais.

Sans aller jusqu'à reproduire aussi les logos, il y a aussi des
différences de forme pour ces numéros (par exemple dans un cercle ou
un carré). Enfin il ne serait pas inutile de repérer les terminus sur
la carte (ce sont des arrêts où le bus change de sens ou bien où il
dépose tout le monde et poursuit sans passagers vers son dépôt) en
affichant les numéros de ligne sur la carte. Cela demanderait une
collection de petites icônes (faciles à générer de façon vectorielle à
partir d'une forme de base, des couleurs de fond, de bordure et de
texte et le numéro ou à défaut une abbréviation du nom ou un symbole
générique) en mettant en libellé le nom de la destination à partir de
ce terminus (si la ligne est jsute un cycle, un seul point est
rensiegné, le point d'arrêt principal, souvent sur une place centrale
d'échange, et en libellé on mettrait le nom de la ligne.

Selon les références que tu trouves, on pourrait avoir pour ton rendu,
dans ta propre base, des noms adaptés à ta carte pour remplacer ceux
trouvés dans la base quand ils ne conviennent pas bien (pas besoin
forcément de mettre à jour la base OSM), dans la délimitation
géographique de l'agglomération que tu as définie.

Note: une des villes est nommée avec le préfixe abrégé "Agglo", à mon
avis inutile et perturbant dans la liste. Tout dans cette liste de
sélection concerne une agglomération (parfois un peu plus sur des
réseaux étendus tels que "Paris Est", où on se demande pourquoi on n'a
pas aussi "Paris Ouest" pour tout ce qui est autour du réseau au
départ de Saint-Lazare et des lignes de bus en correspondance dans les
villes traversées, et "Paris Sud" depuis Montparnasse ou la Gare de
Lyon).

Enfin certaines villes manquent de traits d'union dans la liste affichée.

Le 26 juillet 2012 17:53, rldhont  a écrit :
> Bonjour Philippe,
>
> Tout d'abord OSMTransport a été construit il y a 3 ans, à l'époque il n'y
> avait qu'un seul modèle pour les lignes de bus un seul relations par ligne
> et il n'était pas question de s'amuser à définir une relation par sens de
> circulation ni de super-relation par ligne référence toutes les relations
> formant toutes les variations d'une ligne. Sachant cela :
> * la référence est pour moi la clef d'identification d'une ligne donc si il
> y a plusieurs relations portant le même tag ref, je les colles ensembles
> * l'affichage du tag name vient d'être ajouté pour voir, celui-ci comme la
> couleur de la ligne est extrait de la première relation que je rencontre
> avec ce ref en particulier
>
> Donc tout problème de répétition de la référence dans le nom est à mettre à
> l'actif des contributeurs.
>
> Enfin la sélection en se fait pas par operator mais par emprise
> géographique.
>
> René-Luc
>
>
> Le 26/07/2012 17:44, Philippe Verdy a écrit :
>>
>> Petits commentaires suppélmentaires.
>>
>> Les noms des lignes sont assez bizarre à Rennes. Par exemple:
>>
>> 64: Bus Rennes Ligne 64 Direction Rennes
>> 65: Bus Rennes Ligne 65 Direction Rennes
>>
>> ->  Il semble qu'il y ait confusion entre le nom du sens de
>> circulation et le nom de la ligne (quand les deux parcours ne passent
>> pas par le même chemin, les deux sens sont regroupés dans une même
>> relation donnant le nom de l'ensemble).
>> -> Est-ce utile aussi de rappeler le numéro de la ligne dans le nom
>> alors que le numéro est affiché dans un rectangle en tête ?
>> -> Ces mêmes cas se rencontrent aussi dans d'autres villes.
>>
>> 52 Bus Rennes Ligne 52 Direction Saint-Gilles
>>
>> -> Là cela ne nomme que la moitié de la ligne (la partie ouest mais
>> pas la partie nord, Rennes n'étant que le milieu de la ligne à la
>> station de métro, si tu prends un des deux terminus, l'autre n'est
>> même pas nommé, Rennes n'est pas le terminus)
>> -> Ces mêmes cas se rencontrent aussi dans d'autres villes.
>>
>>
>> Comment as-tu dressé la liste des lignes et des réseaux de transport
>> (recherche sur "operator=*") ? Si tu te bases uniquement sur les
>> données présentes dans la base, est-ce que le modèle est adapté, et
>> comment faudrait-il le changer pour que ça marche (si on doit le
>> changer ou si c'est ton outil qu'il fait modifier) ?
>>
>> Derniers cas à analyser :
>>
>> -> certaines lignes n'ont PAS de numéro, juste un nom (exemple le
>> CityTAN à Niort, qui est forme une double boucle en huit sans terminus
>> réel), mais tu affiches quand même "null" ce qui est superflu (au pire
>> tu peux juste afficher une espace insécable ou un symbole générique
>> comme "+")
>> -> Les trams à Nantes sont affichés deux fois (une fois dans la
>> rubrique tramways pour tout le réseau en noir sans discerner l

Re: [OSM-talk-fr] OSMTransport change de peau

[rldhont]

Bonjour Philippe,

Tout d'abord OSMTransport a été construit il y a 3 ans, à l'époque il 
n'y avait qu'un seul modèle pour les lignes de bus un seul relations par 
ligne et il n'était pas question de s'amuser à définir une relation par 
sens de circulation ni de super-relation par ligne référence toutes les 
relations formant toutes les variations d'une ligne. Sachant cela :
* la référence est pour moi la clef d'identification d'une ligne donc si 
il y a plusieurs relations portant le même tag ref, je les colles ensembles
* l'affichage du tag name vient d'être ajouté pour voir, celui-ci comme 
la couleur de la ligne est extrait de la première relation que je 
rencontre avec ce ref en particulier


Donc tout problème de répétition de la référence dans le nom est à 
mettre à l'actif des contributeurs.


Enfin la sélection en se fait pas par operator mais par emprise 
géographique.


René-Luc


Le 26/07/2012 17:44, Philippe Verdy a écrit :

Petits commentaires suppélmentaires.

Les noms des lignes sont assez bizarre à Rennes. Par exemple:

64: Bus Rennes Ligne 64 Direction Rennes
65: Bus Rennes Ligne 65 Direction Rennes

->  Il semble qu'il y ait confusion entre le nom du sens de
circulation et le nom de la ligne (quand les deux parcours ne passent
pas par le même chemin, les deux sens sont regroupés dans une même
relation donnant le nom de l'ensemble).
-> Est-ce utile aussi de rappeler le numéro de la ligne dans le nom
alors que le numéro est affiché dans un rectangle en tête ?
-> Ces mêmes cas se rencontrent aussi dans d'autres villes.

52 Bus Rennes Ligne 52 Direction Saint-Gilles

-> Là cela ne nomme que la moitié de la ligne (la partie ouest mais
pas la partie nord, Rennes n'étant que le milieu de la ligne à la
station de métro, si tu prends un des deux terminus, l'autre n'est
même pas nommé, Rennes n'est pas le terminus)
-> Ces mêmes cas se rencontrent aussi dans d'autres villes.


Comment as-tu dressé la liste des lignes et des réseaux de transport
(recherche sur "operator=*") ? Si tu te bases uniquement sur les
données présentes dans la base, est-ce que le modèle est adapté, et
comment faudrait-il le changer pour que ça marche (si on doit le
changer ou si c'est ton outil qu'il fait modifier) ?

Derniers cas à analyser :

-> certaines lignes n'ont PAS de numéro, juste un nom (exemple le
CityTAN à Niort, qui est forme une double boucle en huit sans terminus
réel), mais tu affiches quand même "null" ce qui est superflu (au pire
tu peux juste afficher une espace insécable ou un symbole générique
comme "+")
-> Les trams à Nantes sont affichés deux fois (une fois dans la
rubrique tramways pour tout le réseau en noir sans discerner les
lignes, une autre fois avec chaque ligne, mais la sélection "tramways"
recouvre des longueurs plus importantes que les lignes, sans doûte car
des segments ne portent pas le numéro de la ou les lignes concernées).

Bon courage.

Le 26 juillet 2012 10:43, rldhont  a écrit :

Pour l'ordre des numéros c'était une régression, c'est corrigé. D'ailleurs
tous les réseaux n'utilisent pas que des chiffres pour identifier les
lignes.

René-Luc

___
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] OSMTransport change de peau

[Philippe Verdy]

Petits commentaires suppélmentaires.

Les noms des lignes sont assez bizarre à Rennes. Par exemple:

64: Bus Rennes Ligne 64 Direction Rennes
65: Bus Rennes Ligne 65 Direction Rennes

->  Il semble qu'il y ait confusion entre le nom du sens de
circulation et le nom de la ligne (quand les deux parcours ne passent
pas par le même chemin, les deux sens sont regroupés dans une même
relation donnant le nom de l'ensemble).
-> Est-ce utile aussi de rappeler le numéro de la ligne dans le nom
alors que le numéro est affiché dans un rectangle en tête ?
-> Ces mêmes cas se rencontrent aussi dans d'autres villes.

52 Bus Rennes Ligne 52 Direction Saint-Gilles

-> Là cela ne nomme que la moitié de la ligne (la partie ouest mais
pas la partie nord, Rennes n'étant que le milieu de la ligne à la
station de métro, si tu prends un des deux terminus, l'autre n'est
même pas nommé, Rennes n'est pas le terminus)
-> Ces mêmes cas se rencontrent aussi dans d'autres villes.


Comment as-tu dressé la liste des lignes et des réseaux de transport
(recherche sur "operator=*") ? Si tu te bases uniquement sur les
données présentes dans la base, est-ce que le modèle est adapté, et
comment faudrait-il le changer pour que ça marche (si on doit le
changer ou si c'est ton outil qu'il fait modifier) ?

Derniers cas à analyser :

-> certaines lignes n'ont PAS de numéro, juste un nom (exemple le
CityTAN à Niort, qui est forme une double boucle en huit sans terminus
réel), mais tu affiches quand même "null" ce qui est superflu (au pire
tu peux juste afficher une espace insécable ou un symbole générique
comme "+")
-> Les trams à Nantes sont affichés deux fois (une fois dans la
rubrique tramways pour tout le réseau en noir sans discerner les
lignes, une autre fois avec chaque ligne, mais la sélection "tramways"
recouvre des longueurs plus importantes que les lignes, sans doûte car
des segments ne portent pas le numéro de la ou les lignes concernées).

Bon courage.

Le 26 juillet 2012 10:43, rldhont  a écrit :
> Pour l'ordre des numéros c'était une régression, c'est corrigé. D'ailleurs
> tous les réseaux n'utilisent pas que des chiffres pour identifier les
> lignes.
>
> René-Luc

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

Re: [OSM-talk-fr] JOSM en touche "enter"

[Vincent Privat]

Apparement c'est svn.osm.org qui est tombé en carafe cette nuit et qui a
causé des problèmes.
Du coup on devrait avoir le latest demain matin !
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OSMTransport change de peau

[Philippe Verdy]

Si la liste des villes s'allonge, il serait bien de pouvoir les
classer au moins par région ou département, au delà de la seule
sélection du pays (plus un niveau national pour les lignes SNCF, ou
lignes bus interdépartementales régulières).

Le choix alors de la ville ou plus souvent de l'agglomération (ou le
nom du réseau pour le niveau national ou un niveau régional) serait
plus facile (et évitera aussi des homonymies).

Il me semble aussi que toutes les métropoles et communauté urbaines ou
d'agglomération devraient y être (elles ont compétence territoriale
directement sur l'ensemble des transports publics pour toutes les
communes membres).

Au delà de ça les lignes ou réseaux privés (stations de taxi par
exemple) pourraient être ajoutés. Les réseaux cyclables en revanche
sont rarement aussi bien intégrés et sont davantage de la compétence
des communes, voire souvent aussi d'assos locales.

A voir aussi les lignes de bac et ferry pour les liaisons côtières,
trans-Manche, ou trans-méditerranéennes vers la Corse, la Sardaigne,
l'Espagne, l'Italie ou l'Algérie.

Et les bateaux-bus dans les villes sur des grand fleuves ou estuaires
ou qui traversent un port assez grand qu'il est assez long de
contourner à pied (par exemple avec des enfants qui ne marchent pas
longtemps ou pour les handicapés qui ne peuvent pas garer non plus
leur véhicule aussi près qu'ils voudraient quand les parkings sont
plus éloignés et du mauvais côté), certaines villes ayant même
plusieurs ports et marinas qu'on peut rejoindre par ces moyens
maritimes et fluviaux.

Le 26 juillet 2012 10:36, Francescu GAROBY  a écrit :
> Merci tout d'abord pour la réponse rapide :-)
>
> Autre point "génant" : le tri des lignes de bus/tram se fait selon un ordre
> alphanumérique (1 puis 19 puis 2) et non numérique (1 puis 2 puis 19).
> Pour Caen, je regarde ce qu'il en est pour les tags des lignes existantes.
>
> Francescu
>
> Le 26 juillet 2012 10:31, rldhont  a écrit :
>
>> Bonjour Francescu,
>>
>> Pour la mise à jour, c'est un gros chantier qui ne peut prendre trop de
>> temps sur mon travail ou mon temps libre. Donc pour le moment je lance de
>> temps en temps des rafraîchissements. Mais il faut aussi que je travail sur
>> le système de cache qui est trop long.
>>
>> Pour la référence, j'utilise le tag ref, et pour le nom j'utilise le tag
>> name. Sur Caen, il y a peut-être un problème de fraîcheur des données.
>>
>> Pour les Numéros au sein de la popup des arrêts, c'est une bonne idée. Je
>> n'ai aps fait de test sur des données possédant où les arrêts ont de
>> nombreuses connections.
>>
>> Enfin pour les pictogramme, j'y avais pensé. Je pensais même à une sorte
>> d'image qui se construirait en fonction des informations présentes. Par
>> contre pour les arrêts de bus j'ai découvert qu'il y avait les tags shelter
>> et covered !
>>
>> René-Luc
>>
>>
>> Le 26/07/2012 10:22, Francescu GAROBY a écrit :
>>
>> Bonjour,
>> Bravo pour cette refonte, très jolie graphiquement !
>>
>> Quelques questions/propositions d'amélioration, cependant :
>> * quelle est la fréquence de rafraîchissement des données ? Je travaille
>> actuellement sur les lignes de transport de Caen, et je ne vois pas tous mes
>> travaux ;
>> * sur quel(s) tag(s) vous basez-vous pour le nom des lignes ? Car les
>> trams de Caen n'ont pas de nom indiqué ("undefined"), alors qu'ils existent
>> dans OSM ;
>> * les numéros des lignes passant par un arrêt de bus/tram ne sont pas
>> classés par ordre croissant, ce qui rendrait la lecture plus aisée ;
>> * dans un souci de compréhension, il faudrait remplacer "shelter" et
>> "bench" par un pictogramme ;
>>
>> Merci d'avance,
>> Francescu
>>
>> Le 26 juillet 2012 10:05, rldhont  a écrit :
>>>
>>> Bonjour,
>>>
>>> Nous, 3Liz, profitons de l'été pour mettre à jour les interfaces de nos
>>> démonstrateurs. Après LizMap, solution de web mapping basé sur QGIS Server,
>>> c'est au tour d'OSMTransport :
>>> http://demo.3liz.com/osmtransport
>>>
>>> Ce changement d'interface est aussi l'occasion de faire évoluer les
>>> fonctionnalités :
>>> * dans les fonds de carte vous trouverez le fond MapQuest par défaut, le
>>> fond OpenStreetMap, et le fond Bing Aerial. Nous avons pensé que pouvoir
>>> visualiser les données TC au dessus du fond utilisé pour la digitalisation
>>> pouvait être quelque chose d'intéressant
>>> * réorganisation de l'arbre des données TC
>>> * Affichage par défaut d'un maximum de 100 objets géographiques
>>> représentant des lignes
>>> * Ajout d'informations dans les popups des données. Par exemple les tags
>>> shelter, bench pour les arrêts.
>>>
>>> Voici quelque liens directs :
>>> * Montpellier
>>> http://demo.3liz.com/osmtransport/index.php?country=1&location=2
>>> * Orange
>>> http://demo.3liz.com/osmtransport/index.php?country=1&location=84
>>> * Marseille
>>> http://demo.3liz.com/osmtransport/index.php?country=1&location=11
>>> * Nantes http://demo.3liz.com/osmtransport/index.php?country=1&location=4
>>>
>>> Si il y a des tags q

Re: [OSM-talk-fr] JOSM en touche "enter"

[Philippe Verdy]

OK merci. C'et vrai que je pourrais la compiler moi-même, j'ai les
outils pour ça, mais je ne m'occupe pas de ce repository, je pense
qu'il y a assez de monde pour la maintenance de l'appli, et j'ai aussi
d'autres choses à faire que de développer pour une appli de plus.

Le 26 juillet 2012 16:40, Vincent Privat  a écrit :
> Ou plein d'autres raisons qu'on ne peut pas deviner. J'ai remonté l'info sur
> josm-dev, je n'ai aucun doute que Dirk va trouver et corriger le problème en
> moins de temps qu'il ne faut pour l'expliquer :)
> Je pense qu'on aura une latest générée manuellement dans la journée. Sinon
> ce sera pour cette nuit :)

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

Re: [OSM-talk-fr] récupérer une carte OSM sous forme d'image géoéréférencée, par ex. au format pngw

[Philippe Verdy]

Il me semble qu'au vu de la capacité mémoire limitée des GPS portable,
il n'est guère possible d'y embarquer des rendus aussi précis sur des
zones aussi grande, avec un format bitmap.

Les GPS portables utilisent tous des formats vectoriels avec un rendu
logiciel intégré (avec plus ou moins de détails selon la capacité de
calcul de l'appareil) s'ils ne doivent pas dépendre entièrement d'une
connexion réseau mobile (souvent très lente hors des grands centres
urbains et qui ne permettra pas de télécharger convenablement les
tuiles, comme on le voit par exemple avec Google Maps sur les
appareils Android, et souvent trop cher aussi à l'usage pour
l'utilisateur à cause de la façon dont les opérateurs surfacturent
leurs mégaoctets avec des forfaits data trop limités pour ce genre
d'application).

C'est donc avantage vers un logiciel de rendu vectoriel (ou celui déjà
intégré dans l'appareil avec son format de données supporté) et un
export de données vectorielles qu'on devra chercher une solution.

Car même la solution TMS (façon Google Maps dans le mode de
visualisation "satellite" et non "plan") sera trop coûteuse et trop
lente (La 3G ou 3G+ c'et bien beau mais en pratique on ne capte
souvent pas autre chose que du GPRS via aussi des proxies obligatoires
des opérateurs qui limitent énormément les protocoles supportés et
posent de sérieux problèmes avec les caches intégrés, et le maintien
des sessions puisqu'on passe presque toujours par un NAT souvent
surchargé qui ferme les ports trop vite ; les microconnexions qui
utilisent le système MMS sont de plus très coûteuses en plus de
manquer d'interactivité pour autre chose que le transport de
mini-textes, c'est bien pour ça que maintenant les sites web proposent
systématiquement leurs propres applications mobiles pour optimiser la
bande passante, la réactivité et la gestion plus intelligente d'un
cache local dans le périphérique mobile car le web "normal" est
presque inutilisable en plus d'avoir une interface utilisateur
difficilement exploitable, même sur une tablette).

Le mode bitmap en revanche peut suffire pour une navigation de type
piéton, où on ne parcourt pas des distances énormes, et où on peut
parfois capter facilement des accès Wifi itinérants plus économiques
et souvent gratuits (souvent proposés en ville dans les cafés ou
restaux, moyennant juste une préidentification et l'acceptation
préalable d'une charte d'utilisation via une page d'accueil préalable,
ce qui n'est pas possible en mode itinérant où on passera ans arrêt
d'un point d'accès à un autre).

Le 26 juillet 2012 15:07, Mathieu Rajerison
 a écrit :
> Bonjour,
>
> J'ai réalisé un raster de données OSM au format PNG sur la commune d'Aix en
> Provence en utilisant la méthode René Luc.
>
> J'ai pu voir qu'en ayant des tuiles de 500 mètres de côté, on obtenait un
> niveau de détails très précis.
>
> Par contre, le fichier fait 230 Mo. Cela me semble donc difficilement
> gérable, à moins de se restreindre à un quartier. Je vais donc regarder les
> solutions de Nicolas.
>
> Je pense que l'idéal est d'avoir un GPS connecté à internet et pouvant
> recevoir des données selon le protocole TMS. Je ne sais pas si ça existe et
> si cela existe, ça doit coûter très cher. Un ordi portable connecté à un GPS
> peut faire l'affaire mais c'est assez encombrant. Sur smartphone peut-être,
> avec QGIS pour Android.
>
> Merci pour tous les retours très instructifs en tout cas!
>
> Mathieu
>
> Le 25 juillet 2012 11:51, Nicolas Moyroud  a écrit :
>>
>>
>> As-tu testé NoniMapView et gMapCatcher ?
>>
>> Jean-Claude
>>
>> NoniMapView génère des dalles avec des fichiers de géoréférencement un peu
>> exotiques (c'est du .map adapté au logiciel pour Windows Mobile
>> NoniGPSPlot). Par contre, il y a le logiciel Mobile Atlas Creator dans le
>> même genre qui est capable de générer plusieurs formats (KMZ, Garmin,
>> Magellan, ...)
>>
>> Nicolas
>>
>> ___
>> 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] JOSM en touche "enter"

[Vincent Privat]

Ou plein d'autres raisons qu'on ne peut pas deviner. J'ai remonté l'info
sur josm-dev, je n'ai aucun doute que Dirk va trouver et corriger le
problème en moins de temps qu'il ne faut pour l'expliquer :)
Je pense qu'on aura une latest générée manuellement dans la journée. Sinon
ce sera pour cette nuit :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] JOSM en touche "enter"

[Philippe Verdy]

Ok, on attendra donc la 5367 maintenant (avec la correction que tu
viens de faire de la touche Enter (au lieu de Q) pour fermer certains
dialogues.

Reste à savoir ce qui a fait planter la compilation et si cela ne
cache pas une autre correction à faire (par exemple un package non
trouvé dans le chemin de compilation, ou une mauvaise
installation/mise à jour d'une bibliothèque dépendante ou d'un
utilitaire ou script utilisé dans le processus automatique de
compilation, ou un problème matériel sur le serveur, ou un problème
d'espace de stockage lié à un gros log plus volumineux que d'habitude
mais oublié dans un dossier temporaire, ou un chemin d'accès réseau
indisponible, le problème étant peut-être déjà corrigé tout seul).

Le 26 juillet 2012 15:20, Vincent Privat  a écrit :
>
> Le 26 juillet 2012 13:30, Philippe Verdy  a écrit :
>
>>
>> Mais c'est encore la 5361 que je charge en JNLP (donc pas de mise à
>> jour détectée).
>>
> Effectivement il y a un souci, on dirait que la compilation s'est mal passé
> cette nuit (c'est entièrement automatique, la compil est lancée entre 3 et
> 4h du mat', et je ne l'avais jamais vu échouer jusqu'ici). Je demande à Dirk
> (c'est lui qui gère le serveur)

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

Re: [OSM-talk-fr] JOSM en touche "enter"

[Vincent Privat]

2012/7/26 Pieren 

> Par contre, j'ai de nombreuses exceptions au démarrage et qui n'ont
> probablement rien à voir avec le sujet, genre:
> EDT violation detected
>

Comment lances-tu JOSM ? Si c'est depuis Eclipse c'est "normal", elles ne
sont visibles que par les développeurs. Tu peux les désactiver en
positionnant le paramètre *debug.edt-checker.enable* à false.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] JOSM en touche "enter"

[Vincent Privat]

Le 26 juillet 2012 13:30, Philippe Verdy  a écrit :

>
> Mais c'est encore la 5361 que je charge en JNLP (donc pas de mise à
> jour détectée).
>
> Effectivement il y a un souci, on dirait que la compilation s'est mal
passé cette nuit (c'est entièrement automatique, la compil est lancée entre
3 et 4h du mat', et je ne l'avais jamais vu échouer jusqu'ici). Je demande
à Dirk (c'est lui qui gère le serveur)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Quelques questions d'un débutant OSM

[Philippe Verdy]

Le 26 juillet 2012 14:53, Gilles Bassière  a écrit :
> En revanche, ton arrêt de bus fera (à terme) partie de relations
> décrivant chacune des lignes passant par ton arrêt. Sur ces relations,
> la clé operator a toute sa valeur et elle est normalement unique (il y a
> des exceptions, sur le RER notamment, mais c'est moins fréquent).

Il me semble que le RER est un réseau dont la responsabilité est
publique mais qui comprend une exploitation commerciale par plusieurs
sociétés (même si elles sont semi-publiques et se partagent les
lignes, en forunissant des moyens qui leur sont propres ou encore
empruntés à d'autres sociétés sous contrats notamment pour le
personnel, l'entretien, la vente de billets et abonnements).

Le réseau lui-même est indépendant des rames qui y circulent (RATP,
SNCF voire aussi sociétés de transport étrangères ou privées). On doit
distinguer alors la cartographie physique (celle des lignes
construites, qui sont souvent sous forme de tronçons placés sous des
responsabilités diverses selon les collectivités concernées, voire les
sociétés mixtes d'aménagement propriétaires des terrains ou immeubles
dans lesquels passent les voies) des lignes commerciales (exploitées
par un réseau et soumis à un regroupement tarifaire pour les
voyageurs, mais pas pour les exploitants et l'entretien, ni pour
d'autres applications que le transport de voyageurs).

Pour cela OSM propose des modèles différents : on commence par la
géographie physique (à laquelle on attache la géométrie des noeuds et
ways et les accès aux gares), puis on construit des relations pour les
lignes dans chaque sens, avec les arrêts desservis ou non, puis des
relations pour construire le réseau d'un exploitant commercial destiné
à une catégorie de transport (ces réseaux pouvant se superposer, avoir
la même finalité ou pas, être l'objet de conventions de service public
ou pas, et même sur une même ligne, des rames peuvent être
subventionnées par certaines collectivités membre et pas d'autres, ce
qui explique des trajets plus ou moins longs et des droits d'accès
différents selon les titres de transport utilisés par les voyageurs et
leurs formules d'abonnement ou pas, à laquelle participe ou non un
employeur selon le lieu de travail et celui de résidence).

Si on commence à détailler les possibilités, cela peut devenir assez
complexe. Raison de plus de ne pas tout mettre directement dans les
briques de base de la géométrie physique.

Le "RER" en lui-même n'est pas réellement un réseau car c'est plus un
concept d'aménagement régional (en chantier quasi-permanent où les
lignes ferroviaires sont souvent remplacées par des lignes de bus ou
d'autres moyens parfois saisonniers ou temporaires le temps de
travaux) regroupant de nombreux acteurs sur le terrain sur des trajets
interurbains (mais intégrés à Paris en complément du métro pour des
liaisons plus rapides avec moins d'arrêts intermédiaires et une
capacité de transport plus massif de voyageurs surtout aux heures de
pointe que le seul métro ne pourrait absorber efficacement dans ses
couloirs). Il y a en fait des tas de lignes très distinctes mais qui
se recouvrent partiellement et autorisent ou pas divers titres de
transport émis par un des acteurs.

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

Re: [OSM-talk-fr] récupérer une carte OSM sous forme d'image géoéréférencée, par ex. au format pngw

[Mathieu Rajerison]

Bonjour,

J'ai réalisé un raster de données OSM au format PNG sur la commune d'Aix en
Provence en utilisant la méthode René Luc.

J'ai pu voir qu'en ayant des tuiles de 500 mètres de côté, on obtenait un
niveau de détails très précis.

Par contre, le fichier fait 230 Mo. Cela me semble donc difficilement
gérable, à moins de se restreindre à un quartier. Je vais donc regarder les
solutions de Nicolas.

Je pense que l'idéal est d'avoir un GPS connecté à internet et pouvant
recevoir des données selon le protocole TMS. Je ne sais pas si ça existe et
si cela existe, ça doit coûter très cher. Un ordi portable connecté à un
GPS peut faire l'affaire mais c'est assez encombrant. Sur smartphone
peut-être, avec QGIS pour Android.

Merci pour tous les retours très instructifs en tout cas!

Mathieu

Le 25 juillet 2012 11:51, Nicolas Moyroud  a écrit :

> **
>
>
> As-tu testé NoniMapView et gMapCatcher ?
>
> Jean-Claude
>
>  NoniMapView génère des dalles avec des fichiers de géoréférencement un
> peu exotiques (c'est du .map adapté au logiciel pour Windows Mobile
> NoniGPSPlot). Par contre, il y a le logiciel Mobile Atlas Creator dans le
> même genre qui est capable de générer plusieurs formats (KMZ, Garmin,
> Magellan, ...)
>
> Nicolas
>
> ___
> 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] Tagguer un bâtiment à usage multiple (était: Re: Quelques questions d'un débutant OSM)

[Mathieu Rajerison]

Bonjour Gilles,

C'est bien ce que je me disais. Cette approche me semble beaucoup plus
intelligente.

Merci

Le 26 juillet 2012 14:45, Gilles Bassière  a écrit :

> Bonjour Mathieu,
>
> On jeu., 2012-07-26 at 13:51 +0200, Mathieu Rajerison wrote:
> > - Aussi, comment indiquer qu'un bâtiment abrite à la fois des
> > activités commerciales et des logements?
>
> Ça peut se faire au niveau de la clé building. Par exemple :
>building=retail;residential
>
> Je l'ai rarement vu. En général, un tel niveau de détail n'est pas
> atteint : le bâtiment est simplement building=yes et on y rajoute les
> clé shop=* qui vont bien.
>
> De plus en plus souvent, je laisse le bâtiment tel quel et j'ajoute un
> node portant les tags du lieu, par exemple shop=...
>
> Cordialement
> --
> Gilles Bassière - Web/GIS software engineer
> http://gbassiere.free.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] Quelques questions d'un débutant OSM

[Gilles Bassière]

Re,

On jeu., 2012-07-26 at 13:51 +0200, Mathieu Rajerison wrote:
> - On ne peut pas utiliser plusieurs fois le tag operator. Lorsqu'une
> plate-forme de bus est affectée à plusieurs opérateurs, doit-on
> utiliser des relations? Et comment?

Tu peux toujours utiliser la notation ';'. Par exemple :
operator=RTM;Cartreize

Je continue à mettre operator sur les arrêts de bus seulement parce que
c'est dans mes presets JOSM et que j'ai la flemme de les mettre à jour.
Honnêtement, je ne trouve pas ça très utile.

En revanche, ton arrêt de bus fera (à terme) partie de relations
décrivant chacune des lignes passant par ton arrêt. Sur ces relations,
la clé operator a toute sa valeur et elle est normalement unique (il y a
des exceptions, sur le RER notamment, mais c'est moins fréquent).

Pour les relations, l'usage en est généralement présenté comme "avancé"
mais ce n'est pas si compliqué. Il doit y avoir quelques tutos sur le
Web + de la doc sur le Wiki. Si tu as l'occasion de passer nous voir à
Marseille, je te montrerai avec plaisir comment les utiliser. Ce sera
plus simple de vive voix et par la pratique.

Cordialement
-- 
Gilles Bassière - Web/GIS software engineer
http://gbassiere.free.fr/



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

[OSM-talk-fr] Tagguer un bâtiment à usage multiple (était: Re: Quelques questions d'un débutant OSM)

[Gilles Bassière]

Bonjour Mathieu,

On jeu., 2012-07-26 at 13:51 +0200, Mathieu Rajerison wrote:
> - Aussi, comment indiquer qu'un bâtiment abrite à la fois des
> activités commerciales et des logements?

Ça peut se faire au niveau de la clé building. Par exemple :
   building=retail;residential

Je l'ai rarement vu. En général, un tel niveau de détail n'est pas
atteint : le bâtiment est simplement building=yes et on y rajoute les
clé shop=* qui vont bien.

De plus en plus souvent, je laisse le bâtiment tel quel et j'ajoute un
node portant les tags du lieu, par exemple shop=...

Cordialement
-- 
Gilles Bassière - Web/GIS software engineer
http://gbassiere.free.fr/



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

Re: [OSM-talk-fr] Traduction de "redaction" en français

[Philippe Verdy]

Oui car il me semble que le bot pourrait être utilisé aussi pour faire
un "revert" massif de toutes les contributions d'un utilisateur qui a
fait une violation de copyright (mettant en doute la totalité de ses
contributions qu'il vaut mieux défaire en totalité quitte à devoir les
retracer avec des attributions plus respectueuses, ou parce qu'un
utilisateur est malveillant et a introduit des données massivement et
de façon désordonnée qu'il serait trop long de recontrôler isolément),
ou suite à une injonction judiciaire qui demande une réponse très
rapide et aussi efficace que possible.

Le changement de licence à l'initiative d'OSM n'est pas la seule raison.

Je laisserais donc la phrase :
"Veuillez consulter %{redaction_link} pour plus d'informations."
sans rien y ajouter de plus.

J'approuve aussi le terme "masqué" qui répond bien à ce que fait
effectivement le bot (qui se charge de cacher toutes les contributions
d'un ou plusieurs utilisateurs, pour un ou plusieurs motifs qui seront
précisés dans la page accessible par le lien %{redaction_link}.

Le 26 juillet 2012 14:07, Nicolas Dandrimont
 a écrit :
> Le 26/07/2012 à 11:21, Hélène PETIT  écrivit :
>> Le 26/07/2012 01:19, Nicolas Dandrimont a écrit :
>> > Je pensais à quelque chose du style "La version %{version} de ce(tte)
>> > %{type} ne peut pas être affichée car elle a été (cachée/censurée/???).
>> > Veuillez consulter %{redaction_link} pour plus d'informations."
>> >
>> > La question est sur le mot entre parenthèses. :)
>>
>> "masqué" met plus l'accent sur le caractère intentionnel de la chose,
>> et on peut aussi compacter la petite redondance de sens, par exemple
>> comme ça :
>>
>> "La version %{version} de ce(tte) %{type} est masquée, conformément au
>> changement de licence consultable ici : %{redaction_link}."
>
> Le mécanisme de masquage a été conçu de manière plus générique
> qu'uniquement pour ce changement de licence, donc la contraction n'est
> pas forcément adaptée. C'est d'ailleurs pour ça qu'il y a une page
> d'information spécifique pour chaque passe.
>
> Le terme "masquage" me semble tout à fait clair et adapté, j'approuve. \o/
>
> Je m'occupe de revoir les traductions de ce pas.
>
> Merci à tous,
> --
> Nicolas Dandrimont
>
> ___
> 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] JOSM en touche "enter"

[Pieren]

2012/7/26 Vincent Privat :
> Merci beaucoup Christian pour tes essais qui m'ont aiguillé sur le problème
> :)
> C'est normalement corrigé dans la latest de ce matin !

Je confirme que ça marche ! Merci à Christian pour l'effort titanesque.

Par contre, j'ai de nombreuses exceptions au démarrage et qui n'ont
probablement rien à voir avec le sujet, genre:
EDT violation detected
javax.swing.JMenuItem[,0,0,0x0,invalid,disabled,alignmentX=0.0,alignmentY=0.0,border=javax.swing.plaf.metal.MetalBorders$MenuItemBorder@8b1323,flags=264,maximumSize=,minimumSize=,preferredSize=,defaultIcon=javax.swing.ImageIcon@8c6e04,disabledIcon=,disabledSelectedIcon=,margin=javax.swing.plaf.InsetsUIResource[top=2,left=2,bottom=2,right=2],paintBorder=true,paintFocus=false,pressedIcon=,rolloverEnabled=false,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=Tunnel]
at java.lang.Thread.getStackTrace(Unknown Source)
at 
org.jdesktop.swinghelper.debug.CheckThreadViolationRepaintManager.checkThreadViolations(CheckThreadViolationRepaintManager.java:81)
at 
org.jdesktop.swinghelper.debug.CheckThreadViolationRepaintManager.addDirtyRegion(CheckThreadViolationRepaintManager.java:72)
at javax.swing.JComponent.repaint(Unknown Source)
at java.awt.Component.repaint(Unknown Source)
at javax.swing.AbstractButton.setIcon(Unknown Source)
at javax.swing.JMenuItem.setIconFromAction(Unknown Source)
at javax.swing.JMenuItem.smallIconChanged(Unknown Source)
at javax.swing.AbstractButton.actionPropertyChanged(Unknown Source)
at javax.swing.JMenuItem.actionPropertyChanged(Unknown Source)
at 
javax.swing.AbstractButton$ButtonActionPropertyChangeListener.actionPropertyChanged(Unknown
Source)
at 
javax.swing.AbstractButton$ButtonActionPropertyChangeListener.actionPropertyChanged(Unknown
Source)
at javax.swing.ActionPropertyChangeListener.propertyChange(Unknown 
Source)
at java.beans.PropertyChangeSupport.firePropertyChange(Unknown Source)
at 
javax.swing.event.SwingPropertyChangeSupport.firePropertyChange(Unknown
Source)
at java.beans.PropertyChangeSupport.firePropertyChange(Unknown Source)
at javax.swing.AbstractAction.firePropertyChange(Unknown Source)
at javax.swing.AbstractAction.putValue(Unknown Source)
at 
org.openstreetmap.josm.gui.tagging.TaggingPreset$1.run(TaggingPreset.java:1257)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown 
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

(build avec Eclipse)

Pieren

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

Re: [OSM-talk-fr] Traduction de "redaction" en français

[Christian Rogel]

Le 26 juil. 2012 à 01:19, Nicolas Dandrimont a écrit :

> 
> Je n'ai jamais vu de livre publié dans lequel il y avait des cadres
> noirs mis par l'éditeur (au sens "personne qui a édité le texte") avec
> marqué : "ce texte n'était pas convenable". Je pense que l'analogie est
> donc très limitée, surtout que la question là est de savoir quoi écrire
> dans le cadre.

Il me semble que tu cherches à rendre le processus de masquage/reconstruction
dans un mot français, mais est-ce nécessaire d'aller si loin, quand le mot 
"révision"
le reflète de manière synthétique, exactement comme le fait le mot anglais
"redaction".
L'analogue peut tout à fait être faite. Un passage retiré ou réécrit dans un 
livre peut 
être indiqué par un texte explicatif en italique, un mot dans la préface ou une 
note.
Par ailleurs, il est arrivé que le Canard enchaîné, quand il était soumis à la 
censure,
remplace le passage caviardé par une mention satirique.

> Pour préciser le contexte, il s'agit en particulier de traduire ce message :
> http://translatewiki.net/wiki/Osm:Browse.redacted.message_html/en
> 
> (et les messages attenants)
> 
> Que l'on trouvera par exemple sur la page:
> http://www.openstreetmap.org/browse/way/23216749/history
> 
> Je pensais à quelque chose du style "La version %{version} de ce(tte)
> %{type} ne peut pas être affichée car elle a été (cachée/censurée/???).
> Veuillez consulter %{redaction_link} pour plus d'informations."
> 
> La question est sur le mot entre parenthèses. :)


"été l'objet d'une révision" (pour migration de licence)
C'est plus approprié que "révisée", car on suggère ainsi que l'opération est 
plus complexe
qu'un simple époussetage.

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

[OSM-talk-fr] Opendata : préfecture de Paris

[Eric Pommereau]

D'abord désolé pour le sujet que j'ai oublié de mettre, d'autre part je
travaille bien à la DSI de la Préfecture de Police... ce qui n'était pas
forcément clair dans mon message précédent.

@++


> Message: 3
> Date: Thu, 26 Jul 2012 11:38:17 +0200
> From: Eric Pommereau 
> To: talk-fr@openstreetmap.org
> Subject: Re: [OSM-talk-fr] Lot Talk-fr, Vol 72, Parution 159
> Message-ID:
>  hjh...@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Bonjour,
>
> Juste une info il s'agit des données de la Préfecture de Police de Paris et
> non la Préfecture de Paris qui est une autre entité (aujourd'hui regroupée
> avec la Préfecture Ile de France...).
>
> Si vous avez besoin de plus d'infos sur le jeu de données je travaille à la
> direction informatique (mais je n'ai pas réalisé cet export...). Je peux
> aider à la documentation du wiki si c'est nécessaire.
>
> @ bientôt
>
> Eric
>
>
> > --
> >
> > Message: 2
> > Date: Thu, 26 Jul 2012 11:10:07 +0200
> > From: Romain MEHUT 
> > To: Discussions sur OSM en français 
> > Subject: Re: [OSM-talk-fr] Opendata : préfecture de Paris
> > Message-ID:
> >  > 89gejdmfoxm9b_uexc+dtknjvg3ch4fgsdf+2crtc...@mail.gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > Bonjour Axel,
> >
> > La Licence Ouverte est compatible pour une intégration des données dans
> > OSM.
> > Tu pourras le constater ici:
> > http://wiki.openstreetmap.org/wiki/WikiProject_France/data.gouv.fr
> > D'ailleurs, il faudrait documenter les données de la Préfecture de Police
> > qui n'y sont pas référencées.
> >
> > Aussi, ce serait bien que tu documentes ton projet d'import comme dans le
> > cas de Versailles:
> > http://wiki.openstreetmap.org/wiki/FR:Potential_Datasources/France
> >
> >
> http://wiki.openstreetmap.org/wiki/Open_Data_Versailles:_analyse_des_donn%C3%A9es
> >
> > Romain
> >
> >
> -- section suivante --
> Une pièce jointe HTML a été nettoyée...
> URL: <
> http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20120726/83377371/attachment-0001.html
> >
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Traduction de "redaction" en français

[Nicolas Dandrimont]

Le 26/07/2012 à 11:21, Hélène PETIT  écrivit :
> Le 26/07/2012 01:19, Nicolas Dandrimont a écrit :
> > Je pensais à quelque chose du style "La version %{version} de ce(tte)
> > %{type} ne peut pas être affichée car elle a été (cachée/censurée/???).
> > Veuillez consulter %{redaction_link} pour plus d'informations."
> > 
> > La question est sur le mot entre parenthèses. :)
> 
> "masqué" met plus l'accent sur le caractère intentionnel de la chose,
> et on peut aussi compacter la petite redondance de sens, par exemple
> comme ça :
> 
> "La version %{version} de ce(tte) %{type} est masquée, conformément au
> changement de licence consultable ici : %{redaction_link}."

Le mécanisme de masquage a été conçu de manière plus générique
qu'uniquement pour ce changement de licence, donc la contraction n'est
pas forcément adaptée. C'est d'ailleurs pour ça qu'il y a une page
d'information spécifique pour chaque passe.

Le terme "masquage" me semble tout à fait clair et adapté, j'approuve. \o/

Je m'occupe de revoir les traductions de ce pas.

Merci à tous,
-- 
Nicolas Dandrimont


pgpR7deFLHqrd.pgp
Description: PGP signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Quelques questions d'un débutant OSM

[Mathieu Rajerison]

Bonjour,


J'aurais quelques questions de débutant:

- On ne peut pas utiliser plusieurs fois le tag operator. Lorsqu'une
plate-forme de bus est affectée à plusieurs opérateurs, doit-on utiliser
des relations? Et comment?

- Aussi, comment indiquer qu'un bâtiment abrite à la fois des activités
commerciales et des logements?

- Lorsque des terrains de sport sont contenus dans un parc, peut-on les
numériser par-dessus? Dans quel cas la superposition d'objets surfaciques
est-elle autorisée?


Merci!

Mathieu, un débutant OSM
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] JOSM en touche "enter"

[Philippe Verdy]

Il me semble que tu avais annoncé hier que la version compilée 5366
(corrigeant une anomalie sur l'accès aux historiques des comptes
utilisateurs supprimés et dont le nom contient des caractères spéciaux
comme le signe "%" qui nécessite un URL-encodage) serait disponible
aujourd'hui dans le flux développeur (josm-latest).

Mais c'est encore la 5361 que je charge en JNLP (donc pas de mise à
jour détectée).

Y a-t-il eu un problème de dernière minute à la compilation ou pendant
les tests qui a fait reporter cette version ?

Le 26 juillet 2012 12:37, Vincent Privat  a écrit :
> Merci beaucoup Christian pour tes essais qui m'ont aiguillé sur le problème
> :)
> C'est normalement corrigé dans la latest de ce matin !

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

Re: [OSM-talk-fr] Changer des ways en areas ?

[Philippe Verdy]

Par défaut tous les chemins fermés (ways ou collections de ways
membres d'une même relation) sont interprétés comme des surfaces, sauf
si le type d'objet désigne une route/rue/sentier (highway=*) ou une
ligne de chemin de fer (railway=*), ou une ligne de transport en
général (type=route, que ce soit pour des bus, des taxis, des
sentiers), ou les lignes électriques.

Ce sont ces lignes de transports qui seules nécessitent area=yes si on
veut que ça désigne toute la surface délimitée par ce chemin (le plus
souvent on le trouve pour les places et secteurs piétonniers), et pas
seulement une zone tampon ("buffer") située de part et d'autre du
chemin (la largeur de ce chemin est souvent implicitement estimée mais
ignorée dans le rendu qui peut tracer la ligne avec une épaisseur plus
grande comparaitivement à l'échelle; l'estimation de largeur de la
zone tampon est dépendante du moteur de rendu, mais on peut l'etimer à
3 mètres de part et d'autre, ou tenir compte d'autres attributs comme
l'indication du nombre de voies de circulation, ou utiliser
l'indication de la largeur avec width=* qui est rarement employé car
souvent pas homogène sur la longueur du chemin dont on n'a tracé
qu'une ligne centrale souvent suffisante pour la plupart des rendus
aux échelles courantes).

En pratique malgré tout, même les rues ou routes ont une largeur qui
devrait pouvoir être cartographiée pour préciser la disposition des
voies, des trottoirs, bandes cyclables, voies bus, zones de
stationnement, ilots directionnels et positionner divers équipements
plus précisément. Et de fait presque tout devrait devenir des surfaces
à terme. Mais le travail de cartographie est plus long et plus
compliqué pour ces objets qui sont nettement plus longs que leur
largeur. On peut regretter toutefois que les moteurs de routage (pour
calculer un itinéraire) se débrouillent très mal avec les surfaces
(ils ne savent pas comment interconnecter correctement une surface
avec un chemin) et nécessitent de tracer malgré tout au moins une
ligne centrale en plus de cette surface et il n'y a pas encore de
modèle stable pour avoir les deux.

En principe on devrait pouvoir déduire automatiquement la géométrie de
cette ligne centrale virtuelle à partir de la géométrie de la surface
délimitée mais le calcul géométrique est un peu compliqué et trop
lourd pour nombre de petits appareils portables ou mobiles. La
solution serait de pouvoir préparer les données selon le dispositif
afin de leur faire satisfaire certaines contraintes, mais à l'heure
actuelle cela ne semble pas encore marcher avec les outils d'exports
et préparation de données. Donc en fin de compte on utilise des routes
tracées avec un seul trait, le moteur de rendu utilise une largeur un
peu arbitraire pour le rendu de l'épaisseur du tracé afin de ne pas
couvrir une surface trop grande ni trop petite relative à l'échelle de
rendu.

Mais si la capacité de calcul des appareils de navigation s'améliore
(par exemple avec un rendu 3D montrant les bâtiments autour, le
relief, et divers équipement ou même des façades de commerce et les
trottoirs et toutes les voies), la donnée de la seule ligne centrale
virtuelle pourra devenir insuffisante pour faire de la navigation avec
une indication précise des voies de circulation qui ne recouvrent pas
ce qui est à afficher autour.  Le modèle actuel est plutpot adapté à
un rendu sous forme de plan en projection vu de dessus et ne montrant
au mieux une précision décamétrique. Pour la précision métrique ou
décimétrique la modélisation (ou l'approximation par estimation des
largeurs de "buffer" prenant en compte d'autres attributs) des routes
par surfaces d'occupation pourrait devenir nécessaire.

On n'en est pas encore là mais le besoin se fait de plus en plus
sentir dans les zones urbaines denses avec une navigation compliquée,
où l'estimation des largeurs de "buffer" ne suffit plus à préciser
correctement les positions relatives des divers objets à représenter.

Pour le reste (hors des voies et lignes de transport), area=no ne
semble pour l'instant servir à rien de connu, et area=yes est alors
inutile puisque c'est l'interprétation par défaut (bâtiments, et même
les murs, frontières administratives ou physiques, parcs et jardins,
zones de culture, forêts, eaux). Il doit y avoir des exceptions par
endroit pour certains tags peu employés (par exemple les pipelines).
Et plutôt que d'avoir à maintenir une liste de plus en plus longue
d'exceptions (et pas facile à mettre à jour car l'information est
disséminée et on pourrait trouver des cas contradictoires) c'est vrai
que la séparation des types géométriques serait bienvenue pour lever
cette ambiguïté de façon plus propre.

En attendant c'est à ça que doit servir l'attribut area=yes/no, mais
cela ne facilite pas la validation automatique de la géométrie des
objets et on doit alors utiliser des outils externes de surveillance
de la qualité (par exemple Osmose) pour trouver ces ambiguïtés ou
possibles anomalies liées le plus souve

Re: [OSM-talk-fr] Traduction de "redaction" en français

[THEVENON Julien]

 De : Vincent Privat 




  Le 26 juillet 2012 11:21, Hélène PETIT  a écrit :


>   "La version %{version} de ce(tte) %{type} est masquée, conformément 
>  au 
changement de licence consultable ici : %{redaction_link}."
>
>
 J'aime bien cette formulation.



Pareil, ca a le merite d etre neutre.

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

Re: [OSM-talk-fr] Traduction de "redaction" en français

[Vincent Privat]

Le 26 juillet 2012 11:21, Hélène PETIT  a écrit :

>
> "La version %{version} de ce(tte) %{type} est masquée, conformément au
> changement de licence consultable ici : %{redaction_link}."
>
>
J'aime bien cette formulation.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] JOSM en touche "enter"

[Vincent Privat]

Merci beaucoup Christian pour tes essais qui m'ont aiguillé sur le problème
:)
C'est normalement corrigé dans la latest de ce matin !
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Lot Talk-fr, Vol 72, Parution 159

[Eric Pommereau]

Bonjour,

Juste une info il s'agit des données de la Préfecture de Police de Paris et
non la Préfecture de Paris qui est une autre entité (aujourd'hui regroupée
avec la Préfecture Ile de France...).

Si vous avez besoin de plus d'infos sur le jeu de données je travaille à la
direction informatique (mais je n'ai pas réalisé cet export...). Je peux
aider à la documentation du wiki si c'est nécessaire.

@ bientôt

Eric


> --
>
> Message: 2
> Date: Thu, 26 Jul 2012 11:10:07 +0200
> From: Romain MEHUT 
> To: Discussions sur OSM en français 
> Subject: Re: [OSM-talk-fr] Opendata : préfecture de Paris
> Message-ID:
>  89gejdmfoxm9b_uexc+dtknjvg3ch4fgsdf+2crtc...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Bonjour Axel,
>
> La Licence Ouverte est compatible pour une intégration des données dans
> OSM.
> Tu pourras le constater ici:
> http://wiki.openstreetmap.org/wiki/WikiProject_France/data.gouv.fr
> D'ailleurs, il faudrait documenter les données de la Préfecture de Police
> qui n'y sont pas référencées.
>
> Aussi, ce serait bien que tu documentes ton projet d'import comme dans le
> cas de Versailles:
> http://wiki.openstreetmap.org/wiki/FR:Potential_Datasources/France
>
> http://wiki.openstreetmap.org/wiki/Open_Data_Versailles:_analyse_des_donn%C3%A9es
>
> Romain
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Traduction de "redaction" en français

[Hélène PETIT]

Le 26/07/2012 01:19, Nicolas Dandrimont a écrit :

Je pensais à quelque chose du style "La version %{version} de ce(tte)
%{type} ne peut pas être affichée car elle a été (cachée/censurée/???).
Veuillez consulter %{redaction_link} pour plus d'informations."

La question est sur le mot entre parenthèses. :)


"masqué" met plus l'accent sur le caractère intentionnel de la chose, et 
on peut aussi compacter la petite redondance de sens, par exemple comme 
ça :


"La version %{version} de ce(tte) %{type} est masquée, conformément au 
changement de licence consultable ici : %{redaction_link}."



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

Re: [OSM-talk-fr] Nouveautés Open Data

[Romain MEHUT]

Bonjour Christian,

As-tu prévu de faire remonter l'info du constat que tu as fait? Et est-ce
qu'on ne pourrait pas extraire d'OSM un fichier équivalent de meilleure
qualité?

Romain

Le 25 juillet 2012 16:48, Christian Quest  a écrit
:

> Le 13 juillet 2012 09:50, Romain MEHUT  a écrit :
> > Bonjour,
> >
> > Les nouveaux venus:
> >
> > Saint-Maur-des-Fossés (clin d’œil à Christian)
>
> Bon... comment dire...
>
> Un fichier KML, mal fichu qui contient les descriptifs en texte HTML
> Des données pas bien fraiches (le trésor public a déménagé il y a
> plusieurs mois, mais toujours placé à l'ancienne adresse)
> Des localisations très approximatives... ça sent le géocodage rapide à
> plein nez
>
> Bref, presque rien à en tirer.
>
> Ce genre de fichier peut être éventuellement utile pour comparer
> simplement la présence ou l'absence dans OSM d'un objet (et encore, il
> faudrait qu'il soit à jour), mais il n'y a rien d'importable en
> l'état.
>
> #opendatafail
>
> --
> 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

Re: [OSM-talk-fr] Changer des ways en areas ?

[Ab_fab]

Ah, sauf si c'est implicite avec le tag amenity=school comme le dit Vincent

Le 26 juillet 2012 11:11, Ab_fab  a écrit :

> Si si, il fallait bien !
>
> Le 26 juillet 2012 10:53, Francescu GAROBY  a écrit :
>
> OK, merci pour vos explications.
>> Et oui, c'est moi qui ai ajouté le tag "area". Fallait pas ?
>>
>> Francescu
>>
>> Le 26 juillet 2012 10:47, Ab_fab  a écrit :
>>
>> Le type d'objet "area" n'existe pas dans OSM. Certains souhaitent
>>> l'introduire si l'API évolue.
>>> Les surfaces sont actuellement des ways, ou des assemblages de ways, qui
>>> incluent des tags supplémentaires tels que "area = yes", quand cela n'est
>>> pas déjà sous-entendu par le tag principal comme "building = yes", pour
>>> indiquer qu'il s'agit de surfaces
>>>
>>> A ce propos, est-ce toi qui a ajouté le "area = yes" dans la dernière
>>> révision de l'objet le 24/07 ?
>>>
>>> Le 26 juillet 2012 07:53, Francescu GAROBY  a écrit
>>> :
>>>
 Bonjour,
 En tagguant les établissement scolaires de ma commune, j'ai eu la
 surprise de m'apercevoir que certains bâtiments, déjà identifiés depuis
 plusieurs mois, avaient été représentés non pas par une area mais par un
 way ! Ex : http://www.openstreetmap.org/browse/way/149706281/history

 Mes questions sont donc les suivantes :
 * sachant que la page du wiki portant sur le tag 
 "amenity=school"indique
  bien que cela ne peut se faire que sur un node ou une area, est-il
 possible de transformer ces ways en areas, sans avoir à tout retracer ?
 * ne faudrait-il pas que ce genre de vérifications, somme toute assez
 faciles, soient effectuées au moment de la validation des modifications ?
 Soit en renvoyant un message d'erreur et en refusant l'update des données,
 soit (mais je suis moins emballé) en remplaçant automatiquement le way par
 un area ?

 --
 Cordialement,
 Francescu GAROBY


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


>>>
>>>
>>> --
>>> ab_fab 
>>> "Il n'y a pas de pas perdus"
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>>
>> --
>> Cordialement,
>> Francescu GAROBY
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> ab_fab 
> "Il n'y a pas de pas perdus"
>



-- 
ab_fab 
"Il n'y a pas de pas perdus"
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Changer des ways en areas ?

[Ab_fab]

Si si, il fallait bien !

Le 26 juillet 2012 10:53, Francescu GAROBY  a écrit :

> OK, merci pour vos explications.
> Et oui, c'est moi qui ai ajouté le tag "area". Fallait pas ?
>
> Francescu
>
> Le 26 juillet 2012 10:47, Ab_fab  a écrit :
>
> Le type d'objet "area" n'existe pas dans OSM. Certains souhaitent
>> l'introduire si l'API évolue.
>> Les surfaces sont actuellement des ways, ou des assemblages de ways, qui
>> incluent des tags supplémentaires tels que "area = yes", quand cela n'est
>> pas déjà sous-entendu par le tag principal comme "building = yes", pour
>> indiquer qu'il s'agit de surfaces
>>
>> A ce propos, est-ce toi qui a ajouté le "area = yes" dans la dernière
>> révision de l'objet le 24/07 ?
>>
>> Le 26 juillet 2012 07:53, Francescu GAROBY  a écrit :
>>
>>> Bonjour,
>>> En tagguant les établissement scolaires de ma commune, j'ai eu la
>>> surprise de m'apercevoir que certains bâtiments, déjà identifiés depuis
>>> plusieurs mois, avaient été représentés non pas par une area mais par un
>>> way ! Ex : http://www.openstreetmap.org/browse/way/149706281/history
>>>
>>> Mes questions sont donc les suivantes :
>>> * sachant que la page du wiki portant sur le tag 
>>> "amenity=school"indique
>>>  bien que cela ne peut se faire que sur un node ou une area, est-il
>>> possible de transformer ces ways en areas, sans avoir à tout retracer ?
>>> * ne faudrait-il pas que ce genre de vérifications, somme toute assez
>>> faciles, soient effectuées au moment de la validation des modifications ?
>>> Soit en renvoyant un message d'erreur et en refusant l'update des données,
>>> soit (mais je suis moins emballé) en remplaçant automatiquement le way par
>>> un area ?
>>>
>>> --
>>> Cordialement,
>>> Francescu GAROBY
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>>
>> --
>> ab_fab 
>> "Il n'y a pas de pas perdus"
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Cordialement,
> Francescu GAROBY
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
ab_fab 
"Il n'y a pas de pas perdus"
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Opendata : préfecture de Paris

[Romain MEHUT]

Bonjour Axel,

La Licence Ouverte est compatible pour une intégration des données dans OSM.
Tu pourras le constater ici:
http://wiki.openstreetmap.org/wiki/WikiProject_France/data.gouv.fr
D'ailleurs, il faudrait documenter les données de la Préfecture de Police
qui n'y sont pas référencées.

Aussi, ce serait bien que tu documentes ton projet d'import comme dans le
cas de Versailles:
http://wiki.openstreetmap.org/wiki/FR:Potential_Datasources/France
http://wiki.openstreetmap.org/wiki/Open_Data_Versailles:_analyse_des_donn%C3%A9es

Romain

Le 25 juillet 2012 15:43, Axel Simon  a écrit :

> Bonjour tout le monde,
>
> Déjà, désolé si ce sujet a déjà été abordé. ;)
>
> Je viens de voir que la Préfecture de Paris a publié des données sur le
> portail
> data.gouv.fr :
>
> http://www.data.gouv.fr/content/search?SearchText=Pr%C3%A9fecture%20de%20police%20de%20Paris
>
> Entre autres éléments intéressants, la position des fourrières, des
> casernes et
> des 200 caméras de vidéo « protection » déjà en place (sur… 1105 prévues).
>
> Quelques questions :
>
> - La Licence Ouverte/Open Licence
> (http://www.data.gouv.fr/Licence-Ouverte-Open-Licence) est-elle
> compatible avec
> l'ODbL ? À sa lecture, je dirais que oui, d'autant qu'elle est compatible
> avec
> la CC-BY 2.0 de Creative Commons et la« Open Data Commons Attribution »
> (ODC-BY)
> d'après le texte de la licence.
>
> - Quelqu'un a-t-il déjà de l'expérience dans l'import de ce genre de
> données ?
>
> - Ces données en question ont-elles déjà été importées d'ailleurs ?
>
> Bref, désolé si je débarque, je regarde comment importer les shapefiles
> (shp)
> là, je vous tiens au courant de l'avancement des choses de toute façon :)
>
> axel
>
> --
> Axel Simon
>
> --
> mail/jabber/gtalk: axelsi...@axelsimon.net
> mobile: +33 (0)6 08 04 01 44
> twitter / identi.ca: @AxelSimon
>
> ___
> 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] Changer des ways en areas ?

[Vincent de Chateau-Thierry]

Le 26/07/2012 10:47, Ab_fab a écrit :

Le type d'objet "area" n'existe pas dans OSM. Certains souhaitent
l'introduire si l'API évolue.
Les surfaces sont actuellement des ways, ou des assemblages de ways, qui
incluent des tags supplémentaires tels que "area = yes", quand cela
n'est pas déjà sous-entendu par le tag principal comme "building = yes",
pour indiquer qu'il s'agit de surfaces



Il faut cependant que le way, ou la  suite de ways, forme(nt) une 
boucle, mis bout à bout. Dans le cas cité en exemple (l'école), le 
premier et le dernier point sont identiques :

http://www.openstreetmap.org/browse/node/1626540873 ,
par suite, l'association avec le tag amenity=school fabrique de fait une 
surface.


vincent

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

Re: [OSM-talk-fr] Changer des ways en areas ?

[Francescu GAROBY]

OK, merci pour vos explications.
Et oui, c'est moi qui ai ajouté le tag "area". Fallait pas ?

Francescu

Le 26 juillet 2012 10:47, Ab_fab  a écrit :

> Le type d'objet "area" n'existe pas dans OSM. Certains souhaitent
> l'introduire si l'API évolue.
> Les surfaces sont actuellement des ways, ou des assemblages de ways, qui
> incluent des tags supplémentaires tels que "area = yes", quand cela n'est
> pas déjà sous-entendu par le tag principal comme "building = yes", pour
> indiquer qu'il s'agit de surfaces
>
> A ce propos, est-ce toi qui a ajouté le "area = yes" dans la dernière
> révision de l'objet le 24/07 ?
>
> Le 26 juillet 2012 07:53, Francescu GAROBY  a écrit :
>
>> Bonjour,
>> En tagguant les établissement scolaires de ma commune, j'ai eu la
>> surprise de m'apercevoir que certains bâtiments, déjà identifiés depuis
>> plusieurs mois, avaient été représentés non pas par une area mais par un
>> way ! Ex : http://www.openstreetmap.org/browse/way/149706281/history
>>
>> Mes questions sont donc les suivantes :
>> * sachant que la page du wiki portant sur le tag 
>> "amenity=school"indique
>>  bien que cela ne peut se faire que sur un node ou une area, est-il
>> possible de transformer ces ways en areas, sans avoir à tout retracer ?
>> * ne faudrait-il pas que ce genre de vérifications, somme toute assez
>> faciles, soient effectuées au moment de la validation des modifications ?
>> Soit en renvoyant un message d'erreur et en refusant l'update des données,
>> soit (mais je suis moins emballé) en remplaçant automatiquement le way par
>> un area ?
>>
>> --
>> Cordialement,
>> Francescu GAROBY
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> ab_fab 
> "Il n'y a pas de pas perdus"
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] Changer des ways en areas ?

[Ab_fab]

Le type d'objet "area" n'existe pas dans OSM. Certains souhaitent
l'introduire si l'API évolue.
Les surfaces sont actuellement des ways, ou des assemblages de ways, qui
incluent des tags supplémentaires tels que "area = yes", quand cela n'est
pas déjà sous-entendu par le tag principal comme "building = yes", pour
indiquer qu'il s'agit de surfaces

A ce propos, est-ce toi qui a ajouté le "area = yes" dans la dernière
révision de l'objet le 24/07 ?

Le 26 juillet 2012 07:53, Francescu GAROBY  a écrit :

> Bonjour,
> En tagguant les établissement scolaires de ma commune, j'ai eu la surprise
> de m'apercevoir que certains bâtiments, déjà identifiés depuis plusieurs
> mois, avaient été représentés non pas par une area mais par un way ! Ex :
> http://www.openstreetmap.org/browse/way/149706281/history
>
> Mes questions sont donc les suivantes :
> * sachant que la page du wiki portant sur le tag 
> "amenity=school"indique
>  bien que cela ne peut se faire que sur un node ou une area, est-il
> possible de transformer ces ways en areas, sans avoir à tout retracer ?
> * ne faudrait-il pas que ce genre de vérifications, somme toute assez
> faciles, soient effectuées au moment de la validation des modifications ?
> Soit en renvoyant un message d'erreur et en refusant l'update des données,
> soit (mais je suis moins emballé) en remplaçant automatiquement le way par
> un area ?
>
> --
> Cordialement,
> Francescu GAROBY
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
ab_fab 
"Il n'y a pas de pas perdus"
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OSMTransport change de peau

[rldhont]

Pour l'ordre des numéros c'était une régression, c'est corrigé. 
D'ailleurs tous les réseaux n'utilisent pas que des chiffres pour 
identifier les lignes.


René-Luc


Le 26/07/2012 10:36, Francescu GAROBY a écrit :

Merci tout d'abord pour la réponse rapide :-)

Autre point "génant" : le tri des lignes de bus/tram se fait selon un 
ordre alphanumérique (1 puis 19 puis 2) et non numérique (1 puis 2 
puis 19).

Pour Caen, je regarde ce qu'il en est pour les tags des lignes existantes.

Francescu

Le 26 juillet 2012 10:31, rldhont > a écrit :


Bonjour Francescu,

Pour la mise à jour, c'est un gros chantier qui ne peut prendre
trop de temps sur mon travail ou mon temps libre. Donc pour le
moment je lance de temps en temps des rafraîchissements. Mais il
faut aussi que je travail sur le système de cache qui est trop long.

Pour la référence, j'utilise le tag ref, et pour le nom j'utilise
le tag name. Sur Caen, il y a peut-être un problème de fraîcheur
des données.

Pour les Numéros au sein de la popup des arrêts, c'est une bonne
idée. Je n'ai aps fait de test sur des données possédant où les
arrêts ont de nombreuses connections.

Enfin pour les pictogramme, j'y avais pensé. Je pensais même à une
sorte d'image qui se construirait en fonction des informations
présentes. Par contre pour les arrêts de bus j'ai découvert qu'il
y avait les tags shelter et covered !

René-Luc


Le 26/07/2012 10:22, Francescu GAROBY a écrit :

Bonjour,
Bravo pour cette refonte, très jolie graphiquement !

Quelques questions/propositions d'amélioration, cependant :
* quelle est la fréquence de rafraîchissement des données ? Je
travaille actuellement sur les lignes de transport de Caen, et je
ne vois pas tous mes travaux ;
* sur quel(s) tag(s) vous basez-vous pour le nom des lignes ? Car
les trams de Caen n'ont pas de nom indiqué ("undefined"), alors
qu'ils existent dans OSM ;
* les numéros des lignes passant par un arrêt de bus/tram ne sont
pas classés par ordre croissant, ce qui rendrait la lecture plus
aisée ;
* dans un souci de compréhension, il faudrait remplacer "shelter"
et "bench" par un pictogramme ;

Merci d'avance,
Francescu

Le 26 juillet 2012 10:05, rldhont mailto:rldh...@gmail.com>> a écrit :

Bonjour,

Nous, 3Liz, profitons de l'été pour mettre à jour les
interfaces de nos démonstrateurs. Après LizMap, solution de
web mapping basé sur QGIS Server, c'est au tour d'OSMTransport :
http://demo.3liz.com/osmtransport

Ce changement d'interface est aussi l'occasion de faire
évoluer les fonctionnalités :
* dans les fonds de carte vous trouverez le fond MapQuest par
défaut, le fond OpenStreetMap, et le fond Bing Aerial. Nous
avons pensé que pouvoir visualiser les données TC au dessus
du fond utilisé pour la digitalisation pouvait être quelque
chose d'intéressant
* réorganisation de l'arbre des données TC
* Affichage par défaut d'un maximum de 100 objets
géographiques représentant des lignes
* Ajout d'informations dans les popups des données. Par
exemple les tags shelter, bench pour les arrêts.

Voici quelque liens directs :
* Montpellier
http://demo.3liz.com/osmtransport/index.php?country=1&location=2
* Orange
http://demo.3liz.com/osmtransport/index.php?country=1&location=84
* Marseille
http://demo.3liz.com/osmtransport/index.php?country=1&location=11
* Nantes
http://demo.3liz.com/osmtransport/index.php?country=1&location=4

Si il y a des tags que vous souhaitez que nous ajoutiez
faîtes le moi savoir.

René-Luc

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




-- 
Cordialement,

Francescu GAROBY



___
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




--
Cordialement,
Francescu GAROBY



___
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] Changer des ways en areas ?

[THEVENON Julien]

 De : Francescu GAROBY 


 Bonjour,
 En tagguant les établissement scolaires de ma commune, j'ai eu la surprise 
 de m'apercevoir que certains bâtiments, déjà identifiés depuis 
plusieurs mois, avaient été
 représentés non pas par une area mais par un way ! Ex : 
 http://www.openstreetmap.org/browse/way/149706281/history

 Mes questions sont donc les suivantes :
 * sachant que la page du wiki portant sur le tag "amenity=school" indique 
 bien que cela ne peut se faire que sur un node ou une area, 
est-il possible de transformer ces ways en areas, sans avoir à tout 
retracer ?
 * ne faudrait-il pas que ce genre de vérifications, somme toute assez 
faciles, soient effectuées au moment de la validation des modifications ? Soit 
en renvoyant un message d'erreur et en refusant l'update des 
données, soit (mais je suis moins emballé) en remplaçant automatiquement le way 
par un area ?



Salut,

Dans ce cas area signifie way fermé, pas way avec le tag area=yes

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

Re: [OSM-talk-fr] Traduction de "redaction" en français

[Sébastien Pierrel]

Épurer, épuration?
L'automate a tourné pour obtenir une base de données odbl pure.

2012/7/25 Nicolas Dandrimont 

> Salut,
>
> J'ai fait quelques éditions d'objets qui ont été modifiés par le
> Redaction Bot (qui a d'ailleurs terminé son travail il y a quelques
> heures), et les messages traduits en français sur le site web n'ont
> aucun sens (avec du "t'el que rédigé" (sic) et consorts).
>
> Je me suis donc inscrit sur translate wiki, ai demandé les droits de
> traduction (que j'ai obtenus), je compte donc reprendre la traduction de
> ces messages.
>
> Voici la question : y a-t-il consensus sur la traduction de "redaction",
> "redacted", "to redact" en français ? Je n'ai vu aucune occurence
> traduite sur le wiki ni sur cette liste de diffusion.
>
> Je pensais à "censure", qui a une connotation plutôt négative, même si
> c'est une traduction littérale du terme anglais. Après avoir posé la
> question sur IRC, Jocelyn a suggéré "purge" qui me plait pas mal et est
> plus neutre. Je demande d'autres avis via ce mail avant de me lancer.
>
> Merci,
> --
> Nicolas Dandrimont
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] OSMTransport change de peau

[rldhont]

Bonjour Tetsuo,

Les ajouts se font par mes soins maintenant.
Si vous souhaitez des ajouts j'ai besoin :
* d'un nom
* du pays
* de l'emprise pour pouvoir sélectionner les données, le mieux étant de 
se restreindre (pour l'emprise) au coeur du réseau.


Cordialement,
René-Luc

Le 26/07/2012 10:32, Tetsuo Shima a écrit :

Boujours

Même chose, comment sont sélectionnés les villes qui apparaissent sur
la carte des transports? Il y a pas mal de réseaux qui n'y
apparaissent pas alors qu'ils sont dans OSM depuis plusieurs mois.

Cordialement.

___
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] OSMTransport change de peau

[Francescu GAROBY]

Merci tout d'abord pour la réponse rapide :-)

Autre point "génant" : le tri des lignes de bus/tram se fait selon un ordre
alphanumérique (1 puis 19 puis 2) et non numérique (1 puis 2 puis 19).
Pour Caen, je regarde ce qu'il en est pour les tags des lignes existantes.

Francescu

Le 26 juillet 2012 10:31, rldhont  a écrit :

>  Bonjour Francescu,
>
> Pour la mise à jour, c'est un gros chantier qui ne peut prendre trop de
> temps sur mon travail ou mon temps libre. Donc pour le moment je lance de
> temps en temps des rafraîchissements. Mais il faut aussi que je travail sur
> le système de cache qui est trop long.
>
> Pour la référence, j'utilise le tag ref, et pour le nom j'utilise le tag
> name. Sur Caen, il y a peut-être un problème de fraîcheur des données.
>
> Pour les Numéros au sein de la popup des arrêts, c'est une bonne idée. Je
> n'ai aps fait de test sur des données possédant où les arrêts ont de
> nombreuses connections.
>
> Enfin pour les pictogramme, j'y avais pensé. Je pensais même à une sorte
> d'image qui se construirait en fonction des informations présentes. Par
> contre pour les arrêts de bus j'ai découvert qu'il y avait les tags shelter
> et covered !
>
> René-Luc
>
>
> Le 26/07/2012 10:22, Francescu GAROBY a écrit :
>
> Bonjour,
> Bravo pour cette refonte, très jolie graphiquement !
>
> Quelques questions/propositions d'amélioration, cependant :
> * quelle est la fréquence de rafraîchissement des données ? Je travaille
> actuellement sur les lignes de transport de Caen, et je ne vois pas tous
> mes travaux ;
> * sur quel(s) tag(s) vous basez-vous pour le nom des lignes ? Car les
> trams de Caen n'ont pas de nom indiqué ("undefined"), alors qu'ils existent
> dans OSM ;
> * les numéros des lignes passant par un arrêt de bus/tram ne sont pas
> classés par ordre croissant, ce qui rendrait la lecture plus aisée ;
> * dans un souci de compréhension, il faudrait remplacer "shelter" et
> "bench" par un pictogramme ;
>
> Merci d'avance,
> Francescu
>
> Le 26 juillet 2012 10:05, rldhont  a écrit :
>
>> Bonjour,
>>
>> Nous, 3Liz, profitons de l'été pour mettre à jour les interfaces de nos
>> démonstrateurs. Après LizMap, solution de web mapping basé sur QGIS Server,
>> c'est au tour d'OSMTransport :
>> http://demo.3liz.com/osmtransport
>>
>> Ce changement d'interface est aussi l'occasion de faire évoluer les
>> fonctionnalités :
>> * dans les fonds de carte vous trouverez le fond MapQuest par défaut, le
>> fond OpenStreetMap, et le fond Bing Aerial. Nous avons pensé que pouvoir
>> visualiser les données TC au dessus du fond utilisé pour la digitalisation
>> pouvait être quelque chose d'intéressant
>> * réorganisation de l'arbre des données TC
>> * Affichage par défaut d'un maximum de 100 objets géographiques
>> représentant des lignes
>> * Ajout d'informations dans les popups des données. Par exemple les tags
>> shelter, bench pour les arrêts.
>>
>> Voici quelque liens directs :
>> * Montpellier
>> http://demo.3liz.com/osmtransport/index.php?country=1&location=2
>> * Orange
>> http://demo.3liz.com/osmtransport/index.php?country=1&location=84
>> * Marseille
>> http://demo.3liz.com/osmtransport/index.php?country=1&location=11
>> * Nantes http://demo.3liz.com/osmtransport/index.php?country=1&location=4
>>
>> Si il y a des tags que vous souhaitez que nous ajoutiez faîtes le moi
>> savoir.
>>
>> René-Luc
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
> Cordialement,
> Francescu GAROBY
>
>
>
> ___
> 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,
Francescu GAROBY
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Changer des ways en areas ?

[Francescu GAROBY]

Bonjour,
En tagguant les établissement scolaires de ma commune, j'ai eu la surprise
de m'apercevoir que certains bâtiments, déjà identifiés depuis plusieurs
mois, avaient été représentés non pas par une area mais par un way ! Ex :
http://www.openstreetmap.org/browse/way/149706281/history

Mes questions sont donc les suivantes :
* sachant que la page du wiki portant sur le tag
"amenity=school"indique
bien que cela ne peut se faire que sur un node ou une area, est-il
possible de transformer ces ways en areas, sans avoir à tout retracer ?
* ne faudrait-il pas que ce genre de vérifications, somme toute assez
faciles, soient effectuées au moment de la validation des modifications ?
Soit en renvoyant un message d'erreur et en refusant l'update des données,
soit (mais je suis moins emballé) en remplaçant automatiquement le way par
un area ?

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

Re: [OSM-talk-fr] OSMTransport change de peau

[Tetsuo Shima]

Boujours

Même chose, comment sont sélectionnés les villes qui apparaissent sur
la carte des transports? Il y a pas mal de réseaux qui n'y
apparaissent pas alors qu'ils sont dans OSM depuis plusieurs mois.

Cordialement.

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

Re: [OSM-talk-fr] OSMTransport change de peau

[rldhont]

Bonjour Francescu,

Pour la mise à jour, c'est un gros chantier qui ne peut prendre trop de 
temps sur mon travail ou mon temps libre. Donc pour le moment je lance 
de temps en temps des rafraîchissements. Mais il faut aussi que je 
travail sur le système de cache qui est trop long.


Pour la référence, j'utilise le tag ref, et pour le nom j'utilise le tag 
name. Sur Caen, il y a peut-être un problème de fraîcheur des données.


Pour les Numéros au sein de la popup des arrêts, c'est une bonne idée. 
Je n'ai aps fait de test sur des données possédant où les arrêts ont de 
nombreuses connections.


Enfin pour les pictogramme, j'y avais pensé. Je pensais même à une sorte 
d'image qui se construirait en fonction des informations présentes. Par 
contre pour les arrêts de bus j'ai découvert qu'il y avait les tags 
shelter et covered !


René-Luc


Le 26/07/2012 10:22, Francescu GAROBY a écrit :

Bonjour,
Bravo pour cette refonte, très jolie graphiquement !

Quelques questions/propositions d'amélioration, cependant :
* quelle est la fréquence de rafraîchissement des données ? Je 
travaille actuellement sur les lignes de transport de Caen, et je ne 
vois pas tous mes travaux ;
* sur quel(s) tag(s) vous basez-vous pour le nom des lignes ? Car les 
trams de Caen n'ont pas de nom indiqué ("undefined"), alors qu'ils 
existent dans OSM ;
* les numéros des lignes passant par un arrêt de bus/tram ne sont pas 
classés par ordre croissant, ce qui rendrait la lecture plus aisée ;
* dans un souci de compréhension, il faudrait remplacer "shelter" et 
"bench" par un pictogramme ;


Merci d'avance,
Francescu

Le 26 juillet 2012 10:05, rldhont > a écrit :


Bonjour,

Nous, 3Liz, profitons de l'été pour mettre à jour les interfaces
de nos démonstrateurs. Après LizMap, solution de web mapping basé
sur QGIS Server, c'est au tour d'OSMTransport :
http://demo.3liz.com/osmtransport

Ce changement d'interface est aussi l'occasion de faire évoluer
les fonctionnalités :
* dans les fonds de carte vous trouverez le fond MapQuest par
défaut, le fond OpenStreetMap, et le fond Bing Aerial. Nous avons
pensé que pouvoir visualiser les données TC au dessus du fond
utilisé pour la digitalisation pouvait être quelque chose
d'intéressant
* réorganisation de l'arbre des données TC
* Affichage par défaut d'un maximum de 100 objets géographiques
représentant des lignes
* Ajout d'informations dans les popups des données. Par exemple
les tags shelter, bench pour les arrêts.

Voici quelque liens directs :
* Montpellier
http://demo.3liz.com/osmtransport/index.php?country=1&location=2
* Orange
http://demo.3liz.com/osmtransport/index.php?country=1&location=84
* Marseille
http://demo.3liz.com/osmtransport/index.php?country=1&location=11
* Nantes
http://demo.3liz.com/osmtransport/index.php?country=1&location=4

Si il y a des tags que vous souhaitez que nous ajoutiez faîtes le
moi savoir.

René-Luc

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




--
Cordialement,
Francescu GAROBY



___
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] OSMTransport change de peau

[Francescu GAROBY]

Bonjour,
Bravo pour cette refonte, très jolie graphiquement !

Quelques questions/propositions d'amélioration, cependant :
* quelle est la fréquence de rafraîchissement des données ? Je travaille
actuellement sur les lignes de transport de Caen, et je ne vois pas tous
mes travaux ;
* sur quel(s) tag(s) vous basez-vous pour le nom des lignes ? Car les trams
de Caen n'ont pas de nom indiqué ("undefined"), alors qu'ils existent dans
OSM ;
* les numéros des lignes passant par un arrêt de bus/tram ne sont pas
classés par ordre croissant, ce qui rendrait la lecture plus aisée ;
* dans un souci de compréhension, il faudrait remplacer "shelter" et
"bench" par un pictogramme ;

Merci d'avance,
Francescu

Le 26 juillet 2012 10:05, rldhont  a écrit :

> Bonjour,
>
> Nous, 3Liz, profitons de l'été pour mettre à jour les interfaces de nos
> démonstrateurs. Après LizMap, solution de web mapping basé sur QGIS Server,
> c'est au tour d'OSMTransport :
> http://demo.3liz.com/**osmtransport 
>
> Ce changement d'interface est aussi l'occasion de faire évoluer les
> fonctionnalités :
> * dans les fonds de carte vous trouverez le fond MapQuest par défaut, le
> fond OpenStreetMap, et le fond Bing Aerial. Nous avons pensé que pouvoir
> visualiser les données TC au dessus du fond utilisé pour la digitalisation
> pouvait être quelque chose d'intéressant
> * réorganisation de l'arbre des données TC
> * Affichage par défaut d'un maximum de 100 objets géographiques
> représentant des lignes
> * Ajout d'informations dans les popups des données. Par exemple les tags
> shelter, bench pour les arrêts.
>
> Voici quelque liens directs :
> * Montpellier http://demo.3liz.com/**osmtransport/index.php?**
> country=1&location=2
> * Orange http://demo.3liz.com/**osmtransport/index.php?**
> country=1&location=84
> * Marseille http://demo.3liz.com/**osmtransport/index.php?**
> country=1&location=11
> * Nantes http://demo.3liz.com/**osmtransport/index.php?**
> country=1&location=4
>
> Si il y a des tags que vous souhaitez que nous ajoutiez faîtes le moi
> savoir.
>
> René-Luc
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>



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

[OSM-talk-fr] OSMTransport change de peau

[rldhont]

Bonjour,

Nous, 3Liz, profitons de l'été pour mettre à jour les interfaces de nos 
démonstrateurs. Après LizMap, solution de web mapping basé sur QGIS 
Server, c'est au tour d'OSMTransport :

http://demo.3liz.com/osmtransport

Ce changement d'interface est aussi l'occasion de faire évoluer les 
fonctionnalités :
* dans les fonds de carte vous trouverez le fond MapQuest par défaut, le 
fond OpenStreetMap, et le fond Bing Aerial. Nous avons pensé que pouvoir 
visualiser les données TC au dessus du fond utilisé pour la 
digitalisation pouvait être quelque chose d'intéressant

* réorganisation de l'arbre des données TC
* Affichage par défaut d'un maximum de 100 objets géographiques 
représentant des lignes
* Ajout d'informations dans les popups des données. Par exemple les tags 
shelter, bench pour les arrêts.


Voici quelque liens directs :
* Montpellier 
http://demo.3liz.com/osmtransport/index.php?country=1&location=2

* Orange http://demo.3liz.com/osmtransport/index.php?country=1&location=84
* Marseille 
http://demo.3liz.com/osmtransport/index.php?country=1&location=11

* Nantes http://demo.3liz.com/osmtransport/index.php?country=1&location=4

Si il y a des tags que vous souhaitez que nous ajoutiez faîtes le moi 
savoir.


René-Luc

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

Re: [OSM-talk-fr] Traduction de "redaction" en français

[Vincent de Chateau-Thierry]

Bonjour,

Le 26/07/2012 01:19, Nicolas Dandrimont a écrit :


Je pensais à quelque chose du style "La version %{version} de ce(tte)
%{type} ne peut pas être affichée car elle a été (cachée/censurée/???).
Veuillez consulter %{redaction_link} pour plus d'informations."

La question est sur le mot entre parenthèses. :)



[...] ne peut pas être affichée car elle a été *caviardée* ?

vincent

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

Re: [OSM-talk-fr] Traduction de "redaction" en français

[Hélène PETIT]

Le 26/07/2012 00:13, Christian Quest a écrit :

"Bot de migration", je crois bien que c'est Francisco Dos Santos qui
l'a utilisé le premier.


Bot ?
"Automate" me convient mieux ; car un "robot" dispose d'une certaine 
autonomie ; un automate qui fonctionne en boucle ouverte n'est pas trop 
robotique ...




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