Re: [OSM-talk-fr] erreur Overpass turbo

[David Crochet]

Le 09/11/2015 13:08, Philippe Verdy a écrit :

Si tu veux que tes mails
arrivent sans que tu changes ton adresse mail de souscription,  vérifie
tes paramètres SMTP pour l'envoi du courrier pour utiliser le serveur
SMTP de la poste quand tu écrits ici sous ton adresse mail de la poste.


Que neni, il utilise un DKIM-Signature. Donc c'est Gmail le problème.

Cordialement
--
David Crochet

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

Re: [OSM-talk-fr] Problème de nommage de rue

[Jérôme Seigneuret]

>
>
> Dans les manuels de littérature, c'est le nom complet qui est mentionné et
> le lien  avec la commune semble digne d'être indiqué.
> De bonnes raisons pour éviter l'abréviation .
>
>
Le choix dans OSM est clair de toute façon. Pas d’abréviation dans le name
sinon il y a le tag short_name
 pour cela.
Jérôme
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Problème de nommage de rue

[Ch. Rogel]

De : "Ludovic Hirlimann" 
Date : 9 nov. 2015 
11:17:35Sujet : Re: [OSM-talk-fr] Problème 
de nommage de rueje n'ai pas de problème avec Jean 
Jacques LEFRANC dans mon exemple. J'ai plus des problèmes avec rue/avenue et 
avec la partie manquante "de pompignan" , comment choisir entre rue et ave ? (j 
pense prendre le de pompugnan car présent dans le cadastre.Dans 
les manuels de littérature, c'est le nom complet qui est mentionné et le lien___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Gestion des périodes historiques pour le patrimoine

[dHuy Pierre]

Il y aussi start_date=C11 ou ~C11 ou même mid C11 pour le milieu du siècle qui 
correspond très bien plutôt que d'inventer un nouveau tag. 


 Le Lundi 9 novembre 2015 11h21, Philippe Verdy  a 
écrit :
   

 tu peux proposer "historic:century=11" si la classification par époque ou 
civilisation est difficile (d'ailleurs elle varie selon les pays ou cultures, 
ce qui est documenté est difficile à standardiser et faire accepter partout).le 
"start_date=*" est plutôt réservé à noter des dates précises (avec un format 
compatible ISO 8601 contenant au minimum une année complète), mais le XIe 
siècle n'est pas assez précis on ne peut pas non plus mettre 
"start_date=1001-1100" (format incompatible posant problème), start_date=1001 
(oui, le XIe siècle commence l'année suivant l'an mil) ou start_date=1050 
(milieu du siècle) serait au contraire trop précis (rien n'indique que c'est en 
fait une estimation à plus ou mois 50 ans près).
Le 9 novembre 2015 11:07, Jérôme Seigneuret  a écrit :

Bonjour, en faisant un fix sur le nom d'une église je me retrouve à 
avoir:Église ST Barthélémy XIième siècle que je corrige en Église 
Saint-Barthélémy-de-Baillarguet
Mon problème est d'ajouter l'information lié au XI ème siècle> période du moyen 
age central + précision sur le siècle
Ducoup je regarde du coté des tags 
http://wiki.openstreetmap.org/wiki/FR:Key:historic:civilizationhistoric:period=
start_date=

Je me rend compte que rien n'est précisé sur les siècles tel que l'on a 
l'habitude de l'utilisé d'une part et que les grandes périodes de notre 
civilisation ne sont pas détaillé:
préhistoire et protohistoire c'est OK   
   - historic:civilization=prehistoric 
   - historic:civilization=protohistoric 

Reste les périodes après JC et les périodes spécifique à des régions
moyen-age :vie ‑xve
haut Moyen Âge = : vie ‑ xe siècleMoyen Âge central : xie ‑ xiiie siècleMoyen 
Âge tardif : xive ‑ xve siècle

époque moderne :
Époque moderne antérieure :1492 – 1792
époque contemporaine :

Époque moderne I : 1792 – 1920Époque moderne II : 1920 à nos jours


Bonne journéeJérôme

___
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] erreur Overpass turbo

[Philippe Verdy]

Non c'est la poste qui n'a pas validé dans son enregistrement DNS l'adresse
IP de tous ses serveurs SMTP sortants pu qui n'a pas o stable les
extensions s nécessaires sur tous ses serveurs. Gmail diagnostique que
cette adresse n'est pas authentifiée correctement. Cependant ce n'est pas e
cas du mail direct que tu viens de m'envoyer et dont la source est
authentifiée. La Poste n'utilise sans doute pas les mêmes serveurs sortants
selon que tu écrits à la liste OSM hébergée aux USA ou directement à un
côté personnel comme le mien.

Je voulais juste t'en informer car cela peut limiter l'audience attendue
des messages que tu postes à la liste et il y a de nombreux inscrits ici
avec Gmail, qui n'ont même pas vu que tes messages finissaient dans les
spams. Et ce problème touche certainement d'autres utilisateurs de la poste
qui ont du mal à recevoir certains courriers ou se plaignent de n'avoir
aucune réponse quand ces messages sont filtres indépendamment des auteurs
ou des contenus.
Le 9 nov. 2015 13:28, "David Crochet"  a écrit :

> Le 09/11/2015 13:08, Philippe Verdy a écrit :
>
>> Si tu veux que tes mails
>> arrivent sans que tu changes ton adresse mail de souscription,  vérifie
>> tes paramètres SMTP pour l'envoi du courrier pour utiliser le serveur
>> SMTP de la poste quand tu écrits ici sous ton adresse mail de la poste.
>>
>
> Que neni, il utilise un DKIM-Signature. Donc c'est Gmail le problème.
>
> Cordialement
> --
> David Crochet
>
> ___
> 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] Import de traces GPS et conversion en chemins

[pepilepi...@ovh.fr]

Le 09/11/2015 15:32, Greg a écrit :
> Pour résumer, on va dire que la communauté est très frileuse
> concernant les imports car la donnée est rarement directement
> utilisable, il faut toujours retravailler. Dans le cas des traces GPX,
> c'est améliorer et intégrer le tracé qui est souhaité (ajouter des
> points là où il faut, les supprimer dans les sections droites,
> fusionner les intersections avec d'autres chemins...).
>
> Donc une trace GPX, c'est un outil de base, à utiliser avec l'imagerie
> aérienne et le cadastre pour croiser les sources.
>
> Et le cadastre n'est pas non plus intégralement dans OSM pour les
> mêmes raisons : pas d'import brut, mais de l'intégration manuelle pour
> garantir une qualité des données plutôt que la quantité.

C'est clair, merci.

JP


>
>
>
> 2015-11-08 23:09 GMT+01:00  >:
>
> Pour le cadastre, sous JOSM, il y a un greffon qui te permet
> d'afficher le cadastre en fond de plan.
> Vérifie le calage par rapport à des éléments existants dans OSM ou
> des orthophotographies.
>
> Sur le côté "aider un nouveau", c'est toi qui va nous aider ;-).
>
> Et on est toujours nouveau sur certains sujets.
> Cette liste permet même de se poser des questions sur des sujets
> dont on ignorait même l'existence ! Et de progresser sur des
> sujets que l'on pensait bien connaître.
>
> Jean-Yvon
>
> ___
> 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] Extractions du cadastre indisponibles

[Gaël Simon]

Bonjour,
Une source de simplification supplémentaire pourrait être de supprimer les 
points "alignés" (à moins de 20 cm ?). Ça pourrait éviter de surcharger la base 
avec des points inutiles, générés souvent aux limites de parcelle. 

Gaël


Le 6 nov. 2015 à 23:32, Tyndare  a écrit :

> Le 6 novembre 2015 22:37, David Crochet  a écrit :
> Le 06/11/2015 21:59, Tyndare a écrit :
>> 
>>  - merge (M) des nœuds proches (20 cm)
> 
> 
> En gros :
> 
> si un point déjà existant dans la base OSM se trouve à moins de x cm d'un
> point de l'extraction de la base cadastre, alors c'est le même.
> c'est ca ?

En fait non, il n'y a aucun lien avec la base OSM, c'est juste une
simplification du fichier extrait du cadastre, qui contient souvent
des points beaucoup trop proches les uns des autres pour que sa vaille
la peine de les distinguer.

> 
>>  - join (J) des nœuds au chemin proche (20 cm)
> 
> si un point déjà existant dans la base OSM se trouve à moins de x cm d'un
> chemin de l'extraction de la base cadastre, alors ajoute ce point au chemin,
> comme cela la prochaine fois, ça fera simplement un "merge".
> j'ai bien compris ?

Non, il ne s'agit toujours pas de merge avec les données de la base OSM.
Le merge est un sujet bien plus compliqué qui est traité ici:
- https://github.com/jecor/bati-fusion
ou là:
- https://github.com/sebastien-bugzilla/BatiOsm

Ici je ne parle toujours que d'extraction brute des données du
cadastre, rien de changé par rapport a avant.

> 
>>  - simplify (Shift-Y) des chemins avec un threshold=0.2
> 
> en d'autres termes ?

Je fais juste référence à la fonction JOSM de simplification des
chemins, comme expliqué sur le Wiki d'import semi automatique du bâti:
http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents

___
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] Import de traces GPS et conversion en chemins

[Greg]

Pour résumer, on va dire que la communauté est très frileuse concernant les
imports car la donnée est rarement directement utilisable, il faut toujours
retravailler. Dans le cas des traces GPX, c'est améliorer et intégrer le
tracé qui est souhaité (ajouter des points là où il faut, les supprimer
dans les sections droites, fusionner les intersections avec d'autres
chemins...).

Donc une trace GPX, c'est un outil de base, à utiliser avec l'imagerie
aérienne et le cadastre pour croiser les sources.

Et le cadastre n'est pas non plus intégralement dans OSM pour les mêmes
raisons : pas d'import brut, mais de l'intégration manuelle pour garantir
une qualité des données plutôt que la quantité.



2015-11-08 23:09 GMT+01:00 :

> Pour le cadastre, sous JOSM, il y a un greffon qui te permet d'afficher le
> cadastre en fond de plan.
> Vérifie le calage par rapport à des éléments existants dans OSM ou des
> orthophotographies.
>
> Sur le côté "aider un nouveau", c'est toi qui va nous aider ;-).
>
> Et on est toujours nouveau sur certains sujets.
> Cette liste permet même de se poser des questions sur des sujets dont on
> ignorait même l'existence ! Et de progresser sur des sujets que l'on
> pensait bien connaître.
>
> Jean-Yvon
>
> ___
> 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] purge d'ingération des adresses de Montpellier

[Jérôme Seigneuret]

Je reviens sur la purge de données

Les propositions d'intégrations (en tous cas pour les données adresses de
Montpellier) ne sont pas retirées même si les adresses existent déjà dans
OSM
exemple : 553 Rue Valéry Larbaud, Montpellier

Adresse intégrée en 2013 et c'est pareil pour beaucoup d'autres. Nominatim
les trouve très bien. La plus part des adresses traitées n'ont pas le nom
de rue intégré dans le nœud portant l'adresse mais la relation est faite
via AssociatedStreet

http://osmose.openstreetmap.fr/fr/map/#zoom=18=43.634557=3.883908=Mapnik=T==1%2C2%2C3==

Et-il possible de forcer la suppression via Nominatim et non un "corrigé" à
la main pour tous les points existant.

Merci,
Jérôme


Le 6 novembre 2015 17:02, Christian Quest  a écrit
:

> Le retour à la normale de cadastre.openstreetmap.fr ne devrait plus
> tarder...
>
>
> On 06/11/2015 10:59, Vincent de Château-Thierry wrote:
> > Bonjour,
> >
> >> De: "Nicolas Moyroud" 
> >>
> >> De même pour cadastre.openstreetmap.fr.
> >> C'est bien dommage ces outils hors service ont tendance à réfréner
> >> quelque peu mes pulsions de contribution ;-)
> > Le problème sur cadastre.openstreetmap.fr est pris en charge mais pas
> encore résolu. Comme indiqué ici :
> > https://github.com/osm-fr/bano/issues/104 on espère une issue rapide.
> >
> > vincent
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> 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] Gestion des périodes historiques pour le patrimoine

[Philippe Verdy]

La syntaxe avec C11 est-elle bien supportée et compatible avec l'ISO ou un
format RFC connu pour les dates? En tout cas celle avec tilde ou avec un
mot clé supplémentaire comme "mid" n'est documentée nulle part. Pour
l'instant start_daye n'est documentée qu'avec une date précise jusqu'à la
seconde,  mais au minimum avec l'année complète et rien pour les autres
intervalles d'incertitude.
Le 9 nov. 2015 13:50, "dHuy Pierre"  a écrit :

> Il y aussi start_date=C11 ou ~C11 ou même mid C11 pour le milieu du siècle
> qui correspond très bien plutôt que d'inventer un nouveau tag.
>
>
>
> Le Lundi 9 novembre 2015 11h21, Philippe Verdy  a
> écrit :
>
>
> tu peux proposer "historic:century=11" si la classification par époque ou
> civilisation est difficile (d'ailleurs elle varie selon les pays ou
> cultures, ce qui est documenté est difficile à standardiser et faire
> accepter partout).
> le "start_date=*" est plutôt réservé à noter des dates précises (avec un
> format compatible ISO 8601 contenant au minimum une année complète), mais
> le XIe siècle n'est pas assez précis on ne peut pas non plus mettre
> "start_date=1001-1100" (format incompatible posant problème),
> start_date=1001 (oui, le XIe siècle commence l'année suivant l'an mil) ou
> start_date=1050 (milieu du siècle) serait au contraire trop précis (rien
> n'indique que c'est en fait une estimation à plus ou mois 50 ans près).
>
> Le 9 novembre 2015 11:07, Jérôme Seigneuret  a
> écrit :
>
> Bonjour, en faisant un fix sur le nom d'une église je me retrouve à avoir:
> Église ST Barthélémy XIième siècle que je corrige en Église
> Saint-Barthélémy-de-Baillarguet
>
> Mon problème est d'ajouter l'information lié au XI ème siècle
> > période du moyen age central + précision sur le siècle
>
> Ducoup je regarde du coté des tags
> http://wiki.openstreetmap.org/wiki/FR:Key:historic:civilization
> historic:period =
> start_date =
>
> Je me rend compte que rien n'est précisé sur les siècles tel que l'on a
> l'habitude de l'utilisé d'une part et que les grandes périodes de notre
> civilisation ne sont pas détaillé:
> préhistoire et protohistoire c'est OK
>
>- *historic:civilization*=prehistoric
>- *historic:civilization*=protohistoric
>
>
> Reste les périodes après JC et les périodes spécifique à des régions
>
> moyen-age :vie ‑xve
>
> haut Moyen Âge = : vie ‑ xe siècle
> Moyen Âge central : xie ‑ xiiie siècle
> Moyen Âge tardif  :
> xive ‑ xve siècle
>
>
> époque moderne :
>
> Époque moderne antérieure :1492 – 1792
>
> époque contemporaine :
>
> Époque moderne I : 1792 – 1920
> Époque moderne II : 1920 à nos jours
>
>
> Bonne journée
> Jérôme
>
>
> ___
> 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] Gestion des périodes historiques pour le patrimoine

[dHuy Pierre]

Je ne pense pas que ça soit ISO effectivement mais largement utilisé et 
documenté sur le Wiki, sur le lien fourni plus haut d'ailleurs. Les logiciels 
comme josm renvoie d'ailleurs à cette page pour ce type de clef donc c'est 
plutôt largement utilisé. Et puis c'est toujours mieux que d'ajouter un tag qui 
ne sera utilisé que par peu de personnes. 


 Le Lundi 9 novembre 2015 15h31, Philippe Verdy  a 
écrit :
   

 La syntaxe avec C11 est-elle bien supportée et compatible avec l'ISO ou un 
format RFC connu pour les dates? En tout cas celle avec tilde ou avec un mot 
clé supplémentaire comme "mid" n'est documentée nulle part. Pour l'instant 
start_daye n'est documentée qu'avec une date précise jusqu'à la seconde,  mais 
au minimum avec l'année complète et rien pour les autres intervalles 
d'incertitude. Le 9 nov. 2015 13:50, "dHuy Pierre"  a écrit :

Il y aussi start_date=C11 ou ~C11 ou même mid C11 pour le milieu du siècle qui 
correspond très bien plutôt que d'inventer un nouveau tag. 


 Le Lundi 9 novembre 2015 11h21, Philippe Verdy  a 
écrit :
   

 tu peux proposer "historic:century=11" si la classification par époque ou 
civilisation est difficile (d'ailleurs elle varie selon les pays ou cultures, 
ce qui est documenté est difficile à standardiser et faire accepter partout).le 
"start_date=*" est plutôt réservé à noter des dates précises (avec un format 
compatible ISO 8601 contenant au minimum une année complète), mais le XIe 
siècle n'est pas assez précis on ne peut pas non plus mettre 
"start_date=1001-1100" (format incompatible posant problème), start_date=1001 
(oui, le XIe siècle commence l'année suivant l'an mil) ou start_date=1050 
(milieu du siècle) serait au contraire trop précis (rien n'indique que c'est en 
fait une estimation à plus ou mois 50 ans près).
Le 9 novembre 2015 11:07, Jérôme Seigneuret  a écrit :

Bonjour, en faisant un fix sur le nom d'une église je me retrouve à 
avoir:Église ST Barthélémy XIième siècle que je corrige en Église 
Saint-Barthélémy-de-Baillarguet
Mon problème est d'ajouter l'information lié au XI ème siècle> période du moyen 
age central + précision sur le siècle
Ducoup je regarde du coté des tags 
http://wiki.openstreetmap.org/wiki/FR:Key:historic:civilizationhistoric:period=
start_date=

