date:20141011


Le 10/10/2014 11:02, Nicolas Moyroud a écrit :





- un m à la fin n'est tout simplement pas une erreur, c'est juste
l'unité par défaut.

Non. Même si le wiki ne dit pas explicitement que c'est une erreur,
tout le suggère : http://wiki.openstreetmap.org/wiki/Key:ele
«Elevation of a point in metres in WGS84.» Voir aussi les exemples cités.
On ne met pas capacity=10 places
JB.


Tout à fait d'accord. En plus l'erreur osmose s'appelle "valeur
numérique". Une lettre représentant une unité n'a donc rien à y faire.


Voilà c'est à jour :

http://osmose.openstreetmap.fr/fr/errors/?country=france_languedoc_roussillon&item=3091

Par contre ça autorise toujours une unité (c'est même le propre de cette 
analyse)

https://github.com/osm-fr/osmose-backend/blob/master/plugins/Number.py

Tu peux voir le détail des tags d'un objet en erreur en cliquant sur le 
E, mais je pense que ça ne va pas t'aider plus que ça


Frédéric.


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

Re: [OSM-talk-fr] Osmose : erreur de commune pour le géocodage d'un Monument historique non intégré


Le 07/10/2014 18:50, Yves Pratter a écrit :

Bonsoir,

Le château de Malans
 est proposé en
intégration par Osmose sur la commune de Malans dans le Doubs
,
alors qu’il s’agit de Malans dans la Haute-Sâone
.
Fiche méritée PA00102218


Est-ce un problème de données ou un bogue dans Osmose ?


En entre les deux. Les monuments ont été géocodé en 2012 avec nominatime 
(donc données OSM). Il faudrait refaire le géocodage ou refaire le point 
sur les données données disponible aujourd'hui sur le sujet.



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

Re: [OSM-talk-fr] [Nouveau sur la liste] Bonjour à tous !

2014-10-11 Par sujet Jo

Salut Frem, rebienvenu!
On Oct 10, 2014 3:07 PM, "frem"  wrote:

> Je me présnete : frem (frem-eu sur osm), actif en région Poitou-Charentes,
> avec qqes années de contributions derrière moi (depuis 2008).
>
> J’ai recommencé à contribuer de façon plus active et je vous rejoins pour
> discuter des problématique encore non-résolues et du projet en général.
>
> À bientôt
>
> frem
>
> ___
> 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] Géocacheurs...

2014-10-11 Par sujet Seb

Salut,

Nouveau sur la liste, j'habite prés de Libourne, contributions OSM
locales autour de chez moi.

Je confirme geocaching et OSM font bon ménage. J'ai commencé par le
geocaching.
Les Geocacheurs ont leur GPS allumé tout le temps et je voulais que mes
traces servent à quelque chose. J'ai découvert OSM qui me permet :
- de mieux préparer mes sorties Geocaching en étudiant la carte
existante

- de trouver des nouveaux spots pour placer des caches.
- de rajouter une activité en "en route" entre la voiture et la cache.

Une promotion par objets voyageur est une bonne idée car chaque objet à
une "mission" = une page web que chaque géocacheur consulte à le
découverte de l'objet. Sur ces pages il est possible de déposer une
description de OSM et liens vers plus d'info. La mission peut même être
"rajouter un chemin ou un tag sur OSM..."

Laudge

On 2014-10-07 19:56, Eric Debeau wrote:

Salut

Je suis aussi un peu loin aussi.

C'est vrai que ce serait une bonne idée de créer des objets
voyageurs "OSM".

Bon courage et bonne promo de OSM.

Eric

2014-10-07 19:14 GMT+02:00 Sylvain Maillard
:

Salut,

un peu loin également ce week-end ...

bon courage pour les innombrables questions ;)

Sylvain

Le 7 octobre 2014 16:35, Yves Pratter a
écrit :

Le 7 oct. 2014 à 16:18, Christian Quest a
écrit :

Je n'ai eu aucun retour pour cet évènement qui se déroulera ce
week-end.Je suis trop loin géographiquement mais le coeur y est :-)

Je pense que c'est un belle opportunité à saisir pour faire venir
à OSM des géocacheurs, mais à moi tout seul je vais avoir un peu
de mal à assurer le week-end !As-tu pensé à mettre des goodies
dans les géocaches ?

Pour ceux qui ne sont pas « initiés », les organisateurs d’un
rassemblement de géocacheurs mettent des petits cadeaux/souvenirs
pour les FTF (first to find) dans les nouvelles caches.
Ça peut être un pins, badge… il suffit que ça tienne dans la
boite ;-)

Il est aussi possible de mettre des objets plus « précieux » et
particuliers : les « objets voyageurs » (travel bug) ou des «
géo-monnaies » (geocoin).
Ceux-ci sont souvent offerts au FTF lors des rassemblement. De
toutes façon, ils sont destinés à voyager. On peut ainsi voir
leurs trajets sur une carte (OSM ;-)

Le « top » et d’en faire réaliser des personnalisé pour
l’occasion ou pour promouvoir une cause (lutte contre le
diabète… et au hasard : OSM).

Quelques exemples : « simples [1] » « sophistiqués [2] »… il
n’y a pas de limites !

—
Yves

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

___
Talk-fr mailing list

Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr [3]

Links:
--
[1]
http://www.cache-aventure.com/epages/box13593.sf/fr_FR/?ObjectPath=/Shops/box13593/Categories/GEOCOINS/micro_geocoins
[2]
http://www.cache-aventure.com/epages/box13593.sf/fr_FR/?ObjectPath=/Shops/box13593/Categories/GEOCOINS/geocoins_navigation
[3] 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] Intégration des pharmacies en France avec Osmose


Bonjour,

L'entreprise Celtipharm à mise à disposition son recensement des 
pharmacies en France. Les données ont été collectées sur le terrain 
depuis 2000. Il y a donc près de 14 ans de métier ;) dans ces données. 
Ils ont été séduit par OSM et y voient une opportunité de moderniser 
leur système d'information avec une publication en OpenData sous licence 
ODbL.


Après un test et des retours sur leurs données, l'intégration est 
maintenant possible sur Osmose :


http://osmose.openstreetmap.fr/fr/errors/?source=7406&item=

Pharmacies dans OSM sans référence ref:FR:FINESS :
http://osmose.openstreetmap.fr/fr/map/#item=7150

Pharmacie non intégré, en OpenData mais référence non retrouvé dans OSM
http://osmose.openstreetmap.fr/fr/map/#item=8210

Proposition de rapprochement entre l'OpenData et l'OSM :
http://osmose.openstreetmap.fr/fr/map/#item=8211

Le travail préliminaire à cette intégration à Osmose à soulevé des 
questions sur la liste CA, que je vous livres dans un soucie de 
transparence :


