Re: [OSM-talk-fr] Osmose "Missing object kind" sur Piste de ski

[Philippe Verdy]

Le 18 octobre 2014 22:43, Jérôme Seigneuret  a
écrit :

> @Matthias Dietrich je vais juste reprendre point par point
>
> *Après vérification du wiki, il faudrait en effet que information=* soit
> accompagné de tourism=information. *
>
> En effet c'est précisé ici
> http://wiki.openstreetmap.org/wiki/FR:Key:information
>
> PS: quand dans la boite à droite c'est écrit G*roupe : ** c'est que le
> groupe est le tag principal il me semble
>
> *En revanche mountain_pass=yes ne nécessite rien d'autre. Pour golf=* le
> wiki ne dit pas qu'il doit être ajouté à sport=golf par exemple. *
>
> Ça c'est pas vrai!
>
> Premièrement, Pour *mountain_pass *c'est considéré comme attribut d'un
> highway donc il manque aussi un tag! La doc anglaise dit
> :
> *Applies to the "highest node" on a highway =
> motorway/secondary/footway/... (could be any appropriate "highway"):*
> Donc highway=* est indispensable
>

Non; justement ! "highway=*" ira sur le chemin (way), et mountain_pass ira
sur un seul neud (node) traversé par ce chemin. Donc pas en même temps sur
le même objet. Et c'est clair en anglais à condition de ne pas oublier de
lire le mot "node".

Ce noeud isolé, marqué par mountain_pass, ne peut pas être marqué avec
highway=primary/secondary/tertiary/unclassified/track/path. Cependant le
chemin devrait passer par ce noeud (pas toujours le cas en cas de chaussées
séparées: un seul noeud est placé entre les deux chaussées

(cas identique aux passages piétons, passages à niveau, passages à gué,
point de mise à l'eau de bateaux à l'intersection d'une voie terrestre de
service et du rivage ou d'une berge; aux portes d'écluse sur un canal ou
une rivière canalisée ou en sortie de certains ports par un chenal
découvert à marée basse...)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] une même adresse pour des équipement différents

[Philippe Verdy]

