Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS

2015-01-23 Par sujet Cyrille Giquello 
Le 20 janvier 2015 21:35, Christian Quest  a écrit :
> Mon petit doigt me dit qu'en principe les nouveaux IRIS devraient
> arriver en opendata dans un avenir proche... sans avoir vu à quoi ce jeu
> de données pourrait ressembler.

Mince je viens tout juste d'acheter les contours d'Indre-et-Loire !

-- 
Cyrille.

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

Re: [OSM-talk-fr] Zonages statistiques Ilots et IRIS

2015-01-23 Par sujet Cyrille Giquello 
Le 20 janvier 2015 19:25, Philippe Verdy  a écrit :
> Franchement; si des communes entières sont des IRIS, pas la peine d'ajouter
> une relation supplémentaire, il suffira juste de les marquer avec un tag
> supplémentaire tel que "statistical=FR:IRIS".

Du coup ça me fait penser au problème des "GR" avec la FFRP.

Les conditions de réutilisations des contours IRIS mis à dispo par
INSEE interdisent leur représentation autre que via les PDF fournis,
interdiction d'en faire une représentation vectorielle.
Du coup ajouter le tag IRIS revient à en faire une représentation
vectorielle, qui est donc interdite.

Donc, d'après ma compréhension, quelque soit la méthode, nous n'avons
pas le droit de représenter les contours IRIS autre que pour un usage
privé.

Cyrille.
-- 
Cyrille.

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

[OSM-talk-fr] Projet OSM_SN - Touba-building - Sénégal

2015-01-23 Par sujet SEYE Ismaila 
Bonsoir,

Une tâche #848 dans le Tasking Manager vient d'être créer dans la région de
Touba (Sénégal).

La ville de Touba est de nos jours l'une des plus grandes villes du
Sénégal, de par sa démographie, son activité économique surtout tertiaire.
La ville a cependant un statut particulier puisque comme d'autres villes
saintes du Sénégal, elle dispose d'une police particulière et d'un
règlement basé sur la shari'a selon l'école juridique malékite. Touba
enregistre la plus forte croissance démographique des agglomérations du
Sénégal (3,2 % annuel pour le moment avec un taux de croissance estimé à 12
% pour les années 2010). Cette croissance est due aux arrivées massives de
villageois des provinces historiques du Baol et du Cayor ; ces villages se
vident progressivement au profit de Touba.

Ce job a pour objectif de cartographier les batiments de la ville de Touba,
Sénégal

-- 
Ismaila SEYE
Informaticien
695 Grand Dakar / Dakar-Sénégal
Membre OSM_SN
Tél: +221 77 447 93 62
Skype: seyeize1
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Tagging] Deprecation of associatedStreet-relations

2015-01-23 Par sujet Philippe Verdy 
Alors ça explique bien des choses sur des noeuds d'adresse oubliés dans
BANO: ils ont juste un numéro (ou juste un "housename") et pas de nom de
rue; mais ont été oubliés de la relation street/associatedStreet.
Et ils ne sont même pas tous signalés en erreur non plus (les outils en
revanche signalent des noms de rues inconnus ou non rapprochés (souvent des
abréviations ou des noms tronqués dans l'export du cadastre, ou des noms
d'usage local ; qui n'ont pas été ajoutés en alt_name=* ou loc_name=* pour
le chemin de voirie ou la relation ou encore d'anciens noms encore utilisés
par les résidents).

Le 23 janvier 2015 15:51, Vincent de Château-Thierry  a
écrit :

>
> > De: "Philippe Verdy" 
> >
> > Pour l'instant non, mais on verra ce que ça donnera si des
> > contributeurs se mettent à virer toutes les relations et insistent
> > pour ne taguer que les noeuds et les voies.
> >
> > On a déjà de nombreuses erreurs liées à cette séparation; le
> > rapprochement BANO se fait déjà mal et les relations ont chaque fois
> > résolu les problèmes d'ambiguité comme des points d'adresses
> > rapporochés sur la mauvaise rue (et pallié aussi à de nombreux
> > oublis quand les relations n'étaient pas là pour référencer les
> > noeuds isolés un peu trop loin de la voie).
>
> Le rapprochement des données OSM dans BANO exploite soit l'appartenance à
> une relation associatedStreet, soit le couple de tags addr: street et
> addr:housenumber. Il n'y a _aucune_ prise en compte de la géométrie pour
> les rapprochements, le critère d'éloignement de la voie n'est pas pris en
> compte.
>
> vincent
>
> ___
> 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] [Tagging] Deprecation of associatedStreet-relations