- le tag type:FR:FINESS est aussi utilisé 216 fois. Désolé, mais là par 
contre je ne vois pas l'intérêt de mettre ça dans OSM. On a déjà des 
tags pour mettre en correspondance de ces numéros. Sauf si le type fait 
partie de l'identifiant, mais dans ce cas il ne faudrait pas un tag 
séparé. Il y a même une page sur le wiki : 
http://wiki.openstreetmap.org/wiki/FR:Key:type:FR:FINESS [moi]


- Le problème, c'est que ces intégrations osmose ne sont pas
documentées depuis osmose et très mal dans le wiki et qu'il y a en a
de plus en plus. D'ailleurs, le fait même que cette discussion se
passe sur la liste ca@ et non sur la liste talk-fr@ est aussi
symptomatique. [Pieren]

- Je serais d'ailleurs curieux de connaitre la réaction à la demande 
d'ajouter… 9000 ? tag ref:FR:FINESS pour une valeur ajoutée… légère ? 
d'un point de vue contributeur/réutilisateur basique ?
J'ai encore du mal avec ces rapprochements de bdd séparées uniquement à 
l'aide d'un identifiant unique, alors qu'avec une position géographique, 
un nom, une adresse, on doit pouvoir rapprocher la quasi-totalité des 
existantes dans OSM (du moins sur l'échantillon représentatif d'une 
dizaine regardée du coté de Troyes). On parle de pharmacies, pas 
d'arbres ou de batiments, quand même…

Bon, non, j'ai pas les doigts dans le code. [JB]

Frédéric.

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

Re: [OSM-talk-fr] Prix des carburants ?


Le 10 oct. 2014 à 23:38, Frédéric Rodrigo  a écrit :

> L'analyse est donc maintenant disponible et avec plus de tags supportés.
Merci :-)

> Si vous être curieux de voir la mapping de tags c'est là :
> 
> https://github.com/osm-fr/osmose-backend/blob/2cd5c8238124c405a98e78052a015b0ce1e7172e/analysers/analyser_merge_fuel_FR.py

opening_hours=* n’est traité pour le moment que dans le cas de l’ouverture 
24h/24 et 7j/7

Je vais essayer de traiter les autres cas. Comme je n’ai pas accès au serveur, 
je vais remplir à la main les valeur de debut, fin et saufjour.
Est-ce qu’elles restent telles que dans le fichier xml ou reformates-tu leur 
contenu ? 

res["debut"] = ’07:00’
res["fin"] = ’20:00’
res["saufjour"] = ‘Samedi;Dimanche’


>> J’ai vu que tu ne proposes pas d’attribut ref.
> Il y en a un, mais ne sachant pas à quoi il correspond, mais je ne l'ai pas 
> prit.
Ben, c’est un identifiant unique utilisé par la DGCCRF ?

Il est utilisé dans le code HTML des pages du site du ministère :  
http://www.prix-carburants.economie.gouv.fr/recherche/

Exemple :
STATION AVIA - GARAGE BEUCLER
Avia 
82 Rue du Général de Gaulle
25420 BART

https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Intégration des pharmacies en France avec Osmose

> Date: Sat, 11 Oct 2014 12:25:33 +0200
> From: fred.rodr...@gmail.com
> To: talk-fr@openstreetmap.org
> Subject: [OSM-talk-fr] Intégration des pharmacies en France avec Osmose
> 
> Bonjour,
> 
> L'entreprise Celtipharm a mise à disposition son recensement des 
> pharmacies en France. Les données ont été collectées sur le terrain 
> depuis 2000. Il y a donc près de 14 ans de métier ;) dans ces données. 
> Ils ont été séduits par OSM et y voient une opportunité de moderniser 
> leur système d'information avec une publication en OpenData sous licence 
> ODbL.
> 
> Après un test et des retours sur leurs données, l'intégration est 
> maintenant possible sur Osmose :
Bonjour Frédéric,J'ai reçu ton annonce en même temps qu'une de ces erreurs via 
RSS alors j'ai jeté un oeil. J'ai plusieurs remarques :
- Le géocodage est bizarre, le marqueur n'est pas situé sur ou à proximité du 
point adresse dans OSM mais sur la rue correspondante, et même pas au droit de 
l'adresse.- ref:FR:FINESS c'est quoi ? le Wiki OSM ne connait pas.- Toutes les 
erreurs Intégration portent un tag name rempli, par défaut avec le nom du 
propriétaire. 1) Ça ne correspond pratiquement jamais avec ce qu'on peut lire 
sur le terrain. 2) Le nom de famille est parfois répété 3) Le nom est en 
majuscules, j'ai souvenir que ce n'est pas correct du point de vue des 
conventions typographiques. Pour moi, name doit contenir le nom vu sur le 
terrain en devanture, pas le nom professionnel utilisé dans les déclarations 
administratives.- J'ai des propositions d'intégration pour des pharmacies déjà 
présentes avec ou pas le nom identique à la proposition d'intégration.
Exemple sur un quartier qui contient 4 pharmacies : 
http://osmose.openstreetmap.fr/fr/map/#item=8210&zoom=18&lat=48.845012&lon=2.40489&layer=Mapnik&overlays=FFFT&bbox=2.402781844139099%2C48.84406629555003%2C2.408929467201233%2C48.84597266461056&level=3&tags=&fixable=
4 propositions d'intégrations, 3 pharmacies déjà présentes. Dans les 4 cas, les 
points adresse existent mais ne sont pas utilisés pour placer les marqueurs. 2 
proposent un tag name rempli avec le nom du pharmacien (Diaz et Haddad) mais 
qui n'est pas le nom affiché sur la devanture. 1 propose un tag name "Pharmacie 
CENTRALE SAINT MANDE" alors que la devanture indique seulement Pharmacie.
George___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Prix des carburants ?


Le 11/10/2014 12:26, Yves Pratter a écrit :


Le 10 oct. 2014 à 23:38, Frédéric Rodrigo mailto:fred.rodr...@gmail.com>> a écrit :


L'analyse est donc maintenant disponible et avec plus de tags supportés.

Merci :-)


Si vous être curieux de voir la mapping de tags c'est là :

https://github.com/osm-fr/osmose-backend/blob/2cd5c8238124c405a98e78052a015b0ce1e7172e/analysers/analyser_merge_fuel_FR.py


opening_hours=* n’est traité pour le moment que dans le cas de
l’ouverture 24h/24 et 7j/7

Je vais essayer de traiter les autres cas. Comme je n’ai pas accès au
serveur, je vais remplir à la main les valeur de debut, fin et saufjour.
Est-ce qu’elles restent telles que dans le fichier xml ou reformates-tu
leur contenu ?

res["debut"]= ’07:00’
res["fin"]= ’*20:00*’
res["saufjour"] = ‘*Samedi;Dimanche*’