Je me rend compte que rien n'est précisé sur les siècles tel que l'on a 
l'habitude de l'utilisé d'une part et que les grandes périodes de notre 
civilisation ne sont pas détaillé:
préhistoire et protohistoire c'est OK   
   - historic:civilization=prehistoric 
   - historic:civilization=protohistoric 

Reste les périodes après JC et les périodes spécifique à des régions
moyen-age :vie ‑xve
haut Moyen Âge = : vie ‑ xe siècleMoyen Âge central : xie ‑ xiiie siècleMoyen 
Âge tardif : xive ‑ xve siècle

époque moderne :
Époque moderne antérieure :1492 – 1792
époque contemporaine :

Époque moderne I : 1792 – 1920Époque moderne II : 1920 à nos jours


Bonne journéeJérôme

___
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] OpenSolarMap...

[Florian LAINEZ]

   - Dans le cas de toits à 4 pans, je mets en général "?", est-ce le cas
   de tout le monde ?

oui, et cela m'arrive très souvent.

Le 9 novembre 2015 11:37, Philippe Verdy  a écrit :

>
>
> Le 9 novembre 2015 11:08, Pierre GRANJON  a écrit :
>
>> Bonjour à tous,
>> Très bonne idée ce projet, et l'outil de crowdsourcing donne envie de
>> participer !
>> J'ai fait 200 ajouts, ça marche très bien mais j'ai quelques commentaires
>> :
>>
>>- Dans le cas de toits à 4 pans, je mets en général "?", est-ce le
>>cas de tout le monde ?
>>
>> Si les deux autres pans sont seulemnt sur les pignons  et que la plus
> grande partie du toit est à double pente, il men semble qu'on peut ignorer
> ces pignons.
>
> D'ailleurs la classification demandée se contente juste de chercher deux
> orientations possibles pour les double pentes, ou le toit plat (difficile
> malgré tout de voir sur une photo aérienne si le toit est réellement plat
> ou en pente, et encore plus de voir son orientation réelle qui peut très
> bien être vers l'est ou le nord et pas favorable aux panneaux solaires: cas
> assez fréquents pour les toits métailliques de batiments commerciaux,
> industriels ou agricoles, sachant que bon nombre de batiments d'élevage
> sont faits avec des orientations favorables destinées à optimiser les couts
> de chauffage/climatisation et augmenter le rendement énergétique global,
> même sans aucun panneau solaire: cette étude thermique des batiments
> agricoles se fait depuis de nombreuses décennies: voir avec le CEMAGREF qui
> a fait des études avec les chambres d'agricultures et syndicats ou
> coopératives agricoles et même développé des logiciels pour ça, incluant
> aussi l'études des matériaux, des données météo moyennes, et les
> équipements de ventilisation ou récupérateurs de chaleur).
>
>>
>>- Enfin, j'ai repéré quelques panneaux solaires déjà existants, pour
>>lesquels j'ai tout  de même renseigné l'orientation. Ca pourrait être
>>l'occasion de recenser l'existant en panneaux solaires ?
>>
>> S'il y a des panneaux solaires visibles, l'emplacement est à priori
> favorable pour ça et ce serait utile de pouvoir cliquer sur une icone pour
> les toits déjà équipés, sans même avoir à saisir l'orientatation réelle qui
> aura peu d'intérêt pour cette application.
>
> De plus dans de nombreuses zones urbaines, les toits de batiments mitoyens
> d'une même rue adoptent une orientation commune (en cas d'ambiguité sur un
> ds batiments les batiments voisins mieux visibles peuvent donner une
> indication du potentiel sur toute une rue, notamment s'il y a déjà des
> batiments équipés).
>
> ___
> 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] [OSMOSE] purge d'ingération des adresses de Montpellier

[Frédéric Rodrigo]

La distance de rapprochement est de 15m, ça ne semple pas suffisant pour 
Montpellier compte tenu que l'OpenData à l'air d'être à l'entré de la 
propriété et que les données OSM dans ce coin sont sur l'entré du bâtiment.


L'analyse Osmose ne tient pas compte de la rue, juste le numéro.


Le 09/11/2015 15:15, Jérôme Seigneuret a écrit :

Je reviens sur la purge de données

Les propositions d'intégrations (en tous cas pour les données adresses 
de Montpellier) ne sont pas retirées même si les adresses existent 
déjà dans OSM

exemple : 553 Rue Valéry Larbaud, Montpellier

Adresse intégrée en 2013 et c'est pareil pour beaucoup d'autres. 
Nominatim les trouve très bien. La plus part des adresses traitées 
n'ont pas le nom de rue intégré dans le nœud portant l'adresse mais la 
relation est faite via AssociatedStreet


http://osmose.openstreetmap.fr/fr/map/#zoom=18=43.634557=3.883908=Mapnik=T==1%2C2%2C3==

Et-il possible de forcer la suppression via Nominatim et non un 
"corrigé" à la main pour tous les points existant.


Merci,
Jérôme


Le 6 novembre 2015 17:02, Christian Quest > a écrit :


Le retour à la normale de cadastre.openstreetmap.fr
 ne devrait plus
tarder...


On 06/11/2015 10:59, Vincent de Château-Thierry wrote:
> Bonjour,
>
>> De: "Nicolas Moyroud" >
>>
>> De même pour cadastre.openstreetmap.fr
.
>> C'est bien dommage ces outils hors service ont tendance à réfréner
>> quelque peu mes pulsions de contribution ;-)
> Le problème sur cadastre.openstreetmap.fr
 est pris en charge mais pas
encore résolu. Comme indiqué ici :
> https://github.com/osm-fr/bano/issues/104 on espère une issue
rapide.
>
> vincent
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr

--
Christian Quest - OpenStreetMap France


___
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] JOSM : couleur de base de la page de téléchargement

[Philippe Verdy]

Regarde dans tes spams,  je l'ai déjà signalé en privé à Bernard,  ses
mails sont envoyés par un serveur SMTP non authentifié par son fournisseur
de messagerie la poste.net... Sa signature DKIM est invalide... Gmail par
exemple classe ses messages en spam
Le 9 nov. 2015 21:08, "Jérôme Seigneuret"  a
écrit :

> Normal que l'on ne voit pas le message initial de Bernard dans la liste?
>
> Le 9 novembre 2015 20:59, David Crochet  a écrit :
>
>> Bonjour
>>
>> Le 09/11/2015 19:39, bernard a écrit :
>>
>>> Bonjour,
>>> Je viens de remarquer que les couleurs de la page de téléchargement de
>>> JOSM ont changé.
>>> Les Primary prennent la couleur des secondary
>>> Les Secondary celles des Tertiary
>>> Les Tertiary n'en a plus.
>>> Je n'ai touché à aucun réglage
>>>
>>
>> Normal
>>
>>
>>> Par ailleurs, lors de la coupure d'un way, il s'affiche une boite de
>>> dialogue qui nécessite un clic ... inutile.
>>> Pour quelle raison cette modification?
>>>
>>
>> JOSM est un logiciel en constante évolution. S'il y a évolution, c'est
>> qu'il y a demande d'évolution.
>>
>> Cordialement
>>
>> --
>> David Crochet
>>
>> ___
>> 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] JOSM : couleur de base de la page de téléchargement

[Philippe Verdy]

Même diagnostic pour toi Vincent,  puisque tu es à la poste..  Toi aussi
t'es messages vont automatiquement dans la boîte spam. Le problème est donc
à la poste sur leurs serveurs SMTP sortants mal configurés...
Le 9 nov. 2015 21:38, "Vincent de Château-Thierry"  a
écrit :

> Bonsoir,
>
> Le 09/11/2015 21:07, Jérôme Seigneuret a écrit :
>
>> Normal que l'on ne voit pas le message initial de Bernard dans la liste?
>>
>
> Il est bien là :
> https://lists.openstreetmap.org/pipermail/talk-fr/2015-November/078585.html
>
> Le 9 novembre 2015 20:59, David Crochet > > a écrit :
>>
>> Bonjour
>>
>> Le 09/11/2015 19:39, bernard a écrit :
>>
>> Bonjour,
>> Je viens de remarquer que les couleurs de la page de
>> téléchargement de
>> JOSM ont changé.
>> Les Primary prennent la couleur des secondary
>> Les Secondary celles des Tertiary
>> Les Tertiary n'en a plus.
>> Je n'ai touché à aucun réglage
>>
>> Normal
>>
>
> La charte par défaut d'osm.org a changé il y a une semaine :
> https://blog.openstreetmap.org/2015/10/30/openstreetmap-org-map-changing/
> C'est celle qui s'affiche aussi dans JOSM par défaut. On l'a évoqué ici :
> https://lists.openstreetmap.org/pipermail/talk-fr/2015-October/078440.html
>
>
> Par ailleurs, lors de la coupure d'un way, il s'affiche une boite
>> de
>> dialogue qui nécessite un clic ... inutile.
>> Pour quelle raison cette modification?
>>
>>
>> JOSM est un logiciel en constante évolution. S'il y a évolution,
>> c'est qu'il y a demande d'évolution.
>>
>
> Cette évolution fait la "une" des changements de la dernière version
> stable : https://josm.openstreetmap.de/wiki/Fr%3AStartupPage
>
> 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] OpenSolarMap...

[osm . sanspourriel]

Oui, effectivement on en rencontre beaucoup.
La règle est simple, comme dit par Christian, tout ce qui n'est pas N/S, 
E/O ou plat est ?.
? étant donc autre et non une question (l'iconographie est ici peu 
explicite, et quand je ne sais pas plutôt que de répondre, je rafraichis 
la page plutôt que de répondre "autre".
Comme pour les sondages, NSP (Ne Se Prononce Pas) est une réponse 
différente de "autre".
"autre" c'est toit de travers par rapport aux points cardinaux, et qui 
n'est pas plat.

"NSP" c'est un toit mal identifiable.

Je comprends le soucis de simplification, mais là on risque de perdre en 
qualité.
Arrêter de demander pour un toit à peu près plat dont la vue aérienne 
est insuffisante aboutira à une classification en ? c'est à dire mauvais 
alors que la "bonne" réponse est qu'il faut regarder de plus près.


Sinon pouvoir étendre la sélection aux bâtiments de la rue s'ils ont 
même orientation permettrait de gagner du temps.


J'allais oublier, une requête overpass sur les highway sans 
landuse=forest ou forte densité urbaine à côté va pouvoir suffire :

http://www.parismatch.com/Actu/Environnement/Les-routes-solaires-l-energie-de-demain-Revetement-photovoltaique-861963
;-)

N'oublions pas que les talus nord des autoroutes est-ouest (murs 
antibruits par exemple) sont aussi de bon emplacements.


Jean-Yvon

Le 09/11/2015 15:53, Florian LAINEZ - winner...@free.fr a écrit :


  * Dans le cas de toits à 4 pans, je mets en général "?", est-ce le
cas de tout le monde ?

oui, et cela m'arrive très souvent.


Le 9 novembre 2015 11:37, Philippe Verdy > a écrit :




Le 9 novembre 2015 11:08, Pierre GRANJON > a écrit :

Bonjour à tous,
Très bonne idée ce projet, et l'outil de crowdsourcing donne
envie de participer !
J'ai fait 200 ajouts, ça marche très bien mais j'ai quelques
commentaires :

  * Dans le cas de toits à 4 pans, je mets en général "?",
est-ce le cas de tout le monde ?

Si les deux autres pans sont seulemnt sur les pignons  et que la
plus grande partie du toit est à double pente, il men semble qu'on
peut ignorer ces pignons.

D'ailleurs la classification demandée se contente juste de
chercher deux orientations possibles pour les double pentes, ou le
toit plat (difficile malgré tout de voir sur une photo aérienne si
le toit est réellement plat ou en pente, et encore plus de voir
son orientation réelle qui peut très bien être vers l'est ou le
nord et pas favorable aux panneaux solaires: cas assez fréquents
pour les toits métailliques de batiments commerciaux, industriels
ou agricoles, sachant que bon nombre de batiments d'élevage sont
faits avec des orientations favorables destinées à optimiser les
couts de chauffage/climatisation et augmenter le rendement
énergétique global, même sans aucun panneau solaire: cette étude
thermique des batiments agricoles se fait depuis de nombreuses
décennies: voir avec le CEMAGREF qui a fait des études avec les
chambres d'agricultures et syndicats ou coopératives agricoles et
même développé des logiciels pour ça, incluant aussi l'études des
matériaux, des données météo moyennes, et les équipements de
ventilisation ou récupérateurs de chaleur).




--

*Florian Lainez*

@overflorian 


___
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] Gestion des périodes historiques pour le patrimoine

[osm . sanspourriel]

Moi aussi ça me va.

Pour plus de clarté je suis pour l'utilisation des tirets dans l'ISO 
8601 pour désigner des dates.

Soit :
1001..1099 - 1492-02-12..1492-02-13
C'est moins cabalistique.

Pour la fameuse année zéro, comme vous de savez pas à 4 ans près (ou 
plus) quand le Jésus Christ a poussé son premier Christ, heu cri, donner 
des dates antérieures à une précision de +/- 1 an, on s'en fiche (pour 
les données qui nous concernent).


Jean-Yvon

Le 09/11/2015 17:10, Jérôme Seigneuret - jseigneuret-...@yahoo.fr a écrit :


Si on voulait préciser une construction s'étalant du 11e siècle au
15e, cela donnerait "1001..1099 - 1401..1499". Si on peut dater
plus précisément une date, par exemple février 1492 pour la
seconde borne au lieu du simple 15e siècle, cela donnerait
"1001..1099 - 1492-02"

Je trouve ça plutôt intéressant