Pas forcément: ce cas est courant où il n'y a qu'une seule adresse car un
seul lieu et une seule entité légale, mais deux enseignes nommées
simultanément (généralement les deux no,s sont indiqués séparés par un "/".
Et souvent il n'y a même pas différence entre les autres tags applicables à
chaque enseigne.
Dans certains cas il y a bien deux entités légales mais le lieu partage le
même personnel (ou une bonne partie qui peut en changer facilement au cours
du temps ou travaille en temps partagé pour l'une ou l'autre société), par
exemple un même secrétariat.
Cabinet de notaires associés, cabinets médicaux avec plusieurs médecins ou
infirmiers, et bon nombre de sociétés contrôlées par un même groupe; ou
magasins multienseigne, y compris la distribution (par ex. "Promod / LIDL",
aucune des deux enseignes n'est privilégiée). On en trouve aussi dans les
services publics et associatifs (ex. "Centre d'activité / Foyer pour les
jeunes"; clubs sportifs groupés)
Bon nombre de tags peuvent être communs ou spécifiques à une des activités
proposées au même endroit, avec me même clé mais plusieurs valeurs (par ex:
club de foot / club de rugby).

Le 18 octobre 2014 21:55, Francescu GAROBY  a écrit :

> Bonjour,
> Dans ton cas, je laisserais le 85 sur le bâti, créerais 2 nodes pour le
> centre culturel et la bibliothèque municipale et créerais une
> "associatedAddress" (type de relation encore à l'état de brouillon, ceci
> dit...), regroupant le bâti, le centre culturel et la bibliothèque
> municipale.
>
> Francescu
>
> Le 18 octobre 2014 21:52, Gwen  a écrit :
>
> bonjour
>>
>> J'aimerai savoir comment effectuer l'adressage d'équipement différents
>> mais situés au même endroit.
>>
>> En l'occurence, un centre culturel appelé L'Antichambre
>> (amenity=community_center) et une bibliothèque municipale
>> (amenity=library).
>> Ces 2 équipement se situent au 85 avenue du Maréchal Leclerc, 35310
>> Mordelles.
>> La relation associatedStreet n'a pas encore été créée.
>>
>> C'est ici :
>> http://www.openstreetmap.org/#map=19/48.07597/-1.84020
>> Le rendu Mapnik n'affiche pas le community_center
>>
>> d'avance merci pour votre aide.
>>
>> Gwen
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
> Cordialement,
> Francescu GAROBY
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose "Missing object kind" sur Piste de ski

[Jean-Baptiste Holcroft]

Cela montre que la détection osmose a vraiment du sens, je vous propose de
demander à scinder les erreurs avec des messages différents pour lieux
guider les utilisateurs. Qu'en pensez vous ?
Le 18 oct. 2014 23:39, "Matthias Dietrich"  a écrit :

> Je reprends également point par point.
>
> Je ne comprends pas groupe comme étant le tag principal, mais simplement
> la "catégorie" en quelque sorte. D'ailleurs le lien ne pointe pas vers la
> clé highway, mais sur une page listant tout ce qui concerne la voirie.
>
> Soit nous ne parlons pas de la même chose, soit tu extrapoles ce que dit
> le wiki. Pour mountain_pass, le noeud doit certes se trouver sur un way
> highway=*, mais le noeud en lui-même ne doit pas porter un quelconque
> highway=*. C'est cette soi-disant erreur que rapporte Osmose.
>
> Pour traffic_sign, relis la partie qui explique comment le taguer sur un
> noeud.
>
> *As a **separate* *node*
>
> Create a separate node beside the road at the position of the actual sign.
>
> Et si tu regardes le tableau en dessous dans le wiki, pour
> traffic_sign=city_limit  seul le cas d'un noeud est prévu. Cela n'aurait
> aucun sens sur un way, à moins de micro-tagguer les dimensions du panneau
> ...
>
> Regarde également dans le panneau de droite les "useful combinations". La
> clé highway n'y est pas citée.
>
> Enfin, et j'arrêterai là, ces façons de tagguer les cols et les panneaux
> d'agglomération existent depuis longtemps, c'est ce que je voulais dire en
> citant les chiffres de taginfo. Taginfo reflète avant tout la pratique des
> contributeurs. Avec parfois des incohérences certes, mais jusqu'à
> aujourd'hui, on y apprend que personne n'a ajouté de tag highway=* à
> mountain_pass ou à traffic_sign=city_limit.
> Qu'on veuille les changer, pourquoi pas, mais cela doit passer par une
> discussion sur tagging ou autres. Ce n'est pas à Osmose d'imposer une
> nouvelle interprétation.
>
> Personnellement je me moque royalement de devoir ajouter du highway=* ou
> pas à ces noeuds s'il y'a un consensus pour le faire, parce que certains
> trouvent ça plus clair. Ce qui me dérange, c'est qu'Osmose rapporte comme
> erreur ce qui est la pratique majoritaire, documentée et établie depuis
> longtemps.
>
> Le 18 oct. 2014 22:44, "Jérôme Seigneuret"  a
> écrit :
>
>> @Matthias Dietrich je vais juste reprendre point par point
>>
>> *Après vérification du wiki, il faudrait en effet que information=* soit
>> accompagné de tourism=information. *
>>
>> En effet c'est précisé ici
>> http://wiki.openstreetmap.org/wiki/FR:Key:information
>>
>> PS: quand dans la boite à droite c'est écrit G*roupe : ** c'est que le
>> groupe est le tag principal il me semble
>>
>> *En revanche mountain_pass=yes ne nécessite rien d'autre. Pour golf=* le
>> wiki ne dit pas qu'il doit être ajouté à sport=golf par exemple. *
>>
>> Ça c'est pas vrai!
>>
>> Premièrement, Pour *mountain_pass *c'est considéré comme attribut d'un
>> highway donc il manque aussi un tag! La doc anglaise dit
>> :
>> *Applies to the "highest node" on a highway =
>> motorway/secondary/footway/... (could be any appropriate "highway"):*
>> Donc highway=* est indispensable
>>
>> Et en ce qui concerne traffic_sign=city_limit, là non plus il n'est pas
>> précisé qu'il doit être ajouté à autre chose. En non, il ne doit pas être
>> nécessairement sur du highway
>>
>> Humm Il me semble que la page dit que c'est un membre du groupe highway.
>> Donc highway est indispensable avec highway=traffic_sign! C'est un manque
>> du wiki est j'espère que ce sera traité comme tel.
>>
>> mais à l'emplacement physique du panneau, qui est en général à côté de la
>> voirie, comme indiqué dans le wiki.
>>
>> oui est non : *It is possible to use a node which is part of a way, or
>> to create a separate node beside the road. Both methods are used in
>> practice.*
>>
>>  Taginfo indique également qu'aucun des quelque 100 000 nœuds
>> traffic_sign=city_limit n'est actuellement accompagné de highway=*.
>>
>> Pour moi c'est une connerie du au fait que ce ne soit pas précisé dans le
>> wiki! traffic_sign peut être correspondre à tout les élèments ou partie de
>> voirie. dans un way dans tous les cas tu auras un highway. Donc dans les
>> noeud isolé pour être cohérent il faut ajouter
>>
>>
>> *Donc en dehors de information=*, Osmose ne devrait pas lever d'erreurs
>> sur ces objets (en tout cas pas si on s'en tient aux usages actuels). *
>>
>> *Taginfo indique également qu'aucun des quelque 100 000 nœuds
>> traffic_sign=city_limit n'est actuellement accompagné de highway=*.*
>>
>> Cela peut aussi être du à un manque dans le wiki... Taginfo ne remonte
>> que la manière dont c'est utilisé et pas les incohérence sur l'utilisation.
>> Si c'est pas claire tout le monde fera n'importe quoi et on le voit sur
>> d'autre tags. Si j'en corrige 75000 highway=traffic_sign ,
>> considèrera-t-on que c'est ça qu'il faut faire?
>> Bref Taginfo permet de savoir combien on a de sai

Re: [OSM-talk-fr] Osmose "Missing object kind" sur Piste de ski

[Matthias Dietrich]

Je reprends également point par point.

Je ne comprends pas groupe comme étant le tag principal, mais simplement la
"catégorie" en quelque sorte. D'ailleurs le lien ne pointe pas vers la clé
highway, mais sur une page listant tout ce qui concerne la voirie.

Soit nous ne parlons pas de la même chose, soit tu extrapoles ce que dit le
wiki. Pour mountain_pass, le noeud doit certes se trouver sur un way
highway=*, mais le noeud en lui-même ne doit pas porter un quelconque
highway=*. C'est cette soi-disant erreur que rapporte Osmose.

Pour traffic_sign, relis la partie qui explique comment le taguer sur un
noeud.

*As a **separate* *node*

Create a separate node beside the road at the position of the actual sign.

Et si tu regardes le tableau en dessous dans le wiki, pour
traffic_sign=city_limit  seul le cas d'un noeud est prévu. Cela n'aurait
aucun sens sur un way, à moins de micro-tagguer les dimensions du panneau
...

Regarde également dans le panneau de droite les "useful combinations". La
clé highway n'y est pas citée.

Enfin, et j'arrêterai là, ces façons de tagguer les cols et les panneaux
d'agglomération existent depuis longtemps, c'est ce que je voulais dire en
citant les chiffres de taginfo. Taginfo reflète avant tout la pratique des
contributeurs. Avec parfois des incohérences certes, mais jusqu'à
aujourd'hui, on y apprend que personne n'a ajouté de tag highway=* à
mountain_pass ou à traffic_sign=city_limit.
Qu'on veuille les changer, pourquoi pas, mais cela doit passer par une
discussion sur tagging ou autres. Ce n'est pas à Osmose d'imposer une
nouvelle interprétation.

Personnellement je me moque royalement de devoir ajouter du highway=* ou
pas à ces noeuds s'il y'a un consensus pour le faire, parce que certains
trouvent ça plus clair. Ce qui me dérange, c'est qu'Osmose rapporte comme
erreur ce qui est la pratique majoritaire, documentée et établie depuis
longtemps.

Le 18 oct. 2014 22:44, "Jérôme Seigneuret"  a
écrit :

> @Matthias Dietrich je vais juste reprendre point par point
>
> *Après vérification du wiki, il faudrait en effet que information=* soit
> accompagné de tourism=information. *
>
> En effet c'est précisé ici
> http://wiki.openstreetmap.org/wiki/FR:Key:information
>
> PS: quand dans la boite à droite c'est écrit G*roupe : ** c'est que le
> groupe est le tag principal il me semble
>
> *En revanche mountain_pass=yes ne nécessite rien d'autre. Pour golf=* le
> wiki ne dit pas qu'il doit être ajouté à sport=golf par exemple. *
>
> Ça c'est pas vrai!
>
> Premièrement, Pour *mountain_pass *c'est considéré comme attribut d'un
> highway donc il manque aussi un tag! La doc anglaise dit
> :
> *Applies to the "highest node" on a highway =
> motorway/secondary/footway/... (could be any appropriate "highway"):*
> Donc highway=* est indispensable
>
> Et en ce qui concerne traffic_sign=city_limit, là non plus il n'est pas
> précisé qu'il doit être ajouté à autre chose. En non, il ne doit pas être
> nécessairement sur du highway
>
> Humm Il me semble que la page dit que c'est un membre du groupe highway.
> Donc highway est indispensable avec highway=traffic_sign! C'est un manque
> du wiki est j'espère que ce sera traité comme tel.
>
> mais à l'emplacement physique du panneau, qui est en général à côté de la
> voirie, comme indiqué dans le wiki.
>
> oui est non : *It is possible to use a node which is part of a way, or to
> create a separate node beside the road. Both methods are used in practice.*
>
>  Taginfo indique également qu'aucun des quelque 100 000 nœuds
> traffic_sign=city_limit n'est actuellement accompagné de highway=*.
>
> Pour moi c'est une connerie du au fait que ce ne soit pas précisé dans le
> wiki! traffic_sign peut être correspondre à tout les élèments ou partie de
> voirie. dans un way dans tous les cas tu auras un highway. Donc dans les
> noeud isolé pour être cohérent il faut ajouter
>
>
> *Donc en dehors de information=*, Osmose ne devrait pas lever d'erreurs
> sur ces objets (en tout cas pas si on s'en tient aux usages actuels). *
>
> *Taginfo indique également qu'aucun des quelque 100 000 nœuds
> traffic_sign=city_limit n'est actuellement accompagné de highway=*.*
>
> Cela peut aussi être du à un manque dans le wiki... Taginfo ne remonte que
> la manière dont c'est utilisé et pas les incohérence sur l'utilisation. Si
> c'est pas claire tout le monde fera n'importe quoi et on le voit sur
> d'autre tags. Si j'en corrige 75000 highway=traffic_sign ,
> considèrera-t-on que c'est ça qu'il faut faire?
> Bref Taginfo permet de savoir combien on a de saisie ou de comparer des
> mode de saisie mais pas de dire que c'est bien ou non. Au moins on sait que
> 10 noeud seront à revoir...
>
> traffic_sign est une restriction doit-on ajouter des tags restriction pour
> avoir une catégorie principale... ou complètement ignoré les restrictions
> du test...
>
> Voir:
> http://wiki.openstreetmap.org/wiki/Map_Features
>
>
>
>
> Le 18 octobre

Re: [OSM-talk-fr] Controverse : l'empire des data, les frontières de l'Open

[Christophe Merlet]

Le 17/10/2014 16:35, sebastien.di...@free.fr a écrit :
> Bonjour,
> 
> Ceux d'entre vous qui s'intéressent à l'Open Data, aux opportunités et
> problèmes que créent le « Big Data » et le « Data Mining » et qui seront
> sur Toulouse ce week-end seront peut-être intéressés par la controverse
> à laquelle je vais participer samedi à 14h au Grand Rond :
> 
> « Controverse : l'empire des data, les frontières de l'Open
> 
> »
> 
> J'y suis invité en tant que contributeur à OpenStreetMap et promoteur de
> l'Open Data.

C'était intéressant.
Cependant 3 heures c'était vraiment trop court vu l'étendue du sujet
(Open Data / Big Data) qui plus est d'un point de vue technique,
juridique et sociétal, sans oublier les prospectives futuristes.

Je tiens à saluer tout particulièrement le travail du graphiste qui a
illustré avec talent les sujets abordés par l'ensemble des intervenants.
http://ftp.redfoxcenter.org/pub/RedFox/Divers/OpenStreetMap/20141018_Novela_OpenData.jpg


Un seul regret à cette après-midi : J'ai encore perdu mon téléphone
portable !! Nom de diou. Et comme je l'avais mis en mode avion,
ben pas possible de le faire sonner. Cette guigne :/

> Les autres invités sont :
> 
>   * Bertrand Serp, vice-président de Toulouse Métropole en charge du
> numérique et président d'Open Data France
> 
>   * Sandrine Mathon, juriste, spécialiste de droit de l'informatique et
> ancienne membre de la CNIL, elle est aussi la chef de projet du
> portail Open Data de Toulouse Métropole
> 
>   * Pierre-Henri Cros, fondateur du CERFACS (Centre européen de
> recherche et de formation avancée en calcul scientifique)
> 
>   * Jean-Michel Loubes, mathématicien au sein de l'IRIT, connu pour ses
> recherches sur le Big Data
> 
>   * Céline Castets-Renard, professeur de droit privé à l'Université
> Toulouse 1 Capitole, directrice adjointe de l’IRDEIC (Institut de
> Recherche en Droit européen, International et Comparé)
> 
>   * Fanny Lalleman, docteur en science du langage dont la thèse porte
> sur l'exploitation des grandes masses de données
> 
> Les animateurs de l'événement l'on qualifié de « Controverse » car ce ne
> sera ni une conférence, ni une table ronde mais bien un débat au cours
> duquel les participants, mêlés au public, échangeront leurs points de
> vue sur les grandes questions du domaine et répondront aux questions du
> public.
> 
> Sébastien


Librement,
-- 
Christophe Merlet (RedFox)

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

Re: [OSM-talk-fr] Osmose "Missing object kind" sur Piste de ski

[Jérôme Seigneuret]

@Matthias Dietrich je vais juste reprendre point par point

*Après vérification du wiki, il faudrait en effet que information=* soit
accompagné de tourism=information. *

En effet c'est précisé ici
http://wiki.openstreetmap.org/wiki/FR:Key:information

PS: quand dans la boite à droite c'est écrit G*roupe : ** c'est que le
groupe est le tag principal il me semble

*En revanche mountain_pass=yes ne nécessite rien d'autre. Pour golf=* le
wiki ne dit pas qu'il doit être ajouté à sport=golf par exemple. *

Ça c'est pas vrai!

Premièrement, Pour *mountain_pass *c'est considéré comme attribut d'un
highway donc il manque aussi un tag! La doc anglaise dit
:
*Applies to the "highest node" on a highway =
motorway/secondary/footway/... (could be any appropriate "highway"):*
Donc highway=* est indispensable

Et en ce qui concerne traffic_sign=city_limit, là non plus il n'est pas
précisé qu'il doit être ajouté à autre chose. En non, il ne doit pas être
nécessairement sur du highway

Humm Il me semble que la page dit que c'est un membre du groupe highway.
Donc highway est indispensable avec highway=traffic_sign! C'est un manque
du wiki est j'espère que ce sera traité comme tel.

mais à l'emplacement physique du panneau, qui est en général à côté de la
voirie, comme indiqué dans le wiki.

oui est non : *It is possible to use a node which is part of a way, or to
create a separate node beside the road. Both methods are used in practice.*

 Taginfo indique également qu'aucun des quelque 100 000 nœuds
traffic_sign=city_limit n'est actuellement accompagné de highway=*.

Pour moi c'est une connerie du au fait que ce ne soit pas précisé dans le
wiki! traffic_sign peut être correspondre à tout les élèments ou partie de
voirie. dans un way dans tous les cas tu auras un highway. Donc dans les
noeud isolé pour être cohérent il faut ajouter


*Donc en dehors de information=*, Osmose ne devrait pas lever d'erreurs sur
ces objets (en tout cas pas si on s'en tient aux usages actuels). *

*Taginfo indique également qu'aucun des quelque 100 000 nœuds
traffic_sign=city_limit n'est actuellement accompagné de highway=*.*

Cela peut aussi être du à un manque dans le wiki... Taginfo ne remonte que
la manière dont c'est utilisé et pas les incohérence sur l'utilisation. Si
c'est pas claire tout le monde fera n'importe quoi et on le voit sur
d'autre tags. Si j'en corrige 75000 highway=traffic_sign , considèrera-t-on
que c'est ça qu'il faut faire?
Bref Taginfo permet de savoir combien on a de saisie ou de comparer des
mode de saisie mais pas de dire que c'est bien ou non. Au moins on sait que
10 noeud seront à revoir...

traffic_sign est une restriction doit-on ajouter des tags restriction pour
avoir une catégorie principale... ou complètement ignoré les restrictions
du test...

Voir:
http://wiki.openstreetmap.org/wiki/Map_Features




Le 18 octobre 2014 20:00, Matthias Dietrich  a écrit :

> Après vérification du wiki, il faudrait en effet que information=* soit
> accompagné de tourism=information.
>
> En revanche mountain_pass=yes ne nécessite rien d'autre. Pour golf=* le
> wiki ne dit pas qu'il doit être ajouté à sport=golf par exemple.
>
> Et en ce qui concerne traffic_sign=city_limit, là non plus il n'est pas
> précisé qu'il doit être ajouté à autre chose. En non, il ne doit pas être
> nécessairement sur du highway, mais à l'emplacement physique du panneau,
> qui est en général à côté de la voirie, comme indiqué dans le wiki. Taginfo
> indique également qu'aucun des quelque 100 000 nœuds
> traffic_sign=city_limit n'est actuellement accompagné de highway=*.
> Donc en dehors de information=*, Osmose ne devrait pas lever d'erreurs sur
> ces objets (en tout cas pas si on s'en tient aux usages actuels).
>
> Le 18 octobre 2014 15:22, Jérôme Seigneuret  a
> écrit :
>
> L'ensemble de ces clé doivent normalement être membre des clés
>> précédemment cités (explicite ou implicite)
>>
>> *traffic_sign *n'est pas cité dans la page principale mais *traffic_signal
>> *oui
>> ne doit t'on pas mettre :
>> *highway=traffic_sign *en plus?
>>
>> même cas pour *information*:
>> *highway=information*
>> *tourism=information*
>> *etc...*
>>
>> Je pense que rajouter n'est pas forcément juste. Sinon il faut considérer
>> qu'il y a des nouveau types principaux.
>> Si ce sont des type implicites il faut pouvoir vérifier leurs
>> correspondance avec l'une des clés principales.
>>
>> Exemple pour les trafic_sign il faut forcément qu'ils soit sur du highway
>> parcontre un panneau d'information est quand à lui positionné sur des
>> parcelles privé et non sur la voirie.
>>
>> A la base le modèle est en XML. N'y a t-il pas un schéma XSD ou JSON?
>>
>> en json on peut analyser le contenu avec un correspondance à un schema
>> https://pypi.python.org/pypi/jsonschema
>>
>> On pourra aussi proposer via ça des listes de balises connexes manquantes
>>
>>
>>
>>
>>
>>
>>
>> Le 18 octobre 2014 14:32, Matthias Dietrich  a
>> écrit :

[OSM-talk-fr] OsmAnd : notes audio dans JOSM

[Eric SIBERT]

Bonsoir à tous,

J'utilise depuis quelques jours OsmAnd sous Android pour faire mes 
relevés de terrain. J'ai plusieurs petits problèmes.


Mon problème le plus important, c'est que je ne sais pas comment lire et 
localiser mes notes audio dans JOSM.


Des idées?


--
Éric

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

Re: [OSM-talk-fr] une même adresse pour des équipement différents

[Francescu GAROBY]

Bonjour,
Dans ton cas, je laisserais le 85 sur le bâti, créerais 2 nodes pour le
centre culturel et la bibliothèque municipale et créerais une
"associatedAddress" (type de relation encore à l'état de brouillon, ceci
dit...), regroupant le bâti, le centre culturel et la bibliothèque
municipale.

Francescu

Le 18 octobre 2014 21:52, Gwen  a écrit :

> bonjour
>
> J'aimerai savoir comment effectuer l'adressage d'équipement différents
> mais situés au même endroit.
>
> En l'occurence, un centre culturel appelé L'Antichambre
> (amenity=community_center) et une bibliothèque municipale
> (amenity=library).
> Ces 2 équipement se situent au 85 avenue du Maréchal Leclerc, 35310
> Mordelles.
> La relation associatedStreet n'a pas encore été créée.
>
> C'est ici :
> http://www.openstreetmap.org/#map=19/48.07597/-1.84020
> Le rendu Mapnik n'affiche pas le community_center
>
> d'avance merci pour votre aide.
>
> Gwen
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



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

[OSM-talk-fr] une même adresse pour des équipement différents

[Gwen]

bonjour

J'aimerai savoir comment effectuer l'adressage d'équipement différents
mais situés au même endroit.

En l'occurence, un centre culturel appelé L'Antichambre
(amenity=community_center) et une bibliothèque municipale (amenity=library).
Ces 2 équipement se situent au 85 avenue du Maréchal Leclerc, 35310
Mordelles.
La relation associatedStreet n'a pas encore été créée.

C'est ici :
http://www.openstreetmap.org/#map=19/48.07597/-1.84020
Le rendu Mapnik n'affiche pas le community_center

d'avance merci pour votre aide.

Gwen

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

Re: [OSM-talk-fr] Bâti au Mesnil Raoult

[didier2020]

Le samedi 18 octobre 2014 à 18:55 +0200, Olivier Delaune a écrit : 
> En regardant de plus prêt, les bâtiments correspondent à l'image Bing...
> Bref, je sais pas trop quoi faire dans ce genre de cas à part tout reprendre 
> à 
> la main
reponse de normand (normal dans le 50) :

la valeur ajoutée du cadastre :
- morceler les batiments 
- ajout de wall=no 
- décalage avec les routes 


il ne manque que quelques batiments (d'après bing) 
mais en trop a certains endroits (d après le cadastre) ...

bref, je ne rajouterais les batiments manquants 
> 
> > 
> > Bonjour, en voulant ajouté des infos sur Le Mesnil Raoult (50), je me suis
> > rendu compte que les bâtiments étaient pour la plupart très mal positionnés
> > et/ou de mauvaise forme.
> > https://www.openstreetmap.org/relation/453669
> > Est ce que quelqu'un pourrait essayer de corriger ça ?
> > Merci d'avance.
> > 
> > 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



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

Re: [OSM-talk-fr] Sites de routage basés sur OSM : numéros de rue?

[Greg]

Oups oui, je me suis emmêlé les pinceaux, désolé :)

2014-10-18 20:26 GMT+02:00 Shohreh :

> Grégoire Surrel wrote
> > Je viens de réutiliser CycleMap et finalement deux choses sont possibles
> :
>
> BikeMap, tu veux dire?
> www.bikemap.net
>
>
> Grégoire Surrel wrote
> > Mine de rien, je garde cycle.travel sous le coude, il est bien aussi, ce
> > site.
>
> Oui, il est pas mal du tout. J'ai envoyé à l'auteur des suggestions
> d'amélioration.
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Sites-de-routage-bases-sur-OSM-numeros-de-rue-tp5820443p5820756.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Sites de routage basés sur OSM : numéros de rue?

[Shohreh]

Grégoire Surrel wrote
> Je viens de réutiliser CycleMap et finalement deux choses sont possibles :

BikeMap, tu veux dire?
www.bikemap.net


Grégoire Surrel wrote
> Mine de rien, je garde cycle.travel sous le coude, il est bien aussi, ce
> site.

Oui, il est pas mal du tout. J'ai envoyé à l'auteur des suggestions
d'amélioration.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Sites-de-routage-bases-sur-OSM-numeros-de-rue-tp5820443p5820756.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Osmose "Missing object kind" sur Piste de ski

[Matthias Dietrich]

Après vérification du wiki, il faudrait en effet que information=* soit
accompagné de tourism=information.

En revanche mountain_pass=yes ne nécessite rien d'autre. Pour golf=* le
wiki ne dit pas qu'il doit être ajouté à sport=golf par exemple.

Et en ce qui concerne traffic_sign=city_limit, là non plus il n'est pas
précisé qu'il doit être ajouté à autre chose. En non, il ne doit pas être
nécessairement sur du highway, mais à l'emplacement physique du panneau,
qui est en général à côté de la voirie, comme indiqué dans le wiki. Taginfo
indique également qu'aucun des quelque 100 000 nœuds
traffic_sign=city_limit n'est actuellement accompagné de highway=*.
Donc en dehors de information=*, Osmose ne devrait pas lever d'erreurs sur
ces objets (en tout cas pas si on s'en tient aux usages actuels).

Le 18 octobre 2014 15:22, Jérôme Seigneuret  a
écrit :

> L'ensemble de ces clé doivent normalement être membre des clés
> précédemment cités (explicite ou implicite)
>
> *traffic_sign *n'est pas cité dans la page principale mais *traffic_signal
> *oui
> ne doit t'on pas mettre :
> *highway=traffic_sign *en plus?
>
> même cas pour *information*:
> *highway=information*
> *tourism=information*
> *etc...*
>
> Je pense que rajouter n'est pas forcément juste. Sinon il faut considérer
> qu'il y a des nouveau types principaux.
> Si ce sont des type implicites il faut pouvoir vérifier leurs
> correspondance avec l'une des clés principales.
>
> Exemple pour les trafic_sign il faut forcément qu'ils soit sur du highway
> parcontre un panneau d'information est quand à lui positionné sur des
> parcelles privé et non sur la voirie.
>
> A la base le modèle est en XML. N'y a t-il pas un schéma XSD ou JSON?
>
> en json on peut analyser le contenu avec un correspondance à un schema
> https://pypi.python.org/pypi/jsonschema
>
> On pourra aussi proposer via ça des listes de balises connexes manquantes
>
>
>
>
>
>
>
> Le 18 octobre 2014 14:32, Matthias Dietrich  a écrit
> :
>
> Il n'y a pas que les pistes de ski qui sont touchées par cette nouvelle
>> analyse, on trouve également des erreurs sur :
>> - les cols (mountain_pass=yes + name=*)
>> - les panneaux d'entrée d'agglomération (traffic_sign=city_limite +
>> name=*)
>> - les panneaux d'information (information=* + name=*)
>> - les éléments d'un terrain de golf (golf=* + name=*)
>>
>> Ceci est juste le retour d'un rapide tour d'horizon autour de chez moi.
>> Il doit y avoir plein d'autres cas.
>>
>> Bref, la liste des "tag principaux" est potentiellement bien plus longue
>> que celle supportée actuellement.
>>
>> Le 18 octobre 2014 14:07, Yves Pratter  a écrit :
>>
>>>
>>> Le 18 oct. 2014 à 13:44, Jérôme Seigneuret  a
>>> écrit :
>>>
>>> L'erreur devrait donc être : "Objet nommé dont un tag indispensable
>>> n'existe pas »
>>>
>>> ou « tag manquant pour un objet nommé »
>>>
>>> Osmose considère que seul les objets avec les attributs suivants peuvent
>>> être nommés :
>>>
>>>- aerialway
>>>- aeroway
>>>- amenity
>>>- barrier
>>>- boundary
>>>- building
>>>- craft
>>>- emergency
>>>- geological
>>>- highway
>>>- historic
>>>- landuse
>>>- leisure
>>>- man_made
>>>- military
>>>- natural
>>>- office
>>>- place
>>>- power
>>>- public_transport
>>>- railway
>>>- route
>>>- shop
>>>- sport
>>>- tourism
>>>- waterway
>>>
>>> Pour les pistes de ski, il y a l’attribut *piste:type* mais pas *type*.
>>>
>>> Il faut donc rajouter piste:type à la liste… ou rajouter un mécanisme
>>> qui recherche les attributs se terminant par *:type.
>>>
>>> Le 18 oct. 2014 à 11:30, Yves Pratter  a écrit :
>>>
>>> J’essai de comprendre le code mais ce n’est pas très clair (en
>>> comparaison à d’autres erreurs):
>>> Donc si l’objet à l’attribut « name » et que son parent ne serait pas
>>> nommé ?? (je ne pige pas la seconde condition)
>>>
>>> if tags.get("name") and len(key_set & self.name_parent) == 0: err.append
>>> ((21101, 1, {}))
>>>
>>>
>>> En fait, l’erreur est produite si un objet OSM à un attribut *name* et
>>> qu’il n’a aucun des attributs suivants : *type*, *aerialway*…
>>>
>>> Donc, le message pourrait être *« tag manquant pour un objet nommé » *
>>>
>>> —
>>> Yves
>>>
>>> *key_set *est la liste des attributs de l’objet.
>>> *self.name_parent* est la liste des objets/attributs qui peuvent être
>>> nommé
>>> self.name_parent = set(('type', 'aerialway', 'aeroway', 'amenity',
>>> 'barrier', 'boundary', 'building', 'craft', 'emergency', 'geological',
>>> 'highway', 'historic', 'landuse', 'leisure', 'man_made', 'military',
>>> 'natural', 'office', 'place', 'power', 'public_transport', 'railway',
>>> 'route', 'shop', 'sport', 'tourism', 'waterway'))
>>>
>>> len(key_set & self.name_parent) == 0
>>> indique l’appartenance cf.  A⊆B cf. Utilisation avancée des listes en
>>> Python
>>> 
>>>
>>>
>>> 

Re: [OSM-talk-fr] Bâti au Mesnil Raoult

[Olivier Delaune]

En regardant de plus prêt, les bâtiments correspondent à l'image Bing...
Bref, je sais pas trop quoi faire dans ce genre de cas à part tout reprendre à 
la main

> 
> Bonjour, en voulant ajouté des infos sur Le Mesnil Raoult (50), je me suis
> rendu compte que les bâtiments étaient pour la plupart très mal positionnés
> et/ou de mauvaise forme.
> https://www.openstreetmap.org/relation/453669
> Est ce que quelqu'un pourrait essayer de corriger ça ?
> Merci d'avance.
> 
> 

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

[OSM-talk-fr] Bâti au Mesnil Raoult

[Olivier Delaune]

Bonjour, en voulant ajouté des infos sur Le Mesnil Raoult (50), je me suis 
rendu compte que les bâtiments étaient pour la plupart très mal positionnés 
et/ou de mauvaise forme.
https://www.openstreetmap.org/relation/453669
Est ce que quelqu'un pourrait essayer de corriger ça ?
Merci d'avance.

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

Re: [OSM-talk-fr] Sites de routage basés sur OSM : numéros de rue?

[Paul Desgranges]

Difficile de trouver l'outil ou le site qui fait tout bien, en ce qui 
concerne le tracé des sorties vélo!

Mais j'ai vérifié les points suivants pour OpenRunner
  - l'export en KLM est possible (KLM_0, KLM_5)
  - on peut utiliser le fond de carte que l'on souhaite : Google Map, 
Google Sattelite, OpenStreeMap, OpenCycleMap, MapQuest, HikeBikeMap, 
TopoIGNFrance, ScanExpressIGN France (pas tout essayé!)
  - Il est possible de renseigner un champ adresse pour centrer la 
carte sur cette adresse , (mais pas de champ from/to, c'est vrai ça manque )
  - Sans pouvoir "tirer" sur le parcours, on peut insérer un point 
intermédiaire

  - Pas possible molette pour zoomer, un peu pénible
  - On peut voir le profil, le dénivelé, etc

C'est bien cet inventaire des sites et des applications  pour cartes 
vélo ...  il faudrait créer un thread de mail ad hoc!



Le 17/10/2014 14:24, Shohreh a écrit :

Merci pour les infos.

À ce stade, ni OSRM, ni OSR, ni OpenRunner ne sont pour moi de bonnes
alternatives à Google Maps Classic pour tracer des parcours vélo en zone
urbaine:

OSRM: "Timed out" très fréquent. Visiblement, ils n'ont pas les ressources.

OSR: Pas possible de "tirer" sur le tracé pour le forcer à passer par un
autre endroit

OpenRunner: molette souris marche pas pour zoomer in/out; pas de champs
"From/To" pour taper des adresses.

La moins mauvaise solution pour moi est d'utiliser Google Maps Engine Lite
("New") mais le tracer marche moins bien que la version Classic.

Ailleurs, on me parle de ces serveurs:
http://www.cyclestreets.net/journey/
http://cycle.travel/map

Mais comme c'est du OSM, on retombe sur le problème des numéros de rue.
Exemple : "14 rue Gosciny 75013" passe dans Google, mais marche pas dans OSM
("Aucun résultat n’a été trouvé"; même avec "14 rue René Gosciny 75013").



--
View this message in context: 
http://gis.19327.n5.nabble.com/Sites-de-routage-bases-sur-OSM-numeros-de-rue-tp5820443p5820632.html
Sent from the France mailing list archive at Nabble.com.

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


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

Re: [OSM-talk-fr] Osmose "Missing object kind" sur Piste de ski

[Jérôme Seigneuret]

L'ensemble de ces clé doivent normalement être membre des clés précédemment
cités (explicite ou implicite)

*traffic_sign *n'est pas cité dans la page principale mais *traffic_signal *
oui
ne doit t'on pas mettre :
*highway=traffic_sign *en plus?

même cas pour *information*:
*highway=information*
*tourism=information*
*etc...*

Je pense que rajouter n'est pas forcément juste. Sinon il faut considérer
qu'il y a des nouveau types principaux.
Si ce sont des type implicites il faut pouvoir vérifier leurs
correspondance avec l'une des clés principales.

Exemple pour les trafic_sign il faut forcément qu'ils soit sur du highway
parcontre un panneau d'information est quand à lui positionné sur des
parcelles privé et non sur la voirie.

A la base le modèle est en XML. N'y a t-il pas un schéma XSD ou JSON?

en json on peut analyser le contenu avec un correspondance à un schema
https://pypi.python.org/pypi/jsonschema

On pourra aussi proposer via ça des listes de balises connexes manquantes







Le 18 octobre 2014 14:32, Matthias Dietrich  a écrit :

> Il n'y a pas que les pistes de ski qui sont touchées par cette nouvelle
> analyse, on trouve également des erreurs sur :
> - les cols (mountain_pass=yes + name=*)
> - les panneaux d'entrée d'agglomération (traffic_sign=city_limite + name=*)
> - les panneaux d'information (information=* + name=*)
> - les éléments d'un terrain de golf (golf=* + name=*)
>
> Ceci est juste le retour d'un rapide tour d'horizon autour de chez moi. Il
> doit y avoir plein d'autres cas.
>
> Bref, la liste des "tag principaux" est potentiellement bien plus longue
> que celle supportée actuellement.
>
> Le 18 octobre 2014 14:07, Yves Pratter  a écrit :
>
>>
>> Le 18 oct. 2014 à 13:44, Jérôme Seigneuret  a
>> écrit :
>>
>> L'erreur devrait donc être : "Objet nommé dont un tag indispensable
>> n'existe pas »
>>
>> ou « tag manquant pour un objet nommé »
>>
>> Osmose considère que seul les objets avec les attributs suivants peuvent
>> être nommés :
>>
>>- aerialway
>>- aeroway
>>- amenity
>>- barrier
>>- boundary
>>- building
>>- craft
>>- emergency
>>- geological
>>- highway
>>- historic
>>- landuse
>>- leisure
>>- man_made
>>- military
>>- natural
>>- office
>>- place
>>- power
>>- public_transport
>>- railway
>>- route
>>- shop
>>- sport
>>- tourism
>>- waterway
>>
>> Pour les pistes de ski, il y a l’attribut *piste:type* mais pas *type*.
>>
>> Il faut donc rajouter piste:type à la liste… ou rajouter un mécanisme qui
>> recherche les attributs se terminant par *:type.
>>
>> Le 18 oct. 2014 à 11:30, Yves Pratter  a écrit :
>>
>> J’essai de comprendre le code mais ce n’est pas très clair (en
>> comparaison à d’autres erreurs):
>> Donc si l’objet à l’attribut « name » et que son parent ne serait pas
>> nommé ?? (je ne pige pas la seconde condition)
>>
>> if tags.get("name") and len(key_set & self.name_parent) == 0: err.append
>> ((21101, 1, {}))
>>
>>
>> En fait, l’erreur est produite si un objet OSM à un attribut *name* et
>> qu’il n’a aucun des attributs suivants : *type*, *aerialway*…
>>
>> Donc, le message pourrait être *« tag manquant pour un objet nommé » *
>>
>> —
>> Yves
>>
>> *key_set *est la liste des attributs de l’objet.
>> *self.name_parent* est la liste des objets/attributs qui peuvent être
>> nommé
>> self.name_parent = set(('type', 'aerialway', 'aeroway', 'amenity',
>> 'barrier', 'boundary', 'building', 'craft', 'emergency', 'geological',
>> 'highway', 'historic', 'landuse', 'leisure', 'man_made', 'military',
>> 'natural', 'office', 'place', 'power', 'public_transport', 'railway',
>> 'route', 'shop', 'sport', 'tourism', 'waterway'))
>>
>> len(key_set & self.name_parent) == 0
>> indique l’appartenance cf.  A⊆B cf. Utilisation avancée des listes en
>> Python
>> 
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Sites de routage basés sur OSM : numéros de rue?

[Greg]

Je viens de réutiliser CycleMap et finalement deux choses sont possibles :
on peut désactiver l'accrochage du tracé aux routes ce qui est pas mal pour
forcer un passage quelque part même s'il n'y a pas de chemin sur la carte,
et l'export est au choix en GPX et KML.

Donc finalement, c'est pas si loin du cahier des charges :)

Mine de rien, je garde cycle.travel sous le coude, il est bien aussi, ce
site.

2014-10-17 22:25 GMT+02:00 Shohreh :

> Grégoire Surrel wrote
> > Il faut en effet cliquer d'abord sur la ligne pour créer une nouvelle
> > étape et ensuite seulement ce point est déplaçable. Et un re-clic sur
> > l'étape la supprime.
>
> Merci. Moins agréable/instrinctif que la solution classique.
>
> À ce stade, j'en reste à  Cycle.travel 
>  combiné
> avec l'appli desktop GpsBabel pour convertir le GPX en KML.
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Sites-de-routage-bases-sur-OSM-numeros-de-rue-tp5820443p5820684.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose "Missing object kind" sur Piste de ski

[Yves Pratter]

Le 18 oct. 2014 à 14:32, Matthias Dietrich  a écrit :

> Il n'y a pas que les pistes de ski qui sont touchées par cette nouvelle 
> analyse, on trouve également des erreurs sur :
> - les cols (mountain_pass=yes + name=*)
> - les panneaux d'entrée d'agglomération (traffic_sign=city_limite + name=*)
> - les panneaux d'information (information=* + name=*)
> - les éléments d'un terrain de golf (golf=* + name=*)
> 
> Ceci est juste le retour d'un rapide tour d'horizon autour de chez moi. Il 
> doit y avoir plein d'autres cas.
> 
A rajouter à la liste alors ?

Un rapide coup d’oeil sur la liste des erreurs rencontrées montre que cette 
vérification est loin d’être inutile :-)
J’ai vu plusieurs erreurs sur des lacs, des rivières à Madagascar…
J’en ai corrigé une, signaler l’autre au cartographieur local… il en reste 137 
653 ! ;-D

http://osmose.openstreetmap.fr/fr/errors/?item=2110

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

Re: [OSM-talk-fr] Osmose "Missing object kind" sur Piste de ski

[Philippe Verdy]

Apparemment dans ce que j'ai vu, si on a une clé name=* pour le nom par
défaut, et d'autres clés name:=* pour des traductions et qu'aucune
d'elle ne correspond au nom par défaut, Os,ose considère que le no, donné
dans name=* est dans une langue ambiguë (car la résolution des langues peut
très bien vouloir utiliser une des traductions au lieu d'utiliser le nom
par défaut plus pertinent correspondant à une langue non explicitement
mentionnée.

Par exemple si on a name=* avec le nom effectif en français (mais pas
indiqué) et name:en=* avec une traduction anglaise (lange explicite) et
qu'un utilisateur breton fait une recherche de nom avec ses préférences de
langues établies dans l'ordre : breton, français, anglais, alors la
recherche ne trouvera pas la langue française (puisqu'elle n'est pas
mentionnée) mais utilisera le nom anglais (name=* n'est utilisé qu'en
dernier ressort).

Il apparaît donc que si on a une clé name=* et des clés name:lang=* alors
une de ces clés doit prendre en valeur le nom indiqué dans name=*.

Exception: name=* est parfois multilingue parce qu'on ne peut pas faire le
choix de la traduction; les deux langues sont co-officielles (on a le cas
en Belgique, en Suisse, au Luxembourg; et dans certaines communautés
autonomes espagnoles...) et name=* mentionne ces différents noms, mais
chaque nom dans chaque langue officielle dvrait être listé individuellement
dans un name:=* (et aucun d'eux ne correspondra exactement à la
valeur par défaut, multilingue, donnée dans name=* (dans ce cas Osmose
signale l'ano,alie à traiter comme faux positif si on a bien ajouté aussi
les noms individuels pour chaque langue explicite, ce qui ne posera
cependant pas de problème pour la résolution des traductions).

Ce cas est d'ailleurs signalé avec un autre avertissement ("deux noms") sur
la valeur de name=* (quand elle contient certains séparateurs comme "/",la
virgule, le point-virgule ou le "signe "+" (qui fait aussi des faus
positifs sur les noms de parking "P+R" par exemple dans plusieurs pays
européens y compris la France, la Suisse, la Belgique...), tout bonnement
car les noms multiples sont présents sur la clé name=* de la valeur par
défaut (cette valeur par défaut ne sera pas utilisé quand on recherche ue
traduction dans une des langues utilisées pour ce no, puisqu'on a pris soin
aussi de donner des noms séparés pour chacune d'elle dans name:=*, il
n'y a aucun problème donc pour résoudre les traductions: ce no, ne
s'affichera que pour les recherches dans d'autres langues (par exemple pour
des recherche en russe; en chinois, en arabe... alors qu'aucune des
traductions proposées ne convient à la recherche dans ces langues
"exotiques" et uniquement si l'utilisateur n'a pas mentionné dans la liste
des langues alternatives de repli ou "fallback" une des langues dont on a
une traduction explicite et individuelle).

En revanche l'avertissement "deux noms" ne devrait pas être ignoré sur une
clé "name:=*".

Exception faite dans ce dernier cas de noms comme "P+R x" (il n'y a
qu'un seul nom, pas deux), ou des noms dépendant du côté de la rue pour une
rue ou une rivière frontalière; mais dans ce cas on devrait aussi avoir
"name:left=*" et "name:right=*" pour préciser le nom applicable à chaque
côté ("name:left:=*" et "name:right:=*" pour préciser selon la
langue explicite, par exempel quand on a deux noms français indiqués dans
"name:fr=*", explicités séparément dans "name:left:fr=*" et
"name:fr:rightt=*".






Le 18 octobre 2014 11:30, Yves Pratter  a écrit :

>
> Le 18 oct. 2014 à 10:02, Jean-Baptiste Holcroft  a
> écrit :
>
>
> Dans le code, l'erreur serait là :
>
> https://github.com/osm-fr/osmose-backend/blob/649db8ac4e642e0fdbf065c1012744e627c8e906/plugins/TagFix_MultipleTag.py#L35
>
>
> J’essai de comprendre le code mais ce n’est pas très clair (en comparaison
> à d’autres erreurs):
> Donc si l’objet à l’attribut « name » et que son parent ne serait pas
> nommé ?? (je ne pige pas la seconde condition)
>
> if tags.get("name") and len(key_set & self.name_parent) == 0: err.append((
> 21101, 1, {}))
>
> (si vous parlez des langues étrangères, n'hésitez pas à aider à la
> traduction d’osmose)
>
> Osmose ne semble pas utiliser de bibliothèque de code i18n
>  (la
> traduction est faite dans le code source, pas dans des fichiers ressources
> séparés).
> Bref ça rend la traduction plus difficile à faire et ça explique peut-être
> pourquoi certaines erreurs apparaissent dans une langue, mais pas dans une
> autre… ?
>
> La bibliothèque gtext existe en Python :
> https://docs.python.org/2/library/i18n.html
>
> Est-ce que son utilisation à été envisagée ?
> C’est un gros chantier que de modifier le code source et d’extraire les
> messages, mais vu l’importance d’Osmose et son utilisation qui semble
> mondiale, ce travail sera un gain de temps pour le futur.
> Et avec plein de petites fourmis, il n’est peut-être pas si difficile et
> long à faire.
>
> —

Re: [OSM-talk-fr] Osmose "Missing object kind" sur Piste de ski

[Matthias Dietrich]

Il n'y a pas que les pistes de ski qui sont touchées par cette nouvelle
analyse, on trouve également des erreurs sur :
- les cols (mountain_pass=yes + name=*)
- les panneaux d'entrée d'agglomération (traffic_sign=city_limite + name=*)
- les panneaux d'information (information=* + name=*)
- les éléments d'un terrain de golf (golf=* + name=*)

Ceci est juste le retour d'un rapide tour d'horizon autour de chez moi. Il
doit y avoir plein d'autres cas.

Bref, la liste des "tag principaux" est potentiellement bien plus longue
que celle supportée actuellement.

Le 18 octobre 2014 14:07, Yves Pratter  a écrit :

>
> Le 18 oct. 2014 à 13:44, Jérôme Seigneuret  a
> écrit :
>
> L'erreur devrait donc être : "Objet nommé dont un tag indispensable
> n'existe pas »
>
> ou « tag manquant pour un objet nommé »
>
> Osmose considère que seul les objets avec les attributs suivants peuvent
> être nommés :
>
>- aerialway
>- aeroway
>- amenity
>- barrier
>- boundary
>- building
>- craft
>- emergency
>- geological
>- highway
>- historic
>- landuse
>- leisure
>- man_made
>- military
>- natural
>- office
>- place
>- power
>- public_transport
>- railway
>- route
>- shop
>- sport
>- tourism
>- waterway
>
> Pour les pistes de ski, il y a l’attribut *piste:type* mais pas *type*.
>
> Il faut donc rajouter piste:type à la liste… ou rajouter un mécanisme qui
> recherche les attributs se terminant par *:type.
>
> Le 18 oct. 2014 à 11:30, Yves Pratter  a écrit :
>
> J’essai de comprendre le code mais ce n’est pas très clair (en comparaison
> à d’autres erreurs):
> Donc si l’objet à l’attribut « name » et que son parent ne serait pas
> nommé ?? (je ne pige pas la seconde condition)
>
> if tags.get("name") and len(key_set & self.name_parent) == 0: err.append((
> 21101, 1, {}))
>
>
> En fait, l’erreur est produite si un objet OSM à un attribut *name* et
> qu’il n’a aucun des attributs suivants : *type*, *aerialway*…
>
> Donc, le message pourrait être *« tag manquant pour un objet nommé » *
>
> —
> Yves
>
> *key_set *est la liste des attributs de l’objet.
> *self.name_parent* est la liste des objets/attributs qui peuvent être
> nommé
> self.name_parent = set(('type', 'aerialway', 'aeroway', 'amenity',
> 'barrier', 'boundary', 'building', 'craft', 'emergency', 'geological',
> 'highway', 'historic', 'landuse', 'leisure', 'man_made', 'military',
> 'natural', 'office', 'place', 'power', 'public_transport', 'railway',
> 'route', 'shop', 'sport', 'tourism', 'waterway'))
>
> len(key_set & self.name_parent) == 0
> indique l’appartenance cf.  A⊆B cf. Utilisation avancée des listes en
> Python
> 
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose "Missing object kind" sur Piste de ski

[Yves Pratter]

Le 18 oct. 2014 à 13:44, Jérôme Seigneuret  a écrit :

> L'erreur devrait donc être : "Objet nommé dont un tag indispensable n'existe 
> pas »
ou « tag manquant pour un objet nommé » 

Osmose considère que seul les objets avec les attributs suivants peuvent être 
nommés :
aerialway
aeroway
amenity
barrier
boundary
building
craft
emergency
geological
highway
historic
landuse
leisure
man_made
military
natural
office
place
power
public_transport
railway
route
shop
sport
tourism
waterway
Pour les pistes de ski, il y a l’attribut piste:type mais pas type.

Il faut donc rajouter piste:type à la liste… ou rajouter un mécanisme qui 
recherche les attributs se terminant par *:type.

Le 18 oct. 2014 à 11:30, Yves Pratter  a écrit :

> J’essai de comprendre le code mais ce n’est pas très clair (en comparaison à 
> d’autres erreurs):
> Donc si l’objet à l’attribut « name » et que son parent ne serait pas nommé 
> ?? (je ne pige pas la seconde condition)
> 
> if tags.get("name") and len(key_set & self.name_parent) == 0:
> err.append((21101, 1, {}))
> 
> 


En fait, l’erreur est produite si un objet OSM à un attribut name et qu’il n’a 
aucun des attributs suivants : type, aerialway…

Donc, le message pourrait être « tag manquant pour un objet nommé » 

—
Yves

key_set est la liste des attributs de l’objet.
self.name_parent est la liste des objets/attributs qui peuvent être nommé
self.name_parent = set(('type', 'aerialway', 'aeroway', 'amenity', 'barrier', 
'boundary', 'building', 'craft', 'emergency', 'geological', 'highway', 
'historic', 'landuse', 'leisure', 'man_made', 'military', 'natural', 'office', 
'place', 'power', 'public_transport', 'railway', 'route', 'shop', 'sport', 
'tourism', 'waterway'))

len(key_set & self.name_parent) == 0
indique l’appartenance cf.  A⊆B cf. Utilisation avancée des listes en Python

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

Re: [OSM-talk-fr] Osmose "Missing object kind" sur Piste de ski

[Jérôme Seigneuret]

L'erreur devrait donc être : "Objet nommé dont un tag indispensable
n'existe pas"

Dans l'aide de l'erreur il faut lister les clés considérés comme
indispensables si un élément est nommé.

Le 18 octobre 2014 13:39, Jérôme Seigneuret  a
écrit :

> arf j'ai dis une connerie...
>
> Le tag *name* existe et il faut au moins un des type d'objet
> 'type', 'aerialway', 'aeroway', 'amenity', 'barrier', 'boundary',
> 'building', 'craft', 'emergency', 'geological', 'highway', 'historic',
> 'landuse', 'leisure', 'man_made', 'military', 'natural', 'office', 'place'
> , 'power', 'public_transport', 'railway', 'route', 'shop', 'sport',
> 'tourism', 'waterway'
>
> Le stest ne vérifie pas que le tag name soit renseigné ou nom mais juste
> sa présence.
>
> et en effet si tu mets:
> *name=Domaine de Dupont*
> *addr:housenumber=1*
>
> *tu auras cette erreur.*
>
> *addr:housename**=Domaine de Dupont*
> *addr:housenumber=1*
>
> Ne renvoi pas d'erreur.
>
> * Ca analyse si un objet est nommé et si cet objet est renseigné avec
> au moins un tag considéré comme primaire (donc indispensable)*
>
> Le 18 octobre 2014 13:19, Pierre-Yves Berrard <
> pierre.yves.berr...@gmail.com> a écrit :
>
>> Le 18 octobre 2014 13:10, Jérôme Seigneuret  a
>> écrit :
>>
>>> Ce que je comprend en lisant ce code c'est que l'erreur s'affiche si
>>> 1) name n'est pas renseigné
>>> 2) il manque un tag pour le type d'objet : 'type', 'aerialway',
>>> 'aeroway', 'amenity', 'barrier', 'boundary', 'building', 'craft',
>>> 'emergency', 'geological', 'highway', 'historic', 'landuse', 'leisure',
>>> 'man_made', 'military', 'natural', 'office', 'place', 'power',
>>> 'public_transport', 'railway', 'route', 'shop', 'sport', 'tourism',
>>> 'waterway'
>>> 3) il n'y a pas d'autre erreurs référencés
>>>
>>
>> On a donc potientellement une erreur sur tous les 'addr:housenumber' ?
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose "Missing object kind" sur Piste de ski

[Jérôme Seigneuret]

arf j'ai dis une connerie...

Le tag *name* existe et il faut au moins un des type d'objet
'type', 'aerialway', 'aeroway', 'amenity', 'barrier', 'boundary', 'building'
, 'craft', 'emergency', 'geological', 'highway', 'historic', 'landuse',
'leisure', 'man_made', 'military', 'natural', 'office', 'place', 'power',
'public_transport', 'railway', 'route', 'shop', 'sport', 'tourism',
'waterway'

Le stest ne vérifie pas que le tag name soit renseigné ou nom mais juste sa
présence.

et en effet si tu mets:
*name=Domaine de Dupont*
*addr:housenumber=1*

*tu auras cette erreur.*

*addr:housename**=Domaine de Dupont*
*addr:housenumber=1*

Ne renvoi pas d'erreur.

* Ca analyse si un objet est nommé et si cet objet est renseigné avec
au moins un tag considéré comme primaire (donc indispensable)*

Le 18 octobre 2014 13:19, Pierre-Yves Berrard  a écrit :

> Le 18 octobre 2014 13:10, Jérôme Seigneuret  a
> écrit :
>
>> Ce que je comprend en lisant ce code c'est que l'erreur s'affiche si
>> 1) name n'est pas renseigné
>> 2) il manque un tag pour le type d'objet : 'type', 'aerialway', 'aeroway'
>> , 'amenity', 'barrier', 'boundary', 'building', 'craft', 'emergency',
>> 'geological', 'highway', 'historic', 'landuse', 'leisure', 'man_made',
>> 'military', 'natural', 'office', 'place', 'power', 'public_transport',
>> 'railway', 'route', 'shop', 'sport', 'tourism', 'waterway'
>> 3) il n'y a pas d'autre erreurs référencés
>>
>
> On a donc potientellement une erreur sur tous les 'addr:housenumber' ?
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Prochain SOTM France en 2015 à ....

[Louis-Julien de la Bouëre]

Bonjour à toutes et tous,

Je suis heureux de vous annoncer que le CA d'OSM-fr a décider 
d'organiser le prochain SOTM France en Bretagne !


Il se déroulera en avril 2015 à Brest !

Je coordonnerai l'organisation de cet évènement. Pour l'instant tout est 
à construire... Voici quelques premiers éléments :


- La thématique des rencontres serait autour d'OSM et Usages ! C'est une 
des spécialités brestoise autour du numérique et ça pourrait être la 
"patte" de cette "édition. A discuter, valider.


- En moins d'une journée, la nouvelle s'est propagée sur Brest : 
différents services de la ville m'ont contacté (internet, stratégie...) 
pour nous apporter leur soutien, puis l'université, certaines 
associations numériques et des discussions aussi autour d'une présence 
de membres du CNN. Bref ça bouge vite.


Je vais travailler avec eux à la question des dates, lieux, détails 
techniques... Si vous avez des suggestions, je prends. je mettrais en 
place les outils pour que cette rencontre soit le plus partagée entre 
nous tous prochainement.


J'aimerai que notre communauté bretonne-grand ouest en profite pour 
mieux se connaitre, travailler ensemble... en gros que nous puissions 
créer du lien sur notre territoire...


En attendant les premiers avancements...

Nous vous invitons toutes et tous sur Brest en avril 2015 !

Merci beaucoup pour vos retours et à très bientôt,

Ken@vo

--
Louis-Julien de la Bouëre
Association Tiriad
ljbou...@tiriad.org
www.tiriad.org
Portable : 06 58 79 80 56
Twitter : @assotiriad
Skype : tiloul29
Instagram : ljbouere29
TumblR : http://ljbouere.tumblr.com/

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

Re: [OSM-talk-fr] Osmose "Missing object kind" sur Piste de ski

[Pierre-Yves Berrard]

Le 18 octobre 2014 13:10, Jérôme Seigneuret  a
écrit :

> Ce que je comprend en lisant ce code c'est que l'erreur s'affiche si
> 1) name n'est pas renseigné
> 2) il manque un tag pour le type d'objet : 'type', 'aerialway', 'aeroway',
> 'amenity', 'barrier', 'boundary', 'building', 'craft', 'emergency',
> 'geological', 'highway', 'historic', 'landuse', 'leisure', 'man_made',
> 'military', 'natural', 'office', 'place', 'power', 'public_transport',
> 'railway', 'route', 'shop', 'sport', 'tourism', 'waterway'
> 3) il n'y a pas d'autre erreurs référencés
>

On a donc potientellement une erreur sur tous les 'addr:housenumber' ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose "Missing object kind" sur Piste de ski

[Jérôme Seigneuret]

Ce que je comprend en lisant ce code c'est que l'erreur s'affiche si
1) name n'est pas renseigné
2) il manque un tag pour le type d'objet : 'type', 'aerialway', 'aeroway',
'amenity', 'barrier', 'boundary', 'building', 'craft', 'emergency',
'geological', 'highway', 'historic', 'landuse', 'leisure', 'man_made',
'military', 'natural', 'office', 'place', 'power', 'public_transport',
'railway', 'route', 'shop', 'sport', 'tourism', 'waterway'
3) il n'y a pas d'autre erreurs référencés

ps: l'internationalisation existe dans tout le code donc c'est largement
envisageable de faire le transfère de traduction
https://github.com/osm-fr/osmose-backend/blob/master/po/fr.po


Le 18 octobre 2014 12:42, Cavok  a écrit :

> En effet l'erreur *Missing object kind *est reportée sur plein d'autres
> objets comme par exemple où il n'y a que des tag name=
> La, on peut comprendre qu'il manque quelque chose.
> Mais sur les piste de ski ou les tags piste:type, piste:difficulty, name
> existent, je ne vois pas ce qu'il pourrait manqué d'obligatoire d’où
> l’incompréhension de cette erreur sur ces objets.
>
> Le 18 octobre 2014 11:30, Yves Pratter  a écrit :
>
>>
>> Le 18 oct. 2014 à 10:02, Jean-Baptiste Holcroft 
>> a écrit :
>>
>>
>> Dans le code, l'erreur serait là :
>>
>> https://github.com/osm-fr/osmose-backend/blob/649db8ac4e642e0fdbf065c1012744e627c8e906/plugins/TagFix_MultipleTag.py#L35
>>
>>
>> J’essai de comprendre le code mais ce n’est pas très clair (en
>> comparaison à d’autres erreurs):
>> Donc si l’objet à l’attribut « name » et que son parent ne serait pas
>> nommé ?? (je ne pige pas la seconde condition)
>>
>> if tags.get("name") and len(key_set & self.name_parent) == 0: err.append
>> ((21101, 1, {}))
>>
>> (si vous parlez des langues étrangères, n'hésitez pas à aider à la
>> traduction d’osmose)
>>
>> Osmose ne semble pas utiliser de bibliothèque de code i18n
>>  (la
>> traduction est faite dans le code source, pas dans des fichiers ressources
>> séparés).
>> Bref ça rend la traduction plus difficile à faire et ça explique
>> peut-être pourquoi certaines erreurs apparaissent dans une langue, mais pas
>> dans une autre… ?
>>
>> La bibliothèque gtext existe en Python :
>> https://docs.python.org/2/library/i18n.html
>>
>> Est-ce que son utilisation à été envisagée ?
>> C’est un gros chantier que de modifier le code source et d’extraire les
>> messages, mais vu l’importance d’Osmose et son utilisation qui semble
>> mondiale, ce travail sera un gain de temps pour le futur.
>> Et avec plein de petites fourmis, il n’est peut-être pas si difficile et
>> long à faire.
>>
>> —
>> Yves
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose "Missing object kind" sur Piste de ski

[Cavok]

En effet l'erreur *Missing object kind *est reportée sur plein d'autres
objets comme par exemple où il n'y a que des tag name=
La, on peut comprendre qu'il manque quelque chose.
Mais sur les piste de ski ou les tags piste:type, piste:difficulty, name
existent, je ne vois pas ce qu'il pourrait manqué d'obligatoire d’où
l’incompréhension de cette erreur sur ces objets.

Le 18 octobre 2014 11:30, Yves Pratter  a écrit :

>
> Le 18 oct. 2014 à 10:02, Jean-Baptiste Holcroft  a
> écrit :
>
>
> Dans le code, l'erreur serait là :
>
> https://github.com/osm-fr/osmose-backend/blob/649db8ac4e642e0fdbf065c1012744e627c8e906/plugins/TagFix_MultipleTag.py#L35
>
>
> J’essai de comprendre le code mais ce n’est pas très clair (en comparaison
> à d’autres erreurs):
> Donc si l’objet à l’attribut « name » et que son parent ne serait pas
> nommé ?? (je ne pige pas la seconde condition)
>
> if tags.get("name") and len(key_set & self.name_parent) == 0: err.append((
> 21101, 1, {}))
>
> (si vous parlez des langues étrangères, n'hésitez pas à aider à la
> traduction d’osmose)
>
> Osmose ne semble pas utiliser de bibliothèque de code i18n
>  (la
> traduction est faite dans le code source, pas dans des fichiers ressources
> séparés).
> Bref ça rend la traduction plus difficile à faire et ça explique peut-être
> pourquoi certaines erreurs apparaissent dans une langue, mais pas dans une
> autre… ?
>
> La bibliothèque gtext existe en Python :
> https://docs.python.org/2/library/i18n.html
>
> Est-ce que son utilisation à été envisagée ?
> C’est un gros chantier que de modifier le code source et d’extraire les
> messages, mais vu l’importance d’Osmose et son utilisation qui semble
> mondiale, ce travail sera un gain de temps pour le futur.
> Et avec plein de petites fourmis, il n’est peut-être pas si difficile et
> long à faire.
>
> —
> Yves
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose "Missing object kind" sur Piste de ski

[Yves Pratter]

Le 18 oct. 2014 à 10:02, Jean-Baptiste Holcroft  a écrit 
:

> 
> Dans le code, l'erreur serait là :
> https://github.com/osm-fr/osmose-backend/blob/649db8ac4e642e0fdbf065c1012744e627c8e906/plugins/TagFix_MultipleTag.py#L35

J’essai de comprendre le code mais ce n’est pas très clair (en comparaison à 
d’autres erreurs):
Donc si l’objet à l’attribut « name » et que son parent ne serait pas nommé ?? 
(je ne pige pas la seconde condition)

if tags.get("name") and len(key_set & self.name_parent) == 0:
err.append((21101, 1, {}))


> (si vous parlez des langues étrangères, n'hésitez pas à aider à la traduction 
> d’osmose)
Osmose ne semble pas utiliser de bibliothèque de code i18n (la traduction est 
faite dans le code source, pas dans des fichiers ressources séparés).
Bref ça rend la traduction plus difficile à faire et ça explique peut-être 
pourquoi certaines erreurs apparaissent dans une langue, mais pas dans une 
autre… ?

La bibliothèque gtext existe en Python : 
https://docs.python.org/2/library/i18n.html

Est-ce que son utilisation à été envisagée ?
C’est un gros chantier que de modifier le code source et d’extraire les 
messages, mais vu l’importance d’Osmose et son utilisation qui semble mondiale, 
ce travail sera un gain de temps pour le futur.
Et avec plein de petites fourmis, il n’est peut-être pas si difficile et long à 
faire.

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

Re: [OSM-talk-fr] Osmose "Missing object kind" sur Piste de ski

[Yves Pratter]

Le 18 oct. 2014 à 10:30, Jean-Baptiste Holcroft  a écrit 
:

> Je trouve que c'est tellement générique que cela n'a pas de sens.
> Mais c'est peut-être la détection d'erreur originale qui veut ça : ratisser 
> large
> On notera que le bug "no translation" est toujours là ... 
> http://trac.openstreetmap.fr/ticket/636
> Et qu'il n'y a pas d'explications sur la page 
> http://wiki.openstreetmap.org/wiki/FR:Osmose/erreurs#2110
+1

Le truc marrant aussi, c’est qu’en affichant la page en anglais, il n’y a pas 
le même nombre d’items.
Je pensais retrouver l’erreur 2110 avec le libellé anglais  "Missing object 
kind », ben non ;-)
J’ai essayé au hasard l’espagnol, je suis tombé sur le 4060 seamark:fixme qui 
n’apparait pas en français ??