2015-01-23 Par sujet Vincent de Château-Thierry 

> De: "Philippe Verdy" 
> 
> Pour l'instant non, mais on verra ce que ça donnera si des
> contributeurs se mettent à virer toutes les relations et insistent
> pour ne taguer que les noeuds et les voies.
> 
> On a déjà de nombreuses erreurs liées à cette séparation; le
> rapprochement BANO se fait déjà mal et les relations ont chaque fois
> résolu les problèmes d'ambiguité comme des points d'adresses
> rapporochés sur la mauvaise rue (et pallié aussi à de nombreux
> oublis quand les relations n'étaient pas là pour référencer les
> noeuds isolés un peu trop loin de la voie).

Le rapprochement des données OSM dans BANO exploite soit l'appartenance à une 
relation associatedStreet, soit le couple de tags addr: street et 
addr:housenumber. Il n'y a _aucune_ prise en compte de la géométrie pour les 
rapprochements, le critère d'éloignement de la voie n'est pas pris en compte.

vincent

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

Re: [OSM-talk-fr] [Tagging] Deprecation of associatedStreet-relations

2015-01-23 Par sujet Philippe Verdy 
Le 23 janvier 2015 15:26, Vincent de Château-Thierry  a
écrit :

> > 2015-01-23 11:40 GMT+01:00 Philippe Verdy < verd...@wanadoo.fr > :
> >
> > Mais je voterais plutôt contre la migration des relations vers les
> > noeuds (oui ça foutra le bordel dans les rapprochements de la BANO
>
> Non Philippe, j'insiste, BANO n'est pas impactée.
>

Pour l'instant non, mais on verra ce que ça donnera si des contributeurs se
mettent à virer toutes les relations et insistent pour ne taguer que les
noeuds et les voies.

On a déjà de nombreuses erreurs liées à cette séparation; le rapprochement
BANO se fait déjà mal et les relations ont chaque fois résolu les problèmes
d'ambiguité comme des points d'adresses  rapporochés sur la mauvaise rue
(et pallié aussi à de nombreux oublis quand les relations n'étaient pas là
pour référencer les noeuds isolés un peu trop loin de la voie).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Tagging] Deprecation of associatedStreet-relations

2015-01-23 Par sujet Vincent de Château-Thierry 

> De: "Jo" 
> 
> Puis ils on toutes sortes de raisons, mais cela revient toujours à un
> support pauvre dans certains éditeurs, pour maintenir ces
> relations... aucune iD lequel ça pourrait être.

:) 

