date:20150205

2015-02-05 13:17 GMT+01:00 François Lacombe fl.infosrese...@gmail.com:
 +1 Tony, keep going.

 François Lacombe

Non, c'est trop facile. Il faut d'abord examiner ce qui se passe avant
de donner un blanc-seing aussi rapidement (même si le message suivant
commence à poser les bonnes questions).
Le problème principal tourne autour de cette référence
ref:FR:commune. Il y a déjà en France un code unique pour les rues,
celui de la dgfip ref:FR:FANTOIR. L'explication donnée par Tony:

 Vous faites ce que vous voulez avec les codes Fantoir, nous gérons nos 
 identifiants internes

n'est en aucun cas satisfaisante, pas seulement parce que le tag n'est
documenté nul part (alors qu'il est utilisé depuis 2 ans déjà) mais
surtout parce qu'il est d'un usage interne ! OSM ne peut être le
réceptacle de données à usage interne, inexploitables par les autres
utilisateurs et incompréhensibles par les autres contributeurs. C'est
une règle fondamentale dans ce type de projet. D'autant plus que des
solutions techniques (externes à OSM) sont faciles à mettre en place
si un code unique, celui du fantoir, est correctement mis en place.

Notez que ça n'est pas la première fois que les expérimentations
faites sur Orange posent questions. C'était déjà le cas en 2013 avec
les mêmes personnes et le ref:FR:commune s'appelait à l'époque
ref:orange:
https://lists.openstreetmap.org/pipermail/talk-fr/2013-March/056807.html

mais qu'à l'époque, le ref:FR:fantoir n'existait pas et l'excuse de
l'expérimentation était encore acceptable.

Concernant les autres points (limites communales), il ne s'agit
apparement que de maladresses. Inutile donc d'y revenir. Sinon,
concernant les échanges épistolaires de Philippe, on le connait ici
très bien et il sait déjà qu'il gagnerait beaucoup à être moins
agressif dans le choix de ses expressions mais qu'il ne changera
jamais de ce côté là.

Pieren

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

Re: [Talk-it] parti di edifici e numeri civici

2015-02-05 Diskussionsfäden Marco_T

Stefano Salvador wrote
 nella realtà non è così, quando costruisci una nuova casa il comune ti
 assegna tanti numeri quanti ingressi hai, quindi è molto comune avere più
 civici per immobile (tipicamente porta di casa e portone per l'auto).
 Prova
 a farti un giro in una zona con villette e vedrai che è quasi sempre così.
 
 Inoltre secondo me non è vero che mettendo il numero all'edificio non devi
 metterlo sui poi, infatti capita spesso che negozi contigui appartenenti
 allo stesso edificio abbiano civici diversi (appunto perché il civico
 indica l'ingresso e non l'immobile)

Confermo e concordo (per i comuni che conosco).
Inoltre se l edificio fa angolo tra 2 vie cambia pure il nome della via ai
civici sui relativi affacci.
Saluti.

Marco_T



--
View this message in context: 
http://gis.19327.n5.nabble.com/parti-di-edifici-e-numeri-civici-tp5832513p5832592.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [OSM-talk-nl] OSMC problemen

2015-02-05 Diskussionsfäden Patrick Coenen

Waymarked trails laat in de route omschrijving wel de juiste nieuwste tagging 
zien, alleen de rendering wordt nog niet aangepast. Maar ik ben van 
waymarkedtrails gewend dat die in korte tijd (binnen 10 minuten) eigenlijk met 
de nieuwste aanpassingen direct renderen.

From: marc.ge...@gmail.com
Date: Thu, 5 Feb 2015 13:49:42 +0100
To: talk-nl@openstreetmap.org
Subject: Re: [OSM-talk-nl] OSMC problemen

en je verandering was gedaan voor 12:02 UTC vandaag ?
m
2015-02-05 13:47 GMT+01:00 Patrick Coenen pe...@live.com:

Ik heb de relaties zo gezet als onder aanbevolen, maar het wil niet helemaal op 
waymarkedtrails
Relatie 4559623 = blauw CRelatie 4559785 = groen DRelatie 4559610 = paars E

 Date: Thu, 5 Feb 2015 13:10:39 +0100
 From: md...@xs4all.nl
 To: talk-nl@openstreetmap.org
 Subject: Re: [OSM-talk-nl] OSMC problemen

 On 2015-02-05 12:52, Patrick Coenen wrote:

  ik heb een probleem met de tag OSMC symbol.
  De help functie op deze site [1] helpt me niet verder.
  Hoe moet ik de tag invullen om een gekleurd (paars/groen/blauw/rood)
  vierkantje te krijgen met daarin aan witte letter als symbool?
  mij lukt het niet [2]. een witte E moet op paarse achtergrond, witte D
  op een groene, witte C op een blauwe.

 Je bedoelt denk ik relatie 4559610? Volgens mij ben je een veld 
 vergeten. Er staat nu
 purple:::E:white, volgens mij moet je purple:purple:::E:white hebben.

 way color:purple
 background:purple
 foreground:leeg
 foreground2:leeg
 text:E
 text color:white

 Maarten

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

___

Talk-nl mailing list

Talk-nl@openstreetmap.org

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

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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Pieren wrote
 Okay pour ce cas. Mais uniquement pour ce cas où la voirie n'a pas encore
 de code fantoir. On peut parfaitement tolérer ce ref:FR:commune comme
 une solution transitoire pour satisfaire tout le monde. Mais en aucun cas,
 on ne devrait le généraliser à toutes les voies.

L'avantage de cet identifiant est qu'il est plus exhaustif que le Fantoir.
Par exemple, à Orange, sur les 797 voies recensées, il manque 96 rivolis.
Dans la base DGFiP, j'ai relevé quelques doublons. Je vois pas trop
l'intérêt d'ajouter un identifiant quand le rivoli n'existe pas et de le
supprimer derrière.


Pieren wrote
 Et ça n'exonère pas de le documenter dans le wiki...

J'ai commencé ici :  http://wiki.openstreetmap.org/wiki/Vaucluse/voirie
http://wiki.openstreetmap.org/wiki/Vaucluse/voirie  




-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien  chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5832601.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-nl] OSMC problemen

2015-02-05 Diskussionsfäden Patrick Coenen

Ik heb de relaties zo gezet als onder aanbevolen, maar het wil niet helemaal op 
waymarkedtrails
Relatie 4559623 = blauw CRelatie 4559785 = groen DRelatie 4559610 = paars E

 Date: Thu, 5 Feb 2015 13:10:39 +0100
 From: md...@xs4all.nl
 To: talk-nl@openstreetmap.org
 Subject: Re: [OSM-talk-nl] OSMC problemen

 On 2015-02-05 12:52, Patrick Coenen wrote:

  ik heb een probleem met de tag OSMC symbol.
  De help functie op deze site [1] helpt me niet verder.
  Hoe moet ik de tag invullen om een gekleurd (paars/groen/blauw/rood)
  vierkantje te krijgen met daarin aan witte letter als symbool?
  mij lukt het niet [2]. een witte E moet op paarse achtergrond, witte D
  op een groene, witte C op een blauwe.

 Je bedoelt denk ik relatie 4559610? Volgens mij ben je een veld 
 vergeten. Er staat nu
 purple:::E:white, volgens mij moet je purple:purple:::E:white hebben.

 way color:purple
 background:purple
 foreground:leeg
 foreground2:leeg
 text:E
 text color:white

 Maarten

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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Pieren wrote
Non, c'est trop facile. Il faut d'abord examiner ce qui se passe avant de
donner un blanc-seing aussi rapidement (même si le message suivant
commence à poser les bonnes questions).
Le problème principal tourne autour de cette référence ref:FR:commune.
Il y a déjà en France un code unique pour les rues, celui de la dgfip
ref:FR:FANTOIR. L'explication donnée par Tony:
Vous faites ce que vous voulez avec les codes Fantoir, nous gérons nos
identifiants internes
n'est en aucun cas satisfaisante, pas seulement parce que le tag n'est
documenté nul part (alors qu'il est utilisé depuis 2 ans déjà) mais
surtout parce qu'il est d'un usage interne ! OSM ne peut être le
réceptacle de données à usage interne, inexploitables par les autres
utilisateurs et incompréhensibles par les autres contributeurs. C'est une
règle fondamentale dans ce type de projet. D'autant plus que des solutions
techniques (externes à OSM) sont faciles à mettre en place si un code
unique, celui du fantoir, est correctement mis en place.

Le code Fantoir est généré par la DGFiP a posteriori de la création ou
dénomination de la voie faite par les communes. Du coup, les communes qui
gèrent une base de données voirie en interne attendent entre 1 et 3 ans
avant de récupérer ce code, ce qui n’est pas du tout satisfaisant.

L’idée du projet est d’harmoniser cet identifiant mais, comme la BANO ne se
fera pas en 2 jours, ce projet non plus. En théorie, il n’implique pas OSM
parce que beaucoup de communes gèrent ça dans leurs coins mais, à Orange (et
maintenant la CCPRO), nous avons pris le parti d’intégrer OSM dans le projet
parce que ça permet aussi d’améliorer la qualité des données d’OSM.

Pieren wrote
Notez que ça n'est pas la première fois que les expérimentations faites
sur Orange posent questions. C'était déjà le cas en 2013 avec les mêmes
personnes et le ref:FR:commune s'appelait à l'époque ref:orange:
https://lists.openstreetmap.org/pipermail/talk-fr/2013-March/056807.html
mais qu'à l'époque, le ref:FR:fantoir n'existait pas et l'excuse de
l'expérimentation était encore acceptable.

Effectivement, c’est pour cela que j’ai modifié le ref :orange en ref :FR
:Commune. L’expérimentation est toujours en cours et le code FANTOIR n’est
pas parfait. On s’en rendra très vite compte avec la BANO lorsqu’il faudra
faire les mises à jour des adresses.

Ce sujet pourrait sûrement être discuté au prochain SOTM à Brest.

-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien chef de projets
--
View this message in context:
http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5832597.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

verdy_p wrote
Peux-tu citer une source ouverte (avec une licence compatible) où on peut
contrôler cette données ? Si non, elle n'a rien à faire dans OSM.

Il est un peu vieux parce qu'on n'a pas encore fini notre projet mais ça
devrait te convenir :
https://docs.google.com/spreadsheet/ccc?key=0AvqnfztqzzrOdE16YWpINmdfVm9MaERNWWdqQ09jMHc#gid=0

verdy_p wrote
Tu te dis Administrateur OpenStreetmap.fr mais tu n'en respectes pas les
règles de base.

Je te laisse ton argument, j'ai même pas envie de répondre

verdy_p wrote
Tu te dis Mandataire Grand Sud-Est mais mandataire de qui ?

de l'association OpenStreetMap-France

verdy_p wrote
- Je n'agis pas seul puisqu'on est plusieurs sur le projet

Qui ?

Je te l'ai déjà dit, les 3 grosses intercommunalités de Vaucluse et, je
penses, d'autres qui seront intéressées

verdy_p wrote
- Qu'est ce qui te permet de dire que ce qui a été fait sur Orange a
été mal
fait ?

Ce que moi et d'autres corrigent après ton passage qui est bien un
saccage..

Un saccage parce que j'ai fait péter 3 bouts de relations dans le Vaucluse ?
oufff!!! je mérite au moins la prison à perpétuité, là !

verdy_p wrote
- Je discute même pas sur le reste parce que j'ai même pas envie de
m'étaler
là-dessus, que tu racontes beaucoup d'ânerie et que tu mélanges des
concepts
et des projets qui n'ont rien à voir.

Non tu mélanges le projet OSM avec ton projet privé.

Mon projet n'a rien de privé. Je ne gagne pas d'argent dessus et, au
contraire, j'enrichis les données OSM.

verdy_p wrote
Je t'en ai avisé avant. Et cette discussion dépasse largement le cadre des
échanges privés quand tu commences par me donner un ordre sans rien
expliquer publiquement.

Soit, mais pas au point de faire un vulgaire copier-coller des mails.

verdy_p wrote
Enfin, je crois connaitre le projet BANO largement mieux que toi donc.

On aurait aimé t'entendre ici alors sur ce sujet. Tu arrives bien tard.

Pourquoi ? tu crois qu'il n'y a que dans la mailing list qu'on discute de
BANO ?

-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien chef de projets
--
View this message in context:
http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5832593.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-05 14:41 GMT+01:00 Tony Emery tony.em...@yahoo.fr:

 Le code Fantoir est généré par la DGFiP a posteriori de la création ou
 dénomination de la voie faite par les communes. Du coup, les communes qui
 gèrent une base de données voirie en interne attendent entre 1 et 3 ans
 avant de récupérer ce code, ce qui n’est pas du tout satisfaisant.

Okay pour ce cas. Mais uniquement pour ce cas où la voirie n'a pas
encore de code fantoir. On peut parfaitement tolérer ce
ref:FR:commune comme une solution transitoire pour satisfaire tout
le monde. Mais en aucun cas, on ne devrait le généraliser à toutes les
voies. Et ça n'exonère pas de le documenter dans le wiki...

Pieren

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

Re: [Talk-it] [Bibliotecari] Open Culture Atlas: che strada possiamo fare insieme?

2015-02-05 Diskussionsfäden Germano Massullo

Il 05/02/2015 15:29, Fabri ha scritto:
 ah ok, visto che ancora non è stata scelta data nè argomento, per quello di
 febbraio si riesce a organizzare al fusolab?
Purtroppo a Febbraio io non ci sono, però potete sempre organizzare voi
in caso.

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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Le 5 février 2015 14:09, Tony Emery tony.em...@yahoo.fr a écrit :

  Non tu mélanges le projet OSM avec ton projet privé.

 Mon projet n'a rien de privé. Je ne gagne pas d'argent dessus et, au
 contraire, j'enrichis les données OSM.


L'enrichissement pour mettre des données privées, c'est un projet privé. Tu
n'as donné aucune référence consultable par d'autres. Ces données sont
inutilisables dans l'état. Merci donc de préciser ta source (pour qu'au
moins on puisse vérifier qu'elle est ouverte).

 Je t'en ai avisé avant. Et cette discussion dépasse largement le cadre des
  échanges privés quand tu commences par me donner un ordre sans rien
  expliquer publiquement.

 Soit, mais pas au point de faire un vulgaire copier-coller des mails.


Enfin, je crois connaitre le projet BANO largement mieux que toi donc.
  On aurait aimé t'entendre ici alors sur ce sujet. Tu arrives bien tard.

 Pourquoi ? tu crois qu'il n'y a que dans la mailing list qu'on discute de
 BANO ?


Non. Mais ton projet ne semble avoir été discuté nulle part ailleurs non
plus dans le cadre d'OSM.

Certes BANO n'est pas un projet complètement ficelé, mais il progresse, et
vite. Le nombre d'acteurs impliqués (collectivités et administrations)
aussi. Au fur et à mesure on peut voir des problèmes arriver, et on cherche
des solutions (comme partout dans OSM pour divers sujets). Mais c'est un
projet commun dans la lignée aussi du projet OSM plus général (et tout ce
qui est fait pour BANO ne va pas non plus dans OSM, ou pas immédiatement).

La cartographie est riche de règles qui ont toutes leurs nombreuses
exceptions et ce n'est pas facile de maintenir une certaine cohérence, mais
on cherche **même dans les expérimentations** à permettre aux autres aussi
de contribuer/vérifier/corriger/compléter/améliorer. Tout n'est pas
forcément documenté tout de suite mais on cherche malgré tout à rendre les
choses compréhensibles (ce qui n'est pas le cas de ton tag ref:FR:commune
quand justement tu ne parles plus maintenant d'un niveau communal mais d'un
niveau intercommunal !)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Espaces demi m....

2015-02-05 Diskussionsfäden Marc SIBERT

Le 3 février 2015 21:07, Philippe Verdy verd...@wanadoo.fr a écrit :

 En fait ce n'est pas tellement la taille


Tu as raison, ce n'est pas la taille qui compte.



 des libellé dans l'affichage de la carte qui me gène (qu'ils soient petits
 évite aussi de cacher trop de chose : on devine mais en cas de doute on a
 encore l'onglet des propriétés pour les afficher clairement, sans
 superposition de traits et de couleurs).

 C'est surtout dans l'interface utilisateur (liste des tags, dialogues de
 saisie ou de configuration, menus, etc...) que c'est pénible (et que le
 support international des autres écritures est défectif).

 Certes affiche correctement le tibétain ou le birman est compliqué à
 inclure (dommage qu'il n'y ait pas un meilleur moteur de rendu de texte
 comme il en existe pour Eclipse) et leur normalisation assez récente (avec
 encore quelques problèmes de stabilité), mais pour le bengali c'est stable
 depuis longtemps et c'est une langue diablement importante.

 Et ma presbytie naissante (qu'on aura tous...) commence à être un vrai
 problème que la correction optique ne parvient pas à palier : les textes
 trop petits sont fatigants pour la vue et c'est difficile de voir des
 fautes mineures comme un accent oublié, même en français, alors que tout le
 reste de l'OS et le navigateur ont un réglage possible qui apporte un vrai
 confort visuel.

 

 Je m'énerve


Il ne faudrait pas, car il n'y a pas d'étiquettes dans OSM, je veux dire
adhésives.


 autant devant les étiquettes alimentaires (je veux lire scrupuleusement
 les compositions, notamment la nature des matières grasses et le taux de
 sel de plus en plus souvent excessif) devenues totalement illisibles où il
 me faut chercher une bonne source lumineuse pour accentuer les contrastes,
 en essayant de les lire sans mes lunettes (avec c'est impossible).

 Maintenant il m'arrive d'utiliser la caméra de mon smartphone pour zoomer
 dessus mais ce n'est pas évident de trouver le bon éclairage quand même le
 smartphone apporte de l'ombre et que son flash se réfléchit trop sur la
 surface et est inutilisable et la surface n'est pas non plus plane ou bien
 l'étiquette est sous un plastique alvéolé ou rainuré.

 Vivement la généralisation les étiquettes lisibles sur Internet par
 QR-code : OpenFoodFacts OK, mais les fabricants ou emballeurs devraient les
 rendre lisibles sur en données OpenData sur un site officiel non
 publicitaire contenant toutes les infos légales sur une fiche d'information
 normalisée, y compris les numéros de lots et dates de fraîcheur ou de
 conservation, qui peuvent être ajoutées (en plus du code produit EAN, et
 même le prix de vente sur le QRcode ou sur le code barre additionnel des
 points de vente).

 Certains points de vente (hypermarchés) vont aussi jusqu'à masquer ces
 infos en collant par dessus un emballage ou un autocollant de promo
 (impossible à décoller sans défaire le lot ou abimer l'emballage), mais
 souvent c'est de la faute même de leurs fournisseurs qui livrent ces promos

 (on achète d'abord, après on verra chez soi comment lire les infos sur les
 produits achetés, et on a des mauvaises surprises avec des produits qui
 dans une seule portion contiennent plus de 2 grammes de sel, plus que la
 quantité maximale pour toute une journée, le sel n'est là que pour masquer
 le fait que ce sont des produits totalement insipides, il remplace l'huile
 végétale et les épices... (Ça m'arrive de goûter et de jeter le tout
 tellement c'est gras et salé et souvent aussi sans texture : même un chien
 domestique n'en veut pas, et pourtant c'est un produit de marque connue,
 parfois avec force publicité, vendu plus cher qu'un premier prix
 d'hypermarché).


 Le 3 février 2015 20:18, Félix Marty felixma...@outlook.com a écrit :

 J'approuve Philippe. JOSM a des progrès à faire là-dessus, les caractères
 affichés sur le calque OSM sont par exemple minuscules, et il n'y a à ma
 connaissance pas de possibilité pour changer facilement la taille de
 police
 des calques. Ces problèmes de taille de polices sont d'ailleurs je pense
 surtout visible sur les écrans à haute résolution type 1080p (mon cas).

 Le réglage des polices par défaut a cependant l'air d'être possible sur
 JOSM.
 Dans mon cas, l'utilisation du thème GTK+ permet d'utiliser la police (et
 la
 taille de police) définie par défaut sur le système. Il y quand même de
 nombreuses améliorations à apporter, je remarque par exemple que certains
 textes sont tronqués à cause de la taille de police (14) trop importante
 que
 j'utilise.

 Le mardi 3 février 2015, 13:55:51 Philippe Verdy a écrit :
  [...]


 Bien sûr Philippe, bien sûr.


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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

je suis d'accord, ce n'est même pas une référence communale selon la
description donnée par tony, mais une référence propre à la CCPRO

Bref ce devrait plutôt être ref:FR:87:CCPRO=* ou quelquechose du genre
permettant de classer ça.

Je réitère cependant ma demande d'accès public à la source de référence,
sinon cette référence est inutile dans OSM, et même interdite selon les
termes du contributeur d'OSM (que tony a lues et acceptées) et donc
nuisible au projet.

La CCPRO publie-t-elle ça en OpenData ?

Le 5 février 2015 16:56, Pierre-Yves Berrard pierre.yves.berr...@gmail.com
a écrit :

 Le 5 février 2015 16:13, Pieren pier...@gmail.com a écrit :

 2015-02-05 15:17 GMT+01:00 Tony Emery tony.em...@yahoo.fr:

  Dans la base DGFiP, j'ai relevé quelques doublons. Je vois pas trop
  l'intérêt d'ajouter un identifiant quand le rivoli n'existe pas et de le
  supprimer derrière.

 L'intérêt est que l'usage de ce code resterait très limité (par
 exemple 96 au lieu de 797 pour Orange) et que ça serait cohérent avec
 les autres communes françaises.

  J'ai commencé ici :  http://wiki.openstreetmap.org/wiki/Vaucluse/voirie
  http://wiki.openstreetmap.org/wiki/Vaucluse/voirie

 Il faudrait aussi voir ici:

 http://wiki.openstreetmap.org/wiki/WikiProject_France/Liste_des_r%C3%A9f%C3%A9rences_nationales

 Pieren


 Est-ce vraiment une référence qu'on peut qualifier de nationale ?

 Contrairement aux autres ref:FR:* de la page, on ne va pas la trouver sur
 l'ensemble du territoire français et il n'existe pas de répertoire
 officiel géré par un organisme qui en a la charge.

 PY


 ___
 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] Espaces demi m....

Le 5 février 2015 16:52, Marc SIBERT m...@sibert.fr a écrit :

 Le 3 février 2015 21:07, Philippe Verdy verd...@wanadoo.fr a écrit :

 En fait ce n'est pas tellement la taille


 Tu as raison, ce n'est pas la taille qui compte.


Un trait d'humour, je suppose ;-)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-be] Fixme's in Taglocator

De tag locator bestaat nog maar een dikke maand :-)

Mooie tool!

Op 5 februari 2015 10:50 schreef Glenn Plas gl...@byte-consult.be:

Hallo Marc,

Mooie tool. Zeker met de JOSM hooks. Ik denk dat de fixme's hier wel
over het hoofd worden gezien. Er mag idd wel wat cleanup gebeuren.

Bedankt voor de informatie, ik kende taglocater niet.

Glenn

On 04-02-15 16:26, Marc Zoutendijk wrote:
Goedendag allen,

Ik ben Marc Zoutendijk en mapper uit Nederland (ik woon in Vught) maar
met het meeste mapwerk op Spaanse grond. Omdat ik daar vaak op
fietsvakantie ben.
Ter introductie: http://www.marczoutendijk.nl

Sinds 2011 actief met en op OSM.

In Nederland zijn we veel actiever op het forum dan op de Mailinglist,
in België is dat andersom merk ik, dus meld ik me nu hier met vragen en
antwoorden.

Ik ben al geruime tijd bezig met de ontwikkeling van Taglocator, een op
de overpass-turbo gebaseerde tool waarmee snel een aantal vooraf
gedefinieerde user poi's kunnen worden gevonden.
Er zijn meer van dat soort tools, maar deze is vooral in eerste
instantie gemaakt voor eigen gebruik (om te zien waar in mijn buurt nog
mapwerk was te doen en of het goed was gedaan), maar al gauw bleek er
ook belangstelling van anderen te zijn.

Wat ermee kan kun je lezen in de wiki:

https://wiki.openstreetmap.org/wiki/Taglocator

Je kunt ook de hele ontwikkelingsgang lezen op het forum:
http://forum.openstreetmap.org/viewtopic.php?id=28807

Maar nog beter is proberen.
Op onderstaande permalink kun je zien hoeveel fixme's er in Antwerpen
nog zijn, maar net zo makkelijk is het om te zien hoeveel voetbalvelden
of cafe's daar zijn te vinden.

http://mijndev.openstreetmap.nl/~marczoutendijk/taglocator/?map=variouszoom=15lat=51.22197lon=4.41125layers=B00T

Met groet,
Marc Zoutendijk.

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

--
Everything is going to be 200 OK.

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

[OSM-talk-be] Fwd: [42] Hackathon eTourisme 2015

This seems interesting. I won't be able to go as I don't have a credit card
to pay the €20, but maybe somebody else wants to go and hack on some open
data.

Jo

-- Forwarded message --
From: Hugues Ligot hugues.li...@gmail.com
Date: 2015-02-05 10:12 GMT+01:00
Subject: [42] Hackathon eTourisme 2015
To: 4...@discuss.hackerspaces.be

Hey hackers,

We organise in march the first eTourisme hackathon in Belgium. It will take
place in Libramont from March 20 to 21.
Many public data files will be open for the event.

I heard from Hugo Herter, you might have some interest in it, so here is
the info !

Feel free to contact me or check our website (hackalux.be
http://t.signaledue.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XZs3MhNz6W3MhG_41qwqm4W3Mqkws56dVd2f6jRgQq02?t=http%3A%2F%2Fhackalux.be%2Fsi=5615661674397696pi=8f783747-fc4e-4658-d4b5-703e512d1b69
FR)
for more informations.

Happy hacking,

-- 
*Hugues Ligot*
Hackathon eTourisme 2015 http://www.hackalux.be/
+32 494 732 468 | hugues.li...@gmail.com | Abetterway.be
https://www.linkedin.com/profile/view?id=155250384trk=nav_responsive_tab_profile_pic
   https://twitter.com/Hugues_Lgt

___
42 mailing list
4...@discuss.hackerspaces.be
http://discuss.hackerspaces.be/listinfo.cgi/42-hackerspaces.be
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-it] parti di edifici e numeri civici

2015-02-05 Diskussionsfäden Matteo Quatrida

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 05/02/2015 10:47, Martin Koppenhoefer ha scritto:
 solo che ha lo svantaggio di dover ripetere l'indirizzo su ogni 
 poi

Però se il tuo POI è un'attività commerciale, avere all'interno del
POI l'indirizzo completo di civico credo sia una soluzione migliore,
anche se comporti ripeterlo più volte.
Ad esempio, in un grosso centro commerciale, come faresti a inserire i
POI di tutte le attività comprensive di indirizzo, senza ripetere i
civici n volte?

- -- 
Matteo Quatrida
GNU/Linux User #498939
OpenStreetMap Contributor since 2009

«L'ordine è il piacere della ragione, ma il disordine è il piacere
dell'immaginazione!» Paul Claudel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU00c+AAoJEHnO6jolYLDx17QH/30eUqXVoLqbkxvUPzFCpW3m
q92ynT2zUNdNeH7gB3/hkuShrNMZqrUO/YRyMsfXIboURJDgwHV6Ctqphc9XwhRG
t19z1WAtbjrxDNxpzfp0ZJbmsGzNL1fpMnCU41YSrsd+3rta6EsNUu/y1lMBaAEj
ECrJHKdhx68vZbe1nt+Elae4mZ6dKMmzE58pcILafTwjSUZBbL2N/q/CiFmAga6p
QVjvQwGFl6AM3TSozatpoGe+7j84GwDKLze28AhH4y+XKcKNqZjtRwVFJsw/zeEa
1YC/f+rhgSIkXQKoSXFVyfdh3mnBKFNsCHt/W+a3dO0ryMcNCIPVPQEhf4d4DpY=
=642N
-END PGP SIGNATURE-

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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Si c'est juste pour faire une référence croisée privée entre OSM et ta base
propriétaire (qui n'est à ce jour pas ouverte...) je ne vois pas pourquoi
tu crois quie pour le faire tu changes les priorités et veuille remettre à
plus tard ce qui est la base commune, documentée, et discutée.
Les frontières adminsitrative (comme aussi les besoins pour le projet BANO
activement soutenu, ne passent pas en second plan.
Alors forcément je vis très mal que ton premier message a été un ordre
impératif alors que je corrigeais de gros saccages dans ce que tu as fait.
Oui je te reproche de vouloir agir tout seul et le fait de donner un ordre
en privé de ne pas te corriger.
Ce que tu fais sur Orange a été mal fait. Même si ça casse ce que tu
croyais pouvoir faire plus simplement, il va falloir te faire une raison,
et regarder un peu mieux ce qui préserve la compatibilité, pour que ce ne
soit seulement ton appli métier qui marche au détriment de tous les autres.

Ton initiative privée n'a aucun objectif communautaire, même si c'est pour
travailler (en privé) avec les collectivités qui, elles, soutiennent le
projet commun OSM tel qu'il est. Les collectivités pour leurs besoins
propres ont déjà leur propre SIG. BANO est même conçu pour servir de
plateforme d'échange en France. Qui dit échange ne signifie pas non plus
qu'OSM devra tout faire pour se réorienter uniquement sur les solutions
franco-françaises, OSM est mondial.

Mais tu interviens sur beaucoup plus de choses que tu croies. Tes
références privées (ton tag ref:FR:commune est en fait malvenu, car il
n'est franchement pas issu des données publiques des communes, on n'importe
pas le contenu des SIG communaux ou intercommunaux tels quels, ni même
celles du cadastre : c'est une obligation qu'on a sur OSM de faire un
important travail de fusion, de reclassement).
Ce n'est pas facile, ça demande du temps, mais petit à petit on y arrive.

Et il n'y a pas d'urgence, le développement d'OSM n'est pas lié au
calendrier d'un projet privé. Si tu as des urgences à gérer, fais comme les
communes, crée ton propre SIG métier où tu feras ce que tu veux.

Si tu veux une meilleure intégration de tes données, dans OSM, tu n'as pas
le choix, tu dois le documenter pour que les autres puisse le comprendre
(et les références externes dans OSM n'ont de réel intérêt que si elles
permettent d'accéder à des données accessibles par le public, même si elles
ne sont pas totalement ouvertes, elles doivent servir avant tout à
*n'importe qui* de pouvoir faire des vérifications, ce qui n'est pas
possible pour ton projet qui n'a aucune ouverture publique, qui n'a pas de
nom, et d'ailleurs tu n'as même pas voulu citer l'entreprise pour laquelle
tu fais ça : un aménageur comme Bouygues ou Bolloré ? un distributeur d'eau
? un groupe postal ou logistique privé ? A-t-on moyen d'y trouver un
contact officiel autre que ta propre personne qui ici agit de façon isolée
en ton propre nom ?)


Le 5 février 2015 11:26, Tony Emery tony.em...@yahoo.fr a écrit :

 Bonjour à tous,

 Comme certains le savent, je pilote un projet (il est vrai local) pour
 essayer de constituer une base de données voirie + adresses à terme qui
 puisse être interopérable par différents partenaires.

 Après avoir fait ce travail sur Orange (et je pense que cela a bien était
 fait), j'ai intégré la Communauté de Communes des Pays du Rhône et Ouvèze
 et
 j'applique cette méthode aux 6 autres communes, sachant que je travaille
 aussi avec mes homologues des territoires voisins pour faire de même.

 C'est vrai que la constitution de cette base a provoqué des dégâts au
 niveau
 des limites administratives. J'essaye de les corriger quand je les vois.

 En quelques mots, le projets vise à :
 - recenser toutes les voies de l'interco en croisant les bases de données
 différentes et les connaissances locales ;
 - créer des relations de type associatedStreet sur l'ensemble de ces voies
 et favoriser les liens entre OSM et d'autres applications ;
 - importer les adresses via le plugin http://cadastre.openstreetmap.fr/

 On a recenser toutes les voies des 7 communes de la CCPRO
 On a créer les relation associatedStreet sur 5 des 7 communes
 On a importer les adresses de 5 des 7 communes

 Un fois qu'on aura fini, on controlera les limites administratives
 (d'ailleurs, il faudra modifier les cantons).

 Dans une deuxième étape, on va travailler avec les agents pour qualifier le
 revêtement, les limitations de vitesse et de gabarit, la circulation douce,
 l'éclairage et les gestionnaires des voies.

 Donc, même si c'est un projet professionnel, vous êtes d'accord avec moi
 pour dire que ça peut être utile dans OpenStreetMap ?
 Ne serait-ce que pour améliorer les calculateurs d'itinéraires.



 -
 Tony EMERY
 Administrateur OpenStreetMap.fr
 Mandataire Grand Sud-Est
 Géomaticien  chef de projets
 --
 View this message in context:

Re: [Talk-it] parti di edifici e numeri civici

2015-02-05 12:28 GMT+01:00 Luigi Toscano luigi.tosc...@tiscali.it:

 una possibilie risposta è: non inserisci nuovamente i civici nelle
 attività.
 Dove il numero è per edificio (non in Italia) si ottiene l'informazione con
 una query spaziale.



in tutti i paesi che conosco il civico viene posto all'entrata del lotto /
edificio, non mi sembra una particolarità italiana, come ne anche quella di
avere più civici riferiti ad entità dentro lo stesso edificio.


Il processo per me indica che si tratta di un numero applicabile a tutto
l'immobile / unità ecografica semplice:

Il proprietario dell’immobile, precedentemente alla domanda di Fine Lavori
e/o di Asseveramento, nei casi in cui le opere realizzate abbiano
comportato nuova attribuzione della numerazione civica esterna e/o la
modifica del numero delle unità immobiliari esistenti, deve presentare
domanda di Attestazione di Numerazione Civica Definitiva (art. 43 DPR
223/1989) e, nei casi in cui lo necessita, il Certificato di Unità
Immobiliare Urbana .


perché parla di immobile se in realtà soltanto gli ingressi hanno numeri,
ma gli immobili no?





 In Italia si potrebbe semplicemente legare il punto/area del negozio con il
 punto del civico con una relazione, qualcosa tipo:
 http://wiki.openstreetmap.org/wiki/Relations/Proposed/Associated_Entrance



si possono sempre usare nodi invece di geometria dettagliata (volendo anche
per le strade), ma è sempre meglio avere geometria che da indicazioni su
orientazione, forma e grandezza.

ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Espaces demi m....

Ca ne concerne que le style de rendu de la carte. Le problème est plus
large et concerne toute l'interface de JOSM.
Des petits liebllés sur la carte ne me choquent pas tant qu'on peut
sélectionner facilement un objet dessus et voir correctement le détail dans
les propriétés et les modifier facilement : c'est surtout là qu'on a besoin
de préférences utilisateur (pour la taille et la sélection de polices
appropriées pour les langues que JOSM ne sait pas du tout afficher, dont
certaines très importantes comme le bengali, et cela va même devant la
priorité de traduire les messages de l'interface qui ne peut venir qu'après)


Le 5 février 2015 12:30, Jo winfi...@gmail.com a écrit :

 Avec MapCSS il y a moyen de montrer plus grand ce qui vous intéresse.
 Regardez le style Public Transport que j'ai créé pour le transport public
 (Il est dans la liste). Essayez d'ajouter odbl=new à un arrêt ou une
 relation route. L'effet est le plus intéressant si les arrêts sont sur des
 noeuds isolés à côté de la route.

 Polyglot

 2015-02-05 11:52 GMT+01:00 Pierre Giraud blueca...@gmail.com:

 Défectif ou défectueux ?

 2015-02-03 21:07 GMT+01:00 Philippe Verdy verd...@wanadoo.fr:

 En fait ce n'est pas tellement la taille des libellé dans l'affichage de
 la carte qui me gène (qu'ils soient petits évite aussi de cacher trop de
 chose : on devine mais en cas de doute on a encore l'onglet des propriétés
 pour les afficher clairement, sans superposition de traits et de couleurs).

 C'est surtout dans l'interface utilisateur (liste des tags, dialogues de
 saisie ou de configuration, menus, etc...) que c'est pénible (et que le
 support international des autres écritures est défectif).

 Certes affiche correctement le tibétain ou le birman est compliqué à
 inclure (dommage qu'il n'y ait pas un meilleur moteur de rendu de texte
 comme il en existe pour Eclipse) et leur normalisation assez récente (avec
 encore quelques problèmes de stabilité), mais pour le bengali c'est stable
 depuis longtemps et c'est une langue diablement importante.

 Et ma presbytie naissante (qu'on aura tous...) commence à être un vrai
 problème que la correction optique ne parvient pas à palier : les textes
 trop petits sont fatigants pour la vue et c'est difficile de voir des
 fautes mineures comme un accent oublié, même en français, alors que tout le
 reste de l'OS et le navigateur ont un réglage possible qui apporte un vrai
 confort visuel.

 

 Je m'énerve autant devant les étiquettes alimentaires (je veux lire
 scrupuleusement les compositions, notamment la nature des matières grasses
 et le taux de sel de plus en plus souvent excessif) devenues totalement
 illisibles où il me faut chercher une bonne source lumineuse pour accentuer
 les contrastes, en essayant de les lire sans mes lunettes (avec c'est
 impossible).

 Maintenant il m'arrive d'utiliser la caméra de mon smartphone pour
 zoomer dessus mais ce n'est pas évident de trouver le bon éclairage quand
 même le smartphone apporte de l'ombre et que son flash se réfléchit trop
 sur la surface et est inutilisable et la surface n'est pas non plus plane
 ou bien l'étiquette est sous un plastique alvéolé ou rainuré.

 Vivement la généralisation les étiquettes lisibles sur Internet par
 QR-code : OpenFoodFacts OK, mais les fabricants ou emballeurs devraient les
 rendre lisibles sur en données OpenData sur un site officiel non
 publicitaire contenant toutes les infos légales sur une fiche d'information
 normalisée, y compris les numéros de lots et dates de fraîcheur ou de
 conservation, qui peuvent être ajoutées (en plus du code produit EAN, et
 même le prix de vente sur le QRcode ou sur le code barre additionnel des
 points de vente).

 Certains points de vente (hypermarchés) vont aussi jusqu'à masquer ces
 infos en collant par dessus un emballage ou un autocollant de promo
 (impossible à décoller sans défaire le lot ou abimer l'emballage), mais
 souvent c'est de la faute même de leurs fournisseurs qui livrent ces promos

 (on achète d'abord, après on verra chez soi comment lire les infos sur
 les produits achetés, et on a des mauvaises surprises avec des produits qui
 dans une seule portion contiennent plus de 2 grammes de sel, plus que la
 quantité maximale pour toute une journée, le sel n'est là que pour masquer
 le fait que ce sont des produits totalement insipides, il remplace l'huile
 végétale et les épices... (Ça m'arrive de goûter et de jeter le tout
 tellement c'est gras et salé et souvent aussi sans texture : même un chien
 domestique n'en veut pas, et pourtant c'est un produit de marque connue,
 parfois avec force publicité, vendu plus cher qu'un premier prix
 d'hypermarché).


 Le 3 février 2015 20:18, Félix Marty felixma...@outlook.com a écrit :

 J'approuve Philippe. JOSM a des progrès à faire là-dessus, les
 caractères
 affichés sur le calque OSM sont par exemple minuscules, et il n'y a à ma
 connaissance pas de possibilité pour changer facilement la taille de
 police
 des calques. Ces

Re: [OSM-talk-nl] OSMC problemen

2015-02-05 Diskussionsfäden Maarten Deen


On 2015-02-05 12:52, Patrick Coenen wrote:


ik heb een probleem met de tag OSMC symbol.
De help functie op deze site [1] helpt me niet verder.
Hoe moet ik de tag invullen om een gekleurd (paars/groen/blauw/rood)
vierkantje te krijgen met daarin aan witte letter als symbool?
mij lukt het niet [2]. een witte E moet op paarse achtergrond, witte D
op een groene, witte C op een blauwe.


Je bedoelt denk ik relatie 4559610? Volgens mij ben je een veld 
vergeten. Er staat nu

purple:::E:white, volgens mij moet je purple:purple:::E:white hebben.

way color:purple
background:purple
foreground:leeg
foreground2:leeg
text:E
text color:white

Maarten

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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Le 5 février 2015 13:13, Tony Emery tony.em...@yahoo.fr a écrit :

 Alors on va essayer de faire simple.

 - Je ne vois pas en quoi j'ai demandé de changer des priorités ?
 - Je remet à plus tard rien du tout, je fais quand je vois et je contrôle
 quand j'ai fini, parce que mine de rien c'est un boulot énorme.
 - Ce n'est pas une référence croisé entre MA base et OSM, c'est créer un
 identifiant à la source de la création de la voie, c'est à dire au niveau
 des communes.
 - Si tu corriges mes erreurs (et non saccages), il n'y a pas de problème,
 mais pourquoi avoir supprimé le tag ref:FR:commune quand il était présent
 sur les objets ?


Peux-tu citer une source ouverte (avec une licence compatible) où on peut
contrôler cette données ? Si non, elle n'a rien à faire dans OSM.

Tu te dis Administrateur OpenStreetmap.fr mais tu n'en respectes pas les
règles de base.
 Tu te dis Mandataire Grand Sud-Est mais mandataire de qui ?
   - Je n'agis pas seul puisqu'on est plusieurs sur le projet

Qui ?

- Qu'est ce qui te permet de dire que ce qui a été fait sur Orange a été mal
 fait ?


Ce que moi et d'autres corrigent après ton passage qui est bien un saccage..


 - Je discute même pas sur le reste parce que j'ai même pas envie de
 m'étaler
 là-dessus, que tu racontes beaucoup d'ânerie et que tu mélanges des
 concepts
 et des projets qui n'ont rien à voir.


Non tu mélanges le projet OSM avec ton projet privé.


 Par contre, je trouve très déplacé de ta part de copier sur une mailing
 liste une discussion qui est privée (entre toi et moi).


Je t'en ai avisé avant. Et cette discussion dépasse largement le cadre des
échanges privés quand tu commences par me donner un ordre sans rien
expliquer publiquement.


 Enfin, je crois connaitre le projet BANO largement mieux que toi donc.


On aurait aimé t'entendre ici alors sur ce sujet. Tu arrives bien tard.


 Administrateur OpenStreetMap.fr
 Mandataire Grand Sud-Est
 Géomaticien  chef de projets
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] Tagging addresses on area's

2015-02-05 Diskussionsfäden Brad Neuhauser


  I punted.  When Josm added a preset that included addr:flats, then I
  started using that tag.  Right or wrong I figured most of the other
  tags are Euro-English coloured, so to speak, that it did not mater if
  I used addr:flats verses addr:unit.
 __

 addr:flats works if you are talking about flats, but doesn't fit other
 scenarios, such as suites in an office building.

 addr:flats is for a range of unit numbers. That's how it's described in
the wiki, and you can see that is indeed the main usage if you look at
taginfo: http://taginfo.openstreetmap.org/keys/?key=addr%3Aflats
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-05 Diskussionsfäden Pierre-Yves Berrard

Le 5 février 2015 16:13, Pieren pier...@gmail.com a écrit :

 2015-02-05 15:17 GMT+01:00 Tony Emery tony.em...@yahoo.fr:

  Dans la base DGFiP, j'ai relevé quelques doublons. Je vois pas trop
  l'intérêt d'ajouter un identifiant quand le rivoli n'existe pas et de le
  supprimer derrière.

 L'intérêt est que l'usage de ce code resterait très limité (par
 exemple 96 au lieu de 797 pour Orange) et que ça serait cohérent avec
 les autres communes françaises.

  J'ai commencé ici :  http://wiki.openstreetmap.org/wiki/Vaucluse/voirie
  http://wiki.openstreetmap.org/wiki/Vaucluse/voirie

 Il faudrait aussi voir ici:

 http://wiki.openstreetmap.org/wiki/WikiProject_France/Liste_des_r%C3%A9f%C3%A9rences_nationales

 Pieren


Est-ce vraiment une référence qu'on peut qualifier de nationale ?

Contrairement aux autres ref:FR:* de la page, on ne va pas la trouver sur
l'ensemble du territoire français et il n'existe pas de répertoire
officiel géré par un organisme qui en a la charge.

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

Re: [Talk-us] Tagging addresses on area's

2015-02-05 Diskussionsfäden Brad Neuhauser

On Thu, Feb 5, 2015 at 5:23 AM, Mike N nice...@att.net wrote:

 On 2/4/2015 11:25 PM, Greg Morgan wrote:

   addr:housenumber contains both the number
 and the building letter in the same field.  The map is useful because
 you can find the building. How have other people tried to handle these
 situations?


 I haven't tried in any meaningful way.  It's too early to guess how an
 address matching utility might work.   Until now I have used both

  addr:housenumber=724D

 and
  addr:housenumber=724 + addr:unit=D

  depending on whether the address specified by the owner's web site
 included the letter.   More recently, I've gravitated towards separating
 the addr:unit even if the owner specified it as one word, but I'm not sure
 it's the most useful.   The addr:housenumber doesn't render anyway if the
 building has also been tagged as another POI that renders.

 Including a unit number in the house number is incorrect and potentially
confusing. There are house numbers that have a prefix or suffix as part of
the house number, that's a different thing. It just depends on how the
building is addressed.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Gros problème de correction... Groupe de modifications : 28377712

2015-02-05 Diskussionsfäden Vincent de Château-Thierry

Le 05/02/2015 20:34, Tony Emery a écrit :
 cquest wrote
 Retour sur les ref:xxx...

 On a déjà eu des discussions à propos des ref:xxx pour maintenir un lien
 avec une base privée. La conclusion si je me rappelle bien était que
 seuls les ref:xxx vers des nomenclatures publiques avaient leur place
 dans OSM. C'est préférable pour éviter une multiplication des liens avec
 des données privées, liens qui ne servirait qu'à leur auteurs et à
 personne d'autre.

 Dans le cas présent, c'est pas vraiment privé, mais pas très public non
 plus... et comme toujours les zones grises sont là où vivent les trolls ;)
 En fait, on (François Ganz à Avignon) et moi pensions que cette structure
 (INSEE+V+id) était suffisamment souple pour intégrer les identifiants des
 autres collectivités.


 cquest wrote
 Je rejoindrais la solution proposée par Pieren à savoir utiliser
 ref:FR:FANTOIR là où la DGFiP a attribué un code FANTOIR et à défaut
 utiliser un ref:FR:commune là où il n'y a pas de FANTOIR.
 C'est étonnant qu'il y en ait autant d'ailleurs, ce ne sont que des
 nouvelles voies ?
 Pas que, il y a aussi des voies qui n'ont ni adresse, ni rien. Elles ont
 juste un nom et comme il n'y a personne à taxer (dans le sens littéral), les
 impôts ne recensent pas. Elles n'auront donc jamais de rivoli.
 Avec notre système, on peut même répertorier des vois qui n'ont pas de nom.

Etonnant quand même, les parcelles au bord de ces voies pourraient ainsi
être rattachées par la DGFiP à ces voies. C'est fait à beaucoup
d'endroit, comme ça, mais je constate aussi que localement il y a des
pratiques un peu variables.



 cquest wrote
 Pour les dégâts collatéraux sur les limites admin, il faudrait peut être
 ajouter dans le process de travail un contrôle systématique avec JOSM
 (ou autre) pour s'assurer que rien n'est cassé de ce côté car c'est
 quand même gênant vu le nombre d'outils qui en dépendent.
 Oui, je pensais, avec JOSM, qu'un récupérant une voie j'avais toutes les
 relations de cette voie mais non. Donc c'est plus compliqué de savoir s'il y
 a une relation derrière.
 Mais je suis preneur d'outils ou d'astuce allant dans ce sens.

Travailler sur un sous-ensemble d'objet dans JOSM est toujours périlleux
et ne devrait être limité qu'à des modifications de tags et aucune
modification de géométrie (y compris bien sûr couper un way en deux). En
chargeant la zone en question dans son intégralité, tu évite beaucoup de
problèmes.




 cquest wrote
 Pour les suppressions des ref:FR:commune sans contact préalable, c'est
 une façon très peu respectueuse des autres contributeurs que de procéder
 ainsi. Nous avons quand même des outils simples pour accéder à
 l'historique des objets et les moyens d'entrer en contact avec un
 contributeur avant de supprimer telle ou telle info de façon unilatérale.

 Pour le reste, soyons zen...
 Je ne te le fais pas dire.
 Quant à moi, je suis zen. J'ai même des fous rires derrière mon clavier. Je
 marche à la confiture OSM...


Je vais en refaire si besoin ;)


-- 
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712



Le 05/02/2015 18:04, Tony Emery a écrit :


Voici mon premier mail, dites-moi en quoi il est agressif :
Bonjour Philippe,

(...)

tu ajoute les tags admin_level et boundary sur le tronçon alors que c'est en
doublon avec le fait que ce tronçon fait partie d'une relation de type
boundary
Il faut que tu corriges absolument ces erreurs sur l'ensemble de ton groupe
de modification car nous ne pouvons plus réutiliser ces données par la
suite.


Ajouter les tags admin_level et boundary sur un tronçon, highway ou pas, 
n'a rien d'une erreur dès lors que ce way est membre d'une relation 
boundary=administrative. Et si au passage ça permet de rappeler, en 
cours d'édition, qu'on manipule une route (ou une rivière, etc.) *qui 
est aussi une limite*, ça me semble un garde-fou pas inutile. Il faut se 
rappeler que Potlatch 2 et iD sont muets quand on efface un membre de 
relation. JOSM en revanche, prévient, ce qui devrait limiter la casse.


vincent

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

Re: [Talk-it] open expo 2015

2015-02-05 Diskussionsfäden mircozorzo

Ottimo! Dai, è una soddisfazione vederle utilizzate, anche questo è Expo. 



--
View this message in context: 
http://gis.19327.n5.nabble.com/open-expo-2015-tp5817169p5832647.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-de] mehrere Häuser mit gemeinsamen Dach

2015-02-05 Diskussionsfäden Manuel Reimer

fly lowflight66 at googlemail.com writes:
 Vielleicht habe ich mich undeutlich ausgedrückt. Laut Katasteramt sind
 das mehrere Häuser mit unterschiedlichen Hausnummern, aber auf dem
 Luftbild erkennt man eben nur ein Dach.

Warum nicht ein building außenrum und darin building:part mit den
Adressdaten?

Gruß

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

Re: [Talk-it] parti di edifici e numeri civici

2015-02-05 Diskussionsfäden Elena ``of Valhalla''

On 2015-02-04 at 15:14:41 -0700, frasty wrote:
 In generale opto per la seconda dato che mi pare più preciso assegnare i
 civici esattemente dove sono le antrate ma non vorrei che la prima sia più
 corretta dal punto di vista formale...

in Italia la numerazione viene assegnata agli accessi, quindi direi 
che una soluzione che lascia il civico dove sono le entrate è 
corretta (o comunque migliore) dal punto di vista formale

https://it.wikipedia.org/wiki/Numero_civico#Normativa_italiana

(non ho controllato che legge e decreto siano citati giusti)

-- 
Elena ``of Valhalla''

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

Re: [OSM-talk-fr] Mettre à jour la carte d'une commune

Le 05/02/2015 10:28, Ludovic Hirlimann a écrit :
 Bonjour,

 j'édite depuis peut-être un mois la commune où je viens d’emménager afin d'y
 ajouter les commerces et services. Je me suis rendu compte qu'il y avait des
 manques sur la carte OSM - et des bâtiments qui n'existent plus. Quelle est
 la meilleur marche à suivre pour ajouter le bout de route manquant ,enlever
 les bâtiments détruit et mettre à jour la carte ? Je suis preneur d'un petit
 cours pour pouvoir le faire (même si après avoir brièvement lu le guide
 d'import du cadastre je suis beaucoup moins chaud).

 Ludovic
 ps la commune en question est Grisolles (82170)



Si un bâtiment présent sur OSM n'existe plus sur le terrain... et bien
il suffit de le supprimer !
tu peux aussi conserver le polygone, retirer le tag building et mettre
une note=* pour indiquer que le batiment n'existe plus pour éviter qu'il
ne soit recréé par quelqu'un à partir d'une source qui n'est pas à jour
(cadastre, image aérienne).

Ajouter un bout de route manquant ? Euh... il suffit de l'ajouter avec
les outils d'édition habituels (en ligne: iD, hors ligne: JOSM).

-- 
Christian Quest - OpenStreetMap France


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

[OSM-talk-be] Gebruik van image tag met veel ongeldige verwijzingen.

2015-02-05 Diskussionsfäden Marc Zoutendijk

Met taglocator was ik bezig om de tag image” te verwerken zodat er een
thumbnail van de afbeelding te zien zou zijn.
Dat werkt, en om dat te onderzoeken vraag ik jullie het volgende te doen:

1. Ga met taglocator naar Antwerpen:

http://mijndev.openstreetmap.nl/~marczoutendijk/taglocator/?map=userpoilayerzoom=15lat=51.21823lon=4.40443layers=B00T

2. Klik op User POIs en vul daar het volgende in

image

3. klik op show”

Je krijgt dan een overzicht van Antwerpen met alle tags waar ook een afbeelding
te zien is.
Klik op een paar van de pois die nu op de kaart te zien zijn.
Zie je thumbnails?
Probeer het anders bv. bij de Eiffeltoren in Parijs om te zien hoe het zou
moeten zijn.
(Je komt het snelst bij dat object door in het zoekveld tour eiffel” in te
vullen).

Doe dan het volgende:

1. Klik op User POIs en vul daar het volgende in (inclusief de
aanhalingstekens):

image~^File”

2. klik weer op „show”

Je ziet nu alle pois waarbij een ongeldige verwijzing naar een afbeelding is te
zien. Namelijk een afbeelding die een verwijzing heeft naar een lokaal bestand
(op de computer van de persoon die de oorspronkelijke afbeelding bezit).

Kijk bv. eens naar dit punt http://www.openstreetmap.org/node/2409413865

De verwijzing is: File:Antwerpen_Groenplaats_28-29.jpg

Die verwijzing File” is ook nog eens een serieus veiligheidslek omdat in
principe toegang wordt verkregen tot de lokale directory op de computer van
diegene die op die link klikt!

Met name in Antwerpen tref ik veel verwijzingen aan die afkomstig zijn van
OnroerendErfgoed.
In Taglocator worden al deze verwijzingen nu duidelijk aangemerkt als:
Invalid image reference to local file!

Wie is verantwoordelijk voor het plaatsen van deze (ongeldige) afbeeldings
verwijzingen?
Is dat gebeurd met een grootschalige import?
Het lijkt me belangrijk dat deze verwijzingen worden omgezet in geldige links.

Marc.

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

Re: [OSM-talk-fr] OSM hors ligne

2015-02-05 Diskussionsfäden Eric SIBERT


Le 05/02/2015 02:34, Philippe Verdy a écrit :

Oui, mais une machine virtuelle (qu'elle soit hébergée sur Windows ou
autre) demande un PC assez performant


Je parle d'une machine virtuelle pour s'entrainer, faire des tests sur 
des petites zones...



Une VM c'est pour un usage temporaire


cf. supra.



On devrait tous avoir chez nous maintenant un bon vieux PC de bureau à
recycler en serveur de fichiers ou de médias ou d'archivage


sur lequel je ne fais surtout pas de tests... vu que c'est un serveur en 
prod.


Là on parle d'un gars qui va partir en bateau, qui ne reste pas chez lui 
mais qui veut préparer ça.




Le 4 février 2015 22:16, Eric SIBERT courr...@eric.sibert.fr
mailto:courr...@eric.sibert.fr a écrit :

Non mais fait des essais.

Si tu es sous windows, tu installes VirtualBox.

Dans VirtualBox, tu t'installes un Ubuntu LTS.

Ensuite, tu essaie le tuto avec au début des petites zones. Grâce
aux instantanés, c'est facile de revenir à un état antérieur de la
machine virtuelle. C'est super pratique pour faire des essais.
Ensuite, tu essaies des zones de plus en plus grandes ou plus chargées.

Et tu viens nous raconter ;-)

Eric


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

Re: [Talk-cz] Licence OSM

2015-02-05 Diskussionsfäden Petr Vozdecký

Tusim ze stejny problem ma sluzba http://cisteniulic.cz/

vop



-- Původní zpráva --
Od: Honza Cibulka ho...@datastory.cz
Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
Datum: 4. 2. 2015 19:19:58
Předmět: Re: [Talk-cz] Licence OSM



Jop, trasy mají z GPS na rolbách.


--



S pozdravem



Jan Cibulka




tel: 776 307 158



On 4. 2. 2015, at 19:15, v...@email.cz(mailto:v...@email.cz) v...@email.cz
(mailto:v...@email.cz) wrote:



Zdar,

napsal jsem jim, aby uvedli autorství a licenci podkladu.
Přímo data z OSM podle mě nevyužívají. Data o pohybu rolb jsou prostě stopy 
z GPS a data pro plánování tras z OSM taky nejsou - oproti stopám z OSM tam 
mají trasy navíc i namíň.

Jan Vršovský


-- Původní zpráva --
Od: Jan Martinec j...@martinec.name(mailto:j...@martinec.name)
Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org
(mailto:talk-cz@openstreetmap.org)
Datum: 4. 2. 2015 11:12:00
Předmět: Re: [Talk-cz] Licence OSM

On 02/04/2015 10:43 AM, Pavel Machek wrote:
 On Wed 2015-02-04 07:34:35, jiri2 wrote:



 Zdravím, před pár dny sem byl na lyžích a narazil sem na stejný případ:



 http://bilestopy.cz/cs(http://bilestopy.cz/cs)
(http://bilestopy.cz/cs(http://bilestopy.cz/cs))



 Mapa je také evidentně OSM, ale zmínku sem nenašel. V zápatí hlavní 
stránky 
 sice mají © 2015 Bílé Stopy. Všechna práva vyhrazena. Myslím, ale že 
 podobně jako s OSM na tom budou i správy k datům o upravených stopách

 
 No, ale co jim nedochazi je, ze ted maji povinost dat k dispozici
 svoji databazi...
 Pavel
 
To se mi teda vůbec nezdá. Otázka je, jakým způsobem k těm datům o stopách 
došli
- jestli je ta databáze tedy collective nebo derivative; od toho se ta
povinnost (nebo nepovinnost) odvíjí.

http://wiki.openstreetmap.org/wiki/License/Use_Cases
(http://wiki.openstreetmap.org/wiki/License/Use_Cases) - tady v těch 
příkladech je
to evidentně Case 4 - **If** you create a derivative database, you will 
need
to make it available. (zvýraznění moje)

Čili jsou každopádně povinni uvést OSM jako zdroj podkladu; ale pokud ta 
další
data, která na něm zobrazují, nepochází z žádné části z OSM (třeba pokud to 
jsou
GPS stopy získané úplně odjinud), žádná povinnost publikovat jim nevznikla.

Honza Piškvor Martinec




___
Talk-cz mailing list
Talk-cz@openstreetmap.org(mailto:Talk-cz@openstreetmap.org)
https://lists.openstreetmap.org/listinfo/talk-cz
(https://lists.openstreetmap.org/listinfo/talk-cz)=

___
Talk-cz mailing list
Talk-cz@openstreetmap.org(mailto:Talk-cz@openstreetmap.org)
https://lists.openstreetmap.org/listinfo/talk-cz
(https://lists.openstreetmap.org/listinfo/talk-cz)


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

Re: [Talk-it] turn lanes

2015-02-05 Diskussionsfäden Mauro Costantini

Il 5 febbraio 2015 01:22, Stefano Droghetti
stefano.droghe...@gmail.com ha scritto:
 Due tratti, di direzione opposta verso il semaforo
 La parte in alto:
 turn:lanes:forward=through|left
Ovviamente intendevi turn:lanes:forward=left|through .

 Faccio bene? Cioè, non mi è chiaro se devo specificare anche il lane
 backward:
 lanes:backward=1
Non è necessario, ma se ritieni che sia importante puoi metterlo.

 turn:lanes:backward=through
Qui dipende da cosa c'è all'altro capo della strada!

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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Je tiens quand même à rappeler que l'intégration des tags ref:FR:Communes n'a
rien à voir avec mes erreurs de saccages massifs et honteux méritant la
correctionnelle. D'ailleurs, ces identifiants ont été intégrés avant et
n'ont eu aucune incidence.

C'est juste au moment de la création des relations associatedStreet au
cours de laquelle j'ai voulu corriger les tracés des voies que j'ai
supprimer par mégarde certains objets appartenant à d'autres relations.

Je comprends que p_verdy ait eu envie de corriger ça, avec d'autres
contributeurs. Ce que je ne comprend pas c'est pourquoi, en corrigeant les
relations, il a voulu supprimer le tag ref:FR:Communes qui est présent sur
l'objet et non sur la relation.

Par ailleurs, j'ai bien pris soins d'ajouter les code FANTOIR dans les
relations associatedStreet au moment de l'intégration des adresses, histoire
que l'on ne me taxe pas de fonctionnaire anti-fantoir.



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien  chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5832603.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [Talk-it] [Bibliotecari] Open Culture Atlas: che strada possiamo fare insieme?

2015-02-05 Diskussionsfäden Fabri

ah ok, visto che ancora non è stata scelta data nè argomento, per quello di
febbraio si riesce a organizzare al fusolab?



--
View this message in context: 
http://gis.19327.n5.nabble.com/Re-Bibliotecari-Open-Culture-Atlas-che-strada-possiamo-fare-insieme-tp5831730p5832602.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Le 5 février 2015 14:05, Pieren pier...@gmail.com a écrit :

 Sinon,
 concernant les échanges épistolaires de Philippe, on le connait ici
 très bien et il sait déjà qu'il gagnerait beaucoup à être moins
 agressif dans le choix de ses expressions mais qu'il ne changera
 jamais de ce côté là.


Tu n'as pas lu son tout premier message très agressif qu'il m'a envoyé et
plein de capitales, très agressif dès le premier contact (via la messagerie
interne d'OSM), sur le ton de l'ordre impératif.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-05 15:17 GMT+01:00 Tony Emery tony.em...@yahoo.fr:

 Dans la base DGFiP, j'ai relevé quelques doublons. Je vois pas trop
 l'intérêt d'ajouter un identifiant quand le rivoli n'existe pas et de le
 supprimer derrière.

L'intérêt est que l'usage de ce code resterait très limité (par
exemple 96 au lieu de 797 pour Orange) et que ça serait cohérent avec
les autres communes françaises.

 J'ai commencé ici :  http://wiki.openstreetmap.org/wiki/Vaucluse/voirie
 http://wiki.openstreetmap.org/wiki/Vaucluse/voirie

Il faudrait aussi voir ici:
http://wiki.openstreetmap.org/wiki/WikiProject_France/Liste_des_r%C3%A9f%C3%A9rences_nationales

Pieren

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

Re: [Talk-it] turn lanes

2015-02-05 Diskussionsfäden Matteo Quatrida

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 05/02/2015 16:14, Mauro Costantini ha scritto:
 Ovviamente intendevi turn:lanes:forward=left|through

Non si poteva anche evitare di specificare forward/backward?
Se mi ricordo bene, si doveva prendere il verso del segmento e da
sinistra a destra elencare tutte le corsie.
lanes=3
lanes:forward=2
lanes:backward=1
turn:lanes=through;left|through

Ciao.

- -- 
Matteo Quatrida
GNU/Linux User #498939
OpenStreetMap Contributor since 2009

«L'ordine è il piacere della ragione, ma il disordine è il piacere
dell'immaginazione!» Paul Claudel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU04sXAAoJEHnO6jolYLDxdWIH/1YIMMbKAdssIEHlWz6yvXau
OYskDRSOwk/zRyFQNcggirtiAK3ntwGeMAJaDxEpTI5gevsPo/89HtBi8h2sq8Ho
pluOahQmYrZm9YuyRh5WsK0DoktllwCNOvKS8T9eBpYlErxrjfpiL5Lyvudr4DAP
MtA4EAypEgJWruEHHLlmbbox02UJ4PfF9qoQJ1LjLHnqRwgqmb7mvbm6oOWFP5Jl
13BD1zsh/5TItITykMl66NB7P1xS183bRvTuQZ/94EvowCwNAuy56CblUp3u//1M
RL5JRzNQBrw9sPUQOM7zR8NbIL2J/bCKx8JbYEwEYRjboKo/ax9nSn6P8Bx7VzM=
=gJZY
-END PGP SIGNATURE-

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

[OSM-talk-be] roadsign plugin adapted for Belgium

Hi,

Over the past days, I adapted the data file for the road sign plugin for
Belgium.

I'd like to ask you to test it.

Install the plugin the usual way and select something. Look at the top
right corner of the tags pane on the right. A little icon was added there,
press it and choose BE.

Now it becomes easy to tag traffic signs and their effects on the ways they
apply to. I'm going to ask the developers for some improvements, but it is
functional already.

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

[Talk-br] Situação das traduções

2015-02-05 Diskussionsfäden Vitor George

Pessoal,

Há algum tempo
http://article.gmane.org/gmane.comp.gis.openstreetmap.region.br/1595/match=tradu%C3%A7%C3%B5es
comecei
a mandar na lista de discussão talk-br
https://lists.openstreetmap.org/listinfo/talk-br informes sobre a
situação da tradução ao português brasileiro das ferramentas do
OpenStreetMap.

Agora não consigo mais mandar estes informes com frequência, e coloquei-o
no wiki para que qualquer pessoa possa ajudar no monitoramento:

WikiProject_Brazil/Traduções
https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Tradu%C3%A7%C3%B5es

Gostaria que a comunidade brasileira começasse a se organizar em grupos de
trabalho, que ficariam responsáveis pelas atividades mínimas de organização
de esforços direcionados.
Um grupo de trabalho de traduções poderia ser um primeiro passo. *Caso
alguém se interesse manter a informação do wiki atualizada, ao menos
quinzenalmente, vá em frente e divulgue novidades na lista, fórum e demais
canais da comunidade. *Eu posso ajudar.

Abraço,
Vitor
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-at] Diskussion zu Anonymen Massenimporten in AT auf forum.openstreetmap.org

2015-02-05 Diskussionsfäden Walter Nordmann

Also wenn ihr in AT nix schlimmes mehr findet, was ich inzwischen 
glaube, ist das Thema wohl durch. Wir haben ih bei uns schon heftig 
zurechtgestutzt und damit sollte alles ok sein.



meister fkv hat das im forum schon recht fein zusammengefasst. =)


Gruss
walter


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

Re: [Talk-br] Situação das traduções

2015-02-05 Diskussionsfäden Lists

Vitor

To vendo no wiki que Merkaator e 1000% traducido, mil porcento? bom trabalho!

Aun Johnsen

 On Feb 5, 2015, at 18:58, Vitor George vitor.geo...@gmail.com wrote:
 
 Pessoal,
 
 Há algum tempo 
 http://article.gmane.org/gmane.comp.gis.openstreetmap.region.br/1595/match=tradu%C3%A7%C3%B5es
  comecei a mandar na lista de discussão talk-br 
 https://lists.openstreetmap.org/listinfo/talk-br informes sobre a situação 
 da tradução ao português brasileiro das ferramentas do OpenStreetMap.
 
 Agora não consigo mais mandar estes informes com frequência, e coloquei-o no 
 wiki para que qualquer pessoa possa ajudar no monitoramento:
 
 WikiProject_Brazil/Traduções 
 https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Tradu%C3%A7%C3%B5es
 Gostaria que a comunidade brasileira começasse a se organizar em grupos de 
 trabalho, que ficariam responsáveis pelas atividades mínimas de organização 
 de esforços direcionados.
 
 Um grupo de trabalho de traduções poderia ser um primeiro passo. Caso alguém 
 se interesse manter a informação do wiki atualizada, ao menos quinzenalmente, 
 vá em frente e divulgue novidades na lista, fórum e demais canais da 
 comunidade. Eu posso ajudar.
 
 Abraço,
 Vitor
 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br

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

Re: [OSM-talk-fr] Index R*-Tree pour système embarqué

2015-02-05 Diskussionsfäden Frédéric Rodrigo

Le 5 févr. 2015 19:08, Philippe Verdy verd...@wanadoo.fr a écrit :

 Le test se base sur le fait que tes R*trees ne sont pas maintenus
équilibrés en contenu, une règle commune aux B-trees).

 Et quitte à diviser un rectangle R*tree en deux quand il est plein, on a
normalement intérêt à le couper de préférence sur sa dimension la plus
grande pour répartir les points de chaque côté (mais si on veut optimiser,
on fait le test de répartition sur une dimensio puis sur l'autre, et on
choisit celle où le trait de découpe est plus près du milieu de cette
dimension).
 La charge des R*trees doit normalement être portée sur la répartition,
lors de l'insertion (ou la suppression) des noeuds, pour qu'ensuite les
recherches n'aient pas à le faire.

 Dans ce cas avec un Quadtree tu génères pleins de boites vides et les
branches de l'arbre sont moins bien équilibrées, avec un seuil minimum de
remplissage de 25% là où un R*Tree utilise un minimum de 50% (arrondi à
l'unité inférieure) : si ton R*tree a une capacité maximale de 6 points ou
sous-rectangles, et une capacité minimale de 3 points ou sous-rectangles,
c'est à dire 50% pour la répartition la plus optimale, le nombre de boites
à visiter ne dépend pas de la distribution des points dans les boites
seulement traversées mais sans point, mais seulement du nombre total de
points, et le nombre de boites à visiter est en O(log_6(N) où N est le
nombre total de noeuds, alors que le Quad-Tree ajoute des tas de points
artificiels au centre des boites traversées sans noeud et est seulement en
O(.log_4(N+k*S)) où S est le nombre total de segments et k une variable
liée à la distribution des longueurs de segments.

Tu pourrais s'il te plait détailler ce denier point ? Ta as des sources
pour ces complexités que tu pourrais citer, stp?


 C'est pour ça que dans le cas totalement aléatoire (ton premier test), le
QuadTree s'écroule totalement : il crée beaucoup trop de sous-boites, et la
profondeur de l'arbre de recherche s'accroit énormément. Le R*Tree
produirait un nombre de boites bien plus réduit (à condition de le régler à
un taux de remplissage minimum de 50% arrondi à l'unité inférieure).

 Il doit y avoir un problème dans ton logiciel insérant les points dans le
R*Tree, il n'est visiblement pas optimal comme il devrait.

 De fait les R*trees obtenus sont très étranges (et ça se voit, la
répartition est visiblement n'importe comment et spatialement non
équilibrée, en tout cas beaucoup moins bien que celle obtenue par les
Quad-trees même si, eux, créent plein de boites finales vides et de boites
parentes n'a qu'une seule des 4 ayant un contenu, avec un taux de
remplissage situé en moyenne à peine au dessus de 25% contre plus de 50% en
moyenne pour les R*trees optimums).

 Note: le seuil minimum des R*tree est réglable (tu l'as fait dans ta
démo, mais je me demande si c'est bien le cas au final, et si tu n'as pas
omis de lancer la procédure d'équilibrage (qu'on a intérêt à ne lancer qu'à
la fin des insertions et non pour chaque insertion une par une).


 Le 5 février 2015 18:20, Léo Serre l...@lstronic.com a écrit :

 Bonjour à tous

 Après de longues recherches pour savoir qu'elle est l'indexation la plus
efficace (simplicité de construction, rapidité pour trouver un élément,
taille), tout le monde m'a dit R*-Tree.
 Mais après des essais, ma conclusion est que le quadtree est largement
mieux. Je vous laisse un exemple en vidéo ci-dessous pour ceux que ça
intéresse.


http://www.dailymotion.com/video/x2ghtqj_r-tree-pour-des-donnees-geographiques_tech

 Note : Le code pour convertir des LineString GeoJSON en Segments CSV est
disponible sur simple demande.

 Léo

 --

 Léo SERRE
 LSTRONIC Founder
   l...@lstronic.com
   lstronic.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

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

[OSRM-talk] File repository

2015-02-05 Diskussionsfäden Zbyszek Swirski

OSRM is absolutely incredible, fast routing server. However extract and
convert are real pain in certain part of the body
From my experience small server (64GB RAM, 8 cores) takes over 30 hours
to convert planet file, so I have rented 256GB RAM machine, 40 cores and on
it it takes just 3-4 hours.
As I have already done this job - I realised that there might be some other
who would like to use them.
I am happy to share them with interested parties - please write here if you
are interested.

On request I can also convert single countries or regions.

Be warned however that planet files (bziped and tared) is 35GB, so
downloading takes a while!
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [Talk-br] Situação das traduções

2015-02-05 Diskussionsfäden Vitor George

Haha, excelente trabalho mesmo!

Bom, agora que o erro está no wiki e não nos e-mails que mando, qualquer
pessoa pode ir lá e arrumar. Espero que não demore muito.

2015-02-05 20:17 GMT-02:00 Lists li...@gimnechiske.org:

 Vitor

 To vendo no wiki que Merkaator e 1000% traducido, mil porcento? bom
 trabalho!

 Aun Johnsen

 On Feb 5, 2015, at 18:58, Vitor George vitor.geo...@gmail.com wrote:

 Pessoal,

 Há algum tempo
 http://article.gmane.org/gmane.comp.gis.openstreetmap.region.br/1595/match=tradu%C3%A7%C3%B5es
  comecei
 a mandar na lista de discussão talk-br
 https://lists.openstreetmap.org/listinfo/talk-br informes sobre a
 situação da tradução ao português brasileiro das ferramentas do
 OpenStreetMap.

 Agora não consigo mais mandar estes informes com frequência, e coloquei-o
 no wiki para que qualquer pessoa possa ajudar no monitoramento:

 WikiProject_Brazil/Traduções
 https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Tradu%C3%A7%C3%B5es

 Gostaria que a comunidade brasileira começasse a se organizar em grupos de
 trabalho, que ficariam responsáveis pelas atividades mínimas de organização
 de esforços direcionados.
 Um grupo de trabalho de traduções poderia ser um primeiro passo. *Caso
 alguém se interesse manter a informação do wiki atualizada, ao menos
 quinzenalmente, vá em frente e divulgue novidades na lista, fórum e demais
 canais da comunidade. *Eu posso ajudar.

 Abraço,
 Vitor
 ___
 Talk-br mailing list
 Talk-br@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-br



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


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

Re: [Talk-it] turn lanes

2015-02-05 Diskussionsfäden Stefano Droghetti


Il 05/02/2015 16:14, Mauro Costantini ha scritto:

Il 5 febbraio 2015 01:22, Stefano Droghetti
stefano.droghe...@gmail.com ha scritto:

Due tratti, di direzione opposta verso il semaforo
La parte in alto:
turn:lanes:forward=through|left

Ovviamente intendevi turn:lanes:forward=left|through .

Ops, giusto!


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

[OSM-talk-fr] Index R*-Tree pour système embarqué

2015-02-05 Diskussionsfäden Léo Serre

Bonjour à tous

Après de longues recherches pour savoir qu'elle est l'indexation la plus
efficace (simplicité de construction, rapidité pour trouver un élément,
taille), tout le monde m'a dit R*-Tree.
Mais après des essais, ma conclusion est que le quadtree est largement
mieux. Je vous laisse un exemple en vidéo ci-dessous pour ceux que ça
intéresse.

http://www.dailymotion.com/video/x2ghtqj_r-tree-pour-des-donnees-geographiques_tech

/_Note :_ Le code pour convertir des LineString GeoJSON //en Segments
CSV est disponible sur simple demande./

Léo

-- 
LSTRONIC logo

Léo SERRE
/LSTRONIC Founder/
mail  l...@lstronic.com mailto:l...@lstronic.com
website  lstronic.com http://lstronic.com

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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Ce qui est agressif ce sont les mots TRES GROS, il faut, absolument.

Note bien aussi que cela concernait des voies qui ne sont _pas_seulement_
des limites des communes membres de la CCPRO (cela s'étendait aussi à
d'autres intercommunalités voisines, d'autres arrondissements, ou même le
département, la région, les cantons, qui eux n'ont aucun rapport avec ton
identifiant posé sur les voies partagées, pour un usage propre à quelques
intercommunalités (même si en interne ce sont les SIG des communes membres
qui les créent et les utilisent en se mettant d'accord via
l'intercommunalité pour rapprocher leurs bases).

Comme pour les relations prises en compte pour la BANO (des discussions sur
les corrections possibles des outils sont encore en cours), il te faudra le
migrer sur les relations propres à chaque commune (celle que tu indiques
par le code INSEE inséré dan ton identifiant). Je t'ai expliqué ça mais tu
n'as pas voulu écouter ou comprendre que cela crée des ambiguités ou
conflits (et ce ne sont que ces ambiguïtés/conflits qui posent problème
justement sur les voies intercommunales et notamment avec les communes qui
ne sont pas associées à l'objet de ton projet).

En attendant que l'outil de rapprochement de BANO comprenne, on a le même
problème d’ambiguïté avec ton code que pour le code FANTOIR et les adresses
postales de la BANO (et plus largement du schéma mondial de Karlsruhe pour
les tags des adresses) si tu le mets sur les voies en limite
intercommunales (ou proches de ces limites car il y a aussi des écarts, et
on en a discuté très récemment ici aussi, pour BANO).

Je réitère ma demande : quelle est la source accessible pour ces
identifiants (cela fait plusieurs fois que je te pose la question) ? Mets
ça sur la page wiki [[Vaucluse/voirie]] (tu n'es pas obligé de me répondre
directement à moi seul ou juste à cette liste, cette page suffit si tu la
complètes). C'est indispensable (pour qu'au moins on puisse valider la
licence relative à ces données internes pour l'instant pas accessibles). Là
il te faudra bien demander l'accord des collectivités concernées, tu ne
PEUX PAS te passer de leur accord.


Le 5 février 2015 18:04, Tony Emery tony.em...@yahoo.fr a écrit :

 Désolé, je précise, : Moi ou toute personne que tu aurais voulu et qui
 était
 à l'origine de l'intégration de ce tag dans l'objet, information que tu
 aurais pu relever en consultant l'historique de l'objet en question...
 C'est vrai qu'il y a des personnes adeptes des très longues phrases...

 J'ai passé la soirée hier a recorriger les relations que j'avais cassé,
 donc
 je n'ai rien brisé derrière.

 Voici mon premier mail, dites-moi en quoi il est agressif :
 Bonjour Philippe,
 Je viens de voir que tu as fait des modifications pour rattraper le
 contours
 administratif de certaines zones du côté du Vaucluse.
 Or, il y a 2 TRES GROS problèmes dans tes modifications : exemple Chemin de
 Saint-Roman (96962494)
 tu as supprimé le tag ref:FR:commune de certains tronçons de voie alors que
 pour nous cette information est primordiale et à laisser sur le tronçons de
 la voie.
 tu ajoute les tags admin_level et boundary sur le tronçon alors que c'est
 en
 doublon avec le fait que ce tronçon fait partie d'une relation de type
 boundary
 Il faut que tu corriges absolument ces erreurs sur l'ensemble de ton groupe
 de modification car nous ne pouvons plus réutiliser ces données par la
 suite.
 Par la suite, si tu dois faire des modifications sur ce territoire, merci
 de
 bien vouloir me contacter afin de ne pas détruire ce que nous avons mis en
 place.
 Bonne réception,
 Tony EMERY




 -
 Tony EMERY
 Administrateur OpenStreetMap.fr
 Mandataire Grand Sud-Est
 Géomaticien  chef de projets
 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5832624.html
 Sent from the France mailing list archive at Nabble.com.

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

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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Pieren wrote
 2015-02-05 15:17 GMT+01:00 Tony Emery lt;

 tony.emery@

 gt;:
 
 Dans la base DGFiP, j'ai relevé quelques doublons. Je vois pas trop
 l'intérêt d'ajouter un identifiant quand le rivoli n'existe pas et de le
 supprimer derrière.
 
 L'intérêt est que l'usage de ce code resterait très limité (par
 exemple 96 au lieu de 797 pour Orange) et que ça serait cohérent avec
 les autres communes françaises.
 
 J'ai commencé ici :  http://wiki.openstreetmap.org/wiki/Vaucluse/voirie
 lt;http://wiki.openstreetmap.org/wiki/Vaucluse/voiriegt;
 
 Il faudrait aussi voir ici:
 http://wiki.openstreetmap.org/wiki/WikiProject_France/Liste_des_r%C3%A9f%C3%A9rences_nationales

Et bien tu vois, mon ref:FR:Commune est un peu comme le ref:FR:BSPP:=*
des Casernes de sapeurs-pompiers de Paris et petite couronne.

Pour le moment, il y a la CCPRO et le Grand Avignon, et après on verra pour
que d'autres territoires en fasse de même...



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien  chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5832622.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-be] Opmerking note tramsporen Gent

2015-02-05 Diskussionsfäden Maarten Deen


On 2015-02-05 17:15, Jakka wrote:

https://www.openstreetmap.org/#map=19/51.05053/3.71093layers=N

Wat gebruiker ziet is verwarrend.

Een terechte opmerking tram sporen te Gent.
De aankomende tramsporen zijn dubbel en vermoedelijk in josm getekend
links en rechts van de highway zoals Bernard Spaelaan om de
noordwaarts de Coupure rechts te volgen. Rendering dubbel tramspoor
naast de highway
Vanaf Rozemarijnbrug naar Papegaaistraat is tramspoor samen getagd met
highway waardoor op de rendering maar één tramspoor zichtbaar wordt op
de highway
Ik vermoed de wijze van tekenen dit van de integratie moet zijn in de
highway zelf tenzij de tramsporen een eigen bedding hebben.

Wat moet er met deze ganse situatie gebeuren.
Ontbrekende toevoegen welke methode?
Bestaande aanpassen?
Hoe zonder al de relaties enz.. kwijt te geraken.
Wie kan, durft dit rechtzetten???


Als er een weg ligt met tramsporen erin (dus de auto's rijden op de 
tramsporen) dan zou ik een highway=* met railway=tram leggen. Als er 
twee tramsporen zijn dan ook twee highways.
Op de luchtfoto van google zie ik dat de situatie op de brug weer een 
leuke is met eigenlijk drie wegen: highway, railway en highway+railway. 
Hoewel die middelste eigenlijk ook niet echt alleen een railway is.


Relaties zul je mee moeten nemen bij het editten.

Maarten


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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-05 16:56 GMT+01:00 Pierre-Yves Berrard pierre.yves.berr...@gmail.com:

 Est-ce vraiment une référence qu'on peut qualifier de nationale ?

 Contrairement aux autres ref:FR:* de la page, on ne va pas la trouver sur
 l'ensemble du territoire français et il n'existe pas de répertoire
 officiel géré par un organisme qui en a la charge.

A priori, rien n'empêche d'utiliser ce tag dans d'autres communes.
Mais je suis d'accord, le titre du wiki est maladroit. On devrait dire
liste des tags ref spécifiques à la France

Pieren

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

Re: [Talk-us] Tagging addresses on area's

2015-02-05 Diskussionsfäden Clifford Snow

On Thu, Feb 5, 2015 at 7:53 AM, Brad Neuhauser brad.neuhau...@gmail.com
wrote:

 Including a unit number in the house number is incorrect and potentially
 confusing. There are house numbers that have a prefix or suffix as part of
 the house number, that's a different thing. It just depends on how the
 building is addressed.


+1

I'd like to weigh in on rendering of addresses. Currently the housenumber
renders on z17 and above. From an aesthetics view, rendering addresses
clutters up the map. From a practical view, address information can be
helpful, but rendering every unit number doesn't gain much unless it is in
an area such as a mobile home park. All you really need is just the
housenumber to find the building. I'm all in favor of only rendering only
at the highest zoom level and only once for each housenumber, not for every
unit number, especially since the unit number doesn't render.

Rendering unit numbers in a mobile home park or camping site numbers would
aid finding the correct location.

What is really important is collecting and entering the data so routers and
search engines can find the location.

Clifford
-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-ca] Sommet Canadien des données ouvertes / Canadian Open Data Summit

2015-02-05 Diskussionsfäden Pierre Béland

--- English messagefollows ---
Message deNord-Ouvert sur SOMMET CANADIEN DESDONNÉES OUVERTES: Lancement du 
site web et de la pré-inscription
Nous avons lancé lesite web du Sommet canadien des données ouvertes cette 
semaine! http://opendatasummit.ca
Le Sommet estl’événement annuel pan-canadien où les défis les plus 
pressantsauxquels fait face la communauté des données ouvertes sont abordésà 
l’échelle canadienne. Joignez-vous à nous le 25 mai à Ottawapour partager de 
meilleures pratiques et des expériences locales,pour apprendre d’experts 
internationaux et pour travaillerstratégiquement et en collaboration sur la 
croissance de notrecommunauté.
Consultez l'horaire,informez-vous sur les opportunités de partenariats et 
decommandites, et ne manquez surtout pas la pré-inscription. 
Passez le mot dansvos réseaux! 
L'équipe deNordOuvert

CANADIAN OPEN DATASUMMIT: Website Launch and Early Bird Registration 
We launched theCanadian Open Data Summit event page this week! 
http://opendatasummit.ca
The Summit is theannual pan-Canadian event where the most pressing challenges 
facingthe open data community are addressed on a national scale. Join us onMay 
25th in Ottawa to share best practices and local experiences, tolearn from top 
international experts, and to work on growing thecommunity strategically and 
collaboratively.
Consult theschedule, learn about sponsorship and partnership opportunities, 
andregister now to benefit from early-bird prices. And tell your friendsand 
colleauges! 
All the best, 
The Open North Team 

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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Le 5 février 2015 17:15, Tony Emery tony.em...@yahoo.fr a écrit :

 Donc, à défaut de comprendre comment ça marche et malgré ma « grossière
 erreur pécher mortel » de ne pas avoir documenté ce tag, tu aurais dû me
 contacter avant de le supprimer, quand bien même ce tag TE sembles
 incohérent.


Pourquoi aurais-je du te contacter TOI précisément ? Alors que ce n'était
qu'une toute petite poignée de ces tags qui ne concernaient justement QUE
les frontières incommunales que tu avais brisées un peu partout (et bon
nombre des autres relations dépendantes avec).

Bref de là à marquer dans ton message Gros problème de correction, et
ensuite envoyer un ordre sans rien expliquer et continuer à défaire les
corrections tout à fait légitimes pour briser à nouveau nos relations
partagées... Tu aurais pu au lieu de ce ton agressif et sans même prendre
le temps de te présenter, au moins demander des explications. Je n'ai
honnètement commis aucune erreur, et je le maintiens, il n'y avait
strictement aucun problème dans ce changeset et tu l'as prouvé toi-même
(mais un peu tard).

Et j'ai été correct dans mes messages alors même que tu a continué le ton
agressif dans les réponses suivantes.
Il a fallu que j'insiste pour que tu vienne en parler ici, ce que tu ne
t'es décidé à faire que quand c'est finalement moi qui ait transmis (parce
que tu coupais court à toute discussion et continuait à me donner des
ordres), et je t'avais prévenu à plusieurs reprises (sans même pourtant
revenir à nouveau sur tes modifs suivantes elles aussi imposées sans que tu
changes la moindre façon de faire). Je ne vois pas à quel titre je serais
le seul concerné, dès lors que tu crois que ces données posent problème à
quelqu'un d'autre, c'est juste tombé sur moi, ça aurait pu être un autre et
cela a déjà été le cas).

Heureusement que j'ai posté ici, au moins maintenant tu ébauches une
documentation sur le wiki (avec des tas d'erreurs encore à corriger, y
compris les noms de tag que tu indiques).

Mais toujours SANS documenter correctement ton ref:FR:commune et comment
il est attribué dans le cas des voies intercommunales. Tu mentionnes juste:
  Identifiant unique. Code INSEE Commune + V + identifiant sur 6
caractères. A mettre dans l'objet.
OK mais ça ne suffit toujours pas (quelle commune?), et il n'y a toujours
AUCUNE source publiquement accessible permettant de valider ça (bref là
encore tu exposes ce tag à des suppressions tout à fait légitimes sur les
voies intercommunales).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-ie] 17/05 Sheet Request

2015-02-05 Diskussionsfäden Stephen Roulston

Thanks Donal

Stephen

 On 5 Feb 2015, at 20:48, Donal Diamond donal.diam...@gmail.com wrote:
 
 On 5 February 2015 at 20:32, Stephen Roulston srouls...@me.com wrote:
 
 Could I have 35/35 Ards Peninsula - I think there is the tiniest sliver of
 land in NW and SE - and 35/33 Lecale, please?
 
 Done
 
 http://mapwarper.net/maps?field=titlequery=IRL-GSGS-3906-35-35show_warped=0
 
 http://mapwarper.net/maps?field=titlequery=IRL-GSGS-3906-35-33show_warped=0
 
 Donal
 
 
 
 
 ___
 Talk-ie mailing list
 Talk-ie@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-ie

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

[OSM-talk-fr] Mettre à jour la carte d'une commune

2015-02-05 Diskussionsfäden Ludovic Hirlimann

Bonjour,

j'édite depuis peut-être un mois la commune où je viens d’emménager afin d'y
ajouter les commerces et services. Je me suis rendu compte qu'il y avait des
manques sur la carte OSM - et des bâtiments qui n'existent plus. Quelle est
la meilleur marche à suivre pour ajouter le bout de route manquant ,enlever
les bâtiments détruit et mettre à jour la carte ? Je suis preneur d'un petit
cours pour pouvoir le faire (même si après avoir brièvement lu le guide
d'import du cadastre je suis beaucoup moins chaud).

Ludovic
ps la commune en question est Grisolles (82170)



--
View this message in context: 
http://gis.19327.n5.nabble.com/Mettre-a-jour-la-carte-d-une-commune-tp5832555.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Bonjour à tous,

Comme certains le savent, je pilote un projet (il est vrai local) pour
essayer de constituer une base de données voirie + adresses à terme qui
puisse être interopérable par différents partenaires.

Après avoir fait ce travail sur Orange (et je pense que cela a bien était
fait), j'ai intégré la Communauté de Communes des Pays du Rhône et Ouvèze et
j'applique cette méthode aux 6 autres communes, sachant que je travaille
aussi avec mes homologues des territoires voisins pour faire de même.

C'est vrai que la constitution de cette base a provoqué des dégâts au niveau
des limites administratives. J'essaye de les corriger quand je les vois.

En quelques mots, le projets vise à :
- recenser toutes les voies de l'interco en croisant les bases de données
différentes et les connaissances locales ;
- créer des relations de type associatedStreet sur l'ensemble de ces voies
et favoriser les liens entre OSM et d'autres applications ;
- importer les adresses via le plugin http://cadastre.openstreetmap.fr/

On a recenser toutes les voies des 7 communes de la CCPRO
On a créer les relation associatedStreet sur 5 des 7 communes
On a importer les adresses de 5 des 7 communes

Un fois qu'on aura fini, on controlera les limites administratives
(d'ailleurs, il faudra modifier les cantons).

Dans une deuxième étape, on va travailler avec les agents pour qualifier le
revêtement, les limitations de vitesse et de gabarit, la circulation douce,
l'éclairage et les gestionnaires des voies.

Donc, même si c'est un projet professionnel, vous êtes d'accord avec moi
pour dire que ça peut être utile dans OpenStreetMap ?
Ne serait-ce que pour améliorer les calculateurs d'itinéraires.



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien  chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5832562.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [Talk-it] parti di edifici e numeri civici

2015-02-05 Diskussionsfäden Luigi Toscano

On Thursday 05 of February 2015 11:34:38 Matteo Quatrida wrote:
 Il 05/02/2015 10:47, Martin Koppenhoefer ha scritto:
  solo che ha lo svantaggio di dover ripetere l'indirizzo su ogni
  poi
 
 Però se il tuo POI è un'attività commerciale, avere all'interno del
 POI l'indirizzo completo di civico credo sia una soluzione migliore,
 anche se comporti ripeterlo più volte.
 Ad esempio, in un grosso centro commerciale, come faresti a inserire i
 POI di tutte le attività comprensive di indirizzo, senza ripetere i
 civici n volte?

Aneddoto personale: qui in Repubblica Ceca i numeri sono per edificio, non per 
ingresso. Importati dal loro catasto, lo schema di mappatura (non ho 
approfondito) pare prevedere un punto fluttante dentro l'edificio (e non 
collegato, quindi probabilmente solo con una query spaziale ne comprendi il 
numero). E quando ho messo il numero civico esplicito ad un punto di 
un'attività commerciale dentro un edificio, l'informazione sull'indirizzo è 
stata rimossa...

Ciao
-- 
Luigi


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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-05 Diskussionsfäden François Lacombe

Je ne trouve pas de documentation sur ref:FR:commune.

D'où sont tirées ces valeurs ?

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux http://www.twitter.com/InfosReseaux

Le 5 février 2015 13:17, François Lacombe fl.infosrese...@gmail.com a
écrit :

 +1 Tony, keep going.

 *François Lacombe*

 fl dot infosreseaux At gmail dot com
 www.infos-reseaux.com
 @InfosReseaux http://www.twitter.com/InfosReseaux

 Le 5 février 2015 13:13, Tony Emery tony.em...@yahoo.fr a écrit :

 Alors on va essayer de faire simple.

 - Je ne vois pas en quoi j'ai demandé de changer des priorités ?
 - Je remet à plus tard rien du tout, je fais quand je vois et je contrôle
 quand j'ai fini, parce que mine de rien c'est un boulot énorme.
 - Ce n'est pas une référence croisé entre MA base et OSM, c'est créer un
 identifiant à la source de la création de la voie, c'est à dire au niveau
 des communes.
 - Si tu corriges mes erreurs (et non saccages), il n'y a pas de problème,
 mais pourquoi avoir supprimé le tag ref:FR:commune quand il était présent
 sur les objets ?
 - Je n'agis pas seul puisqu'on est plusieurs sur le projet
 - Qu'est ce qui te permet de dire que ce qui a été fait sur Orange a été
 mal
 fait ?
 - Je discute même pas sur le reste parce que j'ai même pas envie de
 m'étaler
 là-dessus, que tu racontes beaucoup d'ânerie et que tu mélanges des
 concepts
 et des projets qui n'ont rien à voir.

 Par contre, je trouve très déplacé de ta part de copier sur une mailing
 liste une discussion qui est privée (entre toi et moi).

 Enfin, je crois connaitre le projet BANO largement mieux que toi donc.




 -
 Tony EMERY
 Administrateur OpenStreetMap.fr
 Mandataire Grand Sud-Est
 Géomaticien  chef de projets
 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5832583.html
 Sent from the France mailing list archive at Nabble.com.

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



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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-05 Diskussionsfäden François Lacombe

Bonjour,

Je trouve très positive l'utilisation d'identifiants métiers externes à OSM
sur certains objets.

Tout simplement parce que cela permet de suivre ces objets en cas de
suppression/création sous une autre forme ensuite.

Si cela se limite à l'identifiant pour faire le lien avec un référentiel
externe, c'est tout à fait pertinent.
Après pour l'ajout de données plus privées, c'est autre chose mais je ne
crois pas que ce soit ce qui est fait par Tony.

A+

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux http://www.twitter.com/InfosReseaux

Le 5 février 2015 10:11, Vincent de Château-Thierry osm.v...@free.fr a
écrit :

 Bonjour,

  De: Philippe Verdy verd...@wanadoo.fr
 
  Visiblement il utilise OSM comme si c'était un SIG privé.

 Je doute que ça soit son intention. Mais Tony pousse l'utilisation d'OSM
 dans ses retranchements, en couplant les données OSM et ses référentiels
 métier,au sein de sa collectivité.
 Je l'ai alerté sur les relations cassées, j'en ai aussi réparé quelques
 unes depuis 24h.
 Pour ce qui est de tags tels que ref:FR:commune, si ça répond à son
 besoin, alors pourquoi pas. Mais il y a une limite à l'exercice : si ça
 n'est pas documenté, alors d'autres contributeurs n'auront pas de moyen de
 comprendre de quoi il retourne et ça n'aidera pas à la maintenance de ces
 tags, ni des objets qui les portent. Donc si Tony et lui seul en a l'usage,
 à lui avant tout de s'en donner les moyens en documentant ce qu'il fait de
 manière accessible aux contributeurs.

 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: [Talk-it] parti di edifici e numeri civici

2015-02-05 Diskussionsfäden Matteo Quatrida

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ciao,

Il 05/02/2015 10:09, Martin Koppenhoefer ha scritto:
 si usano tutti i due modi, però se metti il civico su un poligono
 si crea un vantaggio perché puoi assumere che tutti gli oggetti
 all'interno di questo poligono abbiano questo civico (per esempio i
 poi)

Questo non è sempre un vantaggio. Così di primo acchito direi che è
una buona soluzione per la grande maggioranza dei casi, ma se lo
stesso poligono avesse due civici? Non credo partizionarlo
arbitrariamente possa essere una soluzione adeguata.

Oppure se in un poligono ci fossero, ipotizziamo, cinque POI, di cui
due con lo stesso civico (es. civico 1) e due con un civico del tipo
2/a 2/b e il terzo, civico 3.
Qui come sarebbe opportuno mappare?

- -- 
Matteo Quatrida
GNU/Linux User #498939
OpenStreetMap Contributor since 2009

«L'ordine è il piacere della ragione, ma il disordine è il piacere
dell'immaginazione!» Paul Claudel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU0zm8AAoJEHnO6jolYLDxvpsIAKfcMhjbfutma/B9B3xiWder
UNDB8JTLBe9oX0ywSBhxUczGC+gMVHeYcficwEjV1MPJy/MoAbREnMnmLhdUf5tS
qfU/R9OIjxFCa23yl69nrJH3Q7aqXc2wnp3rjYRgYEab1iQ2SyLYZKxCuHSFc+MU
Mdm3QizZN2OEPap0JGJytxt2u8LIln/MdZCBnmqUXeY9R8mIR+YK2xOJXXWMI7QQ
af/9mDvk53vgIwuIrTPlQ7iwqgsuZUfjY9aFoWTyXIypl7d8tBRjf2yAp8s6D/pI
OHs4XJ/9FQ0l0hmKvqa6LQ0rRiI+1aFdOrN7833C+vs/79YY7vPLsqFAF2EuRM0=
=zHNe
-END PGP SIGNATURE-

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

Re: [Talk-it] parti di edifici e numeri civici

2015-02-05 Diskussionsfäden Elena ``of Valhalla''

On 2015-02-05 at 10:12:09 +0100, Martin Koppenhoefer wrote:
 credo che si dovrebbe dire: la segnalazione / indicazione del civico
 avviene agli accessi, perché poi vale per tutta l'area di circolazione, no?

non sempre, dato che ci sono edifici che hanno più accessi alla stessa 
area, ma con numeri civici diversi (ma potrebbero essere i comuni che 
interpretano in modo diverso le leggi/decreti citati su wikipedia)

-- 
Elena ``of Valhalla''

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

[Talk-it] Tram in sede stradale

2015-02-05 Diskussionsfäden Luca Sigfrido Percich

Ciao a tutti,

tra le molte cose ancora da sistemare a Milano ci sono i binari dei tram in
sede stradale.

Anche in questo caso durante il collegamento col grafo comunale abbiamo
tendenzialmente lasciato la situazione preesistente, che presenta diverse
casistiche:

1. tracciati railway separati e paralleli alle highway (caso più frequente
e che ci sembrava logico adottare, vedere [1])
2. ways con tag highway e railway (esempio:
https://www.openstreetmap.org/way/289515471)
3. due ways sovrapposte, una con highway=* e l'altra con railway=tram
(esempio: https://www.openstreetmap.org/way/275553581)

Gli approcci 2  e 3 sembrano entrambi consentiti stando alla wiki ([2]).

Il problema del caso 1 è che non abbiamo modo di dire che i binari sono in
sede stradale. Ritengo che questa sia una informazione importante. Non mi
sembra ci siano tag o relation utilizzabili a tal fine, o mi sbaglio?

Per ora cercherei di uniformare la situazione portando i casi 2 e 3 all'1,
ma mi farebbe piacere sapere cosa ne pensano i mappatori più esperti.

Grazie a tutti

Sig



[1]
http://wiki.openstreetmap.org/wiki/Agenzia_mobilit%C3%A0_ambiente_territorio/tram#Soluzione_proposta
[2] http://wiki.openstreetmap.org/wiki/Trams#Tram_tracks
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-be] Fixme's in Taglocator

2015-02-05 Diskussionsfäden Glenn Plas

Hallo Marc,

Mooie tool. Zeker met de JOSM hooks. Ik denk dat de fixme's hier wel
over het hoofd worden gezien. Er mag idd wel wat cleanup gebeuren.

Bedankt voor de informatie, ik kende taglocater niet.

Glenn

On 04-02-15 16:26, Marc Zoutendijk wrote:
Goedendag allen,

Ik ben Marc Zoutendijk en mapper uit Nederland (ik woon in Vught) maar
met het meeste mapwerk op Spaanse grond. Omdat ik daar vaak op
fietsvakantie ben.
Ter introductie: http://www.marczoutendijk.nl

Sinds 2011 actief met en op OSM.

In Nederland zijn we veel actiever op het forum dan op de Mailinglist,
in België is dat andersom merk ik, dus meld ik me nu hier met vragen en
antwoorden.

Wat ermee kan kun je lezen in de wiki:

https://wiki.openstreetmap.org/wiki/Taglocator

Je kunt ook de hele ontwikkelingsgang lezen op het forum:
http://forum.openstreetmap.org/viewtopic.php?id=28807

http://mijndev.openstreetmap.nl/~marczoutendijk/taglocator/?map=variouszoom=15lat=51.22197lon=4.41125layers=B00T

Met groet,
Marc Zoutendijk.

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

--
Everything is going to be 200 OK.

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

Re: [Talk-it] Nomi vie negli incroci

2015-02-05 Diskussionsfäden Luca Sigfrido Percich

Ciao Max,

non so quali criteri usino nell'attribuzione (immagino quello della via
più importante), ma come ti dicevo al SIT del Comune hanno attribuito
ogni area (o sede) stradale di intersezione ad una via piuttosto che ad
un'altra.

Quindi questa è una informazione che in AMAT abbiamo e possiamo trasferire
sulle highway OSM, volevo solo capire se così facendo non rischiamo di
rompere una impostazione consolidata.

Nelle piazze è intuitivo che tutti gli archi prendano il nome della piazza,
e correggeremo in tal senso. L'esempio che fai di piazza Firenze è lampante
- gli archi entranti hanno il loc_ref che inizia con 7173 (il codice di pza
Firenze) ma il nome delle vie entranti, che andremo quindi a cambiare in
Piazza Firenze.

Addirittura per le piazze adotterei il criterio che stanno usando al SIT di
spezzare le way entranti in corrispondenza del passaggio dalla via alla
piazza, in modo da potervi attribuire i due spezzoni.

Per gli incroci il discorso è più difficile. Nei casi in cui gli archi sono
già spezzati (quello della mia mail precedente) l'attribuzione è fattibile,
mentre in incroci semplici come questo no:

https://www.openstreetmap.org/#map=20/45.465595/9.232575

L'area di intersezione fra via Negroli e via Sismondi appartiene a via
Negroli; quindi dovrei spezzare i 4 archi entranti nell'incrocio in modo da
avere 4 ways tutte con name=Via Negroli. Non ha molto senso, ma se così non
facciamo rischiamo l'incongruenza se procediamo a rinominare le ways negli
incroci complessi (strade a più carreggiate).

Credo sia più importante adottare un criterio omogeneo anche se non
perfettamente aderente alla realtà. Cioè vorrei trattare tutte le
intersezioni (non le piazze) allo stesso modo. Quindi mi verrebbe da dire
che forse è meglio lasciarle come stanno.

Se pensiamo che l'informazione possa servire in OSM, magari possiamo
metterla nei nodi di intersezione invece che negli archi.

Grazie

Sig





Il giorno 5 febbraio 2015 08:36, emmexx emm...@tiscalinet.it ha scritto:

 Il 02/04/2015 04:20 PM, Luca Sigfrido Percich scrisse:


 Mi pare invece lecito attribuire a tutti gli archi interni ad una piazza
 il nome della piazza, come in questo caso (Piazza Appio Claudio):

 https://www.openstreetmap.org/#map=19/45.49213/9.19411

 Cosa ne pensate? Questa modifica potrebbe essere utile / dannosa per il
 rendering e le applicazioni di routing?


 Se ne e' discusso varie volte senza giungere ad una conclusione definita.

 Il problema principale e' che spesso non si e' in grado di stabilire un
 confine e l'attribuzione quindi non e' chiara.
 A Milano mi viene in mente viale Teodorico che si innesta in piazza
 Firenze:
 http://www.openstreetmap.org/?mlat=45.48740mlon=9.15559#
 map=18/45.48741/9.15559

 Non ci sono targhe e se si arriva da viale Teodorico non si ha proprio la
 senzazione di entrare in un'altra via o piazza. In piu' si incontra anche
 una via Telemaco Signorini che interrompe piazza Firenze.

 Difficile stabilire delle regole univoche.

 Sempre li' in piazza Firenze viale Teodorico e' l'unico che cambia nome
 all'interno della piazza, tutte le altre vie lo mantengono.

 Non c'e' un criterio usato da vigili o forze dell'ordine per stabilire il
 nome delle vie?

 ciao
 maxx

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

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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-05 Diskussionsfäden Vincent de Château-Thierry

Alors on va essayer de faire simple.

- Je ne vois pas en quoi j'ai demandé de changer des priorités ?
- Je remet à plus tard rien du tout, je fais quand je vois et je contrôle
quand j'ai fini, parce que mine de rien c'est un boulot énorme.
- Ce n'est pas une référence croisé entre MA base et OSM, c'est créer un
identifiant à la source de la création de la voie, c'est à dire au niveau
des communes.
- Si tu corriges mes erreurs (et non saccages), il n'y a pas de problème,
mais pourquoi avoir supprimé le tag ref:FR:commune quand il était présent
sur les objets ?
- Je n'agis pas seul puisqu'on est plusieurs sur le projet
- Qu'est ce qui te permet de dire que ce qui a été fait sur Orange a été mal
fait ?
- Je discute même pas sur le reste parce que j'ai même pas envie de m'étaler
là-dessus, que tu racontes beaucoup d'ânerie et que tu mélanges des concepts
et des projets qui n'ont rien à voir.

Par contre, je trouve très déplacé de ta part de copier sur une mailing
liste une discussion qui est privée (entre toi et moi).

Enfin, je crois connaitre le projet BANO largement mieux que toi donc.




-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien  chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5832583.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-be] Hackathon eTourisme 2015

2015-02-05 Diskussionsfäden Julien Minet

?t=http%3A%2F%2Fhackalux.be%2Fsi=5615661674397696pi=8f783747-fc4e-4658-d4b5-703e512d1b69
FR)
for more informations.


Happy hacking,

-- 
*Hugues Ligot*
Hackathon eTourisme 2015 http://www.hackalux.be/
+32 494 732 468 | hugues.li...@gmail.com | Abetterway.be
https://www.linkedin.com/profile/view?id=155250384trk=nav_responsive_tab_profile_pic
  https://twitter.com/Hugues_Lgt

___
42 mailing list
4...@discuss.hackerspaces.be
http://discuss.hackerspaces.be/listinfo.cgi/42-hackerspaces.be
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openstreetmap.org/pipermail/talk-be/attachments/20150205/0d42c22c/attachment.html

--

Subject: Digest Footer

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


--

End of Talk-be Digest, Vol 86, Issue 11
***


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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Bonjour,

 De: Philippe Verdy verd...@wanadoo.fr
 
 Visiblement il utilise OSM comme si c'était un SIG privé.

Je doute que ça soit son intention. Mais Tony pousse l'utilisation d'OSM dans 
ses retranchements, en couplant les données OSM et ses référentiels métier,au 
sein de sa collectivité. 
Je l'ai alerté sur les relations cassées, j'en ai aussi réparé quelques unes 
depuis 24h.
Pour ce qui est de tags tels que ref:FR:commune, si ça répond à son besoin, 
alors pourquoi pas. Mais il y a une limite à l'exercice : si ça n'est pas 
documenté, alors d'autres contributeurs n'auront pas de moyen de comprendre de 
quoi il retourne et ça n'aidera pas à la maintenance de ces tags, ni des objets 
qui les portent. Donc si Tony et lui seul en a l'usage, à lui avant tout de 
s'en donner les moyens en documentant ce qu'il fait de manière accessible aux 
contributeurs.
 
vincent

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

Re: [OSM-talk-be] Fwd: [42] Hackathon eTourisme 2015

2015-02-05 Diskussionsfäden Marc Ducobu

Hello,

I will probably take part on Friday. I think that Julien Minet will also go
there.

A question is how can OSM be used to create a usefull tool/app/... on this
topic ?

Also, the data will be open during the event but it is not gain that the
data will be open after the event. A goal of the event is to convince the
owner to open their data.

Marc

On 5 February 2015 at 10:55, Jo winfi...@gmail.com wrote:

 This seems interesting. I won't be able to go as I don't have a credit
 card to pay the €20, but maybe somebody else wants to go and hack on some
 open data.

 Jo

 -- Forwarded message --
 From: Hugues Ligot hugues.li...@gmail.com
 Date: 2015-02-05 10:12 GMT+01:00
 Subject: [42] Hackathon eTourisme 2015
 To: 4...@discuss.hackerspaces.be


 Hey hackers,

 We organise in march the first eTourisme hackathon in Belgium. It will
 take place in Libramont from March 20 to 21.
 Many public data files will be open for the event.

 I heard from Hugo Herter, you might have some interest in it, so here is
 the info !

 Feel free to contact me or check our website (hackalux.be
 http://t.signaledue.com/e1t/c/5/f18dQhb0S7lC8dDMPbW2n0x6l2B9nMJW7t5XZs3MhNz6W3MhG_41qwqm4W3Mqkws56dVd2f6jRgQq02?t=http%3A%2F%2Fhackalux.be%2Fsi=5615661674397696pi=8f783747-fc4e-4658-d4b5-703e512d1b69
  FR)
 for more informations.


 Happy hacking,

 --
 *Hugues Ligot*
 Hackathon eTourisme 2015 http://www.hackalux.be/
 +32 494 732 468 | hugues.li...@gmail.com | Abetterway.be

 https://www.linkedin.com/profile/view?id=155250384trk=nav_responsive_tab_profile_pic
https://twitter.com/Hugues_Lgt

 ___
 42 mailing list
 4...@discuss.hackerspaces.be
 http://discuss.hackerspaces.be/listinfo.cgi/42-hackerspaces.be



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




-- 
et en avant pour de folles aventures...
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-fr] Espaces demi m....

Avec MapCSS il y a moyen de montrer plus grand ce qui vous intéresse.
Regardez le style Public Transport que j'ai créé pour le transport public
(Il est dans la liste). Essayez d'ajouter odbl=new à un arrêt ou une
relation route. L'effet est le plus intéressant si les arrêts sont sur des
noeuds isolés à côté de la route.

Polyglot

2015-02-05 11:52 GMT+01:00 Pierre Giraud blueca...@gmail.com:

 Défectif ou défectueux ?

 2015-02-03 21:07 GMT+01:00 Philippe Verdy verd...@wanadoo.fr:

 En fait ce n'est pas tellement la taille des libellé dans l'affichage de
 la carte qui me gène (qu'ils soient petits évite aussi de cacher trop de
 chose : on devine mais en cas de doute on a encore l'onglet des propriétés
 pour les afficher clairement, sans superposition de traits et de couleurs).

 C'est surtout dans l'interface utilisateur (liste des tags, dialogues de
 saisie ou de configuration, menus, etc...) que c'est pénible (et que le
 support international des autres écritures est défectif).

 Certes affiche correctement le tibétain ou le birman est compliqué à
 inclure (dommage qu'il n'y ait pas un meilleur moteur de rendu de texte
 comme il en existe pour Eclipse) et leur normalisation assez récente (avec
 encore quelques problèmes de stabilité), mais pour le bengali c'est stable
 depuis longtemps et c'est une langue diablement importante.

 Et ma presbytie naissante (qu'on aura tous...) commence à être un vrai
 problème que la correction optique ne parvient pas à palier : les textes
 trop petits sont fatigants pour la vue et c'est difficile de voir des
 fautes mineures comme un accent oublié, même en français, alors que tout le
 reste de l'OS et le navigateur ont un réglage possible qui apporte un vrai
 confort visuel.

 

 Je m'énerve autant devant les étiquettes alimentaires (je veux lire
 scrupuleusement les compositions, notamment la nature des matières grasses
 et le taux de sel de plus en plus souvent excessif) devenues totalement
 illisibles où il me faut chercher une bonne source lumineuse pour accentuer
 les contrastes, en essayant de les lire sans mes lunettes (avec c'est
 impossible).

 Maintenant il m'arrive d'utiliser la caméra de mon smartphone pour zoomer
 dessus mais ce n'est pas évident de trouver le bon éclairage quand même le
 smartphone apporte de l'ombre et que son flash se réfléchit trop sur la
 surface et est inutilisable et la surface n'est pas non plus plane ou bien
 l'étiquette est sous un plastique alvéolé ou rainuré.

 Vivement la généralisation les étiquettes lisibles sur Internet par
 QR-code : OpenFoodFacts OK, mais les fabricants ou emballeurs devraient les
 rendre lisibles sur en données OpenData sur un site officiel non
 publicitaire contenant toutes les infos légales sur une fiche d'information
 normalisée, y compris les numéros de lots et dates de fraîcheur ou de
 conservation, qui peuvent être ajoutées (en plus du code produit EAN, et
 même le prix de vente sur le QRcode ou sur le code barre additionnel des
 points de vente).

 Certains points de vente (hypermarchés) vont aussi jusqu'à masquer ces
 infos en collant par dessus un emballage ou un autocollant de promo
 (impossible à décoller sans défaire le lot ou abimer l'emballage), mais
 souvent c'est de la faute même de leurs fournisseurs qui livrent ces promos

 (on achète d'abord, après on verra chez soi comment lire les infos sur
 les produits achetés, et on a des mauvaises surprises avec des produits qui
 dans une seule portion contiennent plus de 2 grammes de sel, plus que la
 quantité maximale pour toute une journée, le sel n'est là que pour masquer
 le fait que ce sont des produits totalement insipides, il remplace l'huile
 végétale et les épices... (Ça m'arrive de goûter et de jeter le tout
 tellement c'est gras et salé et souvent aussi sans texture : même un chien
 domestique n'en veut pas, et pourtant c'est un produit de marque connue,
 parfois avec force publicité, vendu plus cher qu'un premier prix
 d'hypermarché).


 Le 3 février 2015 20:18, Félix Marty felixma...@outlook.com a écrit :

 J'approuve Philippe. JOSM a des progrès à faire là-dessus, les caractères
 affichés sur le calque OSM sont par exemple minuscules, et il n'y a à ma
 connaissance pas de possibilité pour changer facilement la taille de
 police
 des calques. Ces problèmes de taille de polices sont d'ailleurs je pense
 surtout visible sur les écrans à haute résolution type 1080p (mon cas).

 Le réglage des polices par défaut a cependant l'air d'être possible sur
 JOSM.
 Dans mon cas, l'utilisation du thème GTK+ permet d'utiliser la police
 (et la
 taille de police) définie par défaut sur le système. Il y quand même de
 nombreuses améliorations à apporter, je remarque par exemple que certains
 textes sont tronqués à cause de la taille de police (14) trop importante
 que
 j'utilise.

 Le mardi 3 février 2015, 13:55:51 Philippe Verdy a écrit :
  [...]



 ___
 Talk-fr mailing list

Re: [Talk-it] parti di edifici e numeri civici

2015-02-05 10:01 GMT+01:00 Elena ``of Valhalla'' elena.valha...@gmail.com:

 in Italia la numerazione viene assegnata agli accessi,




credo che si dovrebbe dire: la segnalazione / indicazione del civico
avviene agli accessi, perché poi vale per tutta l'area di circolazione, no?

ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-de] mehrere Häuser mit gemeinsamen Dach

Am 3. Februar 2015 um 19:48 schrieb fly lowfligh...@googlemail.com:

 Vielleicht habe ich mich undeutlich ausgedrückt. Laut Katasteramt sind
 das mehrere Häuser mit unterschiedlichen Hausnummern, aber auf dem
 Luftbild erkennt man eben nur ein Dach.






mehrere Hausnummern sind nicht unbedingt mehrere Häuser, normalerweise
sollten im Falle mehrerer Häuser diese in mehrfacher Hinsicht getrennt sein
(Trennwand mit entsprechenden Schallschutz und Brandschutzanforderungen,
Einzelteile statisch unabhängig, etc.), wobei auch Wohnungstrennwände (d.h.
Teile desselben Gebäudes trennende Wände) höhere Brandschutz- und
Schallschutzanforderungen haben als Wände innerhalb derselben
Nutzungseinheit.

Was ich meine: eigentlich oder meistens solltest Du auf dem Dach erkennen
können, wo die einzelnen Häuser jeweils aufhören/anfangen.

Bei einzelnen Gebäudeteilen ist building:part richtig, bei
aneinandergebauten Gebäuden würde ich die jeweils als building=* mappen
(mit gemeinsamen ways wo sie aneinandergebaut sind).

Gruß,
Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk-be] Fixme's in Taglocator

2015-02-05 Diskussionsfäden Marc Gemis

'k had hier nochtans al een berichtje over gestuurd op 3 januari, ha zo,
jullie lezen mijn berichtjes niet :-)
maar er is wel een heleboel functionaliteit bijgekomen sindsdien.

2015-02-05 10:56 GMT+01:00 Jo winfi...@gmail.com:

De tag locator bestaat nog maar een dikke maand :-)

Mooie tool!

Op 5 februari 2015 10:50 schreef Glenn Plas gl...@byte-consult.be:

Hallo Marc,

Mooie tool. Zeker met de JOSM hooks. Ik denk dat de fixme's hier wel
over het hoofd worden gezien. Er mag idd wel wat cleanup gebeuren.

Bedankt voor de informatie, ik kende taglocater niet.

Glenn

On 04-02-15 16:26, Marc Zoutendijk wrote:
Goedendag allen,

Ik ben Marc Zoutendijk en mapper uit Nederland (ik woon in Vught) maar
met het meeste mapwerk op Spaanse grond. Omdat ik daar vaak op
fietsvakantie ben.
Ter introductie: http://www.marczoutendijk.nl

Sinds 2011 actief met en op OSM.

In Nederland zijn we veel actiever op het forum dan op de Mailinglist,
in België is dat andersom merk ik, dus meld ik me nu hier met vragen en
antwoorden.

Wat ermee kan kun je lezen in de wiki:

https://wiki.openstreetmap.org/wiki/Taglocator

Je kunt ook de hele ontwikkelingsgang lezen op het forum:
http://forum.openstreetmap.org/viewtopic.php?id=28807

http://mijndev.openstreetmap.nl/~marczoutendijk/taglocator/?map=variouszoom=15lat=51.22197lon=4.41125layers=B00T

Met groet,
Marc Zoutendijk.

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

--
Everything is going to be 200 OK.

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

Re: [Talk-it] parti di edifici e numeri civici

2015-02-05 Diskussionsfäden Elena ``of Valhalla''

On 2015-02-05 at 11:44:21 +0100, Luigi Toscano wrote:
 Aneddoto personale: qui in Repubblica Ceca i numeri sono per edificio, non 
 per 
 ingresso. 

sì, il modo in cui vengono gestiti gli indirizzi cambia da nazione a
nazione, non è uniforme neanche in europa.

-- 
Elena ``of Valhalla''

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

Re: [OSM-talk-fr] OSM hors ligne

2015-02-05 Diskussionsfäden Pierre Knobel

Je ferais tous les tests en rentrant. En attendant je collecte les
idées et je commence à voir dans les diverses documentations qu'est-ce
que ça implique en terme de logiciels, systèmes d'exploitation et de
matériel nécessaire.

Donc merci pour toutes les idées déjà proposées :)

L'idéal serait vraiment d'avoir tout ce qu'il faut sur un disque USB,
donc les solutions qui nécessitent un serveur ne seront pas
prioritaires sur ma liste de tests. Mais je m'intéresse de près aux
serveurs portables du style xampp
(http://portableapps.com/apps/development/xampp).

Je récapitule les idées que j'ai retenues pour l'instant, en vrac :
- trouver une appli d'affichage de cartes avec son propre format de
données vectorielles
  parmis http://wiki.openstreetmap.org/wiki/Software/Desktop
- peut-être OSMAnd à travers un émulateur Android (beau rendu)
- cahier des charges minimum : affichages au minimum des
occupations de sol, routes,
  chemins, sentiers, divers POI (magasins, tourisme, batiments
publics...), ombrage du
  relief ou courbes de niveau...
- précalculer des tuiles et les afficher directement
  (http://wiki.openstreetmap.org/wiki/OpenLayers_Local_Tiles_Example)
  problème : espace disque, zone de couverture et/ou niveaux de zooms
trop limités.
- faire tourner un serveur de tuiles. Problèmes :
- 500 Go de base de données... est-ce qu'on peut filtrer
efficacement les données OSM
  en amont pour ne garder que ce qui est vraiment nécessaire au rendu ?
- puissance de calcul nécessaire pour le rendu des premiers
niveaux de zoom et
  complexité de la solution pour avoir les belles tuiles avec les
landuse comme sur
  osm-fr  (appel du pied pour récupérer les tuiles osm-fr jusqu'au
niveau 8, 9 ou 10)
- pas sur d'arriver à quelque chose de portable, il va peut-être
me falloir un serveur de
  rendu dédié sur le terrain (ça pourrait éventuellement le faire
pour moi, mais ça ne
  profitera pas à tout le monde avec un simple ordi portable à disposition)

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

Re: [Talk-it] parti di edifici e numeri civici

2015-02-05 10:37 GMT+01:00 Matteo Quatrida matteo.quatr...@linuxmail.org:

 Questo non è sempre un vantaggio. Così di primo acchito direi che è
 una buona soluzione per la grande maggioranza dei casi, ma se lo
 stesso poligono avesse due civici?



si potrebbe mettere 2 poligoni, uno per ciascun civico, modellando la
realtà in quel modo di potrebbe capire, mentre con 2 punti galleggianti non
potresti mai capire che si tratta dello stesso edificio con 2 civici.



 Non credo partizionarlo
 arbitrariamente possa essere una soluzione adeguata.



+1 , e non è stato proposto di farlo ;-)



 Oppure se in un poligono ci fossero, ipotizziamo, cinque POI, di cui
 due con lo stesso civico (es. civico 1) e due con un civico del tipo
 2/a 2/b e il terzo, civico 3.



a quel punto non si potrebbe dire che abbiamo tutti i civici su tutte le
aree, invece dovresti fare un'area per civico e specificare dove di trova
in 3d (building:level per esempio).

Non dico che mappare il civico all'ingresso non funziona, anzi, è la cosa
più facile, e verificabile senza entrare nell'edificio o parlare con
qualcuno, solo che ha lo svantaggio di dover ripetere l'indirizzo su ogni
poi, mentre con un poligono si ha più informazioni (dove valga quel civico).

Ovviamente, quando dico 2 poligoni non intendo 2 ways sovvraposti ma al
soliito farei multipoligoni...

ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-us] Tagging addresses on area's

2015-02-05 Diskussionsfäden Mike N


On 2/4/2015 11:25 PM, Greg Morgan wrote:

  addr:housenumber contains both the number
and the building letter in the same field.  The map is useful because
you can find the building. How have other people tried to handle these
situations?


I haven't tried in any meaningful way.  It's too early to guess how an 
address matching utility might work.   Until now I have used both


 addr:housenumber=724D

and
 addr:housenumber=724 + addr:unit=D

 depending on whether the address specified by the owner's web site 
included the letter.   More recently, I've gravitated towards separating 
the addr:unit even if the owner specified it as one word, but I'm not 
sure it's the most useful.   The addr:housenumber doesn't render anyway 
if the building has also been tagged as another POI that renders.



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

Re: [Talk-it] parti di edifici e numeri civici

2015-02-05 Diskussionsfäden Stefano Salvador

 Il processo per me indica che si tratta di un numero applicabile a tutto
 l'immobile / unità ecografica semplice:

 Il proprietario dell’immobile, precedentemente alla domanda di Fine
 Lavori e/o di Asseveramento, nei casi in cui le opere realizzate abbiano
 comportato nuova attribuzione della numerazione civica esterna e/o la
 modifica del numero delle unità immobiliari esistenti, deve presentare
 domanda di Attestazione di Numerazione Civica Definitiva (art. 43 DPR
 223/1989) e, nei casi in cui lo necessita, il Certificato di Unità
 Immobiliare Urbana .


 perché parla di immobile se in realtà soltanto gli ingressi hanno
 numeri, ma gli immobili no?



nella realtà non è così, quando costruisci una nuova casa il comune ti
assegna tanti numeri quanti ingressi hai, quindi è molto comune avere più
civici per immobile (tipicamente porta di casa e portone per l'auto). Prova
a farti un giro in una zona con villette e vedrai che è quasi sempre così.

Inoltre secondo me non è vero che mettendo il numero all'edificio non devi
metterlo sui poi, infatti capita spesso che negozi contigui appartenenti
allo stesso edificio abbiano civici diversi (appunto perché il civico
indica l'ingresso e non l'immobile)

Non ho dubbi che all'estero le cose funzionino in modo diverso ma non vedo
perché dovremmo imporre lo stesso modello anche per l'Italia.

Ciao,

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

Re: [Talk-it] parti di edifici e numeri civici

2015-02-05 11:34 GMT+01:00 Matteo Quatrida matteo.quatr...@linuxmail.org:

 Ad esempio, in un grosso centro commerciale, come faresti a inserire i
 POI di tutte le attività comprensive di indirizzo, senza ripetere i
 civici n volte?




se tutti i POI hanno lo stesso civico dovrebbe essere sufficiente di
mappare quello come poligono, altrimenti aggiungi lo civico sul POI (oppure
fai più poligoni più grandi di un POI ma più piccoli del centro
commerciale), la soluzione adatta dipende dal caso specifico...

ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[OSM-talk-nl] OSMC problemen

2015-02-05 Diskussionsfäden Patrick Coenen

dag OSM ers.
ik heb een probleem met de tag OSMC symbol.De help functie op deze site helpt 
me niet verder.Hoe moet ik de tag invullen om een gekleurd 
(paars/groen/blauw/rood) vierkantje te krijgen met daarin aan witte letter als 
symbool?mij lukt het niet. een witte E moet op paarse achtergrond, witte D op 
een groene, witte C op een blauwe.
kan iemand beter osmc-en? ___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Salut Tony,

Décrit de cette façon-là, je pense que vos contributions ont certainement
mérite et nous devrions être content que vous voulez les apporter. Je suis
convaincu qu'il sera possible de trouver un moyen pour travailler ensemble,
qui peut satisfaire tout le monde concerné.

Salutations,

Polyglot

2015-02-05 11:26 GMT+01:00 Tony Emery tony.em...@yahoo.fr:

 Bonjour à tous,

 Comme certains le savent, je pilote un projet (il est vrai local) pour
 essayer de constituer une base de données voirie + adresses à terme qui
 puisse être interopérable par différents partenaires.

 Après avoir fait ce travail sur Orange (et je pense que cela a bien était
 fait), j'ai intégré la Communauté de Communes des Pays du Rhône et Ouvèze
 et
 j'applique cette méthode aux 6 autres communes, sachant que je travaille
 aussi avec mes homologues des territoires voisins pour faire de même.

 C'est vrai que la constitution de cette base a provoqué des dégâts au
 niveau
 des limites administratives. J'essaye de les corriger quand je les vois.

 En quelques mots, le projets vise à :
 - recenser toutes les voies de l'interco en croisant les bases de données
 différentes et les connaissances locales ;
 - créer des relations de type associatedStreet sur l'ensemble de ces voies
 et favoriser les liens entre OSM et d'autres applications ;
 - importer les adresses via le plugin http://cadastre.openstreetmap.fr/

 On a recenser toutes les voies des 7 communes de la CCPRO
 On a créer les relation associatedStreet sur 5 des 7 communes
 On a importer les adresses de 5 des 7 communes

 Un fois qu'on aura fini, on controlera les limites administratives
 (d'ailleurs, il faudra modifier les cantons).

 Dans une deuxième étape, on va travailler avec les agents pour qualifier le
 revêtement, les limitations de vitesse et de gabarit, la circulation douce,
 l'éclairage et les gestionnaires des voies.

 Donc, même si c'est un projet professionnel, vous êtes d'accord avec moi
 pour dire que ça peut être utile dans OpenStreetMap ?
 Ne serait-ce que pour améliorer les calculateurs d'itinéraires.



 -
 Tony EMERY
 Administrateur OpenStreetMap.fr
 Mandataire Grand Sud-Est
 Géomaticien  chef de projets
 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5832562.html
 Sent from the France mailing list archive at Nabble.com.

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

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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

2015-02-05 Diskussionsfäden François Lacombe

+1 Tony, keep going.

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux http://www.twitter.com/InfosReseaux

Le 5 février 2015 13:13, Tony Emery tony.em...@yahoo.fr a écrit :

 Alors on va essayer de faire simple.

 - Je ne vois pas en quoi j'ai demandé de changer des priorités ?
 - Je remet à plus tard rien du tout, je fais quand je vois et je contrôle
 quand j'ai fini, parce que mine de rien c'est un boulot énorme.
 - Ce n'est pas une référence croisé entre MA base et OSM, c'est créer un
 identifiant à la source de la création de la voie, c'est à dire au niveau
 des communes.
 - Si tu corriges mes erreurs (et non saccages), il n'y a pas de problème,
 mais pourquoi avoir supprimé le tag ref:FR:commune quand il était présent
 sur les objets ?
 - Je n'agis pas seul puisqu'on est plusieurs sur le projet
 - Qu'est ce qui te permet de dire que ce qui a été fait sur Orange a été
 mal
 fait ?
 - Je discute même pas sur le reste parce que j'ai même pas envie de
 m'étaler
 là-dessus, que tu racontes beaucoup d'ânerie et que tu mélanges des
 concepts
 et des projets qui n'ont rien à voir.

 Par contre, je trouve très déplacé de ta part de copier sur une mailing
 liste une discussion qui est privée (entre toi et moi).

 Enfin, je crois connaitre le projet BANO largement mieux que toi donc.




 -
 Tony EMERY
 Administrateur OpenStreetMap.fr
 Mandataire Grand Sud-Est
 Géomaticien  chef de projets
 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5832583.html
 Sent from the France mailing list archive at Nabble.com.

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

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

[OSM-legal-talk] Can I publish Google Earth Pro images in a book?

2015-02-05 Diskussionsfäden Kathy Bizzoco


Hi, new to the forum, and appreciate any advice I can get.

I'm a small, independent publishing company and have a contract to 
publish a book written by an Vietnam Marine and CT police officer who, 
upon retiring, joined the Military Police and found himself in Iraq in 
charge of 20-somethings, and the other branches of the military are a 
bit irritated by their presence.


I've spent two days reading google's map copyright policies, and my head 
is so turned around, I don't know in which direction to look.


Does anyone know if I can use images of Iraq and Baghdad, using Google 
Earth Pro (because it offers high resolution image download, which I 
need for printing), as long as I include the stated attribution (i.e. 
copyright clause) under each map?


Thanks in advance!

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

Re: [OSM-talk-fr] Index R*-Tree pour système embarqué

Le test se base sur le fait que tes R*trees ne sont pas maintenus
équilibrés en contenu, une règle commune aux B-trees).

Et quitte à diviser un rectangle R*tree en deux quand il est plein, on a
normalement intérêt à le couper de préférence sur sa dimension la plus
grande pour répartir les points de chaque côté (mais si on veut optimiser,
on fait le test de répartition sur une dimensio puis sur l'autre, et on
choisit celle où le trait de découpe est plus près du milieu de cette
dimension).
La charge des R*trees doit normalement être portée sur la répartition, lors
de l'insertion (ou la suppression) des noeuds, pour qu'ensuite les
recherches n'aient pas à le faire.

Dans ce cas avec un Quadtree tu génères pleins de boites vides et les
branches de l'arbre sont moins bien équilibrées, avec un seuil minimum de
remplissage de 25% là où un R*Tree utilise un minimum de 50% (arrondi à
l'unité inférieure) : si ton R*tree a une capacité maximale de 6 points ou
sous-rectangles, et une capacité minimale de 3 points ou sous-rectangles,
c'est à dire 50% pour la répartition la plus optimale, le nombre de boites
à visiter ne dépend pas de la distribution des points dans les boites
seulement traversées mais sans point, mais seulement du nombre total de
points, et le nombre de boites à visiter est en O(log_6(N) où N est le
nombre total de noeuds, alors que le Quad-Tree ajoute des tas de points
artificiels au centre des boites traversées sans noeud et est seulement en
O(.log_4(N+k*S)) où S est le nombre total de segments et k une variable
liée à la distribution des longueurs de segments.

C'est pour ça que dans le cas totalement aléatoire (ton premier test), le
QuadTree s'écroule totalement : il crée beaucoup trop de sous-boites, et la
profondeur de l'arbre de recherche s'accroit énormément. Le R*Tree
produirait un nombre de boites bien plus réduit (à condition de le régler à
un taux de remplissage minimum de 50% arrondi à l'unité inférieure).

Il doit y avoir un problème dans ton logiciel insérant les points dans le
R*Tree, il n'est visiblement pas optimal comme il devrait.

De fait les R*trees obtenus sont très étranges (et ça se voit, la
répartition est visiblement n'importe comment et spatialement non
équilibrée, en tout cas beaucoup moins bien que celle obtenue par les
Quad-trees même si, eux, créent plein de boites finales vides et de boites
parentes n'a qu'une seule des 4 ayant un contenu, avec un taux de
remplissage situé en moyenne à peine au dessus de 25% contre plus de 50% en
moyenne pour les R*trees optimums).

Note: le seuil minimum des R*tree est réglable (tu l'as fait dans ta démo,
mais je me demande si c'est bien le cas au final, et si tu n'as pas omis de
lancer la procédure d'équilibrage (qu'on a intérêt à ne lancer qu'à la fin
des insertions et non pour chaque insertion une par une).


Le 5 février 2015 18:20, Léo Serre l...@lstronic.com a écrit :

  Bonjour à tous

 Après de longues recherches pour savoir qu'elle est l'indexation la plus
 efficace (simplicité de construction, rapidité pour trouver un élément,
 taille), tout le monde m'a dit R*-Tree.
 Mais après des essais, ma conclusion est que le quadtree est largement
 mieux. Je vous laisse un exemple en vidéo ci-dessous pour ceux que ça
 intéresse.


 http://www.dailymotion.com/video/x2ghtqj_r-tree-pour-des-donnees-geographiques_tech

 *Note : Le code pour convertir des LineString GeoJSON **en Segments CSV
 est disponible sur simple demande.*

 Léo

 --
 [image: LSTRONIC logo]

 Léo SERRE
 *LSTRONIC Founder*
 [image: mail]  l...@lstronic.com
 [image: website]  lstronic.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

[Talk-tr] OdaTV haberinde OSM var

2015-02-05 Diskussionsfäden Orkut Murat YILMAZ

Selamlar,

Ekşi Sözlük'te haritacılık ile ilgili yazdığım bir yorum, OdaTV'de
yayınlandı.

Elbette yorumumda OSM'den bahsetmeden geçmedim.

http://odatv.com/n.php?n=biji-serok-google-0502151200

Esenlikle:)

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

Re: [OSM-talk-fr] [OpenStreetMap] Re: Re: Gros problème de correction... Groupe de modifications : 28377712

Oh mon Dieu quelle agressivité de ma part ! J’ai mis 2 mots en majuscule et
j’ai dit « il faut absolument », Belzébut, sors de ce corps…

Je n’ai jamais utilisé ce tag ailleurs que dans les 7 communes de la CCPRO,
sauf erreur grossière de ma part et qui mérite sûrement un autoflagélation.
Pour info, il n’y a pas de SIG dans les communes de la CCPRO. Le SIG est
dans l’interco. Cette base n’est pas seulement utilisée par notre interco
puisque, vu qu’elle est intégrée à OSM, elle est utilisée par d’autres
partenaires.

Les relations que j’ai créées dans OSM sont issues du site
http://cadastre.openstreetmap.fr/ qui est très bien documenté ici :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_adresses
Je pense que tu confonds le gestionnaire de la voie qui peut, par exemple,
être identifié par le tag operator, et la commune où se trouve la voie. Et,
je regrette mais oui, dans une interco, quand une voie fait office de limite
de commune, elle n’est recensée que dans pour des 2 communes, afin d’éviter
les doublons. Et dans la vrai vie, les agents qui interviennent sur ce genre
de voie ne le font pas que d’un côté. C’est une des 2 communes qui en a la
charge. Après, pour la dénomination de la voie ça peut être différent, mais
c’est quand même rare je pense. Au pire, on pourra toujours mettre un :left
ou un :right si vraiment ça pose problème.

Tu n’auras pas de problème avec mon code puisque c’est la commune qui le
fournira. Donc, je ne vois pas où est le problème, sauf a en créer un là où
il n’y en a pas.

Alors moi te dire plus simple. Officiel Voies Orange être disponible en
ligne adresse suivante :
https://docs.google.com/spreadsheet/ccc?key=0AvqnfztqzzrOdE16YWpINmdfVm9MaERNWWdqQ09jMHc#gid=0
identifiant expliqué page 1
licence d’utilisation page 2
base de données voirie page 3, identifiant colonne 4
Tu peux même cliquer sur les liens « localiser », tu verras, c’est magique !
mais c’est perfectible…

Vu que je travaille dans cette collectivité (et oui, je ne suis pas une
boîte privé à la solde de Véolia) et que c’est moi qui ai mis en place ce
projet dans ma collectivité, je te donne l’autorisation de la réutiliser
(bon seigneur que je suis).

Je ne sais que dire de plus….

-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien chef de projets
--
View this message in context:
http://gis.19327.n5.nabble.com/Re-OpenStreetMap-Re-Re-Gros-probleme-de-correction-Groupe-de-modifications-28377712-tp5832528p5832632.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Gros problème de correction... Groupe de modifications : 28377712

Tony, en ne citant pas du tout les messages auxquels tu réponds on a du
mal à comprendre à qui tu répond (surtout quand on filtre certains
messages).

Retour sur les ref:xxx...

On a déjà eu des discussions à propos des ref:xxx pour maintenir un lien
avec une base privée. La conclusion si je me rappelle bien était que
seuls les ref:xxx vers des nomenclatures publiques avaient leur place
dans OSM. C'est préférable pour éviter une multiplication des liens avec
des données privées, liens qui ne servirait qu'à leur auteurs et à
personne d'autre.

Dans le cas présent, c'est pas vraiment privé, mais pas très public non
plus... et comme toujours les zones grises sont là où vivent les trolls ;)

Je rejoindrais la solution proposée par Pieren à savoir utiliser
ref:FR:FANTOIR là où la DGFiP a attribué un code FANTOIR et à défaut
utiliser un ref:FR:commune là où il n'y a pas de FANTOIR.
C'est étonnant qu'il y en ait autant d'ailleurs, ce ne sont que des
nouvelles voies ?


Pour les dégâts collatéraux sur les limites admin, il faudrait peut être
ajouter dans le process de travail un contrôle systématique avec JOSM
(ou autre) pour s'assurer que rien n'est cassé de ce côté car c'est
quand même gênant vu le nombre d'outils qui en dépendent.


Pour les suppressions des ref:FR:commune sans contact préalable, c'est
une façon très peu respectueuse des autres contributeurs que de procéder
ainsi. Nous avons quand même des outils simples pour accéder à
l'historique des objets et les moyens d'entrer en contact avec un
contributeur avant de supprimer telle ou telle info de façon unilatérale.


Pour le reste, soyons zen...

-- 
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Index R*-Tree pour système embarqué

Pour une donnée en 2D, le quad tree est en effet plus adapté à ce qu'il
me semble...


Le 05/02/2015 18:20, Léo Serre a écrit :
 Bonjour à tous

 Après de longues recherches pour savoir qu'elle est l'indexation la
 plus efficace (simplicité de construction, rapidité pour trouver un
 élément, taille), tout le monde m'a dit R*-Tree.
 Mais après des essais, ma conclusion est que le quadtree est largement
 mieux. Je vous laisse un exemple en vidéo ci-dessous pour ceux que ça
 intéresse.

 http://www.dailymotion.com/video/x2ghtqj_r-tree-pour-des-donnees-geographiques_tech

 /_Note :_ Le code pour convertir des LineString GeoJSON //en Segments
 CSV est disponible sur simple demande./

 Léo

 -- 
 LSTRONIC logo

 Léo SERRE
 /LSTRONIC Founder/
 mail  l...@lstronic.com mailto:l...@lstronic.com
 website  lstronic.com http://lstronic.com



 ___
 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: [Talk-it] parti di edifici e numeri civici