Les tags suivants ne sont pas (encore) traduits :

3200No translation 
7150pharmacy, not integrated
8200gas station
8211pharmacy, could be integrated

3033 trait d'union sur Saint
ne devrait-il pas être dans la catégorie rouge Tag name ?

Pour en revenir au fond, j’ai trouvé cette erreur sur un panneau traffic_sign=* 
qui semble bien taggué d’après le wiki : 
http://www.openstreetmap.org/node/2850534213
Peut-être qu’Osmose ratisse trop large ?

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

Re: [OSM-talk-fr] Osmose "Missing object kind" sur Piste de ski

[Jean-Baptiste Holcroft]

Je trouve que c'est tellement générique que cela n'a pas de sens.
Mais c'est peut-être la détection d'erreur originale qui veut ça : ratisser
large
On notera que le bug "no translation" est toujours là ...
http://trac.openstreetmap.fr/ticket/636
Et qu'il n'y a pas d'explications sur la page
http://wiki.openstreetmap.org/wiki/FR:Osmose/erreurs#2110

--
Jean-Baptiste Holcroft

Le 18 octobre 2014 10:23, Damouns  a écrit :

> Pour moi "Missing object kind" ça veut dire :
>
> "genre d'objet manquant" ou "il manque le genre de l'objet"
>
> ou bien on peut remplacer genre par type ou quelque chose dans le genre !
>
> Le 18 octobre 2014 10:02, Jean-Baptiste Holcroft 
> a écrit :
>
> Le libellé de cette erreur ne me semble pas excessivement clair, je n'ai
>> d’ailleurs pas pu le traduire sur Transifex :
>>
>> https://www.transifex.com/projects/p/osmose/translate/#fr/backend/35763040?q=kind
>>
>> Quelqu'un a des suggestions d'améliorations ?
>>
>> Dans le code, l'erreur serait là :
>>
>> https://github.com/osm-fr/osmose-backend/blob/649db8ac4e642e0fdbf065c1012744e627c8e906/plugins/TagFix_MultipleTag.py#L35
>>
>> (si vous parlez des langues étrangères, n'hésitez pas à aider à la
>> traduction d'osmose)
>>
>> --
>> Jean-Baptiste Holcroft
>>
>> Le 18 octobre 2014 09:46, Yves  a écrit :
>>
>>> J'imagine qu' Osmose attend un tag physique du genre highway=xx.
>>> Comme les pistes de ski sont par leur nature un peu moins 'dures' que
>>> ça, je suppose que cette analyse devrait s'assurer la présence d'au moins
>>> le tag piste:type=xx.
>>> Yves
>>>
>>> Le 18 octobre 2014 09:37:01 CEST, PhQ  a écrit :

 Bonjour,

 et si un distingué angliciste pouvait simplement m'expliquer ce que veut
 dire :
 "Missing object kind"

 (signé) un ex élève en anglais de Maitre Capello

 avec l’entièreté de ma Cordialitude
 :)



 --
 View this message in context: 
 http://gis.19327.n5.nabble.com/Osmose-Missing-object-kind-sur-Piste-de-ski-tp5820689p5820699.html
 Sent from the France mailing list archive at Nabble.com.

 --

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