> 2015-01-23 11:40 GMT+01:00 Philippe Verdy < verd...@wanadoo.fr > :
> 
> Mais je voterais plutôt contre la migration des relations vers les
> noeuds (oui ça foutra le bordel dans les rapprochements de la BANO

Non Philippe, j'insiste, BANO n'est pas impactée.

> Faire un vote pour déprécier des tags sans même discuter des
> migrations à faire et de leur impact est assez stupide.

D'accord là dessus.

vincent

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

Re: [OSM-talk-fr] weeklyOSM n°234 en français

2015-01-23 Par sujet althio 
Bonjour,

Pour faire des retours à l'équipe de weeklyOSM, le plus simple est
d'utiliser le formulaire de contact sur
www.weeklyosm.eu/fr/contact
avec un message plus court pour préciser les commentaires ou les
demandes de modification.

Bonne journée et bon week-end à tous.


Subject: Re: [OSM-talk-fr] weeklyOSM n°234 en français
To: Discussions sur OSM en français 

> Au sujet de la métropole de Lyon ce n'est pas compliqué ce n'est toujours
> pas un département (niveau 6) mais simplement un arrondissement (niveau 7) à
> statut spécial (puisque situé hors des compétences du conseil général
> (conseil départemental en mars prochain)
>
> Merci de garder le département du Rhône entier. Il y a une autre relation
> pour la zone de compétence du conseil général/départemental): c'est cette
> relation à part qui est un peu spéciale (taguée pour l'instant comme une
> "boundary=local_authority" avec aussi "local_authority=departement" (?) pour
> désigner la compétence locale du conseil général/départemental. Pas besoin
> de nouveau border_type, c'est une limite d'arrondissement standard (niveau
> 7).
>
> Et donc aucun changement non plus pour le code ISO 311662-2 associé au
> département tout entier. La métrople n'est pas érigée formellement comme un
> département et les textes sont clairs (ils précisent parfois que pour
> l'application d'un texte la métropole est seulement "assimilée" à un
> département et disinguée du reste du département; par exemple pour les
> sièges à élire ou les transferts budgétaires de l'Etat aux départements et
> dans les tableaux de synthèse) bien qu'elle soit juste un arrondissement (à
> statut spécial) et reste aussi un EPCI (à compétence renforcée par rapport
> aux autres métropoles actuelles ou à venir).
>
> L'ancien arrondissement départemental de Lyon étant modifié (avec la
> compétence réduite du sous-préfet de l'arrondissement Lyon mais étendue pour
> le sous-préfet de l'arrondissement de Villefranche-sur-Saône qui capte
> toutes les communes de l'ancien arrondissement lyonnais qui n'ont pas adhéré
> à la métropole), on l'appellera simplement "Métropole de Lyon" et pas
> seulement "Arrondissement de Lyon" pour éviter toute confusion avec les
> arrondissements municipaux de Lyon (qui existent toujours).
>
>
>> Bonjour,
>>
>> L'édition hebdomadaire n°234 de weeklyOSM vient de paraître en
>> français. Retrouvez sur http://www.weeklyosm.eu/fr/ votre petit
>> condensé de l'actualité du monde d'OSM.
>>
>> Bonne lecture !
>>
>> PS : Pour porter des actualités à notre attention, n'hésitez pas à
>> utiliser
>> la page de contact (www.weeklyosm.eu/contact).

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

Re: [OSM-talk-fr] Réunion contributeurs Toulouse ?

2015-01-23 Par sujet Florian LAINEZ 
Merci Laurent, c'était très sympa. J'écris un mail à
quest...@tetaneutral.net pour approfondir les sujets abordés.
Cordialement

Le 23 janvier 2015 10:57, Laurent GUERBY  a écrit :

> On Tue, 2015-01-20 at 11:49 +0100, Florian LAINEZ wrote:
> > Merci les gars du Tetaneutral ! Perso cela me convient tout à fait. On
> > se retrouve donc à la Paniolade à 19h.
>
> Bonjour,
>
> Merci d'être passé :). N'hesitez pas a me contacter pour
> concretiser quelques projets dont nous avons discuté.
>
> Le prochain repas hebdomadaire du libre toulousain est le QJELT
> http://lists.tetaneutral.net/pipermail/tetaneutral/2015-January/000207.html
> mardi 27 en centre ville (inscription necessaire pour logistique)
>
> Sincèrement,
>
> Laurent
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 

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

Re: [OSM-talk-fr] [Tagging] Deprecation of associatedStreet-relations

2015-01-23 Par sujet Jo 
Je ne suis toujours pas convaincu d'avoir malcompris le vote. Il y en a
certains qui sont d'accord à condition de passer a type=street, mais
l'intention initiale était d'abolir au maximum l'utilisation de relations
et de passer à des tags addr:street.

Puis ils on toutes sortes de raisons, mais cela revient toujours à un
support pauvre dans certains éditeurs, pour maintenir ces relations...
aucune iD lequel ça pourrait être.

Jo



2015-01-23 11:40 GMT+01:00 Philippe Verdy :