Comme déjà dit je pense que l'on ne peut que accorder qu'un confiance 
limité en ça.

Ça produit un tag osm opening_hours, c'est con son format :
http://wiki.openstreetmap.org/wiki/Key:opening_hours

Je ne suis pas trop pour intégrer des données peu fiable et inmaintenable.


J’ai vu que tu ne proposes pas d’attribut ref.

Il y en a un, mais ne sachant pas à quoi il correspond, mais je ne
l'ai pas prit.

Ben, c’est un identifiant unique utilisé par la DGCCRF ?

Il est utilisé dans le code HTML des pages du site du ministère :
http://www.prix-carburants.economie.gouv.fr/recherche/

Exemple :
STATION AVIA - GARAGE BEUCLER
Avia
82 Rue du Général de Gaulle
25420 BART



Pour c'est juste un identifiant interne et pas de référence.


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

[OSM-talk-fr] [Osmose] Analyse sur la voirie en forêt

Bonjour,
Je profite qu'Osmose soit le sujet de cette liste en ce moment pour proposer 2 
analyses sur la voirie en forêt. Ça fait suite à des cas que j'ai souvent 
rencontrés :
1) Nom de carrefourDans les forêts, repérer les noeuds à l'intersection de ways 
highway=* et portant uniquement un tag name=*. Proposer de rajouter 
junction=yes avec comme message à l'utilisateur : "Junction=yes manquant pour 
le nom du carrefour".
2) Abréviation de Route ForestièreDans les forêts, repérer les ways highway=* 
avec name="RF *" et proposer à l'utilisateur de changer ce name en "Route 
forestière *"

Des remarques, des avis sur ces analyses ?
George
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Intégration des pharmacies en France avec Osmose


Le 11/10/2014 13:25, George Kaplan a écrit :

 > Date: Sat, 11 Oct 2014 12:25:33 +0200 > From: fred.rodr...@gmail.com
 > To: talk-fr@openstreetmap.org > Subject: [OSM-talk-fr] Intégration
des pharmacies en France avec Osmose > > Bonjour, > > L'entreprise

[bougiboulga]

devanture indique seulement Pharmacie. George


Si les données étaient parfaite on le importeraient. Là on les intègre à 
la main une par une. C'est justement parce qu'il y a des ajustement à 
faire et un besoin de discernement humain.


Frédéric.


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

Re: [OSM-talk-fr] [Osmose] Analyse sur la voirie en forêt


Le 11/10/2014 13:35, George Kaplan a écrit :

Bonjour,
Je profite qu'Osmose soit le sujet de cette liste en ce moment pour proposer 2 
analyses sur la voirie en forêt. Ça fait suite à des cas que j'ai souvent 
rencontrés :
1) Nom de carrefourDans les forêts, repérer les noeuds à l'intersection de ways highway=* 
et portant uniquement un tag name=*. Proposer de rajouter junction=yes avec comme message 
à l'utilisateur : "Junction=yes manquant pour le nom du carrefour".
2) Abréviation de Route ForestièreDans les forêts, repérer les ways highway=* avec name="RF 
*" et proposer à l'utilisateur de changer ce name en "Route forestière *"

Des remarques, des avis sur ces analyses ?
George  


C'est tout a fait sensé et réalisable.

Tu peux, si possible et s'il te plait, créer ces demandes sur 
https://github.com/osm-fr/osmose-backend/issues

Pour un meilleur suivit.
Merci.
Frédéric.


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

Re: [OSM-talk-fr] [Osmose] Analyse sur la voirie en forêt

Le 11 oct. 2014 à 13:40, Frédéric Rodrigo  a écrit :

> C'est tout a fait sensé et réalisable.
> 
> Tu peux, si possible et s'il te plait, créer ces demandes sur 
> https://github.com/osm-fr/osmose-backend/issues
> Pour un meilleur suivit.
> Merci.
> Frédéric.

C'est fait. J'ai aussi au passage arrêter d'utiliser la joueuse interface 
d'Hotmail qui fait sauter les retours à la ligne de mes messages.

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

Re: [OSM-talk-fr] Intégration des pharmacies en France avec Osmose

Renvoyé pour la lisibilité.

Le 11 oct. 2014 à 12:25, Frédéric Rodrigo  a écrit :

> Bonjour,
> 
> L'entreprise Celtipharm à mise à disposition son recensement des pharmacies 
> en France. Les données ont été collectées sur le terrain depuis 2000. Il y a 
> donc près de 14 ans de métier ;) dans ces données. Ils ont été séduit par OSM 
> et y voient une opportunité de moderniser leur système d'information avec une 
> publication en OpenData sous licence ODbL.
> 
> Après un test et des retours sur leurs données, l'intégration est maintenant 
> possible sur Osmose :

Bonjour Frédéric,

J'ai reçu ton annonce en même temps qu'une de ces erreurs via RSS alors j'ai 
jeté un oeil. J'ai plusieurs remarques : 

- Le géocodage est bizarre, le marqueur n'est pas situé sur ou à proximité du 
point adresse dans OSM mais sur la rue correspondante, et même pas au droit de 
l'adresse.
-  ref:FR:FINESS c'est quoi ? le Wiki OSM ne connait pas.
- Toutes les erreurs Intégration portent un tag name rempli, par défaut avec le 
nom du propriétaire. 1) Ça ne correspond pratiquement jamais avec ce qu'on peut 
lire sur le terrain. 2) Le nom de famille est parfois répété 3) Le nom est en 
majuscules, j'ai souvenir que ce n'est pas correct du point de vue des 
conventions typographiques. Pour moi, name doit contenir le  nom vu sur le 
terrain en devanture, pas le nom professionnel utilisé dans les déclarations 
administratives.
- J'ai des propositions d'intégration pour des pharmacies déjà présentes avec 
ou pas le nom identique à la proposition d'intégration.

Exemple sur un quartier qui contient 4 pharmacies : 
http://osmose.openstreetmap.fr/fr/map/&item=8210&zoom=18&lat=48.845012&lon=2.40489&layer=Mapnik&overlays=FFFT&bbox=2.402781844139099%2C48.84406629555003%2C2.408929467201233%2C48.84597266461056&level=3&tags=&fixable=
  

4 propositions d'intégrations, 3 pharmacies déjà présentes.
Dans les 4 cas, les points adresse existent mais ne sont pas utilisés pour 
placer les marqueurs.
2 proposent un tag name rempli avec le nom du pharmacien (Diaz et Haddad) mais 
qui n'est pas le nom affiché sur la devanture.
1 propose un tag name "Pharmacie CENTRALE SAINT MANDE" alors que la devanture 
indique seulement Pharmacie.


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

Re: [OSM-talk-fr] Intégration des pharmacies en France avec Osmose