Mais si la construction s'est achevée encore plus précisément le
12 ou le 13 février, cela donnerait "1001..1099 -
1492-02-12..1492-02-13" (les 4 dates mentionnée sont toutes en
format compatible ISO 8601 (lequel format n'inclut aucune espace
ni aucun point... mais admet qu'on puisse supprimer les
séparateurs "-" entre les composants année-mois-jour à condition
de mettre les années sur 4 chiffres minimum, donc autoriserait
aussi qu'on utilise pour nos intervalles: ""1001..1099 -
14920212..14920213").

Moi ça me va




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

Re: [OSM-talk-fr] Gestion des périodes historiques pour le patrimoine

[Jérôme Seigneuret]

Le 9 novembre 2015 16:58, Philippe Verdy  a écrit :

> Le 9 novembre 2015 16:12, Jérôme Seigneuret  a
> écrit :
>
>> C'est implémenté dans les langages. C'est le principe de passage forcé
>> d'un centenaire avec deux caractères vers 4 caractères YYto
>>
>> Donc C11 renvoi vers 1100-1199 (équivalent OSM 1100..1199)
>>
>
> Ce qui est le **12e** siècle et pas le 11e ! Piège courant (aussi bien en
> anglais qu'en français d'ailleurs). On est aujourd'hui au 21e siècle, pas
> au 20e même si les deux premiers chiffres de l'année commencent par 20, les
> siècles sont comptés à partir de 1, il n'y a pas de siècle zéro !
>

En effet donc dans mon cas c'est C10

>
> mais on peut aussi faire C1150 qui renvoi 1150-1249
>> (équivalent OSM 1150..1249)
>>
>
> Encore plus "merdique", car C11 désigne un siècle (lequel??) mais C1150
> désigne une année de départ, quid alors du siècle débutant en année 11, il
> faut l'écrire alors C0011 ?
>

Exact en tous cas c'est comme ça que le code le prévois


>
> Pour les préfixes c'est interne à OSM comme ~ et autres. Ca mérite à être
>> simplifié ou à proposer des correspondances d'écritures
>>
>> Le but étant de gérer uniformément l'incertitude
>>
>
> Oui pour que ce soit uniforme, mais alors réfléchir à quelquechose de
> cohérent. Le message de départ donnait le 11è siècle, mais là tu as répondu
> avec le 12è !
>
Je suis d'accord merci pour cette correction


>
> Bref comme d'habitude, les tags sous OSM sont créés à la volée, on en
> discute après et ensuite on essaye d'uniformiser et on sse rend compte que
> tout le monde ne comprend pas le même langage. Le minimum serait de
> documenter même les essais sur le wiki afin de pouvoir les critiquer et
> ensuite trouver des solutions d'uniformisation et de migration, puis
> réparer tout ça dans la base car à la longue ces tags multiples compliquent
> les applications de tout le monde.
>
> Je ne dis pas le contraire. Mais mieux vaut le faire maintenant que quand
ce sera déjà utilisé par 5 contributeurs avec des méthodes différentes


> Quitte à faire simple et non ambigu, il serait préférable de mentionner un
> intervalle entre deux dates au format ISO8601 (année, année-mois, ou
> année-mois-jour) et ne pas avoir à se soucier des unités. La première
> réponse était plus simplet et au moins non ambigue le 11e siècle était
> historic:century=11
>

Oui mais finalement on sort du schéma pour créer une nouvelle clé...


> Note, on a aussi besoin d'intervalles pour des périodes de construction
> avec pour les deux bornes des intertitudes. L'usage pour les intervalles
> c'est d'utiliser le signe " - " encadré d'espaces pour ne pas entrer en
> conflit avec le "-" accollé sans espace entre les éléménts d'une date ISO
> 8601. Il donc faut un autre séparateur pour les marges d'intertitude.
>
> Si on voulait préciser une construction s'étalant du 11e siècle au 15e,
> cela donnerait "1001..1099 - 1401..1499". Si on peut dater plus précisément
> une date, par exemple février 1492 pour la seconde borne au lieu du simple
> 15e siècle, cela donnerait "1001..1099 - 1492-02"
>
> Je trouve ça plutôt intéressant


> Mais si la construction s'est achevée encore plus précisément le 12 ou le
> 13 février, cela donnerait "1001..1099 - 1492-02-12..1492-02-13" (les 4
> dates mentionnée sont toutes en format compatible ISO 8601 (lequel format
> n'inclut aucune espace ni aucun point... mais admet qu'on puisse supprimer
> les séparateurs "-" entre les composants année-mois-jour à condition de
> mettre les années sur 4 chiffres minimum, donc autoriserait aussi qu'on
> utilise pour nos intervalles: ""1001..1099 - 14920212..14920213").
>
Moi ça me va

>
> Autre difficulté: les siècles avant Jesus-Christ (important pour dater le
> patrimoine historique). Par convention on suit la date de "BC" en anglais,
> toujours en fin de date donc après l'indication éventuelle du mois et du
> jour, pas entre l'année et le mois. Mais là aussi on n'a alors pas d'année
> "zéro" dans les calendriers, l'année qui précède l'année 0001 est alors
> l'année 0001BC mais en notation astronomique cette année est désignée
> "" et les années précédentes sont décalées de 1 par rapport aux année
> calendaires, en utilisant un signe "-" avant l'année, donc "-0001" désigne
> "0002BC". Les années après Jesus-Christ sont dans l'ère "AD" masi il n'est
> pas utile de l'indiquer si on veut garder la compatibilité ISO 8601 des
> dates d'aujourd'hui où aucun suffixe d'ère n'est nécessaire pour l'actuel
> calendrier grégorien.
>

Bref, il y a du taf. On commence par quoi?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Comment tagguer une résidence/cité comportant plusieurs bâtiments?

[Jérôme Seigneuret]

Bonjour,
Le nom de la résidence se met par usage sur le landuse. Il faut découper le
landuse existant pour éviter les superpositions de landuse.

Le nom du bâtiment sur building

Jérôme

Le 9 novembre 2015 19:39, Julien Noblet  a écrit :

> Bonjour,
> Je viens vers vous pour savoir comment taguer une résidence ou une cité de
> plusieurs bâtiments.
> J'avais pensé à une relation de "type"="site"
> name=
> Avec un chemin avec un rôle perimeter, et les bâtiments avec un rôle
> building.
> Chaque bâtiment peut avoir un nom (ou plutôt une ref) name/ref = Bâtiment
> A/B/C/D...
>
> Quels tags devraient être ajoutés la relation?
>
> Est-ce que j'ai tout faux et je devrais utiliser sur les bâtiment un
> addr:place ou addr:X=?
>
> Merci par avance.
> Librement.
>
> Julien_N
>
> ___
> 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] Parking/Aire de covoiturage

[Gautier]

Bonsoir,

Je me permet de copier une question que j'ai posé sur le forum 
(http://forum.openstreetmap.fr/viewtopic.php?f=2=2338=9737#p9737), 
en espérant qu'une solution soit trouvée :


Il existe de plus en plus de parkings dédiés au covoiturage, mais je 
n'ai rien trouvé pour cartographier ces éléments proprement. Le plus 
proche serait d'utiliser amenity=car_sharing 
 mais 
ce n'est pas du covoiturage à proprement parler.
La plupart des parkings de covoiturage sont de simples parkings avec 
name=Aire de covoiturage ou name=Parking de covoiturage. Peut-on faire 
mieux ?


Nicolas Dumoulin, sur le forum, m'a proposé la solution 
http://www.openstreetmap.org/way/128277712 à savoir :


- amenity=parking
- carpool=designated
- name=Aire de covoiturage
- park_ride=yes

Qu'en pensez-vous ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Gestion des périodes historiques pour le patrimoine

[Jérôme Seigneuret]

Bien. On va essayer déjà de faire ça en français et faire une propos
ensuite sur le wiki comme discussion en anglais mais on est déjà à un
premier niveau de réflexion sur la liste.

A voir donc :
- les besoins et les propositions possibles.
- les équivalences
- quel schéma est :

   - plus flexible et permet de traiter le plus de cas,
   - plus simple pour les contributeurs ou un outil permettant d'avoir
   quelque chose de semi-auto dixit opening_hours

- comment éviter les concurrences



Le 9 novembre 2015 18:16, Philippe Verdy  a écrit :

> On commence par en discuter en cherchant les différentes solutions et
> difficultés. Tout cela devrait être sur le wiki en vue d'une révision des
> schémas de clé.
> Mais comme d'habitude, les clés sont introduites expérimentalement par
> quelques uns, et ensuite on discute de la façon de fusionner les
> différentes idées. Après vient la question du nettoyage car on ne peut pas
> tout garder dans les applis.
> En attendant les clés non discutées, trop nombreuses, insuffisamment
> réfléchies, polluent la base et n'ont d'intérêt qu'e de façon informative à
> condition de chercher comment les interpréter humainement, on est loin de
> pouvoir automatiser les traitements, mais là en plus on ne peuyt même pas
> dire qu'il s'agit d'erreurs. Tout cela n'est qu'expérimental mais
> malheureusement sans discussion ouverte.
> Note: cette liste francophone ne suffit pas. D'une façon ou d'une autre il
> faut rendre ça visible sur le wiki et tenter des traductions anglaises même
> maladroites pour pouvoir en débattre au plan international.
> Mais la difficulté se corse quand dans un pays donné il y a eu des imports
> massifs avec des nouvelles clés ou codifications de valeurs choisies
> indépendamment de tout ce qui se fait ailleurs et sans même chercher à
> s'appuyer sur des normes connues (comme ici l'ISO 8601 ou les convetions
> CLDR ou des nomenclatures internationales existantes, ou quand les clés
> sont choisies de façon très paresseuse et entrent en conflit avec d'autres
> parce qu'aucune recherche n'a été faite avant de les utiliser pour autre
> chose)
>
> Le 9 novembre 2015 17:10, Jérôme Seigneuret  a
> écrit :
>
>>
>>
>> Le 9 novembre 2015 16:58, Philippe Verdy  a écrit :
>>
>>> Le 9 novembre 2015 16:12, Jérôme Seigneuret 
>>> a écrit :
>>>
 C'est implémenté dans les langages. C'est le principe de passage forcé
 d'un centenaire avec deux caractères vers 4 caractères YYto

 Donc C11 renvoi vers 1100-1199 (équivalent OSM 1100..1199)

>>>
>>> Ce qui est le **12e** siècle et pas le 11e ! Piège courant (aussi bien
>>> en anglais qu'en français d'ailleurs). On est aujourd'hui au 21e siècle,
>>> pas au 20e même si les deux premiers chiffres de l'année commencent par 20,
>>> les siècles sont comptés à partir de 1, il n'y a pas de siècle zéro !
>>>
>>
>> En effet donc dans mon cas c'est C10
>>
>>>
>>> mais on peut aussi faire C1150 qui renvoi 1150-1249
 (équivalent OSM 1150..1249)

>>>
>>> Encore plus "merdique", car C11 désigne un siècle (lequel??) mais C1150
>>> désigne une année de départ, quid alors du siècle débutant en année 11, il
>>> faut l'écrire alors C0011 ?
>>>
>>
>> Exact en tous cas c'est comme ça que le code le prévois
>>
>>
>>>
>>> Pour les préfixes c'est interne à OSM comme ~ et autres. Ca mérite à
 être simplifié ou à proposer des correspondances d'écritures

 Le but étant de gérer uniformément l'incertitude

>>>
>>> Oui pour que ce soit uniforme, mais alors réfléchir à quelquechose de
>>> cohérent. Le message de départ donnait le 11è siècle, mais là tu as répondu
>>> avec le 12è !
>>>
>> Je suis d'accord merci pour cette correction
>>
>>
>>>
>>> Bref comme d'habitude, les tags sous OSM sont créés à la volée, on en
>>> discute après et ensuite on essaye d'uniformiser et on sse rend compte que
>>> tout le monde ne comprend pas le même langage. Le minimum serait de
>>> documenter même les essais sur le wiki afin de pouvoir les critiquer et
>>> ensuite trouver des solutions d'uniformisation et de migration, puis
>>> réparer tout ça dans la base car à la longue ces tags multiples compliquent
>>> les applications de tout le monde.
>>>
>>> Je ne dis pas le contraire. Mais mieux vaut le faire maintenant que
>> quand ce sera déjà utilisé par 5 contributeurs avec des méthodes
>> différentes
>>
>>
>>> Quitte à faire simple et non ambigu, il serait préférable de mentionner
>>> un intervalle entre deux dates au format ISO8601 (année, année-mois, ou
>>> année-mois-jour) et ne pas avoir à se soucier des unités. La première
>>> réponse était plus simplet et au moins non ambigue le 11e siècle était
>>> historic:century=11
>>>
>>
>> Oui mais finalement on sort du schéma pour créer une nouvelle clé...
>>
>>
>>> Note, on a aussi besoin d'intervalles pour des périodes de construction
>>> avec pour les deux bornes des intertitudes. L'usage 

[OSM-talk-fr] JOSM : couleur de base de la page de téléchargement

[bernard]

Bonjour,
Je viens de remarquer que les couleurs de la page de téléchargement de 
JOSM ont changé.

Les Primary prennent la couleur des secondary
Les Secondary celles des Tertiary
Les Tertiary n'en a plus.
Je n'ai touché à aucun réglage

Par ailleurs, lors de la coupure d'un way, il s'affiche une boite de 
dialogue qui nécessite un clic ... inutile.

Pour quelle raison cette modification?
Bonne soirée et merci pour vos réponses


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

[OSM-talk-fr] Comment tagguer une résidence/cité comportant plusieurs bâtiments?

[Julien Noblet]

Bonjour,
Je viens vers vous pour savoir comment taguer une résidence ou une cité de
plusieurs bâtiments.
J'avais pensé à une relation de "type"="site"
name=
Avec un chemin avec un rôle perimeter, et les bâtiments avec un rôle
building.
Chaque bâtiment peut avoir un nom (ou plutôt une ref) name/ref = Bâtiment
A/B/C/D...

Quels tags devraient être ajoutés la relation?

Est-ce que j'ai tout faux et je devrais utiliser sur les bâtiment un
addr:place ou addr:X=?

Merci par avance.
Librement.

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

Re: [OSM-talk-fr] Gestion des périodes historiques pour le patrimoine

[Jérôme Seigneuret]

C'est implémenté dans les langages. C'est le principe de passage forcé d'un
centenaire avec deux caractères vers 4 caractères YYto

Donc C11 renvoi vers 1100-1199 (équivalent OSM 1100..1199)
mais on peut aussi faire C1150 qui renvoi 1150-1249
(équivalent OSM 1150..1249)

Pour les préfixes c'est interne à OSM comme ~ et autres. Ca mérite à être
simplifié ou à proposer des correspondances d'écritures

Le but étant de gérer uniformément l'incertitude


Le 9 novembre 2015 15:46, dHuy Pierre  a écrit :

> Je ne pense pas que ça soit ISO effectivement mais largement utilisé et
> documenté sur le Wiki, sur le lien fourni plus haut d'ailleurs. Les
> logiciels comme josm renvoie d'ailleurs à cette page pour ce type de clef
> donc c'est plutôt largement utilisé. Et puis c'est toujours mieux que
> d'ajouter un tag qui ne sera utilisé que par peu de personnes.
>
>
>
> Le Lundi 9 novembre 2015 15h31, Philippe Verdy  a
> écrit :
>
>
> La syntaxe avec C11 est-elle bien supportée et compatible avec l'ISO ou un
> format RFC connu pour les dates? En tout cas celle avec tilde ou avec un
> mot clé supplémentaire comme "mid" n'est documentée nulle part. Pour
> l'instant start_daye n'est documentée qu'avec une date précise jusqu'à la
> seconde,  mais au minimum avec l'année complète et rien pour les autres
> intervalles d'incertitude.
> Le 9 nov. 2015 13:50, "dHuy Pierre"  a écrit :
>
> Il y aussi start_date=C11 ou ~C11 ou même mid C11 pour le milieu du siècle
> qui correspond très bien plutôt que d'inventer un nouveau tag.
>
>
>
> Le Lundi 9 novembre 2015 11h21, Philippe Verdy  a
> écrit :
>
>
> tu peux proposer "historic:century=11" si la classification par époque ou
> civilisation est difficile (d'ailleurs elle varie selon les pays ou
> cultures, ce qui est documenté est difficile à standardiser et faire
> accepter partout).
> le "start_date=*" est plutôt réservé à noter des dates précises (avec un
> format compatible ISO 8601 contenant au minimum une année complète), mais
> le XIe siècle n'est pas assez précis on ne peut pas non plus mettre
> "start_date=1001-1100" (format incompatible posant problème),
> start_date=1001 (oui, le XIe siècle commence l'année suivant l'an mil) ou
> start_date=1050 (milieu du siècle) serait au contraire trop précis (rien
> n'indique que c'est en fait une estimation à plus ou mois 50 ans près).
>
> Le 9 novembre 2015 11:07, Jérôme Seigneuret  a
> écrit :
>
> Bonjour, en faisant un fix sur le nom d'une église je me retrouve à avoir:
> Église ST Barthélémy XIième siècle que je corrige en Église
> Saint-Barthélémy-de-Baillarguet
>
> Mon problème est d'ajouter l'information lié au XI ème siècle
> > période du moyen age central + précision sur le siècle
>
> Ducoup je regarde du coté des tags
> http://wiki.openstreetmap.org/wiki/FR:Key:historic:civilization
> historic:period =
> start_date =
>
> Je me rend compte que rien n'est précisé sur les siècles tel que l'on a
> l'habitude de l'utilisé d'une part et que les grandes périodes de notre
> civilisation ne sont pas détaillé:
> préhistoire et protohistoire c'est OK
>
>- *historic:civilization*=prehistoric
>- *historic:civilization*=protohistoric
>
>
> Reste les périodes après JC et les périodes spécifique à des régions
>
> moyen-age :vie ‑xve
>
> haut Moyen Âge = : vie ‑ xe siècle
> Moyen Âge central : xie ‑ xiiie siècle
> Moyen Âge tardif  :
> xive ‑ xve siècle
>
>
> époque moderne :
>
> Époque moderne antérieure :1492 – 1792
>
> époque contemporaine :
>
> Époque moderne I : 1792 – 1920
> Époque moderne II : 1920 à nos jours
>
>
> Bonne journée
> Jérôme
>
>
> ___
> 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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Gestion des périodes historiques pour le patrimoine

[Philippe Verdy]

Le 9 novembre 2015 16:12, Jérôme Seigneuret  a
écrit :

> C'est implémenté dans les langages. C'est le principe de passage forcé
> d'un centenaire avec deux caractères vers 4 caractères YYto
>
> Donc C11 renvoi vers 1100-1199 (équivalent OSM 1100..1199)
>

Ce qui est le **12e** siècle et pas le 11e ! Piège courant (aussi bien en
anglais qu'en français d'ailleurs). On est aujourd'hui au 21e siècle, pas
au 20e même si les deux premiers chiffres de l'année commencent par 20, les
siècles sont comptés à partir de 1, il n'y a pas de siècle zéro !

mais on peut aussi faire C1150 qui renvoi 1150-1249
> (équivalent OSM 1150..1249)
>

Encore plus "merdique", car C11 désigne un siècle (lequel??) mais C1150
désigne une année de départ, quid alors du siècle débutant en année 11, il
faut l'écrire alors C0011 ?

Pour les préfixes c'est interne à OSM comme ~ et autres. Ca mérite à être
> simplifié ou à proposer des correspondances d'écritures
>
> Le but étant de gérer uniformément l'incertitude
>

Oui pour que ce soit uniforme, mais alors réfléchir à quelquechose de
cohérent. Le message de départ donnait le 11è siècle, mais là tu as répondu
avec le 12è !

Bref comme d'habitude, les tags sous OSM sont créés à la volée, on en
discute après et ensuite on essaye d'uniformiser et on sse rend compte que
tout le monde ne comprend pas le même langage. Le minimum serait de
documenter même les essais sur le wiki afin de pouvoir les critiquer et
ensuite trouver des solutions d'uniformisation et de migration, puis
réparer tout ça dans la base car à la longue ces tags multiples compliquent
les applications de tout le monde.

Quitte à faire simple et non ambigu, il serait préférable de mentionner un
intervalle entre deux dates au format ISO8601 (année, année-mois, ou
année-mois-jour) et ne pas avoir à se soucier des unités. La première
réponse était plus simplet et au moins non ambigue le 11e siècle était
historic:century=11

Note, on a aussi besoin d'intervalles pour des périodes de construction
avec pour les deux bornes des intertitudes. L'usage pour les intervalles
c'est d'utiliser le signe " - " encadré d'espaces pour ne pas entrer en
conflit avec le "-" accollé sans espace entre les éléménts d'une date ISO
8601. Il donc faut un autre séparateur pour les marges d'intertitude.

Si on voulait préciser une construction s'étalant du 11e siècle au 15e,
cela donnerait "1001..1099 - 1401..1499". Si on peut dater plus précisément
une date, par exemple février 1492 pour la seconde borne au lieu du simple
15e siècle, cela donnerait "1001..1099 - 1492-02"

Mais si la construction s'est achevée encore plus précisément le 12 ou le
13 février, cela donnerait "1001..1099 - 1492-02-12..1492-02-13" (les 4
dates mentionnée sont toutes en format compatible ISO 8601 (lequel format
n'inclut aucune espace ni aucun point... mais admet qu'on puisse supprimer
les séparateurs "-" entre les composants année-mois-jour à condition de
mettre les années sur 4 chiffres minimum, donc autoriserait aussi qu'on
utilise pour nos intervalles: ""1001..1099 - 14920212..14920213").

Autre difficulté: les siècles avant Jesus-Christ (important pour dater le
patrimoine historique). Par convention on suit la date de "BC" en anglais,
toujours en fin de date donc après l'indication éventuelle du mois et du
jour, pas entre l'année et le mois. Mais là aussi on n'a alors pas d'année
"zéro" dans les calendriers, l'année qui précède l'année 0001 est alors
l'année 0001BC mais en notation astronomique cette année est désignée
"" et les années précédentes sont décalées de 1 par rapport aux année
calendaires, en utilisant un signe "-" avant l'année, donc "-0001" désigne
"0002BC". Les années après Jesus-Christ sont dans l'ère "AD" masi il n'est
pas utile de l'indiquer si on veut garder la compatibilité ISO 8601 des
dates d'aujourd'hui où aucun suffixe d'ère n'est nécessaire pour l'actuel
calendrier grégorien.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Gestion des périodes historiques pour le patrimoine

[Philippe Verdy]

On commence par en discuter en cherchant les différentes solutions et
difficultés. Tout cela devrait être sur le wiki en vue d'une révision des
schémas de clé.
Mais comme d'habitude, les clés sont introduites expérimentalement par
quelques uns, et ensuite on discute de la façon de fusionner les
différentes idées. Après vient la question du nettoyage car on ne peut pas
tout garder dans les applis.
En attendant les clés non discutées, trop nombreuses, insuffisamment
réfléchies, polluent la base et n'ont d'intérêt qu'e de façon informative à
condition de chercher comment les interpréter humainement, on est loin de
pouvoir automatiser les traitements, mais là en plus on ne peuyt même pas
dire qu'il s'agit d'erreurs. Tout cela n'est qu'expérimental mais
malheureusement sans discussion ouverte.
Note: cette liste francophone ne suffit pas. D'une façon ou d'une autre il
faut rendre ça visible sur le wiki et tenter des traductions anglaises même
maladroites pour pouvoir en débattre au plan international.
Mais la difficulté se corse quand dans un pays donné il y a eu des imports
massifs avec des nouvelles clés ou codifications de valeurs choisies
indépendamment de tout ce qui se fait ailleurs et sans même chercher à
s'appuyer sur des normes connues (comme ici l'ISO 8601 ou les convetions
CLDR ou des nomenclatures internationales existantes, ou quand les clés
sont choisies de façon très paresseuse et entrent en conflit avec d'autres
parce qu'aucune recherche n'a été faite avant de les utiliser pour autre
chose)

Le 9 novembre 2015 17:10, Jérôme Seigneuret  a
écrit :

>
>
> Le 9 novembre 2015 16:58, Philippe Verdy  a écrit :
>
>> Le 9 novembre 2015 16:12, Jérôme Seigneuret  a
>> écrit :
>>
>>> C'est implémenté dans les langages. C'est le principe de passage forcé
>>> d'un centenaire avec deux caractères vers 4 caractères YYto
>>>
>>> Donc C11 renvoi vers 1100-1199 (équivalent OSM 1100..1199)
>>>
>>
>> Ce qui est le **12e** siècle et pas le 11e ! Piège courant (aussi bien en
>> anglais qu'en français d'ailleurs). On est aujourd'hui au 21e siècle, pas
>> au 20e même si les deux premiers chiffres de l'année commencent par 20, les
>> siècles sont comptés à partir de 1, il n'y a pas de siècle zéro !
>>
>
> En effet donc dans mon cas c'est C10
>
>>
>> mais on peut aussi faire C1150 qui renvoi 1150-1249
>>> (équivalent OSM 1150..1249)
>>>
>>
>> Encore plus "merdique", car C11 désigne un siècle (lequel??) mais C1150
>> désigne une année de départ, quid alors du siècle débutant en année 11, il
>> faut l'écrire alors C0011 ?
>>
>
> Exact en tous cas c'est comme ça que le code le prévois
>
>
>>
>> Pour les préfixes c'est interne à OSM comme ~ et autres. Ca mérite à être
>>> simplifié ou à proposer des correspondances d'écritures
>>>
>>> Le but étant de gérer uniformément l'incertitude
>>>
>>
>> Oui pour que ce soit uniforme, mais alors réfléchir à quelquechose de
>> cohérent. Le message de départ donnait le 11è siècle, mais là tu as répondu
>> avec le 12è !
>>
> Je suis d'accord merci pour cette correction
>
>
>>
>> Bref comme d'habitude, les tags sous OSM sont créés à la volée, on en
>> discute après et ensuite on essaye d'uniformiser et on sse rend compte que
>> tout le monde ne comprend pas le même langage. Le minimum serait de
>> documenter même les essais sur le wiki afin de pouvoir les critiquer et
>> ensuite trouver des solutions d'uniformisation et de migration, puis
>> réparer tout ça dans la base car à la longue ces tags multiples compliquent
>> les applications de tout le monde.
>>
>> Je ne dis pas le contraire. Mais mieux vaut le faire maintenant que quand
> ce sera déjà utilisé par 5 contributeurs avec des méthodes différentes
>
>
>> Quitte à faire simple et non ambigu, il serait préférable de mentionner
>> un intervalle entre deux dates au format ISO8601 (année, année-mois, ou
>> année-mois-jour) et ne pas avoir à se soucier des unités. La première
>> réponse était plus simplet et au moins non ambigue le 11e siècle était
>> historic:century=11
>>
>
> Oui mais finalement on sort du schéma pour créer une nouvelle clé...
>
>
>> Note, on a aussi besoin d'intervalles pour des périodes de construction
>> avec pour les deux bornes des intertitudes. L'usage pour les intervalles
>> c'est d'utiliser le signe " - " encadré d'espaces pour ne pas entrer en
>> conflit avec le "-" accollé sans espace entre les éléménts d'une date ISO
>> 8601. Il donc faut un autre séparateur pour les marges d'intertitude.
>>
>> Si on voulait préciser une construction s'étalant du 11e siècle au 15e,
>> cela donnerait "1001..1099 - 1401..1499". Si on peut dater plus précisément
>> une date, par exemple février 1492 pour la seconde borne au lieu du simple
>> 15e siècle, cela donnerait "1001..1099 - 1492-02"
>>
>> Je trouve ça plutôt intéressant
>
>
>> Mais si la construction s'est achevée encore plus précisément le 12 ou le
>> 13 février, cela donnerait "1001..1099 - 

Re: [OSM-talk-fr] Parking/Aire de covoiturage

[Jérôme Seigneuret]

J'en ai fait avec amenity=car_sharing mais j'avais rien trouvé à l'époque.

Voilà ma proposition:

amenity=parking (ou parking_space)
park_ride =hov
name=Aire de Covoiturage
access=hov


Le 9 novembre 2015 20:08, Gautier  a écrit :

> Bonsoir,
>
> Je me permet de copier une question que j'ai posé sur le forum (
> http://forum.openstreetmap.fr/viewtopic.php?f=2=2338=9737#p9737), en
> espérant qu'une solution soit trouvée :
>
> Il existe de plus en plus de parkings dédiés au covoiturage, mais je n'ai
> rien trouvé pour cartographier ces éléments proprement. Le plus proche
> serait d'utiliser amenity=car_sharing
>  mais ce
> n'est pas du covoiturage à proprement parler.
> La plupart des parkings de covoiturage sont de simples parkings avec
> name=Aire de covoiturage ou name=Parking de covoiturage. Peut-on faire
> mieux ?
>
> Nicolas Dumoulin, sur le forum, m'a proposé la solution
> http://www.openstreetmap.org/way/128277712 à savoir :
>
> - amenity=parking
> - carpool=designated
> - name=Aire de covoiturage
> - park_ride=yes
>
> Qu'en pensez-vous ?
>
> ___
> 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] Problème de nommage de rue

[Christian Quest]

J'irai demander confirmation à la mairie... et leur signaler l'incohérence
des panneaux ;)

Le 9 novembre 2015 13:52, Jérôme Seigneuret  a
écrit :

>
>> Dans les manuels de littérature, c'est le nom complet qui est mentionné
>> et le lien  avec la commune semble digne d'être indiqué.
>> De bonnes raisons pour éviter l'abréviation .
>>
>>
> Le choix dans OSM est clair de toute façon. Pas d’abréviation dans le name
> sinon il y a le tag short_name
>  pour cela.
> Jérôme
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] JOSM : couleur de base de la page de téléchargement