> Et là dans la façon dont tu le comprends c'est une des interprétations
> incorrectes de ce vote.
> Ce n'est d'ailleurs pas suffisant même s'il y a une vingaine de vote pour
> cette dépréciation.
> Je veux bien qu'on passe de relation type=associatedStreet à type=street
> pour unifier les deux cependant c'est assez étrange car il y a énormément
> plus de relations associatedStreet que de relations street.
>
> Mais je voterais plutôt contre la migration des relations vers les noeuds
> (oui ça foutra le bordel dans les rapprochements de la BANO et les
> modifications à faire quand une rue est renommée ou divisée pour vérifier
> chacun des noeuds et voir s'ils sont bien orthographiés: Il y aura un
> no,bre considérable d'oublis; c'est gérable uniquement pour les tags des
> ways; mais ça entraine une redondance énorme dans la base pour les adresses
> car les noeuds se contentaient d'indiquer juste un numéro, mais pas le nom
> de rue implicite pour les membres de relations street ou associatedStreet,
> ni les codes postaux et noms de bureaux distributeurs; qui sont déjà gérés
> par polygones englobant, soit ceux des communes, soit ceux des relations de
> zones postales comme en Allemagne)
>
> Faire un vote pour déprécier des tags sans même discuter des migrations à
> faire et de leur impact est assez stupide.
>
> Le 23 janvier 2015 07:19, Jo  a écrit :
>
> Moi, j'ai compris ça comme vouloir abolir l'usage de relation (aS et
>> street) et qu'ils veulent uniquement utiliser addr:street sur chaque
>> bâtiment ayant une adresse.
>>
>> Polyglot
>>
>> 2015-01-23 6:52 GMT+01:00 Vincent de Château-Thierry :
>>
>>> Bonjour,
>>>
>>> Le 23/01/2015 05:17, Philippe Verdy a écrit :
>>>
 Autre difficulté c'est le rapprochement pour BANO avec les codes
 fantoir; dans le cas des segments de rues qui en ont deux car la rue
 sépare deux communes et chaque coté utilise sont code FANTOIR.

>>>
>>> Non, pas de souci ici. BANO gère l'affectation des codes Fantoir uniques
>>> sur les nodes, ways, ways fermés, et relations associatedStreet (tag
>>> ref:FR:FANTOIR) et des codes latéraux sur les ways (ref:FR:FANTOIR:left et
>>> ref:FR:FANTOIR:right).
>>>
>>>  Ce vote s'l aboutit risque de mettre à mal l'important travail de
 rapprochement qui a lieu pour la BANO et ses équivalents dans divers
 pays.

>>>
>>> Ce vote s'il aboutit ne changera rien pour BANO, qui gère les 2 schémas
>>> d'adressage : par relation associatedStreet ou par tag addr: street.
>>>
>>>  Et ça tous ceux qui ont voté pour approuver le chagement n'ont pas
 vraiment compris car les enjeux ne sont pas expliqués, et parce
 qu'aucune solution claire de remplacement n'a été expliquée; ni même
 discutée; avant de passer directement au vote expéditif !

>>>
>>> Oui, ça a été présenté comme un sondage mais l'absence de contexte, et
>>> surtout la confusion sur ce qui devrait remplacer les relations
>>> associatedStreet (la relation Street ? le schema simple addr: street ?)
>>> fait qu'on ne sait pas pour quoi on vote. Pas top.
>>>
>>> vincent
>>>
>>>
>>> ___
>>> 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] weeklyOSM n°234 en français

2015-01-23 Par sujet Philippe Verdy 
Au sujet de la métropole de Lyon ce n'est pas compliqué ce n'est toujours
pas un département (niveau 6) mais simplement un arrondissement (niveau 7)
à statut spécial (puisque situé hors des compétences du conseil général
(conseil départemental en mars prochain)

Merci de garder le département du Rhône entier. Il y a une autre relation
pour la zone de compétence du conseil général/départemental): c'est cette
relation à part qui est un peu spéciale (taguée pour l'instant comme une
"boundary=local_authority" avec aussi "local_authority=departement" (?)
pour désigner la compétence locale du conseil général/départemental. Pas
besoin de nouveau border_type, c'est une limite d'arrondissement standard
(niveau 7).

Et donc aucun changement non plus pour le code ISO 311662-2 associé au
département tout entier. La métrople n'est pas érigée formellement comme un
département et les textes sont clairs (ils précisent parfois que pour
l'application d'un texte la métropole est seulement "assimilée" à un
département et disinguée du reste du département; par exemple pour les
sièges à élire ou les transferts budgétaires de l'Etat aux départements et
dans les tableaux de synthèse) bien qu'elle soit juste un arrondissement (à
statut spécial) et reste aussi un EPCI (à compétence renforcée par rapport
aux autres métropoles actuelles ou à venir).

L'ancien arrondissement départemental de Lyon étant modifié (avec la
compétence réduite du sous-préfet de l'arrondissement Lyon mais étendue
pour le sous-préfet de l'arrondissement de Villefranche-sur-Saône qui capte
toutes les communes de l'ancien arrondissement lyonnais qui n'ont pas
adhéré à la métropole), on l'appellera simplement "Métropole de Lyon" et
pas seulement "Arrondissement de Lyon" pour éviter toute confusion avec les
arrondissements municipaux de Lyon (qui existent toujours).