>>> --
>>> Yves
>>> From my phone
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose "Missing object kind" sur Piste de ski

[Damouns]

Pour moi "Missing object kind" ça veut dire :

"genre d'objet manquant" ou "il manque le genre de l'objet"

ou bien on peut remplacer genre par type ou quelque chose dans le genre !

Le 18 octobre 2014 10:02, Jean-Baptiste Holcroft  a
écrit :

> Le libellé de cette erreur ne me semble pas excessivement clair, je n'ai
> d'ailleurs pas pu le traduire sur Transifex :
>
> https://www.transifex.com/projects/p/osmose/translate/#fr/backend/35763040?q=kind
>
> Quelqu'un a des suggestions d'améliorations ?
>
> Dans le code, l'erreur serait là :
>
> https://github.com/osm-fr/osmose-backend/blob/649db8ac4e642e0fdbf065c1012744e627c8e906/plugins/TagFix_MultipleTag.py#L35
>
> (si vous parlez des langues étrangères, n'hésitez pas à aider à la
> traduction d'osmose)
>
> --
> Jean-Baptiste Holcroft
>
> Le 18 octobre 2014 09:46, Yves  a écrit :
>
>> J'imagine qu' Osmose attend un tag physique du genre highway=xx.
>> Comme les pistes de ski sont par leur nature un peu moins 'dures' que ça,
>> je suppose que cette analyse devrait s'assurer la présence d'au moins le
>> tag piste:type=xx.
>> Yves
>>
>> Le 18 octobre 2014 09:37:01 CEST, PhQ  a écrit :
>>>
>>> Bonjour,
>>>
>>> et si un distingué angliciste pouvait simplement m'expliquer ce que veut
>>> dire :
>>> "Missing object kind"
>>>
>>> (signé) un ex élève en anglais de Maitre Capello
>>>
>>> avec l'entièreté de ma Cordialitude
>>> :)
>>>
>>>
>>>
>>> --
>>> View this message in context: 
>>> http://gis.19327.n5.nabble.com/Osmose-Missing-object-kind-sur-Piste-de-ski-tp5820689p5820699.html
>>> Sent from the France mailing list archive at Nabble.com.
>>>
>>> --
>>>
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>> --
>> Yves
>> From my phone
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose "Missing object kind" sur Piste de ski