[Vincent de Château-Thierry]

Bonsoir,

Le 09/11/2015 21:07, Jérôme Seigneuret a écrit :

Normal que l'on ne voit pas le message initial de Bernard dans la liste?


Il est bien là : 
https://lists.openstreetmap.org/pipermail/talk-fr/2015-November/078585.html



Le 9 novembre 2015 20:59, David Crochet > a écrit :

Bonjour

Le 09/11/2015 19:39, bernard a écrit :

Bonjour,
Je viens de remarquer que les couleurs de la page de
téléchargement de
JOSM ont changé.
Les Primary prennent la couleur des secondary
Les Secondary celles des Tertiary
Les Tertiary n'en a plus.
Je n'ai touché à aucun réglage

Normal


La charte par défaut d'osm.org a changé il y a une semaine : 
https://blog.openstreetmap.org/2015/10/30/openstreetmap-org-map-changing/
C'est celle qui s'affiche aussi dans JOSM par défaut. On l'a évoqué ici 
: 
https://lists.openstreetmap.org/pipermail/talk-fr/2015-October/078440.html




Par ailleurs, lors de la coupure d'un way, il s'affiche une boite de
dialogue qui nécessite un clic ... inutile.
Pour quelle raison cette modification?


JOSM est un logiciel en constante évolution. S'il y a évolution,
c'est qu'il y a demande d'évolution.


Cette évolution fait la "une" des changements de la dernière version 
stable : https://josm.openstreetmap.de/wiki/Fr%3AStartupPage


vincent

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

Re: [OSM-talk-fr] JOSM : couleur de base de la page de téléchargement

[David Crochet]

Bonjour

Le 09/11/2015 19:39, bernard a écrit :

Bonjour,
Je viens de remarquer que les couleurs de la page de téléchargement de
JOSM ont changé.
Les Primary prennent la couleur des secondary
Les Secondary celles des Tertiary
Les Tertiary n'en a plus.
Je n'ai touché à aucun réglage


Normal



Par ailleurs, lors de la coupure d'un way, il s'affiche une boite de
dialogue qui nécessite un clic ... inutile.
Pour quelle raison cette modification?


JOSM est un logiciel en constante évolution. S'il y a évolution, c'est 
qu'il y a demande d'évolution.


Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] JOSM : couleur de base de la page de téléchargement

[Jérôme Seigneuret]

Normal que l'on ne voit pas le message initial de Bernard dans la liste?

Le 9 novembre 2015 20:59, David Crochet  a écrit :

> Bonjour
>
> Le 09/11/2015 19:39, bernard a écrit :
>
>> Bonjour,
>> Je viens de remarquer que les couleurs de la page de téléchargement de
>> JOSM ont changé.
>> Les Primary prennent la couleur des secondary
>> Les Secondary celles des Tertiary
>> Les Tertiary n'en a plus.
>> Je n'ai touché à aucun réglage
>>
>
> Normal
>
>
>> Par ailleurs, lors de la coupure d'un way, il s'affiche une boite de
>> dialogue qui nécessite un clic ... inutile.
>> Pour quelle raison cette modification?
>>
>
> JOSM est un logiciel en constante évolution. S'il y a évolution, c'est
> qu'il y a demande d'évolution.
>
> Cordialement
>
> --
> David Crochet
>
> ___
> 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] JOSM : couleur de base de la page de téléchargement

[Philippe Verdy]

Sur JOSM tu peux choisir tes couleurs dans tes préférences de style.  Sinon
c'est les styles par défaut qui sont téléchargés et remis à jour
régulièrement...
Le 9 nov. 2015 19:40, "bernard"  a écrit :

> Bonjour,
> Je viens de remarquer que les couleurs de la page de téléchargement de
> JOSM ont changé.
> Les Primary prennent la couleur des secondary
> Les Secondary celles des Tertiary
> Les Tertiary n'en a plus.
> Je n'ai touché à aucun réglage
>
> Par ailleurs, lors de la coupure d'un way, il s'affiche une boite de
> dialogue qui nécessite un clic ... inutile.
> Pour quelle raison cette modification?
> Bonne soirée et merci pour vos réponses
>
>
> ___
> 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] JOSM : couleur de base de la page de téléchargement

[Jérôme Seigneuret]

Le 9 novembre 2015 21:06, Philippe Verdy  a écrit :

> Sur JOSM tu peux choisir tes couleurs dans tes préférences de style.
> Sinon c'est les styles par défaut qui sont téléchargés et remis à jour
> régulièrement...
> Le 9 nov. 2015 19:40, "bernard"  a écrit :
>
>> Bonjour,
>> Je viens de remarquer que les couleurs de la page de téléchargement de
>> JOSM ont changé.
>> Les Primary prennent la couleur des secondary
>> Les Secondary celles des Tertiary
>> Les Tertiary n'en a plus.
>> Je n'ai touché à aucun réglage
>>
> Alors les couleurs ne sont pas liées à JOSM mais au rendu du fond de plan
opemnstreetmap.org (choix de changement présenté sur le blog OSM et dans la
liste d'actu d'OSM France)

Sous JOSM il faudrait géré les épaisseurs pour faire la différence donc
c'est très bien ainsi. On peut remarquer que le rendu JOSM (même si ils
sont proche de l'ancien rendu) n'est pas identique pour simplifier la
lisibilité lors de l'édition et c'est le cas aussi sur iD


>> Par ailleurs, lors de la coupure d'un way, il s'affiche une boite de
>> dialogue qui nécessite un clic ... inutile.
>> Pour quelle raison cette modification?
>
> Rien d'inutile. Ça permet de conserver l'identifiant source et de
l'attribuer au tronçon choisi (par défaut celui qui possède le plus de
noeuds)

Pas mal de gens synchronise les données via un identifiant (non visible
mais bien présent dans le format XML ou JSON voir un extrait d'Overpass API

Bonne soirée
Jérôme
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OpenSolarMap...

[Christian Quest]

Il y a plein d'améliorations à faire... n'oubliez pas que ce prototype
tourne depuis même pas 48h !

Effectivement l'icône "?" pourrait plutôt être un moyen de "passer" au
bâtiment suivant plutôt que de répondre... mais c'est vraiment une histoire
de présentation, chose qu'on n'a pas eu le temps d'approfondir (pas de
graphiste/designer dans notre binôme pendant le hackathon).

Si vous voulez proposer des améliorations sur l'interface, vous pouvez le
faire directement, le projet est sur http://github.com/opensolarmap et il
n'y a strictement rien à installer pour la partie "front". C'est juste de
l'HTML5/JS et quelques images qui ont été vite écrits (quick and dirty
comme on dit).
Déjà 2 "pull requests" intégrées hier :)

Côté backend, j'ai modifié un peu la requête de sélection et commencé à
classifier certains bâtiments quand il y a plusieurs réponses identiques
afin de ne plus le sélectionner.
Je dois aussi documenter l'API... et déplacer ça sur un serveur plus stable
(test à venir sur un scaleway).

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

Re: [OSM-talk-fr] OpenSolarMap...

[David Crochet]

Bonjour

Le 10/11/2015 00:25, Jérôme Seigneuret a écrit :

Je ne suis par pour intégrer le contexte environnemental pour le moment
car c'est juste de la détection de type de toit.


De même, sur le principe que l'on a pas implicitement la compétences 
professionnelle pour juger la puissance calorifique reçu par le pan de toit.


Le moyen est de rentrer les paramètre OSM connu des élément autour 
(hauteur des arbres, hauteur des bâtiments, hauteurs des murs.


Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] Comment tagguer une résidence/cité comportant plusieurs bâtiments?

[Julien Noblet]

Bonjour,
Merci :)

J'avais complètement zappé le landuse=residential :/

Librement.
Julien_N

Le lun. 9 nov. 2015 à 19:47, Jérôme Seigneuret  a
écrit :

> Bonjour,
> Le nom de la résidence se met par usage sur le landuse. Il faut découper
> le landuse existant pour éviter les superpositions de landuse.
>
> Le nom du bâtiment sur building
>
> Jérôme
>
> Le 9 novembre 2015 19:39, Julien Noblet  a écrit
> :
>
>> Bonjour,
>> Je viens vers vous pour savoir comment taguer une résidence ou une cité
>> de plusieurs bâtiments.
>> J'avais pensé à une relation de "type"="site"
>> name=
>> Avec un chemin avec un rôle perimeter, et les bâtiments avec un rôle
>> building.
>> Chaque bâtiment peut avoir un nom (ou plutôt une ref) name/ref = Bâtiment
>> A/B/C/D...
>>
>> Quels tags devraient être ajoutés la relation?
>>
>> Est-ce que j'ai tout faux et je devrais utiliser sur les bâtiment un
>> addr:place ou addr:X=?
>>
>> Merci par avance.
>> Librement.
>>
>> Julien_N
>>
>> ___
>> 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] Gestion des périodes historiques pour le patrimoine

[Philippe Verdy]

Ce n'était qu'une proposition.

Si ça te plait et tu veux l"utiliser, documente-là sur le wiki, au moins
pour dire que century=11 signifie 11e siècle (1001-1100) et non les années
1100-1199, et soulever le problème.

Attends-toi ensuite à des contre-propositions sur le wiki et des
discussions (certains voudront quand même utiliser start_date=* mais avec
une syntaxe permettant de spécifier un intervalle de dates pour les dates
estimées, par exemple "start_date=1001..1100" qui n'entre pas en conflit
avec la notation ISO 8601 des dates).

Pouvoir indiquer des dates estimées avec une fourchette suffixante est plus
objectif qu'une classification difficile (et subjective) des époques et
civilisations, avec des tas de valeurs possibles et une difficulté ensuite
à les traiter.. Mais la simple notation du siècle est malgré tout un usage
très répandu partout dans le monde.