Le 21 janvier 2015 12:05, Emmanel Dewaele  a
écrit :

> Bonjour,
>
> L'édition hebdomadaire n°234 de weeklyOSM vient de paraître en
> français. Retrouvez sur http://www.weeklyosm.eu/fr/ votre petit
> condensé de l'actualité du monde d'OSM.
>
> Bonne lecture !
>
> PS : Pour porter des actualités à notre attention, n'hésitez pas à utiliser
> la page de contact (www.weeklyosm.eu/contact).
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/weeklyOSM-n-234-en-francais-tp5830791.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] [Tagging] Deprecation of associatedStreet-relations

2015-01-23 Par sujet Philippe Verdy 
Et là dans la façon dont tu le comprends c'est une des interprétations
incorrectes de ce vote.
Ce n'est d'ailleurs pas suffisant même s'il y a une vingaine de vote pour
cette dépréciation.
Je veux bien qu'on passe de relation type=associatedStreet à type=street
pour unifier les deux cependant c'est assez étrange car il y a énormément
plus de relations associatedStreet que de relations street.

Mais je voterais plutôt contre la migration des relations vers les noeuds
(oui ça foutra le bordel dans les rapprochements de la BANO et les
modifications à faire quand une rue est renommée ou divisée pour vérifier
chacun des noeuds et voir s'ils sont bien orthographiés: Il y aura un
no,bre considérable d'oublis; c'est gérable uniquement pour les tags des
ways; mais ça entraine une redondance énorme dans la base pour les adresses
car les noeuds se contentaient d'indiquer juste un numéro, mais pas le nom
de rue implicite pour les membres de relations street ou associatedStreet,
ni les codes postaux et noms de bureaux distributeurs; qui sont déjà gérés
par polygones englobant, soit ceux des communes, soit ceux des relations de
zones postales comme en Allemagne)

Faire un vote pour déprécier des tags sans même discuter des migrations à
faire et de leur impact est assez stupide.

Le 23 janvier 2015 07:19, Jo  a écrit :

> Moi, j'ai compris ça comme vouloir abolir l'usage de relation (aS et
> street) et qu'ils veulent uniquement utiliser addr:street sur chaque
> bâtiment ayant une adresse.
>
> Polyglot
>
> 2015-01-23 6:52 GMT+01:00 Vincent de Château-Thierry :
>
>> Bonjour,
>>
>> Le 23/01/2015 05:17, Philippe Verdy a écrit :
>>
>>> Autre difficulté c'est le rapprochement pour BANO avec les codes
>>> fantoir; dans le cas des segments de rues qui en ont deux car la rue
>>> sépare deux communes et chaque coté utilise sont code FANTOIR.
>>>
>>
>> Non, pas de souci ici. BANO gère l'affectation des codes Fantoir uniques
>> sur les nodes, ways, ways fermés, et relations associatedStreet (tag
>> ref:FR:FANTOIR) et des codes latéraux sur les ways (ref:FR:FANTOIR:left et
>> ref:FR:FANTOIR:right).
>>
>>  Ce vote s'l aboutit risque de mettre à mal l'important travail de
>>> rapprochement qui a lieu pour la BANO et ses équivalents dans divers
>>> pays.
>>>
>>
>> Ce vote s'il aboutit ne changera rien pour BANO, qui gère les 2 schémas
>> d'adressage : par relation associatedStreet ou par tag addr: street.
>>
>>  Et ça tous ceux qui ont voté pour approuver le chagement n'ont pas
>>> vraiment compris car les enjeux ne sont pas expliqués, et parce
>>> qu'aucune solution claire de remplacement n'a été expliquée; ni même
>>> discutée; avant de passer directement au vote expéditif !
>>>
>>
>> Oui, ça a été présenté comme un sondage mais l'absence de contexte, et
>> surtout la confusion sur ce qui devrait remplacer les relations
>> associatedStreet (la relation Street ? le schema simple addr: street ?)
>> fait qu'on ne sait pas pour quoi on vote. Pas top.
>>
>> vincent
>>
>>
>> ___
>> 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] Ajout de l'indicatif national aux numéros de téléphone français

2015-01-23 Par sujet Philippe Verdy 
source:
http://www.tahiti-infos.com/Telephonie-le-21-juin-tous-les-numeros-passent-a-8-chiffres_a99984.html