[Jean-Baptiste Holcroft]

Le libellé de cette erreur ne me semble pas excessivement clair, je n'ai
d’ailleurs pas pu le traduire sur Transifex :
https://www.transifex.com/projects/p/osmose/translate/#fr/backend/35763040?q=kind

Quelqu'un a des suggestions d'améliorations ?

Dans le code, l'erreur serait là :
https://github.com/osm-fr/osmose-backend/blob/649db8ac4e642e0fdbf065c1012744e627c8e906/plugins/TagFix_MultipleTag.py#L35

(si vous parlez des langues étrangères, n'hésitez pas à aider à la
traduction d'osmose)

--
Jean-Baptiste Holcroft

Le 18 octobre 2014 09:46, Yves  a écrit :

> J'imagine qu' Osmose attend un tag physique du genre highway=xx.
> Comme les pistes de ski sont par leur nature un peu moins 'dures' que ça,
> je suppose que cette analyse devrait s'assurer la présence d'au moins le
> tag piste:type=xx.
> Yves
>
> Le 18 octobre 2014 09:37:01 CEST, PhQ  a écrit :
>>
>> Bonjour,
>>
>> et si un distingué angliciste pouvait simplement m'expliquer ce que veut
>> dire :
>> "Missing object kind"
>>
>> (signé) un ex élève en anglais de Maitre Capello
>>
>> avec l’entièreté de ma Cordialitude
>> :)
>>
>>
>>
>> --
>> View this message in context: 
>> http://gis.19327.n5.nabble.com/Osmose-Missing-object-kind-sur-Piste-de-ski-tp5820689p5820699.html
>> Sent from the France mailing list archive at Nabble.com.
>>
>> --
>>
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
> --
> Yves
> From my phone
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose "Missing object kind" sur Piste de ski