Le 11/10/2014 13:59, George Kaplan a écrit :

Renvoyé pour la lisibilité.
J'ai reçu ton annonce en même temps qu'une de ces erreurs via RSS alors j'ai 
jeté un oeil. J'ai plusieurs remarques :

- Le géocodage est bizarre, le marqueur n'est pas situé sur ou à proximité du 
point adresse dans OSM mais sur la rue correspondante, et même pas au droit de 
l'adresse.
Le coordonnées sont fourni en OpenData, ce n'est pas un géocoage base 
sur OSM.



-  ref:FR:FINESS c'est quoi ? le Wiki OSM ne connait pas.

Si, si le wiki connait.
http://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FINESS


- Toutes les erreurs Intégration portent un tag name rempli, par défaut avec le 
nom du propriétaire. 1) Ça ne correspond pratiquement jamais avec ce qu'on peut 
lire sur le terrain. 2) Le nom de famille est parfois répété 3) Le nom est en 
majuscules, j'ai souvenir que ce n'est pas correct du point de vue des 
conventions typographiques. Pour moi, name doit contenir le  nom vu sur le 
terrain en devanture, pas le nom professionnel utilisé dans les déclarations 
administratives.
- J'ai des propositions d'intégration pour des pharmacies déjà présentes avec 
ou pas le nom identique à la proposition d'intégration.

Oui, il faut ajuster à la main lors de l'intégration.


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

Re: [OSM-talk-fr] Intégration des pharmacies en France avec Osmose

2014-10-11 Par sujet Pierre-Yves Berrard

Le 11 octobre 2014 12:25, Frédéric Rodrigo  a écrit
:

>
> - le tag type:FR:FINESS est aussi utilisé 216 fois. Désolé, mais là par
> contre je ne vois pas l'intérêt de mettre ça dans OSM. On a déjà des tags
> pour mettre en correspondance de ces numéros. Sauf si le type fait partie
> de l'identifiant, mais dans ce cas il ne faudrait pas un tag séparé. Il y a
> même une page sur le wiki : http://wiki.openstreetmap.org/
> wiki/FR:Key:type:FR:FINESS [moi]
>

Tout d'abord, l'argument du nombre d'occurences n'est pas pertinent. Pour
n'importe quel tag, on peut toujours trouver un moment où le nombre
d'occurences était faible...