Le 23 janvier 2015 11:25, Philippe Verdy  a écrit :

> Effectivement les numéros en outremer ont leur propre indicatif
> international (ce n'est pas le +33) suivi de leur numéro à 9 chiffres (sans
> le zéro là aussi).
>
> Il faut gérer à part les blocs de numérotation (référence : ressources de
> numérotation sur le site de l'ARCEP) : c'est simple pour les numéros
> géographiques de lignes fixes, mais beaucoup moins pour les mobiles (06 et
> 07) et les lignes VoIP des box internet (09).
>
> Pour les appels depuis la France (métropolitaine ou outre-mer) on ne fait
> pas la différence puisqu'on ne compose que les 10 chiffres (sauf pour les
> COM du Pacifique où on doit composer le 00 suivi du code international du
> territoire et du numéro local : ils ne sont pas intégrés à la numérotation
> nationale à 10 chiffres et ont leur propre autorité locale de régulation
> des télécoms. Il y a 8 chiffres depuis le 21 juin 2014 pour les numéros en
> Polynésie française, par exemple 40 à Papeete).
>
> Le 23 janvier 2015 11:01, Greg  a écrit :
>
> Personellement, tous les numéros de téléphone de mon répertoire sont au
>> format international avec les espaces correspondant au format local. Donc
>> naturellement, je suis favorable à cette modification.
>>
>> Par contre, il faut faire attention aux numéros courts et numéros
>> spéciaux, ainsi que les numéros en France non-métropolitaine comme je viens
>> de le découvrir.
>>
>> Ensuite, faut-il mettre ces informations dans OSM ? J'ai envie de dire
>> que strictement parlant, il ne faudrait pas, mais il n'y a pas d'autre base
>> de données liée qui fournisse ces informations donc je répond "Oui, faute
>> de mieux". (Et j'avoue bien apprécier quand OsmAnd me donne le numéro de
>> téléphone d'un point d'intérêt : je n'ai pas toujours Internet avec moi)
>>
>> Pour ce qui est de l'édition, il faudrait que les éditeurs le prenne en
>> charge en proposant par exemple le pays en liste déroulante pour ne pas
>> avoir à chercher l'indicatif. C'est par exemple le cas de Telegram
>> .
>>
>> 2015-01-23 10:46 GMT+01:00 Brice MALLET :
>>
>>> Clairement, un affichage avec séparateurs "espace" facilitera l'édition
>>> dans OSM
>>> et cela semble la norme pour affichage : http://fr.wikipedia.org/wiki/
>>> Num%C3%A9ro_de_t%C3%A9l%C3%A9phone
>>>
>>> Britz
>>> Bonne journée
>>>
>>> Le 22/01/2015 16:25, Vincent Pottier a écrit :
>>>
 Le 22/01/2015 16:15, Éric Gillet a écrit :

> Le 22 janvier 2015 15:55, Romain MEHUT  > a écrit :
>
> Ne serait-ce pas plutôt +33 4 12131415  ?
>
>
> Je dois avouer que j'ai pas vraiment d'avis sur l'espace séparant les
> groupes de 4 chiffres, les deux variantes existent et la différence n'est
> que cosmétique car les espaces ou tirets après l'indicatif régional (4 
> ici)
> doivent être ignorés. Si d'autres personnes préfèrent la variante sans
> espace ce sera adjugé vendu :)
>
>  Moi qui n'ai pas assez de mémoire pour stocker 10 chiffres, des
 espaces, ça m'aide. et j'aime la forme 01 23 45 67 89

 La forme +33 (0)1 23 45 67 89 n'est pas valide ?
 Elle est plus lisibles pour les humains et les Français...
 --
 FrViPofm




 ___
 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] Ajout de l'indicatif national aux numéros de téléphone français

2015-01-23 Par sujet Philippe Verdy 
Effectivement les numéros en outremer ont leur propre indicatif
international (ce n'est pas le +33) suivi de leur numéro à 9 chiffres (sans
le zéro là aussi).