Note: certaines parties d'un batiment ont plusieurs époques et parfois les
époques se superposent au même endroit (reste d'un mur ancien sur lequel
est construit ou reconstruit un élément plus récent. et cela est presque
toujours le cas des batiments historiques les plus anciens (abbayes,
cathédrales, églises, chateaux, fortifications, aqueducs/viaducs...). Pour
les batiments les plus récents, on ne les mentionne pas par un siècle mais
par une année de construction plus précise (mais il n'est pas impossible
d'avoir une construction très récente et datée précisément sur une
fondation plus ancienne, incluant même la préservation de certains éléments
historiques comme une façade, un pan de mur, une tour...)

Le 9 novembre 2015 11:28, Jérôme Seigneuret  a
écrit :

> Merci Philippe. Je vais mettre historic:century=11
>
>
> Le 9 novembre 2015 11:19, Philippe Verdy  a écrit :
>
>> tu peux proposer "historic:century=11" si la classification par époque ou
>> civilisation est difficile (d'ailleurs elle varie selon les pays ou
>> cultures, ce qui est documenté est difficile à standardiser et faire
>> accepter partout).
>> le "start_date=*" est plutôt réservé à noter des dates précises (avec un
>> format compatible ISO 8601 contenant au minimum une année complète), mais
>> le XIe siècle n'est pas assez précis on ne peut pas non plus mettre
>> "start_date=1001-1100" (format incompatible posant problème),
>> start_date=1001 (oui, le XIe siècle commence l'année suivant l'an mil) ou
>> start_date=1050 (milieu du siècle) serait au contraire trop précis (rien
>> n'indique que c'est en fait une estimation à plus ou mois 50 ans près).
>>
>> Le 9 novembre 2015 11:07, Jérôme Seigneuret  a
>> écrit :
>>
>>> Bonjour, en faisant un fix sur le nom d'une église je me retrouve à
>>> avoir:
>>> Église ST Barthélémy XIième siècle que je corrige en Église
>>> Saint-Barthélémy-de-Baillarguet
>>>
>>> Mon problème est d'ajouter l'information lié au XI ème siècle
>>> > période du moyen age central + précision sur le siècle
>>>
>>> Ducoup je regarde du coté des tags
>>> http://wiki.openstreetmap.org/wiki/FR:Key:historic:civilization
>>> historic:period 
>>> =
>>> start_date =
>>>
>>> Je me rend compte que rien n'est précisé sur les siècles tel que l'on a
>>> l'habitude de l'utilisé d'une part et que les grandes périodes de notre
>>> civilisation ne sont pas détaillé:
>>> préhistoire et protohistoire c'est OK
>>>
>>>- *historic:civilization*=prehistoric
>>>- *historic:civilization*=protohistoric
>>>
>>>
>>> Reste les périodes après JC et les périodes spécifique à des régions
>>>
>>> moyen-age :vie ‑xve
>>>
>>> haut Moyen Âge = : vie ‑ xe siècle
>>> Moyen Âge central : xie ‑ xiiie siècle
>>> Moyen Âge tardif 
>>>  : xive ‑ xve siècle
>>>
>>>
>>> époque moderne :
>>>
>>> Époque moderne antérieure :1492 – 1792
>>>
>>> époque contemporaine :
>>>
>>> Époque moderne I : 1792 – 1920
>>> Époque moderne II : 1920 à nos jours
>>>
>>>
>>> Bonne journée
>>> Jérôme
>>>
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> Cordialement,
> Jérôme Seigneuret
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Problème de nommage de rue

[Donat ROBAUX]

+1 avec Jérome. Pour le terrain je mettrai le type de voie que les gens
utilisent le plus.

Le mieux étant d'aller voir la délibération du conseil municipal. Sinon la
règle étant de mettre le nom en clair sans abréviation.

Donat



> -- Message transféré --
> From: "Jérôme Seigneuret" 
> To: "Discussions sur OSM en français" 
> Cc:
> Date: Mon, 9 Nov 2015 11:24:38 +0100
> Subject: Re: [OSM-talk-fr] Problème de nommage de rue
> Bonjour,
> Le choix se fait avec le terrain.
> Je mets le code FANTOIR de la rue la mieux nommée et l'autre je la déclare
> comme "Voie doublon et type de voie différent"
>
> Jérôme
>
> Le 9 novembre 2015 11:16, Ludovic Hirlimann  a
> écrit :
>
>> je n'ai pas de problème avec Jean Jacques LEFRANC dans mon exemple. J'ai
>> plus des problèmes avec rue/avenue et avec la partie manquante "de
>> pompignan" , comment choisir entre rue et ave ? (j pense prendre le de
>> pompugnan car présent dans le cadastre.
>>
>> Ludo
>>
>>
>> 2015-11-09 11:10 GMT+01:00 Philippe Verdy :
>>
>>> Les panneaux peuvent parfois utiliser des abréviations (comme ici les
>>> prénoms), la poste aussi (pas toujours les mêmes, la Poste imposant des
>>> noms plus courts pour les adresses normalisées sur les enveloppes peut
>>> avoir utilisé ses propres abréviations). Les planches cadastrales ont aussi
>>> leurs abréviations.
>>>
>>> Le FANTOIR enfin abrège aussi à cause du format du fichier (il y a déjà
>>> les codes pout les types de voie, il manque tous les accents et souvent des
>>> apostrophes ou traits d'union, souvent aucun point abréviatif, et aucune
>>> distinction des casses de lettres.
>>>
>>> Dans OSM on évite ces abréviations et autant que possible on restaure
>>> les noms entiers, les accents, la casse, les apostrophes et traits d'union
>>> corrects (le rapprochement avec FANTOIR reste encore facile avec la
>>> ref:FR:FANTOIR=* malgré ce nom remis en forme, même si le format FANTOIR a
>>> été conçu du temps des vieux logiciels écrits en COBOL sur des systèmes qui
>>> ne savait échanger correctement entre eux que de l'ASCII). C'est au
>>> logiciel de rendu de choisir ensuite la façon d'abréger (si nécessaire) ou
>>> un style d'affichage tout en capitales.
>>>
>>> Quand aux "sauts de lignes" présents sur les panneaux ou dans le
>>> cadastre, ne pas en tenir compte et les traiter comme des blancs.
>>>
>>> Le 9 novembre 2015 10:58, Ludovic Hirlimann  a
>>> écrit :
>>>
 Coucou,

 j'ai commencé a participer au projet BANO, il y a trois semaine. J'ai
 plus ou moins fini ma ville et je me suis donc attelé au village voisin.
 J'ai un soucis avec la commune de Pompignan
 http://cadastre.openstreetmap.fr/fantoir/#insee=82142=0.

 La rue Jean Jacques lefranc :

 https://www.openstreetmap.org/edit#map=18/43.81764/1.31263


 http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/43.81742/1.31282

 en bas de la voie (et à gauche sur la carte) il y a un panneau avec la
 mention :
 Rue
 J. Jacques
 LEFRANC

 Juste au niveau du coude (là ou est le n°19 sur la vue BANO) il y a un
 autre panneau avec la mention

 AVENUE
 J. J. LEFRANC
 DE POMPIGNAN

 Le cadastre réference RUE JJ LEFRANC DE POMPIGNAN

 La commune en question n'est vraiment pas clair organisé sur ses
 panneaux de voiries.

 Ma question est donc, commen dois-je nommer le rue ? que faire dans
 FANTOIR ?


 Ludo
 --
 http://sietch-tabr.tumblr.com/


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

Re: [OSM-talk-fr] Problème de nommage de rue

[Philippe Verdy]

Si sur le terrain on trouve les deux, I doit y avoir un usage même si ce
n'est pas le nom officiel.  Pour faciliter les recherches et le géocodage,
un alt_name=* sera alors utile en plus du nom officiel dans name=*
Le 9 nov. 2015 12:06, "Donat ROBAUX"  a écrit :

> +1 avec Jérome. Pour le terrain je mettrai le type de voie que les gens
> utilisent le plus.
>
> Le mieux étant d'aller voir la délibération du conseil municipal. Sinon la
> règle étant de mettre le nom en clair sans abréviation.
>
> Donat
>
>
>
>> -- Message transféré --
>> From: "Jérôme Seigneuret" 
>> To: "Discussions sur OSM en français" 
>> Cc:
>> Date: Mon, 9 Nov 2015 11:24:38 +0100
>> Subject: Re: [OSM-talk-fr] Problème de nommage de rue
>> Bonjour,
>> Le choix se fait avec le terrain.
>> Je mets le code FANTOIR de la rue la mieux nommée et l'autre je la
>> déclare comme "Voie doublon et type de voie différent"
>>
>> Jérôme
>>
>> Le 9 novembre 2015 11:16, Ludovic Hirlimann  a
>> écrit :
>>
>>> je n'ai pas de problème avec Jean Jacques LEFRANC dans mon exemple. J'ai
>>> plus des problèmes avec rue/avenue et avec la partie manquante "de
>>> pompignan" , comment choisir entre rue et ave ? (j pense prendre le de
>>> pompugnan car présent dans le cadastre.
>>>
>>> Ludo
>>>
>>>
>>> 2015-11-09 11:10 GMT+01:00 Philippe Verdy :
>>>
 Les panneaux peuvent parfois utiliser des abréviations (comme ici les
 prénoms), la poste aussi (pas toujours les mêmes, la Poste imposant des
 noms plus courts pour les adresses normalisées sur les enveloppes peut
 avoir utilisé ses propres abréviations). Les planches cadastrales ont aussi
 leurs abréviations.

 Le FANTOIR enfin abrège aussi à cause du format du fichier (il y a déjà
 les codes pout les types de voie, il manque tous les accents et souvent des
 apostrophes ou traits d'union, souvent aucun point abréviatif, et aucune
 distinction des casses de lettres.

 Dans OSM on évite ces abréviations et autant que possible on restaure
 les noms entiers, les accents, la casse, les apostrophes et traits d'union
 corrects (le rapprochement avec FANTOIR reste encore facile avec la
 ref:FR:FANTOIR=* malgré ce nom remis en forme, même si le format FANTOIR a
 été conçu du temps des vieux logiciels écrits en COBOL sur des systèmes qui
 ne savait échanger correctement entre eux que de l'ASCII). C'est au
 logiciel de rendu de choisir ensuite la façon d'abréger (si nécessaire) ou
 un style d'affichage tout en capitales.

 Quand aux "sauts de lignes" présents sur les panneaux ou dans le
 cadastre, ne pas en tenir compte et les traiter comme des blancs.

 Le 9 novembre 2015 10:58, Ludovic Hirlimann  a
 écrit :

> Coucou,
>
> j'ai commencé a participer au projet BANO, il y a trois semaine. J'ai
> plus ou moins fini ma ville et je me suis donc attelé au village voisin.
> J'ai un soucis avec la commune de Pompignan
> http://cadastre.openstreetmap.fr/fantoir/#insee=82142=0.
>
> La rue Jean Jacques lefranc :
>
> https://www.openstreetmap.org/edit#map=18/43.81764/1.31263
>
>
> http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/43.81742/1.31282
>
> en bas de la voie (et à gauche sur la carte) il y a un panneau avec la
> mention :
> Rue
> J. Jacques
> LEFRANC
>
> Juste au niveau du coude (là ou est le n°19 sur la vue BANO) il y a un
> autre panneau avec la mention
>
> AVENUE
> J. J. LEFRANC
> DE POMPIGNAN
>
> Le cadastre réference RUE JJ LEFRANC DE POMPIGNAN
>
> La commune en question n'est vraiment pas clair organisé sur ses
> panneaux de voiries.
>
> Ma question est donc, commen dois-je nommer le rue ? que faire dans
> FANTOIR ?
>
>
> Ludo
> --
> http://sietch-tabr.tumblr.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

[OSM-talk-fr] Rouen - Pont Mathilde - j'ai un doute sur 3 voies

[david . crochet]

Bonjour

Vous en pensez quoi de ces trois voies :

https://www.openstreetmap.org/way/188324016 
https://www.openstreetmap.org/way/188324013
https://www.openstreetmap.org/way/44785324

ils se suivent et des étiquettes ne sont pas "homogènes"

Cordialement

-- 
David Crochet

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

Re: [OSM-talk-fr] tag source:maxspeed=:zone:30

[Axelos]

Coucou,


lenny.libre wrote
> Quant à zone:maxspeed=FR:zone:30 il y a des infos en plus de la vitesse 
> : les piétons peuvent traverser, il n'y a pas de passage protégé et  
> toutes  les  chaussées  sont  à  double  sens pour  les cyclistes ...

Attention de ne pas confondre les zones de rencontre et les zones 30 :

Sur les zones 30, les piétons ont pour obligation de traverser sur les
passages prévus à cet effet (sauf si ceux-ci se trouvent à plus de 50
mètres).
C'est sur les zones de rencontre que les passages cloutés ne sont pas
obligatoires.

Concernant les cyclistes à contre sens, il y a eu début juillet cette année
des modifications du code de la route, dont le double sens cyclable par
défaut sur les routes limitées à 30 et non plus en uniquement en zone 30. Ce
sera effectif des le 1 janvier 2016, soit environ 6 mois pour que les
communes adaptent leurs signalisations. On pourra compter à cette date sur
les associations qui défendent la cyclabilité pour vérifier si oui ou non
les communes auront leurs précieux sésames pour chacune des rues : "sauf
décision contraire de l'autorité de police".

Sources :
http://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT06074228=LEGIARTI30839280
http://www.legifrance.gouv.fr/affichTexteArticle.do;jsessionid=FF4FC290C34361519E9E84AD8F1E4B51.tpdila13v_1?idArticle=JORFARTI30837283=JORFTEXT30837215

Cordialement.



--
View this message in context: 
http://gis.19327.n5.nabble.com/tag-source-maxspeed-country-code-zone-30-tp5859417p5859466.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

[OSM-talk-fr] Avis aux franciliens

[Romain MEHUT]

Bonjour,

Ayant dû emprunter tout récemment le boulevard périphérique intérieur, je
me suis étonné de voir un oneway étrange à cet endroit
http://www.openstreetmap.org/#map=18/48.82285/2.38027 avec donc les 2 ways
dans le même sens et qui plus est se croisent.

Quelqu'un qui connait bien l'endroit pour corriger?

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

Re: [OSM-talk-fr] OpenSolarMap...

[osm . sanspourriel]

J'oubliais alors que pour les routes j'y pensais : un toit même bien 
orienté, ou plat ne convient pas s'il y a des masques solaires (arbres, 
sommets...).

On répond quoi dans ce cas ?

La réponse n'est pas forcément la tronçonneuse ;-).
Je suppose qu'il faut répondre "bêtement", à préciser dans l'aide.

Je viens de voir (en me faisant avoir) que la surface cliquable est plus 
grande que l'icône.


Jean-Yvon


Le 09/11/2015 23:08, osm.sanspourr...@spamgourmet.com a écrit :




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

Re: [OSM-talk-fr] Gestion des périodes historiques pour le patrimoine

[Philippe Verdy]

On ne sait peut être pas la date de  naissance du christ mais on sait des
dates précises sur cette période.  Cela fixe les calendriers avec une date
connue précisément mêle si ce n'est pas la date du christ mais qu'on
utilise comme date commune de départ des calendriers julien et grégoriens
pour leur année 1. Par la suite pleins de dates de l'ère avant cette date
axiomatique et figée ont été définies précisément.  Ce dont on s'en fiche
alors est de savoir quand est né le christ car la on est même à 4 ou 7
années près selon les sources, et on n'est même pas sur de l'âge du christ
à sa mort alors que cette mort est datée très précisément, au moins pour le
jour du jugement car il y a aussi une incertitude sur la durée du supplice
et le jour de la descente de croix, et par la suite de celui de la
résurrection annoncée et donc du choix finalement arbitraire de la plaque
chrétienne qui a été remaniée politiquement pour menager les oppositions
avec la pâque juive mais aussi les fêtes civiles romaines du printemps.
L'année 1 à donc été fixée arbitrairement pour mettre tout le monde
d'accord plusieurs siècles après et ensuite on a rapproche avec succès les
calendriers romains avec le calendrier julien et c'est un concile qui a
tenté de décider qu'elle pouvait être l'année 1 mais les recherches
historiques de rapprochement avec les calendriers romains n'ont pas
réussi.  Il en est resté des incertitudes dd datation de toute la vie du
christ,  alors que pour le reste,  les dates du premiers siècle ainsi co
venues sont très bien établies. L'incertitude sur les dates du calendrier
romain sont sur des siècles antérieurs au premier siècle et on ne sait pas
précisément la date de fondation de Rome ni plein de dates de l'été
hellénique ou pourtant exustait déjà des fêtes pascales, non chrétiennes
forcément.

Bref l'année 0 n'est pas une question dont on se fout en histoire... Et on
est bien à moins d'une année près, avec seulement des incertitudes de
quelques jours,  notamment dans la période hivernale avant mars puisque les
romains ne dataient pas précisément les deux derniers mois de l'année.
Le 9 nov. 2015 23:26,  a écrit :

> Moi aussi ça me va.
>
> Pour plus de clarté je suis pour l'utilisation des tirets dans l'ISO 8601
> pour désigner des dates.
> Soit :
> 1001..1099 - 1492-02-12..1492-02-13
> C'est moins cabalistique.
>
> Pour la fameuse année zéro, comme vous de savez pas à 4 ans près (ou plus)
> quand le Jésus Christ a poussé son premier Christ, heu cri, donner des
> dates antérieures à une précision de +/- 1 an, on s'en fiche (pour les
> données qui nous concernent).
>
> Jean-Yvon
>
> Le 09/11/2015 17:10, Jérôme Seigneuret - jseigneuret-...@yahoo.fr a
> écrit :
>
> Si on voulait préciser une construction s'étalant du 11e siècle au 15e,
>> cela donnerait "1001..1099 - 1401..1499". Si on peut dater plus précisément
>> une date, par exemple février 1492 pour la seconde borne au lieu du simple
>> 15e siècle, cela donnerait "1001..1099 - 1492-02"
>>
>> Je trouve ça plutôt intéressant
>
>
>> Mais si la construction s'est achevée encore plus précisément le 12 ou le
>> 13 février, cela donnerait "1001..1099 - 1492-02-12..1492-02-13" (les 4
>> dates mentionnée sont toutes en format compatible ISO 8601 (lequel format
>> n'inclut aucune espace ni aucun point... mais admet qu'on puisse supprimer
>> les séparateurs "-" entre les composants année-mois-jour à condition de
>> mettre les années sur 4 chiffres minimum, donc autoriserait aussi qu'on
>> utilise pour nos intervalles: ""1001..1099 - 14920212..14920213").
>>
> Moi ça me va
>
>>
>>
>
> ___
> 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] purge d'ingération des adresses de Montpellier

[Frédéric Rodrigo]

Le 06/11/2015 10:26, Nicolas Moyroud a écrit :

Salut,

En parlant d'adresses est-il prévu que l'outil addr.openstreetmap.fr 
soit remis en route un jour ? Ça m'aidait pas mal pour savoir où on 
était sur Montpellier.

On a une sauvegarde d'il y a un an ? ça vaut le coup de la remettre ?


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

Re: [OSM-talk-fr] OpenSolarMap...

[Jérôme Seigneuret]

Je ne suis par pour intégrer le contexte environnemental pour le moment car
c'est juste de la détection de type de toit.

Jean-Yvon, ce que tu mets en avant  devrait se faire dans un deuxième temps
car, si l'algo doit se baser juste sur la détection de toit, ça fausse tous
le traitement. Après comme tu le dis, un toit favorable peux être
défavorable suivant des conditions environnementales (bâtiment plus grand
devant, arbres, pente orienté dans le mauvais sens pas forcément détectable
sur des toits simple pente...)

Jérôme

Le 9 novembre 2015 23:42,  a écrit :

> J'oubliais alors que pour les routes j'y pensais : un toit même bien
> orienté, ou plat ne convient pas s'il y a des masques solaires (arbres,
> sommets...).
> On répond quoi dans ce cas ?
>
> La réponse n'est pas forcément la tronçonneuse ;-).
> Je suppose qu'il faut répondre "bêtement", à préciser dans l'aide.
>
> Je viens de voir (en me faisant avoir) que la surface cliquable est plus
> grande que l'icône.
>
> Jean-Yvon
>
>
> Le 09/11/2015 23:08, osm.sanspourr...@spamgourmet.com a écrit :
>
>
>
>
> ___
> 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] Gestion des périodes historiques pour le patrimoine

[Philippe Verdy]

tu peux proposer "historic:century=11" si la classification par époque ou
civilisation est difficile (d'ailleurs elle varie selon les pays ou
cultures, ce qui est documenté est difficile à standardiser et faire
accepter partout).
le "start_date=*" est plutôt réservé à noter des dates précises (avec un
format compatible ISO 8601 contenant au minimum une année complète), mais
le XIe siècle n'est pas assez précis on ne peut pas non plus mettre
"start_date=1001-1100" (format incompatible posant problème),
start_date=1001 (oui, le XIe siècle commence l'année suivant l'an mil) ou
start_date=1050 (milieu du siècle) serait au contraire trop précis (rien
n'indique que c'est en fait une estimation à plus ou mois 50 ans près).

Le 9 novembre 2015 11:07, Jérôme Seigneuret  a
écrit :

> Bonjour, en faisant un fix sur le nom d'une église je me retrouve à avoir:
> Église ST Barthélémy XIième siècle que je corrige en Église
> Saint-Barthélémy-de-Baillarguet
>
> Mon problème est d'ajouter l'information lié au XI ème siècle
> > période du moyen age central + précision sur le siècle
>
> Ducoup je regarde du coté des tags
> http://wiki.openstreetmap.org/wiki/FR:Key:historic:civilization
> historic:period =
> start_date =
>
> Je me rend compte que rien n'est précisé sur les siècles tel que l'on a
> l'habitude de l'utilisé d'une part et que les grandes périodes de notre
> civilisation ne sont pas détaillé:
> préhistoire et protohistoire c'est OK
>
>- *historic:civilization*=prehistoric
>- *historic:civilization*=protohistoric
>
>
> Reste les périodes après JC et les périodes spécifique à des régions
>
> moyen-age :vie ‑xve
>
> haut Moyen Âge = : vie ‑ xe siècle
> Moyen Âge central : xie ‑ xiiie siècle
> Moyen Âge tardif  :
> xive ‑ xve siècle
>
>
> époque moderne :
>
> Époque moderne antérieure :1492 – 1792
>
> époque contemporaine :
>
> Époque moderne I : 1792 – 1920
> Époque moderne II : 1920 à nos jours
>
>
> Bonne journée
> Jérôme
>
>
> ___
> 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] tag source:maxspeed=:zone:30

[lenny]

Le 09/11/2015 01:46, Jérôme Amagat a écrit :

(on va dire que je dis des conneries :P)
On s'en fout des source:maxspeed= et des zone:maxspeed= ce qu'on veux 
c'est savoir quelle vitesse est autorisé sur la portion de route donc 
le seul truc utile c'est *maxspeed=*
Jusqu'à il n'y a pas longtemps, j'étais d'accord avec toi, mais depuis 
on m'a expliqué que des infos qui ne me semblaient pas utiles l'étaient 
pour d'autres.


Pour source:maxspeed= - si un jour on change la valeur règlementaire en 
France par exemple 90 > 80 on pourrait modifier automatiquement le 
maxspeed quand source:maxspeed=rural, mais pas quand source:maxspeed=sign*

*
Quant à zone:maxspeed=FR:zone:30 il y a des infos en plus de la vitesse 
: les piétons peuvent traverser, il n'y a pas de passage protégé et  
toutes  les  chaussées  sont  à  double  sens pour  les cyclistes ...


Le 9 novembre 2015 00:12, Jérôme Seigneuret > a écrit :


Je suis en parti en cause pour la France. Mais bon sur le wiki il
y a plusieurs forme (et différentes suivant les pays et même les
contributeurs)

http://wiki.openstreetmap.org/wiki/Key:zone:maxspeed
http://wiki.openstreetmap.org/wiki/Key:source:maxspeed

source:maxspeed=*sign *pour les panneaux rond de vitesse (B14 pour
le début de limitation, B33 pour la fin de limitation)

source:maxspeed=*markings* pour les vitesses marquées au sol

source:maxspeed=*urban*,*rural,motorway *pour des vitesses
réglementaires.

Visible sur ce panneau

http://routes.wikia.com/wiki/Limitations_de_vitesse_en_France_et_%C3%A0_l'%C3%A9tranger?file=C25a.gif



Les suisses et les belges ont un *trunk *défini sur le même type
de panneau

Tous est clair sur ces points

Mais il y a un passage qui ne statut par sur le tag à utiliser
pour les zones au pas, 20, 30

  * /maxspeed
=30 and
zone:maxspeed
=DE:zone30 -
Most used value (used 21k times in June 2015)/

Sauf que depuis tout a été corrigé en zone:maxspeed=DE:30 > 26439
ou c'est une erreur sur le wiki...
zone30 ne représente que 7 valeurs

Chez nous : zone:maxspeed=FR:30 > 9004


  * /maxspeed
=30 and
*source:maxspeed*=DE:zone:30 - Second most used value (used
18k times in June 2015)/
  * /maxspeed
=30 and
*source:maxspeed*=DE:zone - Proposed by a discussion on a
mailing list citisation needed (used /


source:maxspeed=DE:zone30 > 24439
source:maxspeed=DE:zone:30 > 19631

source:maxspeed=FR:zone30 > 3911
source:maxspeed=FR:zone:30 > 32


On a ça aussi =
source:maxspeed=http://www.service-public.*fr*/actualites/007904.html



On pourrait bien avoir pour :

  * *les zones 30*

maxspeed=30
source:maxspeed=FR:zone30
zone:maxspeed=FR:30

  * *les zones de rencontre*

maxspeed=20
source:maxspeed=FR:living_street
zone:maxspeed=FR:20


  * *les aires piétonnes*

maxspeed=6
source:maxspeed=FR:walk
zone:maxspeed=FR:6

Les zones étant encadrées par des panneaux (entrée;sortie):
- zone30 : B30;B51
- living_street : B52;B53
- pedestrian : B54;B55

zone:maxspeed sert à identifier des zones et la vitesse dans la
zone. La zone n'étant pas forcément lié à une source réglemantaire
comme pour les parkings où l'on est souvent sur des zones 10km/h
source:maxspeed sert à déterminer le contexte réglementaire lié à
la vitesse en question (Si je me trompe que l'on me corrige).

Maintenant il faut choisir quoi mettre et bien le détailler dans
le wiki. On peut aussi faire comme sur les autres page en
indiquant les tags à éviter.

Bonne soirée
Jérôme


Le 8 novembre 2015 20:29, lenny > a écrit :

Bonjour
Je viens de découvrir, sur un highway, le tag
"/source:maxspeed=FR:zone30"/
Je l'ai cherché sur le wiki.
Autant je comprend par exemple : "/maxspeed=50/" avec
"/source:maxspeed=FR:urban"/ ou "/source:maxspeed=sign"/ ; par
contre, AMHA, je ne vois pas la valeur ajouté de
"/source:maxspeed=FR:zone30"/ car, dans ce cas, la vitesse
limite est toujours explicite.

Mais je suis encore plus étonné par les valeurs :
le wiki anglais propose deux possibilités (avec ou sans ":"
entre "zone" et "30")
"maxspeed=30 and 

Re: [OSM-talk-fr] Problème de nommage de rue

[Jérôme Seigneuret]

Bonjour,
Le choix se fait avec le terrain.
Je mets le code FANTOIR de la rue la mieux nommée et l'autre je la déclare
comme "Voie doublon et type de voie différent"

Jérôme

Le 9 novembre 2015 11:16, Ludovic Hirlimann  a écrit
:

> je n'ai pas de problème avec Jean Jacques LEFRANC dans mon exemple. J'ai
> plus des problèmes avec rue/avenue et avec la partie manquante "de
> pompignan" , comment choisir entre rue et ave ? (j pense prendre le de
> pompugnan car présent dans le cadastre.
>
> Ludo
>
>
> 2015-11-09 11:10 GMT+01:00 Philippe Verdy :
>
>> Les panneaux peuvent parfois utiliser des abréviations (comme ici les
>> prénoms), la poste aussi (pas toujours les mêmes, la Poste imposant des
>> noms plus courts pour les adresses normalisées sur les enveloppes peut
>> avoir utilisé ses propres abréviations). Les planches cadastrales ont aussi
>> leurs abréviations.
>>
>> Le FANTOIR enfin abrège aussi à cause du format du fichier (il y a déjà
>> les codes pout les types de voie, il manque tous les accents et souvent des
>> apostrophes ou traits d'union, souvent aucun point abréviatif, et aucune
>> distinction des casses de lettres.
>>
>> Dans OSM on évite ces abréviations et autant que possible on restaure les
>> noms entiers, les accents, la casse, les apostrophes et traits d'union
>> corrects (le rapprochement avec FANTOIR reste encore facile avec la
>> ref:FR:FANTOIR=* malgré ce nom remis en forme, même si le format FANTOIR a
>> été conçu du temps des vieux logiciels écrits en COBOL sur des systèmes qui
>> ne savait échanger correctement entre eux que de l'ASCII). C'est au
>> logiciel de rendu de choisir ensuite la façon d'abréger (si nécessaire) ou
>> un style d'affichage tout en capitales.
>>
>> Quand aux "sauts de lignes" présents sur les panneaux ou dans le
>> cadastre, ne pas en tenir compte et les traiter comme des blancs.
>>
>> Le 9 novembre 2015 10:58, Ludovic Hirlimann  a
>> écrit :
>>
>>> Coucou,
>>>
>>> j'ai commencé a participer au projet BANO, il y a trois semaine. J'ai
>>> plus ou moins fini ma ville et je me suis donc attelé au village voisin.
>>> J'ai un soucis avec la commune de Pompignan
>>> http://cadastre.openstreetmap.fr/fantoir/#insee=82142=0.
>>>
>>> La rue Jean Jacques lefranc :
>>>
>>> https://www.openstreetmap.org/edit#map=18/43.81764/1.31263
>>>
>>>
>>> http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/43.81742/1.31282
>>>
>>> en bas de la voie (et à gauche sur la carte) il y a un panneau avec la
>>> mention :
>>> Rue
>>> J. Jacques
>>> LEFRANC
>>>
>>> Juste au niveau du coude (là ou est le n°19 sur la vue BANO) il y a un
>>> autre panneau avec la mention
>>>
>>> AVENUE
>>> J. J. LEFRANC
>>> DE POMPIGNAN
>>>
>>> Le cadastre réference RUE JJ LEFRANC DE POMPIGNAN
>>>
>>> La commune en question n'est vraiment pas clair organisé sur ses
>>> panneaux de voiries.
>>>
>>> Ma question est donc, commen dois-je nommer le rue ? que faire dans
>>> FANTOIR ?
>>>
>>>
>>> Ludo
>>> --
>>> http://sietch-tabr.tumblr.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
>>
>>
>
>
> --
> http://sietch-tabr.tumblr.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] Problème de nommage de rue

[Ludovic Hirlimann]

j'ai rue et aveneue sur le terrain - et une seule entreé avec rue dans
FANTOIR mais je vois ce qu'il faut faire.

Merci à tous.

Ludo

2015-11-09 11:24 GMT+01:00 Jérôme Seigneuret :

> Bonjour,
> Le choix se fait avec le terrain.
> Je mets le code FANTOIR de la rue la mieux nommée et l'autre je la déclare
> comme "Voie doublon et type de voie différent"
>
> Jérôme
>
> Le 9 novembre 2015 11:16, Ludovic Hirlimann  a
> écrit :
>
>> je n'ai pas de problème avec Jean Jacques LEFRANC dans mon exemple. J'ai
>> plus des problèmes avec rue/avenue et avec la partie manquante "de
>> pompignan" , comment choisir entre rue et ave ? (j pense prendre le de
>> pompugnan car présent dans le cadastre.
>>
>> Ludo
>>
>>
>> 2015-11-09 11:10 GMT+01:00 Philippe Verdy :
>>
>>> Les panneaux peuvent parfois utiliser des abréviations (comme ici les
>>> prénoms), la poste aussi (pas toujours les mêmes, la Poste imposant des
>>> noms plus courts pour les adresses normalisées sur les enveloppes peut
>>> avoir utilisé ses propres abréviations). Les planches cadastrales ont aussi
>>> leurs abréviations.
>>>
>>> Le FANTOIR enfin abrège aussi à cause du format du fichier (il y a déjà
>>> les codes pout les types de voie, il manque tous les accents et souvent des
>>> apostrophes ou traits d'union, souvent aucun point abréviatif, et aucune
>>> distinction des casses de lettres.
>>>
>>> Dans OSM on évite ces abréviations et autant que possible on restaure
>>> les noms entiers, les accents, la casse, les apostrophes et traits d'union
>>> corrects (le rapprochement avec FANTOIR reste encore facile avec la
>>> ref:FR:FANTOIR=* malgré ce nom remis en forme, même si le format FANTOIR a
>>> été conçu du temps des vieux logiciels écrits en COBOL sur des systèmes qui
>>> ne savait échanger correctement entre eux que de l'ASCII). C'est au
>>> logiciel de rendu de choisir ensuite la façon d'abréger (si nécessaire) ou
>>> un style d'affichage tout en capitales.
>>>
>>> Quand aux "sauts de lignes" présents sur les panneaux ou dans le
>>> cadastre, ne pas en tenir compte et les traiter comme des blancs.
>>>
>>> Le 9 novembre 2015 10:58, Ludovic Hirlimann  a
>>> écrit :
>>>
 Coucou,

 j'ai commencé a participer au projet BANO, il y a trois semaine. J'ai
 plus ou moins fini ma ville et je me suis donc attelé au village voisin.
 J'ai un soucis avec la commune de Pompignan
 http://cadastre.openstreetmap.fr/fantoir/#insee=82142=0.

 La rue Jean Jacques lefranc :

 https://www.openstreetmap.org/edit#map=18/43.81764/1.31263


 http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/43.81742/1.31282

 en bas de la voie (et à gauche sur la carte) il y a un panneau avec la
 mention :
 Rue
 J. Jacques
 LEFRANC

 Juste au niveau du coude (là ou est le n°19 sur la vue BANO) il y a un
 autre panneau avec la mention

 AVENUE
 J. J. LEFRANC
 DE POMPIGNAN

 Le cadastre réference RUE JJ LEFRANC DE POMPIGNAN

 La commune en question n'est vraiment pas clair organisé sur ses
 panneaux de voiries.

 Ma question est donc, commen dois-je nommer le rue ? que faire dans
 FANTOIR ?


 Ludo
 --
 http://sietch-tabr.tumblr.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
>>>
>>>
>>
>>
>> --
>> http://sietch-tabr.tumblr.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
>
>


-- 
http://sietch-tabr.tumblr.com/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OpenSolarMap...

[Philippe Verdy]

Le 9 novembre 2015 11:08, Pierre GRANJON  a écrit :

> Bonjour à tous,
> Très bonne idée ce projet, et l'outil de crowdsourcing donne envie de
> participer !
> J'ai fait 200 ajouts, ça marche très bien mais j'ai quelques commentaires :
>
>- Dans le cas de toits à 4 pans, je mets en général "?", est-ce le cas
>de tout le monde ?
>
> Si les deux autres pans sont seulemnt sur les pignons  et que la plus
grande partie du toit est à double pente, il men semble qu'on peut ignorer
ces pignons.

D'ailleurs la classification demandée se contente juste de chercher deux
orientations possibles pour les double pentes, ou le toit plat (difficile
malgré tout de voir sur une photo aérienne si le toit est réellement plat
ou en pente, et encore plus de voir son orientation réelle qui peut très
bien être vers l'est ou le nord et pas favorable aux panneaux solaires: cas
assez fréquents pour les toits métailliques de batiments commerciaux,
industriels ou agricoles, sachant que bon nombre de batiments d'élevage
sont faits avec des orientations favorables destinées à optimiser les couts
de chauffage/climatisation et augmenter le rendement énergétique global,
même sans aucun panneau solaire: cette étude thermique des batiments
agricoles se fait depuis de nombreuses décennies: voir avec le CEMAGREF qui
a fait des études avec les chambres d'agricultures et syndicats ou
coopératives agricoles et même développé des logiciels pour ça, incluant
aussi l'études des matériaux, des données météo moyennes, et les
équipements de ventilisation ou récupérateurs de chaleur).

>
>- Enfin, j'ai repéré quelques panneaux solaires déjà existants, pour
>lesquels j'ai tout  de même renseigné l'orientation. Ca pourrait être
>l'occasion de recenser l'existant en panneaux solaires ?
>
> S'il y a des panneaux solaires visibles, l'emplacement est à priori
favorable pour ça et ce serait utile de pouvoir cliquer sur une icone pour
les toits déjà équipés, sans même avoir à saisir l'orientatation réelle qui
aura peu d'intérêt pour cette application.

De plus dans de nombreuses zones urbaines, les toits de batiments mitoyens
d'une même rue adoptent une orientation commune (en cas d'ambiguité sur un
ds batiments les batiments voisins mieux visibles peuvent donner une
indication du potentiel sur toute une rue, notamment s'il y a déjà des
batiments équipés).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] tag source:maxspeed=:zone:30

[Jérôme Seigneuret]

>
>
> Jusqu'à il n'y a pas longtemps, j'étais d'accord avec toi, mais depuis on
> m'a expliqué que des infos qui ne me semblaient pas utiles l'étaient pour
> d'autres.
>
> Pour source:maxspeed= - si un jour on change la valeur règlementaire en
> France par exemple 90 > 80 on pourrait modifier automatiquement le maxspeed
> quand source:maxspeed=rural, mais pas quand source:maxspeed=sign
>
> Quant à zone:maxspeed=FR:zone:30 il y a des infos en plus de la vitesse :
> les piétons peuvent traverser, il n'y a pas de passage protégé et  toutes
> les  chaussées  sont  à  double  sens pour  les  cyclistes ...
>
> Voilà ça résume ma pensé

Donc pour le moment je vais mettre les deux comme je l'ai montré au dessus.
S'il n'y a pas de désaccord, Je mettrai à jour le wiki pour clarifier après
avoir ouvert un vote sur le choix et la forme des clés.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] erreur Overpass turbo

[bernard]

Bonjour,
Si Vous avez ce problème, Vous pouvez consulter et signaler à l'une de 
ces adresses :

https://github.com/tyrasd/overpass-turbo/issues/213
https://github.com/drolbr/Overpass-API/issues/229

Pour ma part, mon problème subsiste avec Firefox mais pas de soucis avec 
Internet Explorer



Le 05/11/2015 12:18, Stéphane Péneau a écrit :

Le 05/11/2015 10:17, François Lacombe a écrit :


Bonjour,

Le soucis se presente régulièrement quand j'exécute un script passant 
plusieurs requêtes successives.

Parfois certaines reçoivent ce code d'erreur en retour.
Pourtant je suis le seul a envoyer des requêtes depuis cette @IP.



De mon côté, c'était en requêtant  plusieurs types de tags via le 
wizard. Du type "shop=* OR craft=* OR office=* in un-nom-de-commune"


Stf



___
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] purge d'ingération des adresses de Montpellier

[Jérôme Seigneuret]

Oui en effet,
Les bâtiments peuvent être à 150m voir 200m. Augmenter le rayon sans
prendre en compte le nom de la rue risqu de poser problème. Peut-être
faudrait t'il s'inspirer du rapprochement fantoir de vdct ou d'une
détection Nominatim.

J'ai le même problème sur les données des bâtiments historiques (un pointé
sur Tavel et situé réellement à 2 km sur Roquemaure) et les stations
essences des autoroutes qui pointent au centre des villages pour certaines.

Bonne soirée,
Jérôme

Le 9 novembre 2015 23:23, Frédéric Rodrigo  a écrit
:

> La distance de rapprochement est de 15m, ça ne semple pas suffisant pour
> Montpellier compte tenu que l'OpenData à l'air d'être à l'entré de la
> propriété et que les données OSM dans ce coin sont sur l'entré du bâtiment.
>
> L'analyse Osmose ne tient pas compte de la rue, juste le numéro.
>
>
> Le 09/11/2015 15:15, Jérôme Seigneuret a écrit :
>
>> Je reviens sur la purge de données
>>
>> Les propositions d'intégrations (en tous cas pour les données adresses de
>> Montpellier) ne sont pas retirées même si les adresses existent déjà dans
>> OSM
>> exemple : 553 Rue Valéry Larbaud, Montpellier
>>
>> Adresse intégrée en 2013 et c'est pareil pour beaucoup d'autres.
>> Nominatim les trouve très bien. La plus part des adresses traitées n'ont
>> pas le nom de rue intégré dans le nœud portant l'adresse mais la relation
>> est faite via AssociatedStreet
>>
>>
>> http://osmose.openstreetmap.fr/fr/map/#zoom=18=43.634557=3.883908=Mapnik=T==1%2C2%2C3==
>>
>> Et-il possible de forcer la suppression via Nominatim et non un "corrigé"
>> à la main pour tous les points existant.
>>
>> Merci,
>> Jérôme
>>
>>
>> Le 6 novembre 2015 17:02, Christian Quest > > a écrit :
>>
>> Le retour à la normale de cadastre.openstreetmap.fr
>>  ne devrait plus
>> tarder...
>>
>>
>> On 06/11/2015 10:59, Vincent de Château-Thierry wrote:
>> > Bonjour,
>> >
>> >> De: "Nicolas Moyroud" >
>> >>
>> >> De même pour cadastre.openstreetmap.fr
>> .
>> >> C'est bien dommage ces outils hors service ont tendance à réfréner
>> >> quelque peu mes pulsions de contribution ;-)
>> > Le problème sur cadastre.openstreetmap.fr
>>  est pris en charge mais pas
>> encore résolu. Comme indiqué ici :
>> > https://github.com/osm-fr/bano/issues/104 on espère une issue
>> rapide.
>> >
>> > vincent
>> >
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org 
>> > https://lists.openstreetmap.org/listinfo/talk-fr
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>>
>> ___
>> 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