[Yves]

J'imagine qu' Osmose attend un tag physique du genre highway=xx.
Comme les pistes de ski sont par leur nature un peu moins 'dures' que ça, je 
suppose que cette analyse devrait s'assurer la présence d'au moins le tag 
piste:type=xx.
Yves

Le 18 octobre 2014 09:37:01 CEST, PhQ  a écrit :
>Bonjour,
>
>et si un distingué angliciste pouvait simplement m'expliquer ce que
>veut
>dire :
>"Missing object kind"
>
>(signé) un ex élève en anglais de Maitre Capello 
>
>avec l’entièreté de ma Cordialitude
>:)
>
>
>
>--
>View this message in context:
>http://gis.19327.n5.nabble.com/Osmose-Missing-object-kind-sur-Piste-de-ski-tp5820689p5820699.html
>Sent from the France mailing list archive at Nabble.com.
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Yves
>From my phone___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose "Missing object kind" sur Piste de ski

[PhQ]

Bonjour,

et si un distingué angliciste pouvait simplement m'expliquer ce que veut
dire :
"Missing object kind"

(signé) un ex élève en anglais de Maitre Capello 

avec l’entièreté de ma Cordialitude
:)



--
View this message in context: 
http://gis.19327.n5.nabble.com/Osmose-Missing-object-kind-sur-Piste-de-ski-tp5820689p5820699.html
Sent from the France mailing list archive at Nabble.com.

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