Il faut gérer à part les blocs de numérotation (référence : ressources de
numérotation sur le site de l'ARCEP) : c'est simple pour les numéros
géographiques de lignes fixes, mais beaucoup moins pour les mobiles (06 et
07) et les lignes VoIP des box internet (09).

Pour les appels depuis la France (métropolitaine ou outre-mer) on ne fait
pas la différence puisqu'on ne compose que les 10 chiffres (sauf pour les
COM du Pacifique où on doit composer le 00 suivi du code international du
territoire et du numéro local : ils ne sont pas intégrés à la numérotation
nationale à 10 chiffres et ont leur propre autorité locale de régulation
des télécoms. Il y a 8 chiffres depuis le 21 juin 2014 pour les numéros en
Polynésie française, par exemple 40 à Papeete).

Le 23 janvier 2015 11:01, Greg  a écrit :

> Personellement, tous les numéros de téléphone de mon répertoire sont au
> format international avec les espaces correspondant au format local. Donc
> naturellement, je suis favorable à cette modification.
>
> Par contre, il faut faire attention aux numéros courts et numéros
> spéciaux, ainsi que les numéros en France non-métropolitaine comme je viens
> de le découvrir.
>
> Ensuite, faut-il mettre ces informations dans OSM ? J'ai envie de dire que
> strictement parlant, il ne faudrait pas, mais il n'y a pas d'autre base de
> données liée qui fournisse ces informations donc je répond "Oui, faute de
> mieux". (Et j'avoue bien apprécier quand OsmAnd me donne le numéro de
> téléphone d'un point d'intérêt : je n'ai pas toujours Internet avec moi)
>
> Pour ce qui est de l'édition, il faudrait que les éditeurs le prenne en
> charge en proposant par exemple le pays en liste déroulante pour ne pas
> avoir à chercher l'indicatif. C'est par exemple le cas de Telegram
> .
>
> 2015-01-23 10:46 GMT+01:00 Brice MALLET :
>
>> Clairement, un affichage avec séparateurs "espace" facilitera l'édition
>> dans OSM
>> et cela semble la norme pour affichage : http://fr.wikipedia.org/wiki/
>> Num%C3%A9ro_de_t%C3%A9l%C3%A9phone
>>
>> Britz
>> Bonne journée
>>
>> Le 22/01/2015 16:25, Vincent Pottier a écrit :
>>
>>> Le 22/01/2015 16:15, Éric Gillet a écrit :
>>>
 Le 22 janvier 2015 15:55, Romain MEHUT >>> romain.me...@gmail.com>> a écrit :

 Ne serait-ce pas plutôt +33 4 12131415  ?


 Je dois avouer que j'ai pas vraiment d'avis sur l'espace séparant les
 groupes de 4 chiffres, les deux variantes existent et la différence n'est
 que cosmétique car les espaces ou tirets après l'indicatif régional (4 ici)
 doivent être ignorés. Si d'autres personnes préfèrent la variante sans
 espace ce sera adjugé vendu :)

  Moi qui n'ai pas assez de mémoire pour stocker 10 chiffres, des
>>> espaces, ça m'aide. et j'aime la forme 01 23 45 67 89
>>>
>>> La forme +33 (0)1 23 45 67 89 n'est pas valide ?
>>> Elle est plus lisibles pour les humains et les Français...
>>> --
>>> FrViPofm
>>>
>>>
>>>
>>>
>>> ___
>>> 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] Services d'OSM-FR plus accessibles suite à panne

2015-01-23 Par sujet Jocelyn Jaubert 
On Fri, Jan 23, 2015 at 08:48:49AM +0100, Jean-Baptiste Holcroft wrote:
> bonjour,
> 
> avez-vous des nouvelles de cette panne ?
> on nous pose la question sur weeklyosm pourquoi live.openstreetmap.fr ne
> fonctionne plus ;)
> j'ai indiqué la panne, mais peut-être que c'est juste le live qui n'a pas
> été réactivé ?