[OSM-talk-fr] Gestion des périodes historiques pour le patrimoine

[Jérôme Seigneuret]

Bonjour, en faisant un fix sur le nom d'une église je me retrouve à avoir:
Église ST Barthélémy XIième siècle que je corrige en Église
Saint-Barthélémy-de-Baillarguet

Mon problème est d'ajouter l'information lié au XI ème siècle
> période du moyen age central + précision sur le siècle

Ducoup je regarde du coté des tags
http://wiki.openstreetmap.org/wiki/FR:Key:historic:civilization
historic:period =
start_date =

Je me rend compte que rien n'est précisé sur les siècles tel que l'on a
l'habitude de l'utilisé d'une part et que les grandes périodes de notre
civilisation ne sont pas détaillé:
préhistoire et protohistoire c'est OK

   - *historic:civilization*=prehistoric
   - *historic:civilization*=protohistoric


Reste les périodes après JC et les périodes spécifique à des régions

moyen-age :vie ‑xve

haut Moyen Âge = : vie ‑ xe siècle
Moyen Âge central : xie ‑ xiiie siècle
Moyen Âge tardif  : xiv
e ‑ xve siècle


époque moderne :

Époque moderne antérieure :1492 – 1792

époque contemporaine :

Époque moderne I : 1792 – 1920
Époque moderne II : 1920 à nos jours