Personnellement, j'ajoute le tag ref:FR:FINESS quand je peux. Cela permet
d'ajouter de l'information à peu de frais sur certains établissements de
soins, pour lesquels les tags osm ne sont pas assez riches
(social_facility=* et social_facility:for=* ne suffisent souvent pas à
décrire précisément la fonction d'un établissement). Je l'ajoute aussi pour
les pharmacies, même si effectivement, tout le monde comprend bien la
fonction d'une pharmacie.

(et juste pour comprendre la logique : pourquoi considérer que ce tag n'a
pas sa place alors que ref:FR:LaPoste, ref:UAI font l'objet d'analyse
d'absence dans osmose ?)

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

Re: [OSM-talk-fr] Intégration des pharmacies en France avec Osmose


Le 11/10/2014 14:34, Pierre-Yves Berrard a écrit :

Le 11 octobre 2014 12:25, Frédéric Rodrigo mailto:fred.rodr...@gmail.com>> a écrit :


- le tag type:FR:FINESS est aussi utilisé 216 fois. Désolé, mais là
par contre je ne vois pas l'intérêt de mettre ça dans OSM. On a déjà
des tags pour mettre en correspondance de ces numéros. Sauf si le
type fait partie de l'identifiant, mais dans ce cas il ne faudrait
pas un tag séparé. Il y a même une page sur le wiki :
http://wiki.openstreetmap.org/__wiki/FR:Key:type:FR:FINESS
 [moi]


Tout d'abord, l'argument du nombre d'occurences n'est pas pertinent.
Pour n'importe quel tag, on peut toujours trouver un moment où le nombre
d'occurences était faible...

Personnellement, j'ajoute le tag ref:FR:FINESS quand je peux. Cela
permet d'ajouter de l'information à peu de frais sur certains
établissements de soins, pour lesquels les tags osm ne sont pas assez
riches (social_facility=* et social_facility:for=* ne suffisent souvent
pas à décrire précisément la fonction d'un établissement). Je l'ajoute
aussi pour les pharmacies, même si effectivement, tout le monde comprend
bien la fonction d'une pharmacie.

(et juste pour comprendre la logique : pourquoi considérer que ce tag
n'a pas sa place alors que ref:FR:LaPoste, ref:UAI font l'objet
d'analyse d'absence dans osmose ?)

PY


La comptage n'est qu'une constant.
Attention la question pour sur type:FR:FINESS et non ref:FR:FINESS.


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

Re: [OSM-talk-fr] Intégration des pharmacies en France avec Osmose

2014-10-11 Par sujet Pierre-Yves Berrard

Le 11 octobre 2014 14:56, Frédéric Rodrigo  a écrit
:

Attention la question pour sur type:FR:FINESS et non ref:FR:FINESS.
>
> Désolé, j'ai lu trop vite.

Donc effectivement pour une pharmacie c'est peu probant car toutes les
pharmacies auront le même type:FR:FINESS.
En revanche, pour d'autres établissements sociaux ou sanitaires très
spécialisés, je maintiens une certaine valeur ajoutée ;-)

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

[OSM-talk-fr] Pertes de contrôle du clavier : anomalie trop fréquente de JOSM

2014-10-11 Par sujet Philippe Verdy

De plus en plus souvent je constate des pertes inopinées de contrôle du
clavier ou de la souris dans JOSM; rendant l'interface inopérante.

Par exemple :
-  les touches + et - (qu'on les tape sur le pavé numérique ou le clavier
alpha) du zoom cessent de répondre (dans ce cas aussi cela ne marche plus
non plus avec le menu ni un raccourci posé sur une icone de la barre
d'icones (c'est le cas le plus fréquent) Et pourtant le zoom sur la
sélection fonctionne encore et le zoom avec + ou - dans le dialogue de
téléchargement d'une zone fonctionne encore.

- quand on ouvre un dialogue; le focus sur le champ de saisie ne fonctionne
pas et impossible de taper un texte dedans parfois aussi la sélection à la
souris d'un morceau du texte ne marche plus (en revanche les autres
boutons, y compris le triangle du sélecteur d'une combobox) fonctionne
encore. La fermeture du dialogue et sa réouverture suffit parfois à
rétablir la fonction; mais pas toujours...

- la suppression et le remise d'une icone de raccourci sur la barre d'icone
fonctionne, mais le bouton ne produit toujours rien quand on clique dessus.

Il semble qu'il y a un bogue dans la bibliothèque qui gère les "bindings"
attachant des événements clavier ou souris à un gestionnaire d'événement;
comme si le gestionnaire avait été perdu par perte de référence (allocation
en "weak pointer" et effet du garbage collector, ou mauvaise
synchronisation de l'ordre des événements en cas de modification dynamique
de la liste des bindings (modification non atomique, comme si la
suppression de référence au gestionnaire d'événement dans une liste de
gestionnaires a eu lieu *avant* l'insertion de ce même gestionnaire dans
une autreliste pour un autre élément d'interface utilisateur).

Je me demande si c'est un bogue de JOSM lui-même ou d'une de ses
bibliothéques de construction d'UI; ou si la modification dyna,ique de
l'interface a oublié de mettre un verrou entre plusieurs threads faisant
des modifications concurrentes de l'UI (par exemple un thread s'occupant de
la construction d'un nouveau dialogue tandis qu'un autre thread s'occupe
encore de celui de la fenêtre principale; ou bien l'événement à réassigner
est encore en cours de traitement par le thread principal qui gère la liste
ordonnée des événements UI et synchronise les rafraichissements écran).


Seule parade : sauver les modifs en cours dans un fichier local, fermer
JOSM et le relancer pour charger le fichier à nouveau. Mais à je suis tombé
sur un cas où c'était la fonction sauvegarder qui ne fonctionnait plus
aussi bien au clavier (CTRL+S), qu'à la souris en cliquant l'icone de la
barre d'icones ou par le menu fichier.

C'est de plus en plus gênant car l'anomalie se reproduit de plus en plus
souvent et aboutit à des pertes de modifs en cours (très gênant quand on a
eu besoin de charger beaucoup de données et vérifier des jeux compliqués de
relations interdépendantes, comme la vérification des cours d'eau, des
lignes de bus, vérifier le routage, refermer les trous dans des relations
(par exemple par ceux qui remplacent sans faire attention des routes ou
transforment un carrefour simple en rond-point tracé n'importe comment et
ne tenant pas compte de l'existant qui s'y connecte (ceux-là ne connaissent
pas CTRL+ALT+D dans JOSM et sont totalement perdus dans iD qui presque tout
le temps fait n'importe quoi et est très peu utiisable pour autre chose que
d'ajouter des tags ou faire un tracé sommaire ou ajouter un POI ou affiner
le tracé existant; mais pas pour transformer des objets: d'ailleurs les
mêmes beaucoup trop souvent ne s'embarassent pas de transformer l'existant,
ils retracent et suppri,ent tout ce qui les gêne et ne fait doublon qu'avec
leur nouveau tracé, ou qui passe une route simple bidirectionnelle en
routes à deux voies unidirectionnelles séparées et oublient de router la
ligne de bus en sens inverse qui passait par la première voie laissée mais
devenue sens unique; créant des routes impossibles).

D'une façon générale JOSM a de plus en plus souvent des soucis de
rafraichissement partiel de l'écran et semble souffrir de bogue de
synchronisation entre ses threads de plus en plus nombreux (chez moi la
moindre session prend maintenant plus de 400 threads parallèles, alors que
j'tilise un jeu très réduit de plugins parmi les plus "stables".

Je détecte cette anomalie depuis début août, mais cela s'aggrave maintenant

Note: je suis toujours à jour des versions, je lance JOSM par JNLP sur la
dernière version en release stable. Et ceci quelque soit le PC utilisé
(sous Windows 7 ou 8.1); avec la dernière versions stable de Java (en
version "Hotspot Server VM" 64 bits en Java 6 ou 7; pas la version 32 bits
qui limite trop la mémoire maxi utilisée alors que j'ai beaucoup de
mémoire, et sollicite énormément le garbage collector ce qui fait des
pauses beaucoup trop souvent, en 64 bits mes VM Java montent sans problème
à 2 gigas, et le garbage collector utilise des threads en arrière-plan qui
ne font jamais aucune pau

Re: [OSM-talk-fr] Pertes de contrôle du clavier : anomalie trop fréquente de JOSM

2014-10-11 Par sujet Jean-Baptiste Holcroft

C'est long, mais j'ai le même, mais ça se provoque de manière aléatoire et
sauvegarder son travail devient ridiculement compliqué.
Pour moi ça apparaît avec le plugin cadastre.
Le 11 oct. 2014 16:11, "Philippe Verdy"  a écrit :

>
> De plus en plus souvent je constate des pertes inopinées de contrôle du
> clavier ou de la souris dans JOSM; rendant l'interface inopérante.
>
> Par exemple :
> -  les touches + et - (qu'on les tape sur le pavé numérique ou le clavier
> alpha) du zoom cessent de répondre (dans ce cas aussi cela ne marche plus
> non plus avec le menu ni un raccourci posé sur une icone de la barre
> d'icones (c'est le cas le plus fréquent) Et pourtant le zoom sur la
> sélection fonctionne encore et le zoom avec + ou - dans le dialogue de
> téléchargement d'une zone fonctionne encore.
>
> - quand on ouvre un dialogue; le focus sur le champ de saisie ne
> fonctionne pas et impossible de taper un texte dedans parfois aussi la
> sélection à la souris d'un morceau du texte ne marche plus (en revanche les
> autres boutons, y compris le triangle du sélecteur d'une combobox)
> fonctionne encore. La fermeture du dialogue et sa réouverture suffit
> parfois à rétablir la fonction; mais pas toujours...
>
> - la suppression et le remise d'une icone de raccourci sur la barre
> d'icone fonctionne, mais le bouton ne produit toujours rien quand on clique
> dessus.
>
> Il semble qu'il y a un bogue dans la bibliothèque qui gère les "bindings"
> attachant des événements clavier ou souris à un gestionnaire d'événement;
> comme si le gestionnaire avait été perdu par perte de référence (allocation
> en "weak pointer" et effet du garbage collector, ou mauvaise
> synchronisation de l'ordre des événements en cas de modification dynamique
> de la liste des bindings (modification non atomique, comme si la
> suppression de référence au gestionnaire d'événement dans une liste de
> gestionnaires a eu lieu *avant* l'insertion de ce même gestionnaire dans
> une autreliste pour un autre élément d'interface utilisateur).
>
> Je me demande si c'est un bogue de JOSM lui-même ou d'une de ses
> bibliothéques de construction d'UI; ou si la modification dyna,ique de
> l'interface a oublié de mettre un verrou entre plusieurs threads faisant
> des modifications concurrentes de l'UI (par exemple un thread s'occupant de
> la construction d'un nouveau dialogue tandis qu'un autre thread s'occupe
> encore de celui de la fenêtre principale; ou bien l'événement à réassigner
> est encore en cours de traitement par le thread principal qui gère la liste
> ordonnée des événements UI et synchronise les rafraichissements écran).
>
>
> Seule parade : sauver les modifs en cours dans un fichier local, fermer
> JOSM et le relancer pour charger le fichier à nouveau. Mais à je suis tombé
> sur un cas où c'était la fonction sauvegarder qui ne fonctionnait plus
> aussi bien au clavier (CTRL+S), qu'à la souris en cliquant l'icone de la
> barre d'icones ou par le menu fichier.
>
> C'est de plus en plus gênant car l'anomalie se reproduit de plus en plus
> souvent et aboutit à des pertes de modifs en cours (très gênant quand on a
> eu besoin de charger beaucoup de données et vérifier des jeux compliqués de
> relations interdépendantes, comme la vérification des cours d'eau, des
> lignes de bus, vérifier le routage, refermer les trous dans des relations
> (par exemple par ceux qui remplacent sans faire attention des routes ou
> transforment un carrefour simple en rond-point tracé n'importe comment et
> ne tenant pas compte de l'existant qui s'y connecte (ceux-là ne connaissent
> pas CTRL+ALT+D dans JOSM et sont totalement perdus dans iD qui presque tout
> le temps fait n'importe quoi et est très peu utiisable pour autre chose que
> d'ajouter des tags ou faire un tracé sommaire ou ajouter un POI ou affiner
> le tracé existant; mais pas pour transformer des objets: d'ailleurs les
> mêmes beaucoup trop souvent ne s'embarassent pas de transformer l'existant,
> ils retracent et suppri,ent tout ce qui les gêne et ne fait doublon qu'avec
> leur nouveau tracé, ou qui passe une route simple bidirectionnelle en
> routes à deux voies unidirectionnelles séparées et oublient de router la
> ligne de bus en sens inverse qui passait par la première voie laissée mais
> devenue sens unique; créant des routes impossibles).
>
> D'une façon générale JOSM a de plus en plus souvent des soucis de
> rafraichissement partiel de l'écran et semble souffrir de bogue de
> synchronisation entre ses threads de plus en plus nombreux (chez moi la
> moindre session prend maintenant plus de 400 threads parallèles, alors que
> j'tilise un jeu très réduit de plugins parmi les plus "stables".
>
> Je détecte cette anomalie depuis début août, mais cela s'aggrave maintenant
>
> Note: je suis toujours à jour des versions, je lance JOSM par JNLP sur la
> dernière version en release stable. Et ceci quelque soit le PC utilisé
> (sous Windows 7 ou 8.1); avec la dernière versions stable de Java (en
> version "H

Re: [OSM-talk-fr] Pertes de contrôle du clavier : anomalie trop fréquente de JOSM

2014-10-11 Par sujet Bruno


Bonjour,

Idem pour moi, je n'utilise plus la touche pour télécharger le cadastre 
(F10 ou F11 suivant paramétrage) car au bout de trois à quatre 
utilisations je perds le clavier, c'est systématique, par contre la 
souris fonctionne dans tous les cas.
ça fait bien un an que c'est comme ça pour moi mais je n'ai pas eu le 
temps de chercher une explication/solution.

Sous Gnu/Linux Ubuntu dernière version (64 bits) et testé avec Java 6 ou 7.

 Le 11/10/2014 16:54, Jean-Baptiste Holcroft a écrit :


C'est long, mais j'ai le même, mais ça se provoque de manière 
aléatoire et sauvegarder son travail devient ridiculement compliqué.

Pour moi ça apparaît avec le plugin cadastre.

Le 11 oct. 2014 16:11, "Philippe Verdy" > a écrit :



De plus en plus souvent je constate des pertes inopinées de
contrôle du clavier ou de la souris dans JOSM; rendant l'interface
inopérante.

Par exemple :
-  les touches + et - (qu'on les tape sur le pavé numérique ou le
clavier alpha) du zoom cessent de répondre (dans ce cas aussi cela
ne marche plus non plus avec le menu ni un raccourci posé sur une
icone de la barre d'icones (c'est le cas le plus fréquent) Et
pourtant le zoom sur la sélection fonctionne encore et le zoom
avec + ou - dans le dialogue de téléchargement d'une zone
fonctionne encore.

- quand on ouvre un dialogue; le focus sur le champ de saisie ne
fonctionne pas et impossible de taper un texte dedans parfois
aussi la sélection à la souris d'un morceau du texte ne marche
plus (en revanche les autres boutons, y compris le triangle du
sélecteur d'une combobox) fonctionne encore. La fermeture du
dialogue et sa réouverture suffit parfois à rétablir la fonction;
mais pas toujours...

- la suppression et le remise d'une icone de raccourci sur la
barre d'icone fonctionne, mais le bouton ne produit toujours rien
quand on clique dessus.

Il semble qu'il y a un bogue dans la bibliothèque qui gère les
"bindings" attachant des événements clavier ou souris à un
gestionnaire d'événement; comme si le gestionnaire avait été perdu
par perte de référence (allocation en "weak pointer" et effet du
garbage collector, ou mauvaise synchronisation de l'ordre des
événements en cas de modification dynamique de la liste des
bindings (modification non atomique, comme si la suppression de
référence au gestionnaire d'événement dans une liste de
gestionnaires a eu lieu *avant* l'insertion de ce même
gestionnaire dans une autreliste pour un autre élément d'interface
utilisateur).

Je me demande si c'est un bogue de JOSM lui-même ou d'une de ses
bibliothéques de construction d'UI; ou si la modification
dyna,ique de l'interface a oublié de mettre un verrou entre
plusieurs threads faisant des modifications concurrentes de l'UI
(par exemple un thread s'occupant de la construction d'un nouveau
dialogue tandis qu'un autre thread s'occupe encore de celui de la
fenêtre principale; ou bien l'événement à réassigner est encore en
cours de traitement par le thread principal qui gère la liste
ordonnée des événements UI et synchronise les rafraichissements
écran).


Seule parade : sauver les modifs en cours dans un fichier local,
fermer JOSM et le relancer pour charger le fichier à nouveau. Mais
à je suis tombé sur un cas où c'était la fonction sauvegarder qui
ne fonctionnait plus aussi bien au clavier (CTRL+S), qu'à la
souris en cliquant l'icone de la barre d'icones ou par le menu
fichier.

C'est de plus en plus gênant car l'anomalie se reproduit de plus
en plus souvent et aboutit à des pertes de modifs en cours (très
gênant quand on a eu besoin de charger beaucoup de données et
vérifier des jeux compliqués de relations interdépendantes, comme
la vérification des cours d'eau, des lignes de bus, vérifier le
routage, refermer les trous dans des relations (par exemple par
ceux qui remplacent sans faire attention des routes ou
transforment un carrefour simple en rond-point tracé n'importe
comment et ne tenant pas compte de l'existant qui s'y connecte
(ceux-là ne connaissent pas CTRL+ALT+D dans JOSM et sont
totalement perdus dans iD qui presque tout le temps fait n'importe
quoi et est très peu utiisable pour autre chose que d'ajouter des
tags ou faire un tracé sommaire ou ajouter un POI ou affiner le
tracé existant; mais pas pour transformer des objets: d'ailleurs
les mêmes beaucoup trop souvent ne s'embarassent pas de
transformer l'existant, ils retracent et suppri,ent tout ce qui
les gêne et ne fait doublon qu'avec leur nouveau tracé, ou qui
passe une route simple bidirectionnelle en routes à deux voies
unidirectionnelles séparées et oublient de router la ligne de bus
en sens inverse qui passait par la première voie laissée mais
devenue sens unique; créant des routes

Re: [OSM-talk-fr] Revoir l'extraction des adresses du cadastre (était [import lieux-dits (avec fixme)])

2014-10-11 Par sujet sylvain letuffe

Vincent de Château-Thierry wrote
> Overpass renvoie 56883 nodes avec le même fixme="à vérifier...". Un tel
> volume ne rime à
> rien avec ce tag. Je suis d'avis de supprimer ces points, car je prends le
> pari qu'ils ne
> seront pas revus un par un avant une éternité. Si pas d'opposition, je
> peux me charger de
> cette suppression dans la semaine.

3 mois sont passés et le nombre est passé à 55792.
Il n'y avait pas eu d'opposition à cette suppression mais Vincent a
peut-être oublié de le faire. Et j'ai peur que plus on attend et plus on
aura de cas de gens qui :
- repositionnent mais oublient d'enlever le fixme
- auraient pû l'ajouter manuellement au bon endroit mais ne le font pas car
un "libellé existe déjà"

Bref, je m'en occupe par la suppression des noeuds avec ce fixme.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Revoir-l-extraction-des-adresses-du-cadastre-etait-import-lieux-dits-avec-fixme-tp5812917p5820048.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] Revoir l'extraction des adresses du cadastre (était [import lieux-dits (avec fixme)])

2014-10-11 Par sujet sylvain letuffe

sylvain letuffe wrote
> Bref, je m'en occupe par la suppression des noeuds avec ce fixme.

Oups, non, pas là tout de suite maintenant, je m'en occupe d'ici quelques
jours s'il n'y a pas d'opposition sur la bases de nouveaux éléments




--
View this message in context: 
http://gis.19327.n5.nabble.com/Revoir-l-extraction-des-adresses-du-cadastre-etait-import-lieux-dits-avec-fixme-tp5812917p5820049.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] Revoir l'extraction des adresses du cadastre (était [import lieux-dits (avec fixme)])

2014-10-11 Par sujet Vincent de Château-Thierry


Bonsoir,

Le 11/10/2014 19:19, sylvain letuffe a écrit :

sylvain letuffe wrote

Bref, je m'en occupe par la suppression des noeuds avec ce fixme.


Oups, non, pas là tout de suite maintenant, je m'en occupe d'ici quelques
jours s'il n'y a pas d'opposition sur la bases de nouveaux éléments


Oops statu quo en effet. Personnellement je n'ai pas changé d'avis (mais 
rien fait non plus) sur le sujet donc je vote toujours pour une suppression.


vincent

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

Re: [OSM-talk-fr] Pertes de contrôle du clavier : anomalie trop fréquente de JOSM

2014-10-11 Par sujet Muselaar

Bonsoir,
Je ne sais pas si ça a un rapport (mais peut-être que si, d'où mon message), 
mais chez moi, c'est la souris (j'utilise peu le clavier), en l'occurrence le 
trackpad qui pose problème. 
Je crois l'avoir déjà signalé, c'est en fait la fenêtre qui devient 
transparente à la souris, ou autrement dit, les actions de la souris continuent 
de s'appliquer à la précédente fenêtre utilisée, même si elle est en arrière 
plan.
La parade que j'ai fini par trouver, vraiment par hasard, c'est de (sur le 
trackpad) simuler avec 2 doigts la molette de la souris, et de faire des 
mouvements rapides de haut en bas. Au bout de quelques secondes, la fenêtre 
visible est prise en compte par le pointeur, et on peut continuer à travailler 
normalement. Là où c'est moins marrant, c'est quand on change sans cesse de 
fenêtre (boîtes de dialogues successives, par exemple).
Mais c'est devenu chez moi un réflexe, et je commence peu à peu à oublier que 
ça pourrait marcher mieux

Envoyé de mon iPhone

Le 11 oct. 2014 à 18:03, Bruno  a écrit :

> Bonjour, 
> 
> Idem pour moi, je n'utilise plus la touche pour télécharger le cadastre (F10 
> ou F11 suivant paramétrage) car au bout de trois à quatre utilisations je 
> perds le clavier, c'est systématique, par contre la souris fonctionne dans 
> tous les cas.
> ça fait bien un an que c'est comme ça pour moi mais je n'ai pas eu le temps 
> de chercher une explication/solution.
> Sous Gnu/Linux Ubuntu dernière version (64 bits) et testé avec Java 6 ou 7.
> 
>  Le 11/10/2014 16:54, Jean-Baptiste Holcroft a écrit :
>> C'est long, mais j'ai le même, mais ça se provoque de manière aléatoire et 
>> sauvegarder son travail devient ridiculement compliqué.
>> Pour moi ça apparaît avec le plugin cadastre.
>> 
>> Le 11 oct. 2014 16:11, "Philippe Verdy"  a écrit :
>>> 
>>> De plus en plus souvent je constate des pertes inopinées de contrôle du 
>>> clavier ou de la souris dans JOSM; rendant l'interface inopérante.
>>> 
>>> Par exemple :
>>> -  les touches + et - (qu'on les tape sur le pavé numérique ou le clavier 
>>> alpha) du zoom cessent de répondre (dans ce cas aussi cela ne marche plus 
>>> non plus avec le menu ni un raccourci posé sur une icone de 
>>> la barre d'icones (c'est le cas le plus fréquent) Et pourtant le zoom sur 
>>> la sélection fonctionne encore et le zoom avec + ou - dans le dialogue de 
>>> téléchargement d'une zone fonctionne encore.
>>> 
>>> - quand on ouvre un dialogue; le focus sur le champ de saisie ne fonctionne 
>>> pas et impossible de taper un texte dedans parfois aussi la sélection à la 
>>> souris d'un morceau du texte ne marche plus (en revanche les autres 
>>> boutons, y compris le triangle du sélecteur d'une combobox) fonctionne 
>>> encore. La fermeture du dialogue et sa réouverture suffit parfois à 
>>> rétablir la fonction; mais pas toujours...
>>> 
>>> - la suppression et le remise d'une icone de raccourci sur la barre d'icone 
>>> fonctionne, mais le bouton ne produit toujours rien quand on clique dessus.
>>> 
>>> Il semble qu'il y a un bogue dans la bibliothèque qui gère les "bindings" 
>>> attachant des événements clavier ou souris à un gestionnaire d'événement; 
>>> comme si le gestionnaire avait été perdu par perte de référence (allocation 
>>> en "weak pointer" et effet du garbage collector, ou mauvaise 
>>> synchronisation de l'ordre des événements en cas de modification dynamique 
>>> de la liste des bindings (modification non atomique, comme si la 
>>> suppression de référence au gestionnaire d'événement dans une liste de 
>>> gestionnaires a eu lieu *avant* l'insertion de ce même gestionnaire dans 
>>> une autreliste pour un autre élément d'interface utilisateur).
>>> 
>>> Je me demande si c'est un bogue de JOSM lui-même ou d'une de ses 
>>> bibliothéques de construction d'UI; ou si la modification dyna,ique de 
>>> l'interface a oublié de mettre un verrou entre plusieurs threads faisant 
>>> des modifications concurrentes de l'UI (par exemple un thread s'occupant de 
>>> la construction d'un nouveau dialogue tandis qu'un autre thread s'occupe 
>>> encore de celui de la fenêtre principale; ou bien l'événement à réassigner 
>>> est encore en cours de traitement par le thread principal qui gère la liste 
>>> ordonnée des événements UI et synchronise les rafraichissements écran).
>>> 
>>> 
>>> Seule parade : sauver les modifs en cours dans un fichier local, fermer 
>>> JOSM et le relancer pour charger le fichier à nouveau. Mais à je suis tombé 
>>> sur un cas où c'était la fonction sauvegarder qui ne fonctionnait plus 
>>> aussi bien au clavier (CTRL+S), qu'à la souris en cliquant l'icone de la 
>>> barre d'icones ou par le menu fichier.
>>> 
>>> C'est de plus en plus gênant car l'anomalie se reproduit de plus en plus 
>>> souvent et aboutit à des pertes de modifs en cours (très gênant quand on a 
>>> eu besoin de charger beaucoup de données et vérifier des jeux compliqués de 
>>> relations interdépendantes, comme la vérification

Re: [OSM-talk-fr] Prix des carburants ?


Le 11 oct. 2014 à 13:32, Frédéric Rodrigo  a écrit :

> Comme déjà dit je pense que l'on ne peut que accorder qu'un confiance limité 
> en ça.
Brice a précisé que ça ne marche pas pour tous les cas, un certains nombre — 
combien exactement 1%, 10%, 90% ? —seront incomplètes, mais pas erronées ?
Sur cette liste il y a d’un côté — des « perfectionnistes » qui veulent des 
donnée fiables à 100%, maintenables et utiles — et de l’autres, des personnes 
qui préfèrent des données moins fiables et leur ’amélioration itérative, plutôt 
qu’une carte blanche.

> Ça produit un tag osm opening_hours,
"opening_hours": lambda res: "24/7" if res["debut"] != "" and res["debut"] == 
res["fin"] and res["saufjour"] == "" else None,

Si je comprends bien le code source, ça produit opening_hours="24/7" uniquement 
si début=fin est que saufjour est vide.
Dans les autres cas, l’attribut opening_hours n’est pas exporté ?


> c'est con son format : http://wiki.openstreetmap.org/wiki/Key:opening_hours
Je ne comprends pas ce que tu veux dire ?
con : simple ?

Ce format est en fait une grammaire qui permet de gérer tous les cas. Simple 
dans les cas triviaux, mais complexe dans certains cas.

Voici un traitement simple qui fonctionne dans tous les cas (je ne connais pas 
python) :
remplacer ‘;' par ‘,' dans res['saufjour’]
remplacer [‘Lundi’,’Mardi’,’Mercredi’,’Jeudi’,’Vendredi’,’Samedi’,’Dimanche’] 
par [‘Lundi’,’Mardi’,’Mercredi’,’Jeudi’,’Vendredi’,’Samedi’,’Dimanche’] dans 
res[‘saufjour']

note : Je ne sais pas coder les étapes 1 et 2 en python

renvoyer la concaténation du tout :
'opening_hours': res['debut'] + ‘-‘ + res[‘fin']  + ‘ open ; ‘ + 
res[‘saufjour’]  + ‘closed’

 donnera 
opening_hours='08:30-20:00 open; Mo,Su closed’

> Je ne suis pas trop pour intégrer des données peu fiable et inmaintenable.
Je laisse e choix de trancher à la personne qui fait l’intégration ;-)

> id='25420005'
> Pour c'est juste un identifiant interne et pas de référence.
Je ne vois pas la différence. Et il est publié dans les données ouvertes donc 
pas si interne que ça.
Tu voulais un identifiant bien « officiel » comme un SIRET ?

Bonne soirée et bon dimanche,

—
Yves


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

Re: [OSM-talk-fr] Osmose : erreur de commune pour le géocodage d'un Monument historique non intégré


Le 11 oct. 2014 à 10:55, Frédéric Rodrigo  a écrit :

> En entre les deux. Les monuments ont été géocodé en 2012 avec nominatime 
> (donc données OSM).
Ok, merci pour la réponse.

> Il faudrait refaire le géocodage ou refaire le point sur les données données 
> disponible aujourd'hui sur le sujet.
Donc refaire le géocodage avec BANO ;-)

—
Yves


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

Re: [OSM-talk-fr] Re: Liste des voies OSM et codes FANTOIR par commune

2014-10-11 Par sujet Vincent de Château-Thierry



Le 10/10/2014 12:15, Francescu GAROBY a écrit :

Super, merci pour ce rajout, ça évitera de s'acharner sur sa touche F5
après avoir fait un rapprochement massif de voies (non, je ne parle pas
d'expérience. Pourquoi pensez-vous ça ?)

Le 10 octobre 2014 12:11, Vincent de Château-Thierry mailto:osm.v...@free.fr>> a écrit :

Les outils qui s'appuient dessus (le rendu carto, les listes de
rapprochements)
sont calés sur ce rythme quotidien. Je vais rajouter sur la page de
comparaison
Fantoir la date de dernière màj, pour une ville donnée.


Vous avec maintenant en haut de page 3 infos relatives à la fraîcheur 
des données :
- la date à laquelle le cadastre a été intégré dans BANO (cette info 
n'est valable qu'avec le cadastre vectoriel)

- la date de dernier rapprochement entre les données OSM et Fantoir
- et la date à laquelle, pour ce rapprochement, on a récupéré les 
données OSM dans une base mise à jour au fil de l'eau


Et pour les codes INSEE corses, 'a' et 'b' sont maintenant compris ;)

vincent

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

[OSM-talk-fr] BANO : pas de rapprochement à cause du nom du lieu-dit - La Crèche 79