La machine en question vient de replanter :(

Elle avait redémarré correctement, et on ne voyait plus de problème depuis le
redémarrage.

Je vais voir ce qu'on peut faire pour les sites hébergés sur osm3: j'ai peur
qu'il faille tous les migrer sur une autre machine.

-- 
Jocelyn

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

Re: [OSM-talk-fr] Ajout de l'indicatif national aux numéros de téléphone français

2015-01-23 Par sujet Greg 
Personellement, tous les numéros de téléphone de mon répertoire sont au
format international avec les espaces correspondant au format local. Donc
naturellement, je suis favorable à cette modification.

Par contre, il faut faire attention aux numéros courts et numéros spéciaux,
ainsi que les numéros en France non-métropolitaine comme je viens de le
découvrir.

Ensuite, faut-il mettre ces informations dans OSM ? J'ai envie de dire que
strictement parlant, il ne faudrait pas, mais il n'y a pas d'autre base de
données liée qui fournisse ces informations donc je répond "Oui, faute de
mieux". (Et j'avoue bien apprécier quand OsmAnd me donne le numéro de
téléphone d'un point d'intérêt : je n'ai pas toujours Internet avec moi)

Pour ce qui est de l'édition, il faudrait que les éditeurs le prenne en
charge en proposant par exemple le pays en liste déroulante pour ne pas
avoir à chercher l'indicatif. C'est par exemple le cas de Telegram
.

2015-01-23 10:46 GMT+01:00 Brice MALLET :

> Clairement, un affichage avec séparateurs "espace" facilitera l'édition
> dans OSM
> et cela semble la norme pour affichage : http://fr.wikipedia.org/wiki/
> Num%C3%A9ro_de_t%C3%A9l%C3%A9phone
>
> Britz
> Bonne journée
>
> Le 22/01/2015 16:25, Vincent Pottier a écrit :
>
>> Le 22/01/2015 16:15, Éric Gillet a écrit :
>>
>>> Le 22 janvier 2015 15:55, Romain MEHUT >> romain.me...@gmail.com>> a écrit :
>>>
>>> Ne serait-ce pas plutôt +33 4 12131415  ?
>>>
>>>
>>> Je dois avouer que j'ai pas vraiment d'avis sur l'espace séparant les
>>> groupes de 4 chiffres, les deux variantes existent et la différence n'est
>>> que cosmétique car les espaces ou tirets après l'indicatif régional (4 ici)
>>> doivent être ignorés. Si d'autres personnes préfèrent la variante sans
>>> espace ce sera adjugé vendu :)
>>>
>>>  Moi qui n'ai pas assez de mémoire pour stocker 10 chiffres, des
>> espaces, ça m'aide. et j'aime la forme 01 23 45 67 89
>>
>> La forme +33 (0)1 23 45 67 89 n'est pas valide ?
>> Elle est plus lisibles pour les humains et les Français...
>> --
>> FrViPofm
>>
>>
>>
>>
>> ___
>> 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] Réunion contributeurs Toulouse ?

2015-01-23 Par sujet Laurent GUERBY 
On Tue, 2015-01-20 at 11:49 +0100, Florian LAINEZ wrote:
> Merci les gars du Tetaneutral ! Perso cela me convient tout à fait. On
> se retrouve donc à la Paniolade à 19h.

Bonjour,

Merci d'être passé :). N'hesitez pas a me contacter pour
concretiser quelques projets dont nous avons discuté.

Le prochain repas hebdomadaire du libre toulousain est le QJELT
http://lists.tetaneutral.net/pipermail/tetaneutral/2015-January/000207.html
mardi 27 en centre ville (inscription necessaire pour logistique)

Sincèrement,

Laurent


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

Re: [OSM-talk-fr] Ajout de l'indicatif national aux numéros de téléphone français

2015-01-23 Par sujet Brice MALLET 
Clairement, un affichage avec séparateurs "espace" facilitera l'édition 
dans OSM
et cela semble la norme pour affichage : 
http://fr.wikipedia.org/wiki/Num%C3%A9ro_de_t%C3%A9l%C3%A9phone


Britz
Bonne journée

Le 22/01/2015 16:25, Vincent Pottier a écrit :

Le 22/01/2015 16:15, Éric Gillet a écrit :
Le 22 janvier 2015 15:55, Romain MEHUT > a écrit :


Ne serait-ce pas plutôt +33 4 12131415  ?


Je dois avouer que j'ai pas vraiment d'avis sur l'espace séparant les 
groupes de 4 chiffres, les deux variantes existent et la différence 
n'est que cosmétique car les espaces ou tirets après l'indicatif 
régional (4 ici) doivent être ignorés. Si d'autres personnes 
préfèrent la variante sans espace ce sera adjugé vendu :)


Moi qui n'ai pas assez de mémoire pour stocker 10 chiffres, des 
espaces, ça m'aide. et j'aime la forme 01 23 45 67 89


La forme +33 (0)1 23 45 67 89 n'est pas valide ?
Elle est plus lisibles pour les humains et les Français...
--
FrViPofm




___
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