Bonne journée
Jérôme
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] tag source:maxspeed=:zone:30

[lenny]

En fait ma remarque ne concernait que certains source:maxspeed (j'avais 
mis les tag maxspeed uniquement pour le contexte)


Le 09/11/2015 00:12, Jérôme Seigneuret a écrit :
Je suis en parti en cause pour la France. Mais bon sur le wiki il y a 
plusieurs forme (et différentes suivant les pays et même les 
contributeurs)


http://wiki.openstreetmap.org/wiki/Key:zone:maxspeed
http://wiki.openstreetmap.org/wiki/Key:source:maxspeed

source:maxspeed=*sign *pour les panneaux rond de vitesse (B14 pour le 
début de limitation, B33 pour la fin de limitation)


source:maxspeed=*markings* pour les vitesses marquées au sol

source:maxspeed=*urban*,*rural,motorway *pour des vitesses 
réglementaires.


Visible sur ce panneau 
http://routes.wikia.com/wiki/Limitations_de_vitesse_en_France_et_%C3%A0_l'%C3%A9tranger?file=C25a.gif 



Les suisses et les belges ont un *trunk *défini sur le même type de 
panneau


Tous est clair sur ces points

Mais il y a un passage qui ne statut par sur le tag à utiliser pour 
les zones au pas, 20, 30


  * /maxspeed =30 and
zone:maxspeed
=DE:zone30 -
Most used value (used 21k times in June 2015)/

Sauf que depuis tout a été corrigé en zone:maxspeed=DE:30 > 26439 ou 
c'est une erreur sur le wiki...

zone30 ne représente que 7 valeurs

Chez nous : zone:maxspeed=FR:30 > 9004


  * /maxspeed =30 and
*source:maxspeed*=DE:zone:30 - Second most used value (used 18k
times in June 2015)/
  * /maxspeed =30 and
*source:maxspeed*=DE:zone - Proposed by a discussion on a mailing
list citisation needed (used /


source:maxspeed=DE:zone30 > 24439
source:maxspeed=DE:zone:30 > 19631

source:maxspeed=FR:zone30 > 3911
source:maxspeed=FR:zone:30 > 32


On a ça aussi =
source:maxspeed=http://www.service-public.*fr*/actualites/007904.html 



On pourrait bien avoir pour :

  * *les zones 30*

maxspeed=30
source:maxspeed=FR:zone30

C'est ce source là dont je ne vois pas l'utilité, car dans les zones 30, 
il aura toujours la même valeur (qu'elle en est la valeur ajoutée ?)


zone:maxspeed=FR:30

  * *les zones de rencontre*

maxspeed=20
source:maxspeed=FR:living_street


pareil ...


zone:maxspeed=FR:20


  * *les aires piétonnes*

maxspeed=6
source:maxspeed=FR:walk
zone:maxspeed=FR:6

Les zones étant encadrées par des panneaux (entrée;sortie):
- zone30 : B30;B51
- living_street : B52;B53
- pedestrian : B54;B55

zone:maxspeed sert à identifier des zones et la vitesse dans la zone. 
La zone n'étant pas forcément lié à une source réglemantaire comme 
pour les parkings où l'on est souvent sur des zones 10km/h
source:maxspeed sert à déterminer le contexte réglementaire lié à la 
vitesse en question (Si je me trompe que l'on me corrige).


Maintenant il faut choisir quoi mettre et bien le détailler dans le 
wiki. On peut aussi faire comme sur les autres page en indiquant les 
tags à éviter.


Bonne soirée
Jérôme


Le 8 novembre 2015 20:29, lenny > a écrit :


Bonjour
Je viens de découvrir, sur un highway, le tag
"/source:maxspeed=FR:zone30"/
Je l'ai cherché sur le wiki.
Autant je comprend par exemple : "/maxspeed=50/" avec
"/source:maxspeed=FR:urban"/ ou "/source:maxspeed=sign"/ ; par
contre, AMHA, je ne vois pas la valeur ajouté de
"/source:maxspeed=FR:zone30"/ car, dans ce cas, la vitesse limite
est toujours explicite.

Mais je suis encore plus étonné par les valeurs :
le wiki anglais propose deux possibilités (avec ou sans ":" entre
"zone" et "30")
"maxspeed=30 and zone:maxspeed=DE:zone30 - Most used value (used
21k times in June 2015)"
"maxspeed=30 and source:maxspeed=DE:zone:30 - Second most used
value (used 18k times in June 2015)"

pareil en Allemand
"maxspeed=30 und source:maxspeed=DE:zone30 oder DE:zone oder
DE:zone:30"

en Français, une seule valeur est indiquée
"Pour taguer une zone 30, ajoutez les tags maxspeed=30 et
source:maxspeed=:zone:30"
et quand je vais voir taginfo, pour environ 9000 
"/zone:maxspeed=FR:30/"

"/source:maxspeed=FR:zone30/">3911
"/source:maxspeed=FR:zone:30/">  32
et là, la valeur proposée par le wiki est la moins utilisée ! déjà
que je ne voyais pas ce que ce tag apportait !!!

Cordialement
Lenny


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

Re: [OSM-talk-fr] OpenSolarMap...

[Pierre GRANJON]

Bonjour à tous,
Très bonne idée ce projet, et l'outil de crowdsourcing donne envie de
participer !
J'ai fait 200 ajouts, ça marche très bien mais j'ai quelques commentaires :

   - Dans le cas de toits à 4 pans, je mets en général "?", est-ce le cas
   de tout le monde ?
   - Il manque un outil pour indiquer une erreur OSM, parfois je tombe sur
   des zones qui ne semblent pas être des bâtiments, en tout cas en se basant
   sur l'image satellite
   - On m'a également proposé des bâtiments d'un complexe pétrolier,
   possibilité de dire que ce type de bâtiment n'est pas adapté ?
   - Enfin, j'ai repéré quelques panneaux solaires déjà existants, pour
   lesquels j'ai tout  de même renseigné l'orientation. Ca pourrait être
   l'occasion de recenser l'existant en panneaux solaires ?
   - Que vont devenir les bâtiments classés en orientation inconnue,
   feront-ils l'objet d'une seconde vague ?

En attendant je continue jusqu'à avoir fini Marseille !
Pierre

Le 9 novembre 2015 11:00, Philippe Verdy  a écrit :

> Pour le visiteur lambda tombant sur le site via un lien, la page devrait
> comporter au minimum un dialogue de présentation. Car si on voit bien un
> rond jaune sur une photo aérienne, le premier réflexe est de cliquer dessus
> mais il ne se passe rien, et même avec les nouvelles icône en bas, on peut
> cliquer dessus sans savoir ce que c'est ou ce que ça fait.
> Le crowdsourcing a ses limites il faut tout de même expliquer un peu ce
> qui est attendu. Sinon cela donnera plein de clics au hasard et la valeur
> de ces clics sera faible, le résultat obtenu sera quasiment inexploitable
> s'il faut ensuite tout revalider, et même si l'aaplication gère le
> crowdsourcing avec plusieurs contributions comparées (combien suffisent ?
> ce n'est pas évident car presque personne ne sait quoi faire quand il tombe
> sur ce genre de page).
>
> OK il y a bien l'icône dans l'angle supérieur gauche mais c'est surtout un
> logo et il est en fait inhabituel de cliquer dans un premier temps sur le
> logo d'un site, quel qu'il soit, surtout s'il manque un libellé explite tel
> que "Aide" ou "Présentation".
>
> Et dans le cadre de cette expérimentation menée uniquement en France pour
> l'instant, ce n'est pas compliqué de mettre ce texte en français lisible
> (les traductions viendront après si l'expérimentation doit s'étendre
> ailleurs, mais au cas où il n'est pas compliqué non plus d'afficher
> quelques mots en anglais).
>
> Bref ajouter au minimum un panneau explicatif sur la page, empêchant de
> cliquer les 4 icones en bas tant que ce panneau n'est pas lu et fermé
> (d'ailleurs l'icône "?" me semblait plus associée à une action pour
> demander de l'aide ou de la documentation, mais un clic dessus est assez
> décevant et on ne voit pas ce qui s'est réellement passé et on ne sait
> toujours pas ce qu'on doit faire.
>
> Et dans le cadre d'une expérimentation, il me semble évident qu'il faut un
> lien clair vers une page d'aide/support pour poster un commentaire,
> signaler une anomalie, consulter une page de nouvelles ou statuts, ou
> listant des anomalies en cours de résolution ou certains changements
> importants ou qui vont être ajoutés bientôt. Ce lien de signalement devrait
> être toujours visible quelque part. Et sans besoin de deviner ce que
> peuvent signifier ces nouvelles icônes ou logos spécifiques à ce
> site/projet.
>
> Sur la page de présentation, il faudrait aussi donner des exemples.
>
> Sinon c'est vrai que plutôt qu'un cercle, il serait préférable d'avoir la
> forme du batiment avec un léger buffer (pas forcément nécessaire si le
> tracé utilise des lignes d'épaisseur suffisante mais semi-transparentes, ou
> si en survolant à la souris il y a moyen de masquer temporairement cette
> forme surajoutée sur la photo ou la faire "clignoter" de façon progressive
> (une simple variation en double pente triangulaire de la composante alpha,
> avec un cycle lent de 2-3 secondes, devrait suffire pour ne même pas avoir
> à calculer un buffer mais directement représenter la géométrie originale).
>
> Il semble que pour l'instant ces cercles de taille fixe sont seulement
> issus de la position d'un seul point du bâtiment (et pas toujours non plus
> son centroïde, dans de nombreux cas le centre est en fait largement décalé
> vers un bord, voire carrément à côté; en zone urbaine on ne sait pas bien
> de quel batiment il s'agit de noter les orientations de toits quand il y a
> plein de batiments accolés les uns aux autres.
>
> Le 9 novembre 2015 09:11, Christian Quest  a
> écrit :
>
>> Petit changement... les icônes représentant les toits sont un peu plus
>> explicites.
>>
>> Plus de 7000 contributions depuis hier matin, c'est impressionnant !
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> 

Re: [OSM-talk-fr] Problème de nommage de rue

[Philippe Verdy]

Les panneaux peuvent parfois utiliser des abréviations (comme ici les
prénoms), la poste aussi (pas toujours les mêmes, la Poste imposant des
noms plus courts pour les adresses normalisées sur les enveloppes peut
avoir utilisé ses propres abréviations). Les planches cadastrales ont aussi
leurs abréviations.

Le FANTOIR enfin abrège aussi à cause du format du fichier (il y a déjà les
codes pout les types de voie, il manque tous les accents et souvent des
apostrophes ou traits d'union, souvent aucun point abréviatif, et aucune
distinction des casses de lettres.

Dans OSM on évite ces abréviations et autant que possible on restaure les
noms entiers, les accents, la casse, les apostrophes et traits d'union
corrects (le rapprochement avec FANTOIR reste encore facile avec la
ref:FR:FANTOIR=* malgré ce nom remis en forme, même si le format FANTOIR a
été conçu du temps des vieux logiciels écrits en COBOL sur des systèmes qui
ne savait échanger correctement entre eux que de l'ASCII). C'est au
logiciel de rendu de choisir ensuite la façon d'abréger (si nécessaire) ou
un style d'affichage tout en capitales.

Quand aux "sauts de lignes" présents sur les panneaux ou dans le cadastre,
ne pas en tenir compte et les traiter comme des blancs.

Le 9 novembre 2015 10:58, Ludovic Hirlimann  a écrit
:

> Coucou,
>
> j'ai commencé a participer au projet BANO, il y a trois semaine. J'ai plus
> ou moins fini ma ville et je me suis donc attelé au village voisin. J'ai un
> soucis avec la commune de Pompignan
> http://cadastre.openstreetmap.fr/fantoir/#insee=82142=0.
>
> La rue Jean Jacques lefranc :
>
> https://www.openstreetmap.org/edit#map=18/43.81764/1.31263
>
> http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/43.81742/1.31282
>
> en bas de la voie (et à gauche sur la carte) il y a un panneau avec la
> mention :
> Rue
> J. Jacques
> LEFRANC
>
> Juste au niveau du coude (là ou est le n°19 sur la vue BANO) il y a un
> autre panneau avec la mention
>
> AVENUE
> J. J. LEFRANC
> DE POMPIGNAN
>
> Le cadastre réference RUE JJ LEFRANC DE POMPIGNAN
>
> La commune en question n'est vraiment pas clair organisé sur ses panneaux
> de voiries.
>
> Ma question est donc, commen dois-je nommer le rue ? que faire dans
> FANTOIR ?
>
>
> Ludo
> --
> http://sietch-tabr.tumblr.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] Problème de nommage de rue

[Ludovic Hirlimann]

je n'ai pas de problème avec Jean Jacques LEFRANC dans mon exemple. J'ai
plus des problèmes avec rue/avenue et avec la partie manquante "de
pompignan" , comment choisir entre rue et ave ? (j pense prendre le de
pompugnan car présent dans le cadastre.

Ludo


2015-11-09 11:10 GMT+01:00 Philippe Verdy :

> Les panneaux peuvent parfois utiliser des abréviations (comme ici les
> prénoms), la poste aussi (pas toujours les mêmes, la Poste imposant des
> noms plus courts pour les adresses normalisées sur les enveloppes peut
> avoir utilisé ses propres abréviations). Les planches cadastrales ont aussi
> leurs abréviations.
>
> Le FANTOIR enfin abrège aussi à cause du format du fichier (il y a déjà
> les codes pout les types de voie, il manque tous les accents et souvent des
> apostrophes ou traits d'union, souvent aucun point abréviatif, et aucune
> distinction des casses de lettres.
>
> Dans OSM on évite ces abréviations et autant que possible on restaure les
> noms entiers, les accents, la casse, les apostrophes et traits d'union
> corrects (le rapprochement avec FANTOIR reste encore facile avec la
> ref:FR:FANTOIR=* malgré ce nom remis en forme, même si le format FANTOIR a
> été conçu du temps des vieux logiciels écrits en COBOL sur des systèmes qui
> ne savait échanger correctement entre eux que de l'ASCII). C'est au
> logiciel de rendu de choisir ensuite la façon d'abréger (si nécessaire) ou
> un style d'affichage tout en capitales.
>
> Quand aux "sauts de lignes" présents sur les panneaux ou dans le cadastre,
> ne pas en tenir compte et les traiter comme des blancs.
>
> Le 9 novembre 2015 10:58, Ludovic Hirlimann  a
> écrit :
>
>> Coucou,
>>
>> j'ai commencé a participer au projet BANO, il y a trois semaine. J'ai
>> plus ou moins fini ma ville et je me suis donc attelé au village voisin.
>> J'ai un soucis avec la commune de Pompignan
>> http://cadastre.openstreetmap.fr/fantoir/#insee=82142=0.
>>
>> La rue Jean Jacques lefranc :
>>
>> https://www.openstreetmap.org/edit#map=18/43.81764/1.31263
>>
>> http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/43.81742/1.31282
>>
>> en bas de la voie (et à gauche sur la carte) il y a un panneau avec la
>> mention :
>> Rue
>> J. Jacques
>> LEFRANC
>>
>> Juste au niveau du coude (là ou est le n°19 sur la vue BANO) il y a un
>> autre panneau avec la mention
>>
>> AVENUE
>> J. J. LEFRANC
>> DE POMPIGNAN
>>
>> Le cadastre réference RUE JJ LEFRANC DE POMPIGNAN
>>
>> La commune en question n'est vraiment pas clair organisé sur ses panneaux
>> de voiries.
>>
>> Ma question est donc, commen dois-je nommer le rue ? que faire dans
>> FANTOIR ?
>>
>>
>> Ludo
>> --
>> http://sietch-tabr.tumblr.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
>
>


-- 
http://sietch-tabr.tumblr.com/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OpenSolarMap...

[Jérôme Seigneuret]

En effet c'est mieux ;-)

Le 9 novembre 2015 09:11, Christian Quest  a écrit
:

> Petit changement... les icônes représentant les toits sont un peu plus
> explicites.
>
> Plus de 7000 contributions depuis hier matin, c'est impressionnant !
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> 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] OpenSolarMap...

[Christian Quest]

 Petit changement... les icônes représentant les toits sont un peu plus
explicites.

Plus de 7000 contributions depuis hier matin, c'est impressionnant !

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

[OSM-talk-fr] Problème de nommage de rue

[Ludovic Hirlimann]

Coucou,

j'ai commencé a participer au projet BANO, il y a trois semaine. J'ai plus
ou moins fini ma ville et je me suis donc attelé au village voisin. J'ai un
soucis avec la commune de Pompignan
http://cadastre.openstreetmap.fr/fantoir/#insee=82142=0.

La rue Jean Jacques lefranc :

https://www.openstreetmap.org/edit#map=18/43.81764/1.31263

http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/43.81742/1.31282

en bas de la voie (et à gauche sur la carte) il y a un panneau avec la
mention :
Rue
J. Jacques
LEFRANC

Juste au niveau du coude (là ou est le n°19 sur la vue BANO) il y a un
autre panneau avec la mention

AVENUE
J. J. LEFRANC
DE POMPIGNAN

Le cadastre réference RUE JJ LEFRANC DE POMPIGNAN

La commune en question n'est vraiment pas clair organisé sur ses panneaux
de voiries.

Ma question est donc, commen dois-je nommer le rue ? que faire dans FANTOIR
?


Ludo
-- 
http://sietch-tabr.tumblr.com/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OpenSolarMap...

[Philippe Verdy]

Pour le visiteur lambda tombant sur le site via un lien, la page devrait
comporter au minimum un dialogue de présentation. Car si on voit bien un
rond jaune sur une photo aérienne, le premier réflexe est de cliquer dessus
mais il ne se passe rien, et même avec les nouvelles icône en bas, on peut
cliquer dessus sans savoir ce que c'est ou ce que ça fait.
Le crowdsourcing a ses limites il faut tout de même expliquer un peu ce qui
est attendu. Sinon cela donnera plein de clics au hasard et la valeur de
ces clics sera faible, le résultat obtenu sera quasiment inexploitable s'il
faut ensuite tout revalider, et même si l'aaplication gère le crowdsourcing
avec plusieurs contributions comparées (combien suffisent ? ce n'est pas
évident car presque personne ne sait quoi faire quand il tombe sur ce genre
de page).

OK il y a bien l'icône dans l'angle supérieur gauche mais c'est surtout un
logo et il est en fait inhabituel de cliquer dans un premier temps sur le
logo d'un site, quel qu'il soit, surtout s'il manque un libellé explite tel
que "Aide" ou "Présentation".

Et dans le cadre de cette expérimentation menée uniquement en France pour
l'instant, ce n'est pas compliqué de mettre ce texte en français lisible
(les traductions viendront après si l'expérimentation doit s'étendre
ailleurs, mais au cas où il n'est pas compliqué non plus d'afficher
quelques mots en anglais).

Bref ajouter au minimum un panneau explicatif sur la page, empêchant de
cliquer les 4 icones en bas tant que ce panneau n'est pas lu et fermé
(d'ailleurs l'icône "?" me semblait plus associée à une action pour
demander de l'aide ou de la documentation, mais un clic dessus est assez
décevant et on ne voit pas ce qui s'est réellement passé et on ne sait
toujours pas ce qu'on doit faire.

Et dans le cadre d'une expérimentation, il me semble évident qu'il faut un
lien clair vers une page d'aide/support pour poster un commentaire,
signaler une anomalie, consulter une page de nouvelles ou statuts, ou
listant des anomalies en cours de résolution ou certains changements
importants ou qui vont être ajoutés bientôt. Ce lien de signalement devrait
être toujours visible quelque part. Et sans besoin de deviner ce que
peuvent signifier ces nouvelles icônes ou logos spécifiques à ce
site/projet.

Sur la page de présentation, il faudrait aussi donner des exemples.

Sinon c'est vrai que plutôt qu'un cercle, il serait préférable d'avoir la
forme du batiment avec un léger buffer (pas forcément nécessaire si le
tracé utilise des lignes d'épaisseur suffisante mais semi-transparentes, ou
si en survolant à la souris il y a moyen de masquer temporairement cette
forme surajoutée sur la photo ou la faire "clignoter" de façon progressive
(une simple variation en double pente triangulaire de la composante alpha,
avec un cycle lent de 2-3 secondes, devrait suffire pour ne même pas avoir
à calculer un buffer mais directement représenter la géométrie originale).

Il semble que pour l'instant ces cercles de taille fixe sont seulement
issus de la position d'un seul point du bâtiment (et pas toujours non plus
son centroïde, dans de nombreux cas le centre est en fait largement décalé
vers un bord, voire carrément à côté; en zone urbaine on ne sait pas bien
de quel batiment il s'agit de noter les orientations de toits quand il y a
plein de batiments accolés les uns aux autres.

Le 9 novembre 2015 09:11, Christian Quest  a écrit
:

> Petit changement... les icônes représentant les toits sont un peu plus
> explicites.
>
> Plus de 7000 contributions depuis hier matin, c'est impressionnant !
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> 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] Rouen - Pont Mathilde - j'ai un doute sur 3 voies

[Jérôme Seigneuret]

Bonjour,

acces=no sur le dernier est très bizarre

A noter que le pont à coté était en travaux donc j'invite vivement à voir
avec des locaux. Un peu de Mapillary ou quelques photos serait l'idéal.

http://www.normandie-actu.fr/a-rouen-le-pont-mathilde-rouvrira-et-dautres-travaux-commenceront_80199/

http://www.mapillary.com/map/search/49.42997594012505/1.0878981038017912/14.270118990329289

Les ruptures des niveaux highway=primary,secondary,tertiary est
incompréhensible

Le problème s'étant au Sud de Rouen.


Le 9 novembre 2015 12:18,  a écrit :

> Bonjour
>
> Vous en pensez quoi de ces trois voies :
>
> https://www.openstreetmap.org/way/188324016
> https://www.openstreetmap.org/way/188324013
> https://www.openstreetmap.org/way/44785324
>
> ils se suivent et des étiquettes ne sont pas "homogènes"
>
> Cordialement
>
> --
> David Crochet
>
> ___
> 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] Avis aux franciliens

[Jérôme Seigneuret]

En effet, rien de compréhensible
http://www.mapillary.com/map/im/n_19TpzXxab4BBiIbH0T8Q/photo

C'est de la 2 fois 4 voies mais je pense juste à une retouche d'un seul des
deux tronçons... Je corrige

Le 9 novembre 2015 12:31, Romain MEHUT  a écrit :

> Bonjour,
>
> Ayant dû emprunter tout récemment le boulevard périphérique intérieur, je
> me suis étonné de voir un oneway étrange à cet endroit
> http://www.openstreetmap.org/#map=18/48.82285/2.38027 avec donc les 2
> ways dans le même sens et qui plus est se croisent.
>
> Quelqu'un qui connait bien l'endroit pour corriger?
>
> Romain
>
> ___
> 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] Avis aux franciliens

[Jérôme Seigneuret]

Voilà c'est fait sur la base des données GPS

Le 9 novembre 2015 12:48, Jérôme Seigneuret  a
écrit :

> En effet, rien de compréhensible
> http://www.mapillary.com/map/im/n_19TpzXxab4BBiIbH0T8Q/photo
>
> C'est de la 2 fois 4 voies mais je pense juste à une retouche d'un seul
> des deux tronçons... Je corrige
>
> Le 9 novembre 2015 12:31, Romain MEHUT  a écrit :
>
>> Bonjour,
>>
>> Ayant dû emprunter tout récemment le boulevard périphérique intérieur, je
>> me suis étonné de voir un oneway étrange à cet endroit
>> http://www.openstreetmap.org/#map=18/48.82285/2.38027 avec donc les 2
>> ways dans le même sens et qui plus est se croisent.
>>
>> Quelqu'un qui connait bien l'endroit pour corriger?
>>
>> Romain
>>
>> ___
>> 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] Avis aux franciliens

[Jérôme Seigneuret]

Il reste le radar "Boulevard Périphérique Intérieur" qui n'a plus sa
relation. Je vous laisse faire un fix la dessus

Le 9 novembre 2015 12:51, Jérôme Seigneuret  a
écrit :

> Voilà c'est fait sur la base des données GPS
>
> Le 9 novembre 2015 12:48, Jérôme Seigneuret  a
> écrit :
>
>> En effet, rien de compréhensible
>> http://www.mapillary.com/map/im/n_19TpzXxab4BBiIbH0T8Q/photo
>>
>> C'est de la 2 fois 4 voies mais je pense juste à une retouche d'un seul
>> des deux tronçons... Je corrige
>>
>> Le 9 novembre 2015 12:31, Romain MEHUT  a écrit :
>>
>>> Bonjour,
>>>
>>> Ayant dû emprunter tout récemment le boulevard périphérique intérieur,
>>> je me suis étonné de voir un oneway étrange à cet endroit
>>> http://www.openstreetmap.org/#map=18/48.82285/2.38027 avec donc les 2
>>> ways dans le même sens et qui plus est se croisent.
>>>
>>> Quelqu'un qui connait bien l'endroit pour corriger?
>>>
>>> Romain
>>>
>>> ___
>>> 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] erreur Overpass turbo

[Philippe Verdy]

Note que tu as des problèmes avec ton fournisseur de messagerie supposé
être laposte.net. Mais lors de l'envoi de tes messages l'adresse IP de
l'expéditeur n'est pas associée à ce domaine et ne correspond pas à
l'authentification fournie par laposte.net. Du coup tes mails postés ici
sont classés systématiquement dans les spams par Gmail. Et on doit les
récupérer un par un et sans doute bcp ici ne les auront même pas lus. C'est
soit un problème de ton fournisseur,  soit parce qu'en fait tu écrits ici
en passant par un autre fournisseur de messagerie. Si tu veux que tes mails
arrivent sans que tu changes ton adresse mail de souscription,  vérifie tes
paramètres SMTP pour l'envoi du courrier pour utiliser le serveur SMTP de
la poste quand tu écrits ici sous ton adresse mail de la poste.
Le 9 nov. 2015 11:44, "bernard"  a écrit :

> Bonjour,
> Si Vous avez ce problème, Vous pouvez consulter et signaler à l'une de ces
> adresses :
> https://github.com/tyrasd/overpass-turbo/issues/213
> https://github.com/drolbr/Overpass-API/issues/229
>
> Pour ma part, mon problème subsiste avec Firefox mais pas de soucis avec
> Internet Explorer
>
>
> Le 05/11/2015 12:18, Stéphane Péneau a écrit :
>
>> Le 05/11/2015 10:17, François Lacombe a écrit :
>>
>>>
>>> Bonjour,
>>>
>>> Le soucis se presente régulièrement quand j'exécute un script passant
>>> plusieurs requêtes successives.
>>> Parfois certaines reçoivent ce code d'erreur en retour.
>>> Pourtant je suis le seul a envoyer des requêtes depuis cette @IP.
>>>
>>>
>> De mon côté, c'était en requêtant  plusieurs types de tags via le wizard.
>> Du type "shop=* OR craft=* OR office=* in un-nom-de-commune"
>>
>> Stf
>>
>>
>>
>> ___
>> 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