Re: [OSM-talk-fr] Alternatives à Mapillary

[Tyndare]

Le 03/07/2020 à 16:52, Yves P. a écrit :
Est-ce que c'est possible de le mettre en ligne pour effectuer quelques 
tests sans devoir tout installer ?


Je n'ai pas de serveur pour mettre en ligne.


A terme, peut-on se partager nos réseaux entrainés ?

>
A un moment donné on partage nos réseaux et on les fusionne dans le but 
d'améliorer la fiabilité de la détection.

Est-ce envisageable ?


De mon côté je n'ai rien entrainé du tout, j'ai juste utilisé le réseau 
déjà entrainé que j'ai mentionné. Je crois qu'il a été entraîné sur le 
jeu de détection d'objets COCO dont tu parlais.


Je ne maîtrise pas suffisamment le sujet pour savoir comment fusionner 
des réseaux mais si c'est possible ça semble une bonne idée.


J'imagine que Mapillary doit intégrer à sa base d’apprentissage des cas 
que les contributeurs ont reflouté manuellement avec l'interface sur 
leur site (Edit Privacy Blur) afin d'améliorer leur détection.



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

Re: [OSM-talk-fr] Alternatives à Mapillary

[Tyndare]

Le 29/06/2020 à 23:45, Frédéric Rodrigo a écrit :
> Je n'ai pas fait le floutage, ou la séparation des classes, juste la
> détection. Je suis toujours preneur si tu as quelque chose.

Je viens de mettre mon script sur github:
https://github.com/tyndare/blur-persons


> Cerise sur le gâteau ce n'est même pas si lent que ça même sans GPU...

Le modèle travaille sur des image de 512x512, donc je répète la 
détection autant de fois que nécessaire sur l'image source, du coup 
c'est très lent chez moi (j'ai pas réussi à refaire marche tensorflow 
sur le GPU de mon portable).




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

Re: [OSM-talk-fr] Alternatives à Mapillary

[Tyndare]

Le June 28, 2020 8:14:03 PM UTC, "Frédéric Rodrigo"  a 
écrit :
>Le 22/06/2020 à 22:59, Tyndare a écrit :
>>https://averdones.github.io/real-time-semantic-image-segmentation-with-deeplab-in-tensorflow/
>
>Tu as un script/outil prêt à l’emploi pour faire ça ?

J'ai un script python pour flouter les personnes en téléchargeant et lançant le 
réseau que j'ai mentionné mais il faut que je le nettoie (il est codé en dur 
pour la taille de mes photos).
J'essaye de le partager ce soir.



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

Re: [OSM-talk-fr] Alternatives à Mapillary

[Tyndare]

Le 22/06/2020 à 10:29, Stéphane Péneau a écrit :

Dans tous ces cas, il manque au moins le floutage, le nerf de la guerre


Ce qu'il faut c'est une bonne base d'exemples pour entraîner un algo 
d’apprentissage.
Aurais-t-on le droit de récupérer à là fois la version d'origine et la 
version floutée de nos images envoyé sur Mapillary pour pouvoir s'en 
servir pour entraîner un algo ?



Perso je trouve que flouter le visage n'est pas suffisant pour le 
respect de la vie privée, Facebook se vente d'être capable de 
reconnaître les gens à leur démarche, même de dos.


J'ai testé le modèle préentrainé suivant pour flouter les personnes en 
entier des images que j'envoie sur Mapillary et je trouve que ça marche 
assez bien même si ce n'est pas parfait:


https://averdones.github.io/real-time-semantic-image-segmentation-with-deeplab-in-tensorflow/


https://www.mapillary.com/map/im/kuSWiUlfKHrqJ_7lHgn4Ug





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

Re: [OSM-talk-fr] Tickets Restaurants et StreetComplete

[Tyndare]

Le 11/06/2020 à 21:31, Florian_G a écrit :

  * si on ne sait pas précisément :
  o payment:meal_voucher=yes
  * si on sait :
  o payment:meal_voucher:ticket_restaurant=yes
  o payment:meal_voucher:apetiz=yes
  o payment:meal_voucher:chèque_déjeuner=yes
  o payment:meal_voucher:pass_restaurant=yes


Je ne vois pas d'exemple comme ça dans le Wiki pour le tag payment mais 
ça me plairait bien cette façon de hiérarchiser.


Il faudrait quand même pouvoir distinguer pour les opérateurs qui 
supporte les deux la version ticket papier de celle avec carte de 
paiement, sur le même principe ça pourrait donner:


si l'on ne sait pas:
payment:meal_voucher:cheque_dejeuner=yes

si l'on sait:
payment:meal_voucher:cheque_dejeuner:ticket=yes
payment:meal_voucher:cheque_dejeuner:card=yes


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

Re: [OSM-talk-fr] Tickets Restaurants et StreetComplete

[Tyndare]

Le tag payment:edenred_voucher est problématique car il regroupe des
tickets différents qui ne rentrent pas tous dans la catégorie
payment:meal_voucher.

L'idéal serait d'avoir des tags payment:* hiérarchiques, comme on a pour
le tag access mais je sais pas si c'est possible.
https://wiki.openstreetmap.org/wiki/FR:Key:access

Par exemple on peut avoir un élément tagué avec
access=no
foot=yes

"access" est générique, "foot" est plus spécifique et donc il prend le
dessus, et on sait que l'accès est autorisé pour les piétons.

Par contre si on a un élément tagué avec:
payment:meal_voucher=no
payment:edenred_voucher=yes

Un edenred_voucher n'est pas forcément un meal_voucher et inversement,
il n'y a pas de hiérarchie possible entre les deux tags, difficile de
savoir lequel a raison, est-ce qu'un paiement par Ticket Restaurant
Edenred serait possible dans ce cas ?

Si on utilise plutôt payment:ticket_restaurant_voucher en France, ce tag
peut être définit comme une sous catégorie de payment:meal_voucher, et
les tags suivants sont alors non ambigus:
payment:meal_voucher=no
payment:ticket_restaurant_voucher=yes

Ici le tag payment:ticket_restaurant_voucher prend le dessus.


Le 11/06/2020 à 15:33, Yves P. a écrit :

Quelle différence entre payment:edenred_voucher et
payment:ticket_restaurant_voucher puisque les tickets restaurant sont
émis par edenred ?


payment:ticket_restaurant_voucher n'est valable qu'en France.

payment:edenred_voucher est peut-être valable en France mais pour des bons 
"cadeaux" dans des enseignes…
ou alors c'est utilisable uniquement en Hongrie ?


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

Re: [OSM-talk-fr] Tickets Restaurants et StreetComplete

[Tyndare]

Le 10/06/2020 à 23:20, Yves P. a écrit :

   payment:edenred_voucher
   payment:edenred_card
mais ils sont plus générique et englobe les cartes cadeaux d'Edenred, 
ça peut être ambigu pour un supermarché qui pourrait accepter l'une 
mais pas l'autre.

Est-ce que c'est utilisable en France ?


Ces tags sont définis sur le wiki Anglais comme s’appliquants à la 
Hongrie, mais vu leur nom c'est difficile de ne pas considérer qu'il 
pourrait aussi correspondre aux tickets ou cartes Edenred françaises 
(Ticket  Restaurant, Kadéos, …).



Ou chez nous c'est uniquement payment:ticket_restaurant_voucher et _card ?


Je crois que je préférerais ça, afin de garder une hiéarchie simple 
(sans héritage multiple), où payment:ticket_restaurant_voucher est une 
sous catégorie de payment:meal_voucher uniquement, pas de 
payment:edenred_voucher.









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

Re: [OSM-talk-fr] Tickets Restaurants et StreetComplete

[Tyndare]

J'ai changé d'avis,

TL;DR: Je sui OK avec la proposition de Guy de rajouter le support de 
payment:meal_voucher dans StreetComplete, mais si on change un peu la 
définition qu'on associe à ce tag en France:

payment:meal_voucher = yes
pourrait signifier en France que le commerçant a reçu l'agrément de la 
CNTR pour accepter les tickets restaurant, mais sans présumer de la 
liste exacte des opérateurs et des moyens de paiements qu'il accepte.


Détail:

D'après cette page

https://www.companeo.com/titre-restaurant/FAQ/affiliation-tickets-restaurant-comment-faire

chaque commerçant est libre de choisir les opérateurs de titres 
restaurant qu'il souhaite accepter ou non, il n'y a aucune obligation de 
tous les accepter, ce qui me parait logique étant donné qu'ils ont tous 
des frais différents, que les commissions peuvent dépendre du volume, et 
que certains (les plus gros) nécessitent un abonnement.


Cette page explique un peu mieux la différence entre les cartes qui sont 
CONECS ou non:

https://www.entrepreneurhero.fr/terminal-de-paiement/ticket-restaurant/

En gros le logiciels CONECS (des 4 gros historiques) permet de ne pas 
passer par le réseau bancaire classique et donc évite au commerçant 
d'avoir a payer la commission carte bancaire (comme MasterCard) en plus 
de la commission de l'opérateur des titres restaurant.


Donc ça me semble nécessaire de pouvoir détailler chaque opérateur et 
moyen de paiement, au cas ou certains ne seraient pas acceptés.


On a déjà dans le Wiki anglais
payment:edenred_voucher
payment:edenred_card
mais ils sont plus générique et englobe les cartes cadeaux d'Edenred, ça 
peut être ambigu pour un supermarché qui pourrait accepter l'une mais 
pas l'autre.


On pourrait rajouter dans le wiki français:

Pour Apetiz http://www.apetiz.com/
payment:apetiz_voucher
payment:apetiz_card

Pour Up Déjeuner (ex Chèque Déjeuner), https://updejeuner.fr/
payment:up_dejeuner_voucher
payment:up_dejeuner_card

Pour Swile (ex Lunchr) https://www.swile.co/
payment:swile_card

Pour Pass Restaurant (Sodexo) https://www.sodexo.fr/commercants/
payment:pass_restaurant_voucher
payment:pass_restaurant_card

Pour Restoflash https://www.restoflash.fr/ , ils n'ont pas leur propre 
carte je n'ai pas compris comment ça marche exactement

payment:restoflash

Pour Ticket Restaurant (Edenred) https://www.edenred.fr/ticket-restaurant
payment:ticket_restaurant_voucher
payment:ticket_restaurant_card

Pour Wedoofood https://wedoofood.com/
payment:wedoofood_card

Et pour savoir si un commerçant supporte les cartes CONECS (ça devient 
un détail technique si on détail chaque opérateur mais à mon avis ça 
fait quand sens de pouvoir le préciser)

payment:conecs_card


Le 09/06/2020 à 18:36, Tyndare a écrit :



Je pense qu'il est nécessaire de faire la distinction entre ticket 
papier et titre dématérialisé, même  dans Street Complete, quitte à ce 
qu'il ne complète que les titres papiers pour l'instant.


Sur le Wiki en anglais ( https://wiki.openstreetmap.org/wiki/Key:payment 
) on trouve:


payment:edenred_voucher
payment:edenred_card

En France si c'est la CNTR qui centralise le paiement des tickets 
papiers, et qu'un commerçant doivent effectivement tous les accepter 
(j'ai un petit doute), on pourrait alors utiliser comme proposé 
payment:meal_voucher mais considérer qu'il ne s'applique qu'au papier, 
ou alors rajouter un tag  genre payment:cntr_voucher.


Pour les titres dématérialisés, d'après cette page ( 
https://www.conecs.fr/prerequis-a-lacceptation-des-trd/ )
il y aurait un logo "conecs" sur les cartes compatibles avec le 
logiciels conecs pour terminal de paiement.


Donc on pourrait imaginer un tag
payment:conecs_card correspondant à toutes les cartes pour titres 
restaurant dématérialisé en France compatible avec le logiciel Conecs 
(je pense qu'il y a les plus gros)


Pour le sans contact le wiki utilise soit payment:contactless générique, 
soit le suffix _contactless ce qui donnerait 
payment:conecs_card_contactless


Qu'est-ce que vous en pensez ?


Le 09/06/2020 à 13:23, osm.sanspourr...@spamgourmet.com a écrit :

Je dirais comme Guy *actuellement* mais si on regarde l'évolution des
chèques (dont le principe est similaire sauf que le risque d'impayé est
plus élevé), on voit de plus en plus de magasins refuser les chèques. Il
est possible, et c'est le but du cartel, qu'à terme ils éliminent les
tickets (gestion dématérialisée mais frais identiques).

Si c'est pour simplifier une quête  StreetComplete ça semble
raisonnable, si c'est pour changer le modèle de tags je suis plus 
réservé.


Doit-on profiter pour demander en plus si le terminal accepte le sans
contact ?

Jean-Yvon

Le 09/06/2020 à 11:09, Guy Godfroy - guy.godf...@gugod.fr a écrit :

Honnêtement je crois que j'ai jamais vu de gens qui acceptaient la carte
mais pas le papier.

D'autre part il me semble (mais je peux me tromper) que seul EdenRed
émet des cartes à

Re: [OSM-talk-fr] Tickets Restaurants et StreetComplete

[Tyndare]

Je pense qu'il est nécessaire de faire la distinction entre ticket 
papier et titre dématérialisé, même  dans Street Complete, quitte à ce 
qu'il ne complète que les titres papiers pour l'instant.


Sur le Wiki en anglais ( https://wiki.openstreetmap.org/wiki/Key:payment 
) on trouve:


payment:edenred_voucher
payment:edenred_card

En France si c'est la CNTR qui centralise le paiement des tickets 
papiers, et qu'un commerçant doivent effectivement tous les accepter 
(j'ai un petit doute), on pourrait alors utiliser comme proposé 
payment:meal_voucher mais considérer qu'il ne s'applique qu'au papier, 
ou alors rajouter un tag  genre payment:cntr_voucher.


Pour les titres dématérialisés, d'après cette page ( 
https://www.conecs.fr/prerequis-a-lacceptation-des-trd/ )
il y aurait un logo "conecs" sur les cartes compatibles avec le 
logiciels conecs pour terminal de paiement.


Donc on pourrait imaginer un tag
payment:conecs_card correspondant à toutes les cartes pour titres 
restaurant dématérialisé en France compatible avec le logiciel Conecs 
(je pense qu'il y a les plus gros)


Pour le sans contact le wiki utilise soit payment:contactless générique, 
soit le suffix _contactless ce qui donnerait payment:conecs_card_contactless


Qu'est-ce que vous en pensez ?


Le 09/06/2020 à 13:23, osm.sanspourr...@spamgourmet.com a écrit :

Je dirais comme Guy *actuellement* mais si on regarde l'évolution des
chèques (dont le principe est similaire sauf que le risque d'impayé est
plus élevé), on voit de plus en plus de magasins refuser les chèques. Il
est possible, et c'est le but du cartel, qu'à terme ils éliminent les
tickets (gestion dématérialisée mais frais identiques).

Si c'est pour simplifier une quête  StreetComplete ça semble
raisonnable, si c'est pour changer le modèle de tags je suis plus réservé.

Doit-on profiter pour demander en plus si le terminal accepte le sans
contact ?

Jean-Yvon

Le 09/06/2020 à 11:09, Guy Godfroy - guy.godf...@gugod.fr a écrit :

Honnêtement je crois que j'ai jamais vu de gens qui acceptaient la carte
mais pas le papier.

D'autre part il me semble (mais je peux me tromper) que seul EdenRed
émet des cartes à puce pour titre restaurant, et s'appuie sur le réseau
MasterCard pour ça, de sorte que si un commerce est habilité à recevoir
des titres restaurant et possède un terminal compatible mastercard, il
me semble que ça passera forcément.

À noter que si effectivement seul EdenRed emet des cartes à titre
restaurant, ces cartes peuvent toutes faire des paiement sans contact.

Le 09/06/2020 à 10:51, Marc M. a écrit :

Bonjour,

Le 09.06.20 à 10:41, Guy Godfroy a écrit :

pour l'instant il suffit de répondre oui ou non à la question
"Est-ce que ce restaurant accepte les titres restaurants".
Est-ce qu'on est d'accord là dessus ?

Pour la France oui, avec le soucis papier<>électronique.
est-ce que tout ceux qui accepte l'electronique accepte
aussi obligatoirement le papier ?

Cordialement,
Marc

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


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



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


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

Re: [OSM-talk-fr] Tickets Restaurants et StreetComplete

[Tyndare]

L'ajout de payment:cb dans le Wiki me parait une bonne idée.


Le 09/06/2020 à 15:49, Yves P. a écrit :


À ce propos, j'ai toujours pas compris sur le wiki quel était le tag 
pour décrire le paiement avec une carte bancaire classique en France: 
la carte CB ?

https://fr.wikipedia.org/wiki/Groupement_des_cartes_bancaires_CB
En lisant bien le texte, il y a bien des cartes C. Elles sont aussi 
souvent des cartes VISA ou Mastercard.


En devrait donc avoir dans le wiki la clé payment:cb.
On en trouve quelques unes dans TagInfo 



__
Yves

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



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

Re: [OSM-talk-fr] Tickets Restaurants et StreetComplete

[Tyndare]

À ce propos, j'ai toujours pas compris sur le wiki quel était le tag 
pour décrire le paiement avec une carte bancaire classique en France: la 
carte CB ?

https://fr.wikipedia.org/wiki/Groupement_des_cartes_bancaires_CB

Le 09/06/2020 à 14:48, Yves P. a écrit :

Doit-on profiter pour demander en plus si le terminal accepte le sans
contact ?

On demande tout ce qu'on peut concernant les moyens de paiement :)
Comme ça il n'y a plus à revenir.

__
Yves

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



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

Re: [OSM-talk-fr] Tickets Restaurants et StreetComplete

[Tyndare]

Les opérateurs ont beau avoir essayé de faire un cartel 
(https://www.capital.fr/entreprises-marches/sodexo-edenred-4-emetteurs-de-titres-restaurant-ecopent-dune-amende-pour-entente-1358008) 
ça reste des concurrents qui ont en théorie des conditions différentes, 
et j'ai plutôt constaté que c'était au bon vouloir des restaurateurs 
d'accepter ou non.
Un resto peut accepter les tickets papier le midi mais pas le soir alors 
que les cartes sont acceptées le soir, un autre que les tickets papier 
car il a pas installé le logiciel pour payer par carte (titre 
dématérialisé) un autre que la carte car il veut plus s’embêter avec les 
papiers.
Et les logiciels pour terminaux de paiement par carte ça m'as pas l'air 
si simple non plus, il y avait effectivement une annonce Mastercard 
sensé marcher avec EdenRed, sinon il y a le logiciel CONECS qui est 
sensé être commun, certains opérateurs ont un partenariat avec Google 
Pay. Une cafétéria opérée par SODEXO accepte volontiers les cartes 
SODEXO mais leur terminaux de paiement refuse les transactions avec les 
cartes concurrentes.



Le 09/06/2020 à 11:09, Guy Godfroy a écrit :

Honnêtement je crois que j'ai jamais vu de gens qui acceptaient la carte
mais pas le papier.

D'autre part il me semble (mais je peux me tromper) que seul EdenRed
émet des cartes à puce pour titre restaurant, et s'appuie sur le réseau
MasterCard pour ça, de sorte que si un commerce est habilité à recevoir
des titres restaurant et possède un terminal compatible mastercard, il
me semble que ça passera forcément.

À noter que si effectivement seul EdenRed emet des cartes à titre
restaurant, ces cartes peuvent toutes faire des paiement sans contact.

Le 09/06/2020 à 10:51, Marc M. a écrit :

Bonjour,

Le 09.06.20 à 10:41, Guy Godfroy a écrit :

pour l'instant il suffit de répondre oui ou non à la question
"Est-ce que ce restaurant accepte les titres restaurants".
Est-ce qu'on est d'accord là dessus ?


Pour la France oui, avec le soucis papier<>électronique.
est-ce que tout ceux qui accepte l'electronique accepte
aussi obligatoirement le papier ?

Cordialement,
Marc

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



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



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

Re: [OSM-talk-fr] Problème sur l'outil cadastre

[Tyndare]

Gautier Pelloux-Prayer a trouvé le problème et la correction: il fallait 
passer en https.

Un grand merci à lui !

Le 29/06/2017 à 17:54, Baptiste Mille-Mathias a écrit :

Ca ne serait pas lié au disque plein sur une des machine
https://munin.openstreetmap.fr/osm28.openstreetmap.fr/osm210.openstreetmap.fr/df.html
?

Le jeu. 29 juin 2017 à 02:43, Tyndare <tynd...@wanadoo.fr
<mailto:tynd...@wanadoo.fr>> a écrit :

Le 28/06/2017 à 14:31, Antoine Riche a écrit :
 > J'ai peut-être raté une info, mais l'outil
 > http://cadastre.openstreetmap.fr/ ne fonctionne plus. La génération
 > du  bâti produit les erreurs suivantes, cela suggère un problème dans
 > la génération des PDFs :
 >
 > Teléchargement des PDFs de la commune IL143 : REZE (44400)
 > Découpe la bbox en 6 * 4 [24 pdfs]
 > terminate called after throwing an instance of 'PoDoFo::PdfError'
 >what():  ePdfError_NoPdfFile
 > IL143-0-0.pdf

Effectivement, les pdf téléchargés contiennent seulement le message:

 Un problème de sécurité est survenu. Nous ne pouvons
 satisfaire à votre requête.

Il a du y avoir des changements sur le site cadastre.gouv.fr
<http://cadastre.gouv.fr>,
je n'ai pas trop le temps pour l'instant de regarder ça.



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

Re: [OSM-talk-fr] Problème sur l'outil cadastre

[Tyndare]

Le 28/06/2017 à 14:31, Antoine Riche a écrit :
> J'ai peut-être raté une info, mais l'outil
> http://cadastre.openstreetmap.fr/ ne fonctionne plus. La génération
> du  bâti produit les erreurs suivantes, cela suggère un problème dans
> la génération des PDFs :
>
> Teléchargement des PDFs de la commune IL143 : REZE (44400)
> Découpe la bbox en 6 * 4 [24 pdfs]
> terminate called after throwing an instance of 'PoDoFo::PdfError'
>what():  ePdfError_NoPdfFile
> IL143-0-0.pdf

Effectivement, les pdf téléchargés contiennent seulement le message:

Un problème de sécurité est survenu. Nous ne pouvons
satisfaire à votre requête.

Il a du y avoir des changements sur le site cadastre.gouv.fr,
je n'ai pas trop le temps pour l'instant de regarder ça.

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

Re: [OSM-talk-fr] Ajout de ruisseau à partir des berges

[Tyndare]

Bonjour,

Le 10/04/2017 à 13:11, GarenKreiz a écrit :

Bonjour,

Pour faciliter la correction des signalements Osmose (1220 "Riverbank
without river"), j'ai écrit un petit script interactif Python qui
facilite la création d'un chemin de type Waterway à partir d'un
polygone de type Riverbank (algo simpliste sans squelettisation
d'image ni calcul de diagramme de Voronoi) puis son chargement sur
OSM.

Beaucoup des polygones de type Riverbank sont des importations du
cadastre, faut-il dans ce cas appliquer le même champ Source au chemin
généré?


La création du waterway semble automatisée, donc oui je pense que tu 
peux garder le tag source, ou une version modifiée qui précise que c'est 
dérivé depuis cette source.


Est-ce que ton script serait applicable de manière automatique aux 
fichier .osm exportés depuis le cadastre ?


- Tynadre

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

[OSM-talk-fr] Mise à jour bâti cadastre et plugin conflation

[Tyndare]

Bonjour,

J'ai voulu tester l'utilisation du plugin Conflation pour mettre à jour 
le bâti d'une ville depuis le cadastre avec JOSM.


J'ai décrit mon approche ici:

https://www.youtube.com/watch?v=8n34tYJXnEI
http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents#Utilisation_du_plugin_.C2.ABConflation.C2.BB_dans_JOSM

Avant d'essayer faites en sorte d'utiliser la toute dernière version de 
JOSM et de mettre à jour les plugins (pour conflation),


Au passage un grand merci à Vincent Privat pour tout son travail sur 
l'éditeur JOSM !


Tyndare.

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

Re: [OSM-talk-fr] [DGW] Contribution entreprise aux données OSM

[Tyndare]

Le 13 janvier 2017 12:00:51 GMT+01:00, Nicolas Moyroud  a 
écrit :
>
>> En milieu urbain, ce point d'accès sera souvent sur le bâtiment 
>> lui-même mais il suffit que le(s) bâtiment(s) soit en retrait de la 
>> voirie, le point d'accès et donc l'adresse seront alors indépendants 
>> du (des) bâtiment(s).
>Mais qui a dit que le numéro d'adresse devait être placé sur le point 
>d'accès ? On ne travaille pas exclusivement pour les usages des
>postiers 
>que je sache !
>Si tu mets un numéro d'adresse sur un noeud flottant qui n'est
>raccroché 
>à rien d'autre, il faudrait à minima le mettre dans une relation qui 
>contient également le ou les bâtiments concernés. Sinon impossible de 
>savoir à quoi se rapporte ton numéro d'adresse et il ne sert plus qu'à 
>une seule chose : savoir où se trouve le portail ou la boîte aux 
>lettres. Ce qui à mon sens n'est pas l'intérêt principal d'un numéro 
>d'adresse dans OSM, mais le seul intérêt de la poste...

A titre perso, ce que j'attends d'une adresse c'est que mon GPS soit capable de 
m'y amener. En l'indiquant systématiquement sur les bâtiments il y a énormément 
de cas où les logiciels de routage vont essayer d'y arriver par le mauvais 
côte, et donc être bien pire que l'absence de numéro d'adresse qui nous 
amènerait au moins dans la bonne rue.

L'adresse, pour qu'elle soit utile, doit être cohérente avec les autres 
éléments cartographiés pour permettre le routage. 

Les logiciels de routage évitent les passages privés, donc ça me paraît logique 
l'indiquer l'adresse  sur la frontière de la zone privée adressée.


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

Re: [OSM-talk-fr] [DGW] Contribution entreprise aux données OSM

[Tyndare]

Le 11/01/2017 à 16:09, Jean-Martial NDOUTOUME NFENGONE - ZIT.COM a écrit :

Au quotidien, nous remarquons que le terrain bouge plus vite que la
base SIRENE (changement de propriétaire, fermeture, modification
de l'enseigne sous un même propriétaire etc.).


D'après les annonces, la base SIRENE devrais s’améliorer en terme de
réactivité.


Ce que je veux dire par là c'est qu'une même activité commerçante (sur nos 
relevés terrains) peut se faire sous différents codes d'activités officielles 
(administrativement, sur les papiers, dans la base SIRENE).  Par exemple, un 
dépanneur de PC peut, officiellement être dans le négoce de composants 
informatiques ou dans le développement logiciel.

De même, un même établissement peut changer d'activité (sur nos relevé 
terrains) sans pour autant être modifié dans la base SIRENE.  c'est le cas d'un 
magasin de fringues qui devient un magasin de chaussure, mais qui reste le même 
commerçant.


Pour les marchés qui ne sont pas en dur, le seul tag que je connaisse
est http://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dmarketplace
mais en général il n'y a pas de détails de chacun des exposants.
Après, si c'est expliqué en commentaires, que les heures d'ouvertures
sont renseignées, il y a tout de même une assez grande tolérance de
la
communauté. En pratique peu de personnes ont la capacité d'aller
vérifier sur le terrain.


Justement, c'est ce que nous souhaitons mettre à profit: nous et nos confrères 
arpentons le terrain tous les jours (les rues et leurs commerces, les salles 
d'attentes des professions libérales, les établissements universitaires, etc.)

Pour nos propres besoins, nous tenons à jour une base de données.

Notre souhait est de pouvoir rendre à la communauté OSM ce que nous en tirons 
en matière cartographique.


C'est une approche qu'on ne peut qu'apprécier :-)

Pour rendre à la communauté, la solution minimaliste c'est de simplement 
diffuser vos données sous licence compatible ODbL. Mais ça sera sans 
garantie qu'elles soient vraiment réutilisées.
(Une intégration dans un outil comme Osmose peut aider: 
http://osmose.openstreetmap.fr/#item=8210%2C82115)


La solution plus ambitieuse et plus sûre c'est de contribuer vous même 
directement à OSM. Cela requiert tout de même  des précautions si vous 
voulez automatiser le processus.




Bon, le cas spécifique des marchés est... un cas spécifique. :)


À ce jour, nous qualifions les commerçants (Ambassadeurs de la
culture) en nous appuyant sur des référentiels comme la
base permanente des équipements (BPE) de l'INSEE, notamment pour la
typologie de l'équipement (usage fait du bâti)
.

Nous affinons également nos informations avec la typologie de
commerce, et tout particulièrement la définition des commerces de
proximité (nous travaillons sur l'économie locale)
.

Enfin, pour nos besoins propres (diffuser la bonne communication
culturelle au bon public) nous qualifions le commerçant avec:
- ses centres d'intérêts culturels déclarés,
- les centres d'intérêts culturels de ses clients.

Ces informations pourraient-elles être utiles au projet OSM?


Vu de l'extérieur, ça me parait assez subjectif comme information.
S'il n'y a pas un lien directe avec le type d'activité du commerce je ne
suis pas sur qu'on trouve une traduction dans la sémantique actuelle
d'OSM.


Les référentiels INSEE, ce n'est pas nous qui les définissons.  Nous faisons 
juste en sorte de nous y référer pour ne pas réinventer la roue et nous 
conformer à un «standard» et une «sémantique» au niveau national.

Les centres d'intérêts de l'établissement sont déclaratifs.  Avec nos 
commerçants, nous signons une charte dans laquelle ils nous disent ce qu'ils 
veulent recevoir comme communication culturelle, selon leurs propres centre 
d'intérêts.  Par exemple, tel tatoueur déclare explicitement qu'il veut 
accueillir des affiches de danse classique (si si, nous avons ça!), ou encore 
telle boulangerie n'a pas de centre d'intérêt précis (et nous y diffusons de 
tout).

Les centres d'intérêts des clients de nos Ambassadeurs sont eux aussi 
déclaratifs: nous tissons une relation avec Micheline qui cotoie le fournil du 
Croissant et qui préfère, par ce biais, recevoir des communications culturelles 
sur les programmes des médiathèques par exemple.

C'est assez objectif, non?


Oui pour tout ce qui est référentiel INSEE, mais il faudra tout de même 
trouver une traduction dans un tag OSM (comme «shop») reconnu en dehors 
de la France, je ne sais pas si ce travail de correspondance a déjà été 
fait.


Pour les «centres d'intérêts déclarés», je ne sais pas si ce genre 
d'information a déjà été cartographié dans OSM, c'est quand même très 
spécifique comme donnée, et peut être pas si facilement vérifiable par 
d'autres contributeurs.
Si vous voulez faire «accepter» à l'international un nouveau tag pour 
cartographier ce type d'info voici un guide 

Re: [OSM-talk-fr] [DGW] Contribution entreprise aux données OSM

[Tyndare]

Le 11/01/2017 à 11:52, Jean-Martial NDOUTOUME NFENGONE - ZIT.COM a écrit :

Au quotidien, nous remarquons que le terrain bouge plus vite que la base SIRENE 
(changement de propriétaire, fermeture, modification de l'enseigne sous un même 
propriétaire etc.).


D'après les annonces, la base SIRENE devrais s’améliorer en terme de 
réactivité.





- disposent d'une stabilité géographique dans le temps : les
commerces ambulants ont moins leur place, même si ça fait débat


Nous considérons aussi les commerçants des marchés, qui ont une stabilité 
géographique dans le temps.

Comment est-ce géré dans OSM?  (Finalement, hormis son usage au quotidien, je 
connais peu le fonctionnement communautaire du projet...)


Pour les marchés qui ne sont pas en dur, le seul tag que je connaisse 
est http://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dmarketplace

mais en général il n'y a pas de détails de chacun des exposants.
Après, si c'est expliqué en commentaires, que les heures d'ouvertures 
sont renseignées, il y a tout de même une assez grande tolérance de la 
communauté. En pratique peu de personnes ont la capacité d'aller 
vérifier sur le terrain.


>

- ne contiennent pas d'informations nominatives (nom du gérant, etc)


OK.


- trouvent leur place d'un point de vue sémantique, notamment par
rapport à ce que propose cette page :
http://wiki.openstreetmap.org/wiki/Key:shop


À ce jour, nous qualifions les commerçants (Ambassadeurs de la culture) en nous 
appuyant sur des référentiels comme la
base permanente des équipements (BPE) de l'INSEE, notamment pour la typologie de 
l'équipement (usage fait du bâti) 
.

Nous affinons également nos informations avec la typologie de commerce, et tout 
particulièrement la définition des commerces de proximité (nous travaillons sur 
l'économie locale) .

Enfin, pour nos besoins propres (diffuser la bonne communication culturelle au 
bon public) nous qualifions le commerçant avec:
- ses centres d'intérêts culturels déclarés,
- les centres d'intérêts culturels de ses clients.

Ces informations pourraient-elles être utiles au projet OSM?


Vu de l'extérieur, ça me parait assez subjectif comme information. S'il 
n'y a pas un lien directe avec le type d'activité du commerce je ne suis 
pas sur qu'on trouve une traduction dans la sémantique actuelle d'OSM.





- et bien sûr sont issues de sources dont le copyright est compatible
avec l'ODbL. S'il s'agit de vos propres relevés de terrain c'est a
priori sans souci.


OK pour la licence.


On parle donc d'un sous-ensemble de vos relevés (enfin, j'imagine).


C'est bien ça.


Se posera potentiellement pour vous la question de l'articulation
des données injectées dans OSM avec le reste de vos données. Le
"pont" entre les deux environnement devrait éviter de se faire via
un identifiant qui vous est propre et qui serait inclus côté OSM. Il
faut privilégier une gestion de votre côté de cette correspondance,
ou bien le recours à des mécanismes sans ID propriétaire :
combinaison de la reconnaissance du nom, de la raison sociale, du
positionnement spatial, d'un SIREN, que sais-je.


Si je comprend bien, il est préférable que les identifiants des objets que nous 
allons mettre à jour dans et avec notre système soit ceux d'OSM (en l'occurrence Odoo 
et son module geospatial intégrant OSM 
).


Je ne connais pas vraiment Odoo, mais en regardant rapidement la page du 
module géospatial, il semble s'agir de permettre d'afficher des éléments 
géographiques au dessus d'un fond de carte comme celui d'OpenStreetMap, 
mais sans lien avec la base OSM !


Donc à moins que vous ne les ajoutiez volontairement, il n'y aura par 
défaut pas de correspondance avec des éléments OSM.




Pourquoi faudrait-il alors une correspondance?


Une correspondance avec une clef externe, tel que le n° de SIRET est 
préférable pour 2 raisons:

1) pérennité du lien
2) indépendance vis à vis de la licence de la base OSM.

1) Un identifiant OSM référence un élément qui peut être supprimé par 
n'importe quel contributeur, par exemple si il décide de ne plus mettre 
les informations du commerce sur un simple Point, mais plutôt sur le 
Polygone du bâtiment hébergeant le commerce, il supprimera le Point.


2) Si vous faite des références aux données OSM, il faut faire très 
attention a la façon dont vous structurez votre base, pour distinguer:


 - vos données qui seront légalement considérées comme une
   «base de donnée dérivée» de celle d'OpenStreetMap,
   et soumise, pour toute utilisation publique, à la clause
   d'attribution et de rediffusion sous licences ODbL (share-alike).

 - vos données qui pourront rester indépendantes, et former une
   «Collective Database» avec les données d'OSM.
   La page suivante essaye d'expliquer dans quel cas c'est possible:

Re: [OSM-talk-fr] site cadastre.openstreetmap.fr

[Tyndare]

J'ai rajouté les liens que tu mentionnent sur 
http://cadastre.openstreetmap.fr/


Mais Hélène Petit m'avais fait remarquer que cette page n'est pas très 
simple pour ceux qui la découvrent pour la première fois, et à force de 
rajouter des trucs ça ne s'améliore pas.


Si quelqu'un a une proposition a faire qui rendrait cette page plus 
claire (quitte à découper en plusieurs sous pages), surtout n'hésitez pas.



Le 22/12/2016 à 15:32, Laurent Combe a écrit :

A partir de ce site
http://cadastre.openstreetmap.fr/
ou de
http://cadastre.openstreetmap.fr/fantoir

je ne vois pas de lien vers les listes départementales (citées
récemment par nicolas)
http://cadastre.openstreetmap.fr/fantoir/voies_recentes_manquantes.html

àm on humble avis, ce serait un plus d'avoir à partir du site accès à
l'ensemble des outils disponibles (par un simple lien)

autre point
sur la page d'accueil http://cadastre.openstreetmap.fr/ il y a bien un
lien vers le wiki mais qui pointe sur la page qui décrit l'historique
de nos relations avec la DgFiP

il manque à mon avis un lien vers la page du wiki : comment contribuer à la BANO
http://wiki.openstreetmap.org/wiki/Contribuer_%C3%A0_la_BANO


Laurent

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



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

Re: [OSM-talk-fr] osmose et adresses bis

[Tyndare]

On 20/12/2016 12:40, Christian Quest wrote:

A ma connaissance, il n'y a pas franchement de règle pour coller ou non
les indices de répétitiion (c'est leur petit nom) aux numéros.


D'après le Larousse[1] bis et ter sont des adverbes, et en français je 
ne crois pas qu'on puisse coller l'adverbe au mot qu'il qualifie.




On peut par contre se fixer une convention dans OSM.


+1, mais faut tomber d'accord et le terrain je ne suis pas sur qu'il 
respecte toujours la même convention ;-)




Je favoriserait le fait de coller les indices, car on peut facilement
les séparer si besoin et surtout ça évite de créer une ambiguïté avec le
reste de l'adresse comme ça peut être le cas avec un "34 A" le "A"
pouvant être un "à...".


C'est plus simple de supprimer les espaces si besoin que d'avoir a en 
rajouter.
De la même manière qu'on ne met pas d'abréviation dans OSM, je 
pencherais plus pour garder une information la plus lisible et correcte 
possible dans OSM, et de documenter les règles de normalisation a 
appliquer pour obtenir une recherche optimale.


Donc je voudrais qu'on privilégie bis/ter/quater plutôt que b/t/q, et 
qu'on garde un espace dans ces cas là.


Par contre entre les numéros et les lettres A/B/C/... là j'ai pas 
vraiment d'avis si un espace est préférable on non.


Actuellement l'export semi automatique des adresses depuis le cadastre 
rajoute un espace par défaut dans tous les cas.
Si on décide que ce n'est pas souhaitable, il faudra changer ça et 
envisager une correction automatique de ce qui a déjà été importé.



Les bis/ter/quater... devraient être en minuscules, les A/B/C en
majuscule. Ils ont du coup différenciés et c'est aussi à mon avis plus
"joli" en terme de graphie, mais là c'est une histoire de goût.


Je crois qu'on m'avais fait remarqué qu'il y a des villages en Alsace où 
sur le terrain les lettres comme a/b/c... sont écrites en minuscule mais 
je n'en suis pas sûr.



Quand on ne sait pas si un b/t/q est un bis/ter/quater (cas possible
avec le cadastre ou la BAN) je le laisserai en minuscule.


Là ça deviens subtil, peut être rajouter un tag "note" pour expliquer 
que la valeur peut être raffinée pour être moins ambigue.
De toute façon une fonction de normalisation pour la recherche d'adresse 
devrait générer la même chose dans tous les cas (que ce soit B, b ou bis 
avec ou sans espace)


>

Le 20 décembre 2016 à 12:02, Julien Lepiller > a écrit :

Bonjour,

au moins sur Rennes, les adresses en "bis" et "ter" sont indiquées
en erreur sur osmose. Elles sont bien indiquées sur OSM, par exemple :

https://www.openstreetmap.org/node/4225509127


a le tag addr:housenumber = "39 bis", et osmose propose plutôt
"39bis" (sans espace), de même pour toutes les adresses contenant un
"ter", et c'est exactement l'inverse quand l'adresse comporte une
lettre (https://www.openstreetmap.org/node/3805090559
). Quelle est la
norme pour ces adresses ? Avec ou sans espace ? Comment corriger ça
durablement (histoire que ça ne se répète pas sur un import futur) ?
Ça fait plein de points sur osmose, c'est pas beau, et j'aimerais
bien que ça disparaisse ;)



[1] http://www.larousse.fr/dictionnaires/francais/bis/9553?q=bis

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

Re: [OSM-talk-fr] adresse commune à plusieurs bâtiments

[Tyndare]

Il trouve C2, mais pas C1.

Je ne sais pas si c'est une bonne solution mais j'essaierais
d'associer l'addr:housenumber et addr:street directement aux deux 
bâtiments C1 et C2:

 - soit en dupliquant cette info sur chacun des bâtiments
 - soit en indiquant cette info non pas sur un unique point adresse, 
mais sur un polygone englobant les deux bâtiments, pour qu'ils fassent 
bien partie de cette adresse (mais je n'ai pas vérifié que ça marchait 
avec nominatim).


Tyndare.

On 09/12/2016 20:17, osm.sanspourr...@spamgourmet.com wrote:

Nominatim trouve le bâtiment C2, rue du Roy Gontran
<https://www.openstreetmap.org/search?query=C2%2C%20Rue%20du%20Roy%20Gontran>.

Et le B, 14  rue du Roy Gontran
<https://www.openstreetmap.org/search?query=B%2C%2014%20Rue%20du%20Roy%20Gontran#map=19/46.77929/4.86444>.

Dans le second cas est précisé :

addr:housenumber
<http://wiki.openstreetmap.org/wiki/Key:addr:housenumber?uselang=en>=14

Jean-Yvon

Le 09/12/2016 à 17:40, Samy Mezani - samy.mez...@wanadoo.fr a écrit :

Bonjour,

Je souhaite tagguer des adresses pour des bâtiments qui sont nommés
par une lettre, et qui partagent une adresse commune.

Exemples de bâtiments :
https://www.openstreetmap.org/way/232922812
https://www.openstreetmap.org/way/458656397

Comment bien tagguer pour pouvoir retrouver l'adresse du bâtiment avec
Nominatim ?

Si je place le numéro sur un node au niveau de l'entrée avec les
boîtes aux lettres, les bâtiments n'ont pas la bonne adresse (Cf.
https://www.openstreetmap.org/node/2412503349)

Le mieux est de créer une relation ?

Merci

Samy

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




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



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

Re: [OSM-talk-fr] Prochaine ouverture de la base SIRENE...

[Tyndare]

Super nouvelle cette ouverture !

J'ai la sensation que les commerces sont une des données d'OSM qui se 
périment le plus vite, la durée avant un déménagement, un changement de 
nom et de propriétaire ou malheureusement une fermeture est assez courte 
en moyenne.


Je ne sais pas comment est structurée la base, mais si certains se 
lancent dans un outil, je pense qu'il serait très utile de prévoir de 
détecter et mettre en valeur les changements au cours du temps, 
notamment les enregistrements qui disparaissent de la base...


Tyndare.


On 10/11/2016 18:25, Christian Quest wrote:

La base SIRENE de l'INSEE sera disponible en opendata début janvier
prochain.

Cette base contient plus de 10 millions d'enregistrements concernant les
"personnes morales": sociétés, entreprises, associations, etc.

Un hackathon aura lieu mardi prochain (15/11) à Paris un peu en avant
première de l'ouverture du jeu de données.

Ce sera une source très intéressante pour compléter et mettre à jour OSM
sur les commerces et artisans. Je n'ai pas encore regardé ce que ça
donnait, je suis en train de terminer son géocodage (avec BAN et BANO).

Il y a de quoi alimenter soit osmose, soit un outil dédié, le plus
simple possible, si possible mobile pour faire de la validation sur le
terrain... un peu comme ce dont parle Florian dans son billet de blog du
jour: 
http://florian.lainez.fr/la-fin-de-google-map-maker-et-le-futur-des-outils-carto/

A suivre !

--
Christian Quest - OpenStreetMap France


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



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

Re: [OSM-talk-fr] Différence affichage cadastre iD/jOSM

[Tyndare]

Normalement c'est l'utilisation du plugin Cadastre-fr qui nécessite un 
changement de projection,

mais ce n'est pas nécessaire pour l'utilisation du serveur TMS
(Menu Imagerie/Préférences d'imagerie, puis bouton +TMS)

Ce que je disais c'est que pour moi la configuration par défaut pour les 
tuiles du cadastre est en fait identique entre iD et JOSM.
Donc je ne comprends pas qu'il puisse y avoir les différences que tu 
constate entre les deux.
Je n'ai pas l'habitude d'utiliser iD mais en regardant rapidement je 
vois exactement la même chose qu'avec JOSM si je fait attention d'être 
au même niveau de zoom.



On 13/10/2016 17:34, David Marchal wrote:

Je connaissait ce mode d'affichage du cadastre, mais il oblige à changer de 
projection et à passer en Lambert, incompatible avec les photos satellites ; 
pour croiser les données, c'est très chiant. Comme ce sont les noms qui 
m'intéressent, le calque Cadastre préconfiguré suffit souvent, mais les textes 
sont souvent tronqués, et devoir changer de projection sans arrêt n'est pas 
pratique ; quitte à utiliser une approximation du vrai cadastre, pourquoi ne 
pas utiliser celle d'iD par défaut, puisqu'elle est apparemment meilleure ?

De : Tyndare [tynd...@wanadoo.fr]
Envoyé : mercredi 12 octobre 2016 16:43
À : talk-fr@openstreetmap.org
Objet : Re: [OSM-talk-fr] Différence affichage cadastre iD/jOSM

iD et JOSM n'utilisent pas la même source de donnée pour déterminer la
liste des images disponibles par défaut selon la région affichée mais
j'ai l'impression que la définition pour les tuiles du cadastre
utilisent pourtant bien le même serveur TMS:
http://tms.cadastre.openstreetmap.fr/*/tout/{zoom}/{x}/{y}.png

Comme expliqué à l'origine par Frédéric Rodrigo, pour éviter les
problèmes de saut aux frontières, il est possible de n'afficher les
tuiles que d'une seule commune en particulier en spécifiant dans
l'éditeur un serveur personnalisé qui utilise l'URL précédant dans
lequel on remplace le * par le code INSEE de la commune voulue:

https://lists.openstreetmap.org/pipermail/talk-fr/2015-February/075223.html

Je crois que la configuration par défaut pour JOSM est définie ici:
https://josm.openstreetmap.de/wiki/Maps/France#Cadastre

et que celle pour iD est définie ici:
https://github.com/osmlab/editor-layer-index/blob/gh-pages/sources/europe/fr/FR-Cadastre.geojson



___
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] Différence affichage cadastre iD/jOSM

[Tyndare]

iD et JOSM n'utilisent pas la même source de donnée pour déterminer la 
liste des images disponibles par défaut selon la région affichée mais 
j'ai l'impression que la définition pour les tuiles du cadastre 
utilisent pourtant bien le même serveur TMS:

http://tms.cadastre.openstreetmap.fr/*/tout/{zoom}/{x}/{y}.png

Comme expliqué à l'origine par Frédéric Rodrigo, pour éviter les 
problèmes de saut aux frontières, il est possible de n'afficher les 
tuiles que d'une seule commune en particulier en spécifiant dans 
l'éditeur un serveur personnalisé qui utilise l'URL précédant dans 
lequel on remplace le * par le code INSEE de la commune voulue:


https://lists.openstreetmap.org/pipermail/talk-fr/2015-February/075223.html

Je crois que la configuration par défaut pour JOSM est définie ici:
https://josm.openstreetmap.de/wiki/Maps/France#Cadastre

et que celle pour iD est définie ici:
https://github.com/osmlab/editor-layer-index/blob/gh-pages/sources/europe/fr/FR-Cadastre.geojson



On 12/10/2016 12:01, David Marchal wrote:

Bonjour à tous.

Question idiote : pourquoi l'affichage du cadastre est-il aussi propre sur iD, 
alors que, sur jOSM, il est tout moche : noms tronqués, tracé de limites 
sautant sans arrêt… L'affichage d'iD n'est pas irréprochable, mais il me semble 
bien meilleur que celui de jOSM, alors pourquoi ne pas utiliser le même serveur 
de tuiles ?

Dans l'attente de vos lumières,

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



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

Re: [OSM-talk-fr] Osmose-dev: bâtiments fractionnés par le Cadastre.

[Tyndare]

On 24/08/2016 07:40, Christian Quest wrote:
Le 24 août 2016 à 00:01, Jérôme Seigneuret 
> a 
écrit :


Pour les retours en effet, je pense qu'on peut aussi hacker le
code d'opensolarmap pour améliorer l’auto-détection des découpages
sur l'ortho en post traitement des détections existante pour
valider ou annuler la génération d'une alerte.


Il est possible de reprendre la logique d'opensolarmap pour une 
confirmation rapide.




Une Interface comme OpenSolarMap se prêterais bien effectivement pour 
analyser les cas de bâtiments fractionnés. Je pense qu'on pourrais peut 
être même envisager une correction automatique si il y a double validation.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose-dev: bâtiments fractionnés par le Cadastre.

[Tyndare]

On 23/08/2016 16:18, Christian Quest wrote:

En croisant avec un peu plus d'infos, il serait possible d'être plus fin.

Je pense à un croisement en amont avec les parcelles et les adresses 
des parcelles. Lorsque 2 polygones de bâtiments on la même limite que 
les parcelles et que ces parcelles ont la même adresse, on a de fortes 
chance pour qu'il ne s'agisse que d'un seul bâtiment...


C'est un traitement à faire en amont, avant import dans OSM, mais 
qu'on pourrait aussi tester sur les bâtiments qui ont été importés 
sans aucun déplacement.


Tu avais déjà mention cette idée intéressante sur la liste dev-fr, mais 
j'avoue je n'ai pas voulu me lancer dans cette analyse car je
n'était pas convaincu du bénéfice, faut dire que j'ai une vision 
biaisée, j'ai vu trop de cas tordus dans les adresses du cadastre...


J'ai essayé de regarder rapidement quelques cas sur Caen: si on ne 
considère que les parcelles ayant une adresse complète (avec un numéro 
de rue),
l'info semble effectivement pertinente, peut être autant pour éliminer 
des faux positifs que pour détecter de nouveaux cas.
Par contre pour la mise en œuvre d'un tel rapprochement je ne vois pas 
trop comment faire pour l'instant (surtout à l'échelle de la France).



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

Re: [OSM-talk-fr] Osmose-dev: bâtiments fractionnés par le Cadastre.

[Tyndare]

La détection des bâtiments en forme de triangles existe déjà dans Osmose 
(grâce à Didier2020 et à Frédéric Rodrigo)


Avec cette analyse je voulais effectivement essayer de détecter des cas 
plus compliqués.


On 23/08/2016 13:42, David Crochet wrote:

Bonjour


Le 23/08/2016 à 13:36, Jean-Claude Repetto a écrit :

Au contraire, je vois surtout des trapèzes,


C'est probablement plus difficile à détecter...

Cordialement




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

Re: [OSM-talk-fr] Osmose-dev: bâtiments fractionnés par le Cadastre.

[Tyndare]

Effectivement, c'est un faux négatif, la détection est loin d'être 
parfaite, elle marche en comparant avec une base d'exemples qu'il faudra 
encore améliorer.


Dans ce cas là la difficulté vient du fait que le bâtiments est coupé 
deux fois (il est en trois morceaux), du coup la majorité des angles ne 
sont pas droits, un peut comme pour les maisons des centres historiques 
des villes où l'algo détecte beaucoup trop de faux positifs... difficile 
de trouver le juste milieu.



On 23/08/2016 13:22, Hamlet wrote:

Bonjour,
a priori pas trop de faux positifs par chez moi.

Par contre un faux négatif, celui-ci est bien à corriger :
http://www.openstreetmap.org/browse/way/298268148
Mais celui juste au-dessus n'est pas détecté !
En fait dans le hameau il y en a pas mal.


2016-08-23 12:52 GMT+02:00 Tyndare <tynd...@wanadoo.fr>:

Bonjour,

j'ai lancé une analyse Osmose pour essayer de détecter des bâtiments
fractionnés par le cadastre.
(cad des bâtiments que le cadastre a scinder en morceaux à cause des limites
de parcelles ou autre).

Le résultat est visible temporairement sur le serveur de développement
d'Osmose:

http://dev.osmose.openstreetmap.fr/fr/map/#source=26121=3

J'aurais aimé votre retour sur la pertinence de cette détection, s'il n'y a
pas trop de faux positifs et donc si la qualité serait suffisante pour
l'intégrer de façon plus pérenne dans Osmose.

Le Cadastre n'est en fait pas utilisé pour l'analyse, seule la forme des
bâtiments comparés deux-à-deux est prise en compte.
Pour les motivés vous pouvez déjà faire des corrections dans OSM (en
vérifiant bien avec les images du Cadastre et les photos aériennes IGN si le
fractionnement est effectivement un artefact du Cadastre ou si au contraire
il a bien une réalité physique qui doit être conservée dans OSM).
Ne vous embêter pas a signaler les faux-positifs sur Osmose, c'est un
serveur de dev, l'info sera perdue.

Je sais qu'il y a beaucoup de faux positifs dans les centre ville à cause de
la forme moins carrée des bâtiments.
En théorie il y a aussi proportionnellement beaucoup de faux positifs dans
la région Rhône-Alpes étant donné que j'y ai déjà corrigé une majorité de
cas.


Tyndare.

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






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

[OSM-talk-fr] Osmose-dev: bâtiments fractionnés par le Cadastre.

[Tyndare]

Bonjour,

j'ai lancé une analyse Osmose pour essayer de détecter des bâtiments 
fractionnés par le cadastre.
(cad des bâtiments que le cadastre a scinder en morceaux à cause des 
limites de parcelles ou autre).


Le résultat est visible temporairement sur le serveur de développement 
d'Osmose:


http://dev.osmose.openstreetmap.fr/fr/map/#source=26121=3

J'aurais aimé votre retour sur la pertinence de cette détection, s'il 
n'y a pas trop de faux positifs et donc si la qualité serait suffisante 
pour l'intégrer de façon plus pérenne dans Osmose.


Le Cadastre n'est en fait pas utilisé pour l'analyse, seule la forme des 
bâtiments comparés deux-à-deux est prise en compte.
Pour les motivés vous pouvez déjà faire des corrections dans OSM (en 
vérifiant bien avec les images du Cadastre et les photos aériennes IGN 
si le fractionnement est effectivement un artefact du Cadastre ou si au 
contraire il a bien une réalité physique qui doit être conservée dans OSM).
Ne vous embêter pas a signaler les faux-positifs sur Osmose, c'est un 
serveur de dev, l'info sera perdue.


Je sais qu'il y a beaucoup de faux positifs dans les centre ville à 
cause de la forme moins carrée des bâtiments.
En théorie il y a aussi proportionnellement beaucoup de faux positifs 
dans la région Rhône-Alpes étant donné que j'y ai déjà corrigé une 
majorité de cas.



Tyndare.

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

Re: [OSM-talk-fr] Problème d'accès à FR-BAN et FR-Cadastre !

[Tyndare]

Arghhh effectivement, je savais pourtant bien qu'il ne faut pas essayer 
de corriger ce qui marche.


Normalement les bâtiments wall=no devraient réapparaître dans les exports.


On 27/07/2016 11:13, Pierre-Yves Berrard wrote:

Constaté aussi pour les wall=no.

PY

Le 27 juillet 2016 à 10:58, Nicolas Moyroud <nmoyr...@free.fr 
<mailto:nmoyr...@free.fr>> a écrit :


Merci effectivement ça a l'air bon pour le water.
J'ai remarqué un autre bug dans les exports en ce qui concerne le
fichier house-simplifie. Tous les polygones en wall=no ne sont
plus présents. Constaté sur 2 communes différentes. Je n'ai pas
regardé ce que ça donnait dans le fichier house non simplifié.

Nicolas

Le 26/07/2016 11:54, Tyndare a écrit :

Résultat à vérifier mais normalement c'est fait.


On 20/07/2016 10:04, Nicolas Moyroud wrote:

Bonjour,

Si à l'occasion tu as le temps de t'occuper du problème
des données data/eau découpées en petits morceaux ça
m'aiderait bien. :-)

Nicolas



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




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


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

Re: [OSM-talk-fr] Problème d'accès à FR-BAN et FR-Cadastre !

[Tyndare]

Résultat à vérifier mais normalement c'est fait.


On 20/07/2016 10:04, Nicolas Moyroud wrote:

Bonjour,

Si à l'occasion tu as le temps de t'occuper du problème des données 
data/eau découpées en petits morceaux ça m'aiderait bien. :-)


Nicolas

Le 27/06/2016 19:43, Tyndare a écrit :


Il y avait effectivement un problème avec le chemin vers le 
répertoire data/eau.


C'est corrigé mais pour l'eau les données reste découpés en petits 
morceaux. Je n'ai pas de temps cette semaine pour essayer d'améliorer 
ça.





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



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

Re: [OSM-talk-fr] Problème d'accès à FR-BAN et FR-Cadastre !

[Tyndare]

Il y avait effectivement un problème avec le chemin vers le répertoire 
data/eau.


C'est corrigé mais pour l'eau les données reste découpés en petits 
morceaux. Je n'ai pas de temps cette semaine pour essayer d'améliorer ça.



On 27/06/2016 15:55, Nicolas Moyroud wrote:

Bonjour,

Merci pour cet excellent travail ça sort maintenant dans la même 
qualité qu'avant pour les bâtiments.
Par contre sur la commune où j'ai travaillé il n'y a rien qui est 
sorti pour les surfaces en eau dans data/eau.


Nicolas

Le 16/06/2016 19:45, Tyndare a écrit :


Les exports sont découpés en petits morceaux pour essayer d'obtenir 
une qualité équivalente à ce qu'on avait avant. Faites remonter les 
cas problématiques si vous constatez toujours des défauts.



___
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] Gros problème qualité de la part d'un contributeur

[Tyndare]

Manifestement il persiste a vouloir réaligner sur le cadastre, même avec 
~ 50m de décalage par rapport aux traces GPS ou aux images aériennes

http://nrenner.github.io/achavi/?changeset=40297179

Je n'ai pas eu de réponses de Sylvain pour l'instant.


On 25/06/2016 18:30, Eric SIBERT wrote:

Je passe par la mailing liste, car je n'a ai eu aucune réponse du
contributeur.


Tu l'as contacté comment? Juste de commentaires sur ses changsets ou 
aussi envoie de messages directs?


Depuis combien de temps?

Continue-t-il après envoi de message? (ça a l'air)

Contributeur inscrit depuis 2009.


Je crois qu'il y a 7000 changeset a analyser...


Un changset par objet...

Data Working Group???

Eric


___
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] Gros problème qualité de la part d'un contributeur

[Tyndare]

On 25/06/2016 18:30, Eric SIBERT wrote:

Je passe par la mailing liste, car je n'a ai eu aucune réponse du
contributeur.


Tu l'as contacté comment? Juste de commentaires sur ses changsets ou 
aussi envoie de messages directs?

Depuis combien de temps?


Commentaire sur changeset il y a 3 jours à propos du problème de 
décalage du cadastre et de la suppression du bâti.

Message direct hier en listant les problèmes que j'ai mentionné ici.



Continue-t-il après envoi de message? (ça a l'air)


Après le message sur changeset oui Il a continué, mon message direct a 
été ignoré aussi mais depuis il s'est mis a cartographier ailleurs (peut 
être pour d’autres raisons)



Contributeur inscrit depuis 2009.


Je crois qu'il y a 7000 changeset a analyser...


Un changset par objet...


Il y a aussi de gros changeset.


Data Working Group???


Je vais faire suive à Sylvain si il en est toujours membre.


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

[OSM-talk-fr] Gros problème qualité de la part d'un contributeur

[Tyndare]

Bonjour,

Je passe par la mailing liste, car je n'a ai eu aucune réponse du 
contributeur.

J'ai un problème avec ce genre de modifications: [1] [2]

Il semble cartographier principalement à partir du cadastre sans aucun 
respects des contributions précédentes, même si le cadastre est décalé 
par rapport à la réalité comme ici.


Avec suppression de tout le bâti qui avait été correctement réaligné 
pour réimporter de façon brute depuis le cadastre, sans aucune 
restauration des tags spécifiques qui étaient présents avant.
Redécalage de toutes les routes sur le cadastre (donc grosse dégradation 
de la qualité des données)


Plus je regarde dans les détails moins je me sent capable d'être diplomate:

Pont réduit à une longueur ridicule par rapport à ce que montre les 
images aérienne: [3]


Recréation de route sans les connecter (alors que celles supprimées 
était bien connectées): [4] [5]


Sentier non connecté d'un côté, croisant deux fois la route de l'autre: [6]

Et quand je vois ça je ne sais pas si il faut en rire ou en pleurer: [7]

Je crois qu'il y a 7000 changeset a analyser...

C'est quoi la solution dans une situation comme celle là ?



[1] http://nrenner.github.io/achavi/?changeset=40212579

[2] http://nrenner.github.io/achavi/?changeset=40213219

[3] https://www.openstreetmap.org/node/327804880

[4] https://www.openstreetmap.org/node/4262804368

[5] https://www.openstreetmap.org/node/2364026411

[6] https://www.openstreetmap.org/way/227611456

[7] http://nrenner.github.io/achavi/?changeset=40281234

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

Re: [OSM-talk-fr] path, cycleway et footway

[Tyndare]

On 22/06/2016 17:43, Jérôme Seigneuret wrote:


*/designated/* a été créer pour définir un usage obligatoire pour des 
usagers spécifiques (le panneaux de ségrégation implique cet usage).
Donc le */yes/* suffit amplement car une voie verte n'impose pas de ne 
pas utiliser une route adjacente. C'est complètement inutile de 
surcharger la clé */foot/* et *bicycle *pour ajouter cette information 
sens le contexte obligatoire. Il y a déjà des règles prédéfinies pour 
cela. Pour les vélo il y a une clé à mettre sur la route 
d'ailleurs*/ bicycle=use_sidepath/*


Je ne suis pas d'accord sur designated, il n'implique aucune obligation, 
il signifie juste que le chemin est explicitement dédié à un type de 
moyen de transport particulier, donc designated est bien la bonne valeur 
a utiliser pour les voies vertes (on pourrait même utiliser la valeur 
"official" plus forte que designated)



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

Re: [OSM-talk-fr] Problème d'accès à FR-BAN et FR-Cadastre !

[Tyndare]

Les exports sont découpés en petits morceaux pour essayer d'obtenir une 
qualité équivalente à ce qu'on avait avant. Faites remonter les cas 
problématiques si vous constatez toujours des défauts.



On 16/06/2016 09:54, Nicolas Moyroud wrote:
Oui ce serait bien. J'étais motivé pour l'import des bâtiments ces 
derniers temps mais là vu la qualité horrible j'arrête le travail tant 
que ça reste comme ça.
En attendant, il faudrait peut-être penser a carrément désactiver le 
service concernant les bâtiments sur cadastre.openstreetmap.fr. 
Quelques contributeurs moins attentifs pourraient nous faire un 
travail bien sale avec ça !


Nicolas



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

Re: [OSM-talk-fr] Bonnes et moins bonnes visibilités OSM

[Tyndare]

L'utilisation de contact:* pour les adresses n'a pas l'air d'être très accepté :

http://www.openstreetmap.org/changeset/39426586

«... this seems to be a "french only" way of tagging things. The discussion 
about having duplicate adresses is still going on, and although I (and I guess 
all other mappers) would love to have a general consent on such a basic issue, 
there is no consent yet...»



Le 13 juin 2016 08:58:35 GMT+02:00, Romain MEHUT  a 
écrit :
>Le 12 juin 2016 à 23:00, Philippe Verdy  a écrit :
>
>> Si on ne multiplie pas les housenumber, comment tu détermines le
>numéro
>> d'adresse des différents pois positionnés autour ?
>>
>
>La question à se poser est la suivante, comme disait Pieren en janvier
>2014
>: "*- l'adresse est-elle un attribut ou une donnée à part entière
>(feature). La question n'est pas anodine lorsque certains répètent à
>l'envie la même adresses sur de multiples POIs. Il n'y aucun problème à
>dupliquer la même adresse si on considère que c'est un simple attribut
>(comme le "surface" d'une route). Mais si on considère que l'adresse
>est
>une donnée en elle-même, il ne faudrait pas la dupliquer (pour suivre
>le
>principe "one feature, one OSM element" [5])*". Sur la base de ce
>principe,
>le tag contact:housenumber permet de faire le lien sans multiplier le
>tag
>addr:housenumber
>
>
>> J'ai vu l'utilisation de "contact:housenumber=40" qui ne me semble
>pas
>> correct car l'adresse de contact n'est pas l'adresse du lieu et peut
>être
>> située complètement ailleurs (exemple d'une boutique qui fait partie
>d'un
>> ensemble de magasins d'un même propriétaire: pourtant chaque boutique
>a son
>> adresse physique, mais une seule est une adresse postale de contact;
>ce cas
>> est fréquent avec les franchises, les différentes boutiques n'ayant
>que des
>> gérants, mais aucune gestion locale du courier).
>>
>> Une adresse de contact n'est pas un lieu où on se rend, juste là où
>on
>> écrit. Et une adresse physique (cadastrale) a souvent plusieurs
>occupants
>> avec leurs propres POIs (on a le cas non seulement pour les
>commerces, mais
>> aussi les services publics, les écoles...)
>>
>
>Pourquoi contact:housenumber ne servirait-il qu'au courrier ?
>
>
>> Sans addr:housenumber=40, cette boutique sera déterminée comme étant
>au 42
>> (qui n'a pas été positionné mais est à mi chemin entre les noeuds
>d'adresse
>> 40 et le 44), pas au 40, en cherchant parmi les noeuds d'adresse
>autour
>> celui qui semble le plus proche !
>>
>
>Le 42 n'existe pas dans OSM mais uniquement dans le cadastre donc il
>n'y a
>pas de raison que cette boutique soit en l'état associée au 42.
>
>
>> Les POIs des boutiques en plus sont plutôt positionnés sur le point
>> d'entrée du commerce sur son pas de porte, pas là où sont les boutes
>à
>> lettres (qui peuvent être dans une partie commune d'un immeuble).
>>
>> Franchement je ne comprend pas cette restriction du "pas de
>multiplication
>> des addr:housenumber" ! Ca n'a été spécifié nulle part et pas discuté
>! Je
>> trouve donc le fait de demander le bloquage pour cette raison assez
>> litigieux !
>>
>
>cf. ci-dessus.
>
>Romain
>
>
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Frontière Guyane osm-fr

[Tyndare]

Oui c'est due à une nouvelle restriction dans la résolution des impressions PDF 
du site cadastre.gouv.fr.

Faites attention, si vous arrivez a exporter un fichier sur 
cadastre.openstreetmap.fr il y a toutes les chances qu'il contienne de grosses 
erreurs de simplification.

Seule la sélection d'une toute petite zone a exporter (zoom au max) donne un 
résultat correcte.



Le 31 mai 2016 10:20:09 GMT+02:00, "Vincent de Château-Thierry" 
<osm.v...@free.fr> a écrit :
>
>> De: "Nicolas Moyroud" <nmoyr...@free.fr>
>> 
>> J'ai eu exactement le même problème hier avec la commune de
>> Baillargues dans l'Hérault. J'obtiens juste le .bbox et le .bz2, par
>contre dans
>> la partie eau le water.osm semble correctement généré au vu de la
>taille
>> (je ne l'ai toutefois pas testé dans JOSM). Toutes les communes sont
>> aussi vectorisées depuis longtemps dans l'Hérault.
>> Dans mon cas le but c'était de mettre à jour le bâti donc c'était un
>> peu raté... Finalement j'ai décalqué à la main avec le fond raster du
>> cadastre. Y'avait longtemps que j'avais pas fait ça j'avais oublié
>> que c'était aussi laborieux !! ;-)
>
>À la grenobloise :)
>Il y a eu des changements côté cadastre.gouv.fr récemment, remontés par
>Tyndare. Je ne sais pas dire le lien avec les soucis que vous remontez
>mais on va regarder.
>  
>> Le 31/05/2016 00:32, Jérôme Amagat a écrit :
>> > j'avais testé en guyane ou dans l'Ain et a chaque fois j'ai pas de
>> > résultat (seulement le .bbox et .bz2 avec rien dedans). Je vient de
>> > tester ailleurs, et c'est vrai que des fois ca marche.
>> > Ce n'est pas que les nouvelle communes vectorielles, dans l'Ain
>> > tout est vectorielle depuis pas mal de temps et je n'arrive pas a
>avoir
>> > un seul resultat.
>
>Je teste à l'instant sur Chaville (92) : export des bâtiment ok en
>apparence, mais des problèmes de géométrie dans le contenu produit. Et
>pas d'export des limites admin. Bref il y a un chantier à venir.
>
>vincent
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Problème d'accès à FR-BAN et FR-Cadastre !

[Tyndare]

Salut Christian,

Pour les explications, pour récupérer les PDFs on appel le service du 
cadastre imprimerExtraitCadastralNonNormalise.do
avec comme paramètre la MAPBOX de la zone voulue mais surtout avec des 
paramètres WIDTH et HEIGHT hors norme, qui généraient un PDF avec le bon 
niveau de détails mais dont les éléments dessinés dépassaient largement 
le format A4 (donc le PDF généré n'avais pas d'utilité avec un lecteur 
PDF classique car la plupart de ce qui était dessiné était clippé a 
l'écran, mais informatiquement on pouvait quand même tout lire).
Maintenant les paramètres WIDTH et HEIGHT semblent ignorés, la 
résolution est automatiquement adaptée ou bridée pour faire rentrer la 
MAPBOX dans le format A4 (ça fait sens pour la fonctionnalité du site 
cadastre.gouv.fr mais nous on se retrouve avec bien moins de détails).


Techniquement on est pas complètement bloqué, on pourrait aussi découper 
les PDF qand on récupère les bâtiments et rassembler les fichiers 
derrière, il y a besoin de moins détails pour les bâtiments que pour les 
numéros d'adresses, mais c'est sur c'est moins pratique et c'est surtout 
bien plus lent...


Ludo.


On 26/05/2016 09:35, Christian Quest wrote:

Arghhh... je me renseigne

Le 26 mai 2016 à 00:36, Tyndare <tynd...@wanadoo.fr 
<mailto:tynd...@wanadoo.fr>> a écrit :



Manifestement il y a de nouvelles restrictions concernant la
résolution des PDF exportés depuis le site cadastre.gouv.fr
<http://cadastre.gouv.fr> qui posent problème pour le site
cadastre.openstreetmap.fr <http://cadastre.openstreetmap.fr>
L'export du bâti ne marche plus car le code actuel récupère un
seul PDF pour toute la commune (les bâtiment si présents ont
parfois de grosses erreurs de simplification).
L'export des adresses était déjà découpé en petit PDF, mais il
faut désormais découper en 100 fois plus de morceaux pour espérer
lire tous les numéros.



On 25/05/2016 15:18, HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU
/ DT ALCA APPUI PERFORMANCE) wrote:

Le cadastre a l'air d'être reparti.
Hop au boulot !!

Denis


-Message d'origine-
De : didier2020 [mailto:didier2...@free.fr
<mailto:didier2...@free.fr>]
Envoyé : mardi 24 mai 2016 17:47
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Problème d'accès à FR-BAN et
FR-Cadastre !

Le mardi 24 mai 2016 à 14:55 +0200, Francois Gouget a écrit :

Depuis environ 48h iD n'arrive plus à afficher la couche
FR-BAN et la
couche FR-Cadastre.

Il semblerait que dans les deux cas ce soit parce que
inspire.cadastre.gouv.fr <http://inspire.cadastre.gouv.fr>
ne répond plus sur le port 80 (pas seulement
de mon adresse).

Quelqu'un sait-il ce qui se passe ?

maintenance :
http://www.cadastre.gouv.fr

-- 
Francois Gouget <fgou...@free.fr <mailto:fgou...@free.fr>>

http://fgouget.free.fr/
   Any sufficiently advanced Operating System is
indistinguishable from
Linux ___
Talk-fr mailing
list Talk-fr@openstreetmap.org
<mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr
---
Ce message et toutes les pièces jointes sont établis à
l'intention exclusive de ses destinataires et sont
confidentiels. L'intégrité de ce message n'étant pas assurée
sur Internet, la SNCF ne peut être tenue responsable des
altérations qui pourraient se produire sur son contenu. Toute
publication, utilisation, reproduction, ou diffusion, même
partielle, non autorisée préalablement par la SNCF, est
strictement interdite. Si vous n'êtes pas le destinataire de
ce message, merci d'en avertir immédiatement l'expéditeur et
de le détruire.
---
This message and any attachments are intended solely for the
addressees and are confidential. SNCF may not be held
responsible for their contents whose accuracy and completeness
cannot be guaranteed over the Internet. Unauthorized use,
disclosure, distribution, copying, or any part thereof is
strictly prohibited. If you are not the intended recipient of
this message, please notify the sender immediately and delete it.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetma

Re: [OSM-talk-fr] Problème d'accès à FR-BAN et FR-Cadastre !

[Tyndare]

Manifestement il y a de nouvelles restrictions concernant la résolution 
des PDF exportés depuis le site cadastre.gouv.fr qui posent problème 
pour le site cadastre.openstreetmap.fr
L'export du bâti ne marche plus car le code actuel récupère un seul PDF 
pour toute la commune (les bâtiment si présents ont parfois de grosses 
erreurs de simplification).
L'export des adresses était déjà découpé en petit PDF, mais il faut 
désormais découper en 100 fois plus de morceaux pour espérer lire tous 
les numéros.



On 25/05/2016 15:18, HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT 
ALCA APPUI PERFORMANCE) wrote:

Le cadastre a l'air d'être reparti.
Hop au boulot !!

Denis


-Message d'origine-
De : didier2020 [mailto:didier2...@free.fr]
Envoyé : mardi 24 mai 2016 17:47
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Problème d'accès à FR-BAN et FR-Cadastre !

Le mardi 24 mai 2016 à 14:55 +0200, Francois Gouget a écrit :

Depuis environ 48h iD n'arrive plus à afficher la couche FR-BAN et la
couche FR-Cadastre.

Il semblerait que dans les deux cas ce soit parce que
inspire.cadastre.gouv.fr ne répond plus sur le port 80 (pas seulement
de mon adresse).

Quelqu'un sait-il ce qui se passe ?

maintenance :
http://www.cadastre.gouv.fr

--
Francois Gouget   http://fgouget.free.fr/
   Any sufficiently advanced Operating System is indistinguishable from
Linux ___ 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
---
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas 
assurée sur Internet, la SNCF ne peut être tenue responsable des altérations 
qui pourraient se produire sur son contenu. Toute publication, utilisation, 
reproduction, ou diffusion, même partielle, non autorisée préalablement par la 
SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce 
message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
---
This message and any attachments are intended solely for the addressees and are 
confidential. SNCF may not be held responsible for their contents whose 
accuracy and completeness cannot be guaranteed over the Internet. Unauthorized 
use, disclosure, distribution, copying, or any part thereof is strictly 
prohibited. If you are not the intended recipient of this message, please 
notify the sender immediately and delete it.
___
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] Doute sur le calage Bing/Cadastre

[Tyndare]

Dans le menu contextuel du calque Strava (clique droit), il y a la
case à cocher «Zoomer automatiquement» qu'il faut désactiver une fois
qu'on est au zoom maximum disponible.

Le 10 février 2016 à 17:10, JB <jb...@mailoo.org> a écrit :
> Le 09/02/2016 12:01, Tyndare a écrit :
> J'apprécie aussi Strava dans les zones où les VTTistes passent, et regrette
> la faible visibilité et manque de zoom aux échelles de traçage.
> Mais désactiver le zoom automatique, tu fais ça comment ?
> JB.

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

Re: [OSM-talk-fr] Doute sur le calage Bing/Cadastre

[Tyndare]

Je ne sais pas ce qu'elle vaut dans ce coin mais en cas de doutes de callage 
j'ai tendance à faire confiance à la couche des traces Strava (en désactivant 
le zoom automatique dans JOSM pour zoomer plus que le fond qu'ils rendent 
disponible, et en affichant la couche plusieurs fois si il y a peu de points 
pour les rendre plus visibles) 



Le 8 février 2016 21:16:31 GMT+01:00, "Jean-Michel Pouré"  a 
écrit :
>J'ai un très gros doute sur le calage ...
>
>Sur les plans auquels j'ai collaboré, certaines rues sont calées sur
>Bing et d'autres sont décalées. J'ai des doutes et je ne sais pas
>comment corriger ces petits décalages.
>
>Quand on pense aux futures applications de guidage et de conduire
>automatique pour automobile ...
>
>Est-ce qu'il existe une synthése concernant le calage sur le wiki ?
>
>Par ailleurs, dans JOSM, il existe plusieurs plugins de calage. Existe-
>t-il un modèle numérique pour caler de manière fiable et corriger tous
>les petits défauts de l'imagerie satellite ? Quel plugin choisir ?
>
>Cordialement,
>
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import de défibrillateurs sur Toulouse

[Tyndare]

Si on reprend les données originales, a priori on a tout ça comme informations:

 - adresse=114 AV DE LESPINET
 - commune=TOULOUSE
 - id=27.0
 - implantation=A l'entrée à droite dans vestiares des tribunes
 - nom_site=Stade Struxiano
 - source=ToulouseMetropole
 - source:date=2015-02-14
 - type_structure=salles ERP sports


Pour la valeur "id" je pense qu'il faudrait un tag du style 
"ref:FR:ToulouseMetropole"
des objections?


Pour la valeur  "implantation", sur le wiki en anglais j'ai trouvé le tag 
"defibrillator:location" qui semble bien adapté.

defibrillator:location =* a textual description where the device is located 
(e.g. "in the porter's longue")

https://wiki.openstreetmap.org/wiki/Tag:emergency%3Ddefibrillator


On garde les tag "source" et "source:date"

Mais pour le reste, tout ce qui correspond à l'adresse le nom du site et le 
"type_structure"
1) on les zappe tout simplement ?
Ca pourrait quand même utile pour vérifier l'intégrité des données.
2) On agrège les valeurs dans un tag "note" ?
3) On crée un nouveau tag "defibrillator:addr"  ?
4) ou  "defibrillator:addr:*" ?

On pourrait agréger de cette manière :
«nom_site (type_structure) adresse commune»




Le 22 janvier 2016 11:45:25 GMT+01:00, Christian Quest 
<cqu...@openstreetmap.fr> a écrit :
>addr:* n'a rien à faire sur un défibrillateur... ni même contact:*
>
>
>On 21/01/2016 13:58, Tyndare wrote:
>> Bonjour,
>>
>> J'ai remarqué un import des défribilateurs
>> dont la liste est dispo en ODBL pour Toulouse.
>>
>> Autant je suis d'accord sur l'utilité des données autant je pense que
>le choix des tags annexes aurait mérite d'être discuté:
>>
>> On peut voir les tags originaux dans l'historique:
>>
>> https://www.openstreetmap.org/node/3953673079/history
>>
>> Je ne suis pas sur qu'utiliser addr:* et loc_ref soit une bonne idée.
>>
>> Quelles sont vos propositions pour corriger ?
>>
>>
>> Tyndare.
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>
>-- 
>Christian Quest - OpenStreetMap France
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr


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

[OSM-talk-fr] Import de défibrillateurs sur Toulouse

[Tyndare]

Bonjour,

J'ai remarqué un import des défribilateurs
dont la liste est dispo en ODBL pour Toulouse.

Autant je suis d'accord sur l'utilité des données autant je pense que le choix 
des tags annexes aurait mérite d'être discuté:

On peut voir les tags originaux dans l'historique:

https://www.openstreetmap.org/node/3953673079/history

Je ne suis pas sur qu'utiliser addr:* et loc_ref soit une bonne idée.

Quelles sont vos propositions pour corriger ?


Tyndare.


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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

[Tyndare]

Sur tous les exemples que j'ai vu le tag ref:INSEE était indiqué sur le nœud 
place, (admin_center)
Si le noeud place correspond au panneau 
du village et non a la commune le tag ref:INSEE n'a pas de sens ici, il 
faudrait le déplacer systématiquement sur la relation admin (pour toutes les 
communes de France)

Je suis mitigé pour basculer les codes INSEE historiques en old_ref
Même si il ne sont plus actifs ils restent toujours plus ou moins valides.





Le 30 décembre 2015 08:05:15 GMT+01:00, "Vincent de Château-Thierry" 
 a écrit :

>Un point qui reste à fixer est le devenir du tag ref:INSEE des communes
>
>déléguées :
>- est-ce qu'elles gardent le tag ref:INSEE sur leur relation admin ?
>ou
>- est-ce qu'on change plutôt ce tag en old_ref:INSEE ? (Rigolez-pas
>dans 
>le fond, on en a déjà ! 
>http://taginfo.openstreetmap.org/keys/old_ref%3AINSEE :) )
>
>vincent



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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

[Tyndare]

Non la situation est à l'opposé des communautés de communes, les gens 
extérieurs auront au contraire à tout pris besoin de connaitre le nom des 
communes nouvelles car il sera utilisé pour les adresses:

http://www.amf.asso.fr/document/fichier.asp?FTP=AMF_13703TELECHARGER_LA_NOTE.pdf_DOC=13703_N_ID=7



Le 29 décembre 2015 14:47:35 GMT+01:00, "Jérôme Amagat" 
<jerome.ama...@gmail.com> a écrit :
>Le 29 décembre 2015 à 14:15, Tyndare <tynd...@wanadoo.fr> a écrit :
>
>>
>>
>> Le 29 décembre 2015 12:46:21 GMT+01:00, "Stéphane Péneau" <
>> stephane.pen...@wanadoo.fr> a écrit :
>> >Le 29/12/2015 11:49, Tyndare a écrit :
>> >> Pour résumer si je n'étais pas claire: Contrairement a ce qui
>semble
>> >> être l'avis majoritaire et ce qui a été fait jusqu'à maintenant
>pour
>> >> les communes nouvelles j'aurais voulu rajouter un tag place avec
>le
>> >> nom des communes nouvelles créés.
>> >
>> >Il y a de nombreux cas où ajouter un tag place n'aura pas vraiment
>de
>> >sens. Regarde la commune nouvelle de Sèvremoine, on le met où ce
>> >"place" ?
>> >http://www.openstreetmap.org/relation/1665801#map=11/47.0834/-1.0691
>> >
>> >Au niveau du chef-lieu ? Ça ne pas de sens
>>
>> Pour moi si ça aurait tout son sens de le mettre au niveau du
>chef-lieu,
>> où se trouve la mairie de la commune.
>>
>
>donc tu mettrai au même endroit le nom de la commune et le nom de la
>ville
>mais s'ils sont différents? le fait que c'est le chef lieu c'est
>inscrit
>dans la relation avec le rôle admin_centre.
>
>
>> Mais je veux bien admettre que je soit influencé par le rendu, zapper
>une
>> commune de plus de 20'000 habitants et n'afficher que le nom des
>quartiers
>> (admin level = 10) ce n'est pas super pratique comme carte ;-)
>>
>> le nom de la commune de 2 habitants n’apparaît peut être pas sur
>le
>rendu mais la ville de 15000 habitant au milieu de la commune apparaît
>bien
>et c'est ce qui est important pour la plupart des gens et il me semble
>pas
>que les admin_level=10 sont plus indiqué que les 8, si il y a un node
>place=suburb avec son nom ou un truc du genre il apparaîtra sinon non.
>
>Pour les communes qui vont être créer ou celle déjà créé par fusion le
>plus
>important c'est le nom des ville et village, le nom de la commune
>apparaît
>beaucoup moins et est beaucoup moins utilisé. c'est comme les
>communauté de
>commune, à part la tienne est t il important et utile dans la vie de
>tous
>les jours de connaître le nom et la composition des autres communauté
>de
>communes.
>
>
>
>
>
>> Quel rendu existant l'affiche correctement ?
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

[Tyndare]

Le 29 décembre 2015 12:46:21 GMT+01:00, "Stéphane Péneau" 
<stephane.pen...@wanadoo.fr> a écrit :
>Le 29/12/2015 11:49, Tyndare a écrit :
>> Pour résumer si je n'étais pas claire: Contrairement a ce qui semble 
>> être l'avis majoritaire et ce qui a été fait jusqu'à maintenant pour 
>> les communes nouvelles j'aurais voulu rajouter un tag place avec le 
>> nom des communes nouvelles créés.
>
>Il y a de nombreux cas où ajouter un tag place n'aura pas vraiment de 
>sens. Regarde la commune nouvelle de Sèvremoine, on le met où ce
>"place" ?
>http://www.openstreetmap.org/relation/1665801#map=11/47.0834/-1.0691
>
>Au niveau du chef-lieu ? Ça ne pas de sens

Pour moi si ça aurait tout son sens de le mettre au niveau du chef-lieu, où se 
trouve la mairie de la commune.
Mais je veux bien admettre que je soit influencé par le rendu, zapper une 
commune de plus de 20'000 habitants et n'afficher que le nom des quartiers 
(admin level = 10) ce n'est pas super pratique comme carte ;-)

Quel rendu existant l'affiche correctement ?


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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

[Tyndare]

Pour résumer si je n'étais pas claire: Contrairement a ce qui semble être 
l'avis majoritaire et ce qui a été fait jusqu'à maintenant pour les communes 
nouvelles j'aurais voulu rajouter un tag place avec le nom des communes 
nouvelles créés.

Si on ne le fait pas je constate une incohérence avec toutes les communes (non 
nouvelles) dans OSM qui ont toutes leur tag place avec la population associée 
(sans avoir toujours de cohérence avec les panneaux sur le terrain et la 
distribution de la population dans les différents hameaux/villages qui 
composent les communes)

Je constate aussi un défaut de visibilité sur les rendus des commune nouvelles 
sans tag place, c'est embêtant car l'adressage se fait d'abord par le nom des 
communes nouvelles.

Le 29 décembre 2015 10:28:30 GMT+01:00, osm.sanspourr...@spamgourmet.com a 
écrit :
>Tyndare, pourquoi dis-tu qu'on ne devrait pas mettre de place avec le 
>nom associé (sachant que tu n'es pas d'accord avec) ?
>Comme toi, ça me semble tellement évident.
>Il y a des cas simples (Fusion Audierne-Esquibien donne Audierne avec 
>comme chef-lieu Audierne).
>
>Pour les panneaux, il y bien aussi des endroits où il est indiqué des 
>noms de "quartier" avec en dessous et plus petit le nom de la commune.
>Ça ne veut pas dire qu'il y a un "admin_level" spécifique, simplement 
>que cette zone urbaine est (ou pas) contigüe avec une autre.
>Par exemple "Les Cinq Chemins, commune de Guidel" (et le panneau de fin
>
>d'agglomération fait suite à un panneau d'entrée dans Guidel).
>Au niveau d'OSM c'est un simple nœud car il n'y a pas de limite nette.
>
>Un "Chanos-Curson" entre Chanos et Curson voir un à la place de Chanos 
>ça me semble bon.
>Et c'est ce qui figure sur OSM
>http://www.openstreetmap.org/relation/77510
>Dernière modification (pas sur le sujet) un certain Verdy_p.
>
>Dans le genre petits détails qui tuent : Audierne et Esquibien
>faisaient 
>partie du canton de Douarnenez.
>J'ai ajouté la nouvelle relation Audierne à la relation canton
>Douarnenez.
>Afin d'éviter les duplicatas, j'ai changé le canton "Douarnenez 
>(4028420)" :
>Relation Audierne (280462) 
><https://www.openstreetmap.org/relation/280462> avec le rôle 
>subarea:-2016-01-01
>Relation Esquibien (278707) 
><https://www.openstreetmap.org/relation/278707> avec le rôle 
>subarea:-2016-01-01
>Relation Audierne (5806724) 
><https://www.openstreetmap.org/relation/5806724> avec le rôle subarea
>(JOSM râle mais avec subarea:-2016-01-01 je ne casse rien et c'est 
>compréhensible - à supprimer au le 1er janvier ?)
>
>Sauf que je vois :
>que la relation Finistère - cantons (mars 2015) (4022330) 
><https://www.openstreetmap.org/relation/4022330> s'appelle "mars 2015"
>Est-ce que la relation canton Douarnenez n'est pas à laisser telle
>quelle ?
>
>Sinon grâce à cette fusion j'ai vu que des traits de côte étaient
>encore 
>incorrects. JOSM le dit mais ne propose pas la solution (les chemin 
>doivent être en sens trigonométrique autour d'une terre). Corrigé 
>rapidement quand j'ai compris ce que signifiait le message sur la 
>discontinuité du littoral).
>
>
>  Finistère
>
>Arrêté du 16 octobre 2015 portant création de la commune nouvelle 
>d'Audierne 
><http://www.legifrance.com/affichTexte.do?cidTexte=JORFTEXT31690191>
>
>  * Relation <https://wiki.openstreetmap.org/wiki/Elements#Relation>
>Audierne (280462) <https://www.openstreetmap.org/relation/280462>
>(XML <http://api.openstreetmap.org/api/0.6/relation/280462>,
>Potlatch2
><http://www.openstreetmap.org/edit?editor=potlatch2=11=280462>,
>iD <http://www.openstreetmap.org/edit?editor=id=280462>,
>JOSM
><http://localhost:8111/import?url=http://api.openstreetmap.org/api/0.6/relation/280462/full>,
>history
><http://osm.virtuelle-loipe.de/history/?type=relation=280462>,
>analyze <http://ra.osmsurround.org/analyze.jsp?relationId=280462>,
>manage <http://osmrm.openstreetmap.de/relation.jsp?id=280462>, gpx
><http://osmrm.openstreetmap.de/gpx.jsp?id=280462>) (chef-lieu et
>commune déléguée)
>  * Relation <https://wiki.openstreetmap.org/wiki/Elements#Relation>
>Esquibien (278707) <https://www.openstreetmap.org/relation/278707>
>(XML <http://api.openstreetmap.org/api/0.6/relation/278707>,
>Potlatch2
><http://www.openstreetmap.org/edit?editor=potlatch2=11=278707>,
>iD <http://www.openstreetmap.org/edit?editor=id=278707>,
>JOSM
><http://localhost:8111/import?url=http://api.openstreetmap.org/api/0.6/relation/278707/full>,
>history
><http://osm.virtuelle-loipe.de/hi

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

[Tyndare]

Je relance le sujet sur le node place de la commune nouvelle.
Ça m'embête qu'il n'y en ai pas.

A partir du moment ou la commune existe et que l'emplacement de son chef lieu 
est  connu je ne voie pas pourquoi on n'aurait pas de tag place avec le nom 
associé.
Sans ça on aura des centaines de communes qui n'apparaîtront sur quasiment 
aucun rendu.

Si on suit le raisonnement du tag place qui devrait uniquement correspondre aux 
panneau il y a  déjà beaucoup d'erreurs dans OSM.
Par exemple la commune de Chanos-Curson, sur le terrain il y a seulement un 
panneau Chanos et un paneau Curson mais en dehors du village quasiment personne 
ne fait la distinction entre les deux, si vous dites Chanos ça sera interpreté 
comme un diminutif et si vous dites Curson ça ne sera souvent pas compris.
Comme le systeme d'adressage change pour les communes nouvelles ça devrais être 
la même chose pour elles dans quelques années, le nom des anciennes communes 
perdra beaucoup en visibilité et les gens extérieurs chercherons d'abord la 
position de la commune nouvelle.

D'un autre cote si on admet que le tag place correspond a la zone du panneau et 
non a la commune il faudrait alors corriger ou à défaut supprimer sur les nœuds 
de tous les villages français les tags population issues de l'INSEE qui 
correspondent a la population de la commune entière et non à celle du village 
principal.




Le 12 décembre 2015 15:38:09 GMT+01:00, "Vincent de Château-Thierry" 
 a écrit :
>Bonjour,
>
>Le 12/12/2015 14:52, Stéphane Péneau a écrit :
>> Le 12/12/2015 14:32, Stéphane Péneau a écrit :
>>> Le 12/12/2015 13:51, Damien Boilley a écrit :

 Pour moi, le node "place=" de la commune déléguée qui est chef-lieu
 de la commune nouvelle doit prendre le nom de la commune nouvelle,
 avec en old_name le nom ancien. Sauf peut-être si le nom change
 beaucoup...
>>>
>>> Pas de mon point de vue.
>>> On change le nom de la commune dans la relation, mais on ne touche
>pas
>>> au reste, sauf s'il y changement des pancartes sur le terrain.
>
>D'accord avec Stéphane, il arrive qu'aucun node place=* ne porte le nom
>
>de la commune. Ce dernier nom est porté par la relation admin_level=8, 
>et dans le cas présent c'est bien à lui de changer, au moins à court
>terme.
>
>vincent


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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

[Tyndare]

Le 12 décembre 2015 à 09:45, Damouns  a écrit :
> Pour rappel les communes supprimées gardent en fait un certain statut ce qui
> se traduit par passer en admin_level=10 leurs limites et leur relation
> (certains penchent plutôt pour un admin_level=9 mais si un consensus est
> trouvé on pourra toujours les basculer).

Bonjour,
Je regarde ce sujet pour la première fois mais en fait je me pose
pleins de questions sur cette histoire de commune nouvelle.
Je crois avoir compris pour les limites, mais pour les tag place=, que
faut-il faire dans le cadre de la création d'une commune nouvelle avec
commune déléguée ?
On créée un nouveau point place= pour la commune nouvelle ?
Est-ce que place=municipality est adapté ?
Doit-on rétrograder les anciens place=village ou faut il les conserver
intactes ?
Est-ce qu'il faut différencier le cas de la commune fusionnée prenant
le statut de commune déléguée (avec mairie annexe) de celle ne le
prenant pas étant donné que sa mairie  devient la mairie principale de
la commune nouvelle ?
Faut-il conserver les limites des communes fusionnées n'obtenant pas
le statut de commune déléguée ?

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

Re: [OSM-talk-fr] Communes nouvelles - fusion de communes

[Tyndare]

Le 12 décembre 2015 à 13:51, Damien Boilley  a écrit :
> Voici mes réponses mais je ne sais pas si ça fait consensus :

Ok merci, ça me parait bien

>> Est-ce que place=municipality est adapté ?
>
> Je ne connais pas...

D'après le Wiki http://wiki.openstreetmap.org/wiki/FR:Key:place
place=municipality: Selon le pays un ensemble arbitraire de hameaux,
villages, et villes peuvent former une unité administrative. Parfois
les membres d'une unité rejoignent une autre municipalité en tant que
résultat d'un processus politique. Au sein d'une municipalité les
établissements sont beaucoup moins connectés que ceux présents à
l'intérieur d'une cité, où ils ont grandi connectés à travers le
temps.

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

Re: [OSM-talk-fr] Extractions du cadastre indisponibles

[Tyndare]

Je viens de réduire le facteur de simplification à 0.1

Le 12 novembre 2015 13:12,   a écrit :
> Vous utilisez quelle valeur d'habitude ?
> Le 12 novembre 2015 09:28:02 GMT+01:00, Christian Quest
>  a écrit :
>>
>> ... et un peu trop de simplification ?

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

Re: [OSM-talk-fr] Extractions du cadastre indisponibles

[tyndare]

Merci d'avoir relayé cette discussion.

Le bug soulevé concernant les blocs de plusieurs bâtiments pourrait 
correspondre à celui que j'ai corrigé entre mardi et mercredi:
http://trac.openstreetmap.fr/ticket/730
Il faudrait un exemple précis pour vérifier.

Pour la simplification, oui elle est assez agressive (plus gênant pour les 
formes rondes que les lignes droites), elle correspond a une valeur 
simplify-way.max-error=0.2

J'ai pour habitude de rerendre plus rond manuellement les bâtiments qui ont un 
intérêt esthétique (bâtiments publiques ou religieux)
Vous utilisez quelle valeur d'habitude ?




Le 12 novembre 2015 09:28:02 GMT+01:00, Christian Quest 
<cqu...@openstreetmap.fr> a écrit :
>Il semble y avoir quelques petits défauts dans les changements
>récents...
>voir sur http://forum.openstreetmap.fr/viewtopic.php?p=9752#p9752
>
>Problème avec multipolygones et un peu trop de simplification ?
>
>Le 8 novembre 2015 17:49, Tyndare <tynd...@wanadoo.fr> a écrit :
>
>> Normalement s'ils sont alignés il sont supprimés lors de la
>> simplification des chemins des bâtiments, je n'ai pas tout compris à
>> l'algorithme de simplification de JOSM que je me suis contenté de
>> recopier, mais je crois que le paramètre 0.2 doit aussi correspondre
>à
>> une distance de 20cm.
>> J'ai corrigé quelques pb depuis vendredi (problème de projection, bug
>> empêchant la génération du fichier -houses-simplifie.osm pour
>> certaines villes),
>> mais n'hésitez pas a remonter ceux que vous rencontrez par un message
>ici
>> ou là:
>>
>>
>http://trac.openstreetmap.fr/newticket?component=export%20cadastre=tyndare
>>
>>
>> Le 8 novembre 2015 12:09, Gaël Simon <gael.simon...@gmail.com> a
>écrit :
>> > Bonjour,
>> > Une source de simplification supplémentaire pourrait être de
>supprimer
>> les points "alignés" (à moins de 20 cm ?). Ça pourrait éviter de
>surcharger
>> la base avec des points inutiles, générés souvent aux limites de
>parcelle.
>> >
>> > Gaël
>>
>>
>> Le 8 novembre 2015 12:09, Gaël Simon <gael.simon...@gmail.com> a
>écrit :
>> > Bonjour,
>> > Une source de simplification supplémentaire pourrait être de
>supprimer
>> les points "alignés" (à moins de 20 cm ?). Ça pourrait éviter de
>surcharger
>> la base avec des points inutiles, générés souvent aux limites de
>parcelle.
>> >
>> > Gaël
>> >
>> > Le 6 nov. 2015 à 23:32, Tyndare <tynd...@wanadoo.fr> a écrit :
>> >
>> >> Le 6 novembre 2015 22:37, David Crochet <david.croc...@free.fr> a
>> écrit :
>> >> Le 06/11/2015 21:59, Tyndare a écrit :
>> >>>
>> >>>  - merge (M) des nœuds proches (20 cm)
>> >>
>> >>
>> >> En gros :
>> >>
>> >> si un point déjà existant dans la base OSM se trouve à moins de x
>cm
>> d'un
>> >> point de l'extraction de la base cadastre, alors c'est le même.
>> >> c'est ca ?
>> >
>> > En fait non, il n'y a aucun lien avec la base OSM, c'est juste une
>> > simplification du fichier extrait du cadastre, qui contient souvent
>> > des points beaucoup trop proches les uns des autres pour que sa
>vaille
>> > la peine de les distinguer.
>> >
>> >>
>> >>>  - join (J) des nœuds au chemin proche (20 cm)
>> >>
>> >> si un point déjà existant dans la base OSM se trouve à moins de x
>cm
>> d'un
>> >> chemin de l'extraction de la base cadastre, alors ajoute ce point
>au
>> chemin,
>> >> comme cela la prochaine fois, ça fera simplement un "merge".
>> >> j'ai bien compris ?
>> >
>> > Non, il ne s'agit toujours pas de merge avec les données de la base
>OSM.
>> > Le merge est un sujet bien plus compliqué qui est traité ici:
>> > - https://github.com/jecor/bati-fusion
>> > ou là:
>> > - https://github.com/sebastien-bugzilla/BatiOsm
>> >
>> > Ici je ne parle toujours que d'extraction brute des données du
>> > cadastre, rien de changé par rapport a avant.
>> >
>> >>
>> >>>  - simplify (Shift-Y) des chemins avec un threshold=0.2
>> >>
>> >> en d'autres termes ?
>> >
>> > Je fais juste référence à la fonction JOSM de simplification des
>> > chemins, comme expliqué sur le Wiki d'import semi automatique du
>bâti:
>> >
>>
>http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2ti

Re: [OSM-talk-fr] Import canaux cadastre pas terrible

[Tyndare]

Pour des cours d'eau aussi étroit il est conseillé de carrément remplacer
les surfaces importées du cadastre par un simple filaire.
Tu peux soit tout supprimer et tout retracer, soit couper la surface à ses
deux extrémités, en garder qu'une seule rive et la repositionner
manuellement au centre de l'ancienne surface. Le cadastre n'étant pas
toujours fiable pour l'eau il faut aussi s'assurer que le tracé est
cohérent vis à vis des images satellite Bing (surtout ne pas hésiter à
corriger et simplifier un peu le tracé importé).
Ensuite il faut choisir la bonne valeur pour l'attribut waterway (par
exemple stream), s'assurer que le chemin est dans le bon sens et le
connecter correctement aux autres cours d'eau (rajouter les sections
manquantes si nécessaire).

Nommer les rivières et créer une relation associée de type waterway est un
plus, voire la page du Wiki:
http://wiki.openstreetmap.org/wiki/FR:Relation:waterway
On peut pour ça s'aider de la couche BD Carthage, disponible par défaut je
crois avec JOSM, sur iD il faut ajouter un fond de carte personnalisé (menu
à droite) en indiquant l'URL suivant:
http://{switch:a,b,c}.tile.openstreetmap.fr/route500hydro/{zoom}/{x}/{y}.png




Le 10 novembre 2015 20:03, Léo Serre  a écrit :

Bonjour à tous,
>
> Je me considère comme un contributeurs novice (dans le sens que je n'ose
> toucher qu'aux trucs simples).
> Je suis face à un import qui a importé des trucs pas très beaux :
>
>
> http://osmose.openstreetmap.fr/fr/map/#zoom=13=43.7347=1.7224=1220=3=Mapnik=T
>
> Savez-vous ce que je peux faire pour corriger toutes ces erreurs dues à
> ces canaux importés comme des aires ?
>
> Merci d'avance.
>
> Léo
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] relation associatedStreet

[Tyndare]

En fait je me suis trompé, en relisant l'historique
http://www.openstreetmap.org/way/307302039/history
le contributeur Pinpin avait l'aire de dire que le nom avait était
vérifié sur le terrain, avec un "z", mais le contributeur Niconil est
revenu en arrière et a introduit l'incohérence. Il faudrait le
contacter.


Le 10 novembre 2015 20:21, Tyndare <tynd...@wanadoo.fr> a écrit :
> Bonjour,
>
> Cette incohérence est effectivement une erreur, et est signalée comme
> telle par le validateur JOSM et par Osmose.
> Mais à priori le contributeur de la relation associatedStreet était
> bien conscient de cette incohérence entre le nom du chemin présent
> dans la base OSM, et le nom associé aux adresses tel qu'importé depuis
> le cadastre (celui de la relation associatedStreet), c'est pourquoi il
> à rajouté une note à ce propos sur le chemin: à vérifier sur le
> terrain.
> Si tu trouves la bonne orthographe n'hésite pas à corriger celle qui
> est erronée.
>
> A noté qu'en pratique il peut être nécessaire d'avoir une relation
> associatedStreet avec un nom différent de celui de la rue si la rue en
> question à plusieurs noms, par exemple un nom différent de chaque côté
> (cas assez fréquent en limite de commune). La rue peut avoir un
> name:left, un name:right, un name="name:left - name:right", et en
> général on créé deux relations associatedStreet, une pour chacun des 2
> noms.
>
> Tyndare.
>
>
> Le 10 novembre 2015 19:09, Laurent Combe <laurent.co...@free.fr> a écrit :
>> bonjour à tous
>>
>> depuis quelques semaines je passe une partie de mon temps à dégommer du
>> rouge sur le rendu BANO
>> pour l'instant je me concentre sur l'aspect rapprochement des voies.
>>
>> Cependant de temps en temps je jette un oeil sur ce qui se fait en terme
>> d'adresse au numero
>>
>> et je suis tombé sur ça
>> http://www.openstreetmap.org/#map=18/43.75258/1.39305
>>
>> rien de bien spécial
>> il s'agit d'un way dénommé "Chemin de Gleyses"
>>
>> mais en regardant "un peu par hasard" avec JOSM
>> je voie que la relation associatedStreet porte son propre tag name
>> et que dans ce cas la valeur est "Chemin de Gleyzes" (avec un 'z')
>>
>> je trouve cela bizarre que la relation porte
>> un tag name et indirectement au travers d'un de ses membres (le way) un
>> autre tag name
>> avec un risque possible d'incohérence comme dans ce cas
>>
>> ça me fait penser un  peu à de la double saisie...
>> j'imagine qu'osmose est capable de faire le job mais dans mon cas il ne doit
>> pas tester cela car je n'ai rien vu.
>>
>> Laurent
>>
>>
>> ___
>> 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] relation associatedStreet

[Tyndare]

Bonjour,

Cette incohérence est effectivement une erreur, et est signalée comme
telle par le validateur JOSM et par Osmose.
Mais à priori le contributeur de la relation associatedStreet était
bien conscient de cette incohérence entre le nom du chemin présent
dans la base OSM, et le nom associé aux adresses tel qu'importé depuis
le cadastre (celui de la relation associatedStreet), c'est pourquoi il
à rajouté une note à ce propos sur le chemin: à vérifier sur le
terrain.
Si tu trouves la bonne orthographe n'hésite pas à corriger celle qui
est erronée.

A noté qu'en pratique il peut être nécessaire d'avoir une relation
associatedStreet avec un nom différent de celui de la rue si la rue en
question à plusieurs noms, par exemple un nom différent de chaque côté
(cas assez fréquent en limite de commune). La rue peut avoir un
name:left, un name:right, un name="name:left - name:right", et en
général on créé deux relations associatedStreet, une pour chacun des 2
noms.

Tyndare.


Le 10 novembre 2015 19:09, Laurent Combe <laurent.co...@free.fr> a écrit :
> bonjour à tous
>
> depuis quelques semaines je passe une partie de mon temps à dégommer du
> rouge sur le rendu BANO
> pour l'instant je me concentre sur l'aspect rapprochement des voies.
>
> Cependant de temps en temps je jette un oeil sur ce qui se fait en terme
> d'adresse au numero
>
> et je suis tombé sur ça
> http://www.openstreetmap.org/#map=18/43.75258/1.39305
>
> rien de bien spécial
> il s'agit d'un way dénommé "Chemin de Gleyses"
>
> mais en regardant "un peu par hasard" avec JOSM
> je voie que la relation associatedStreet porte son propre tag name
> et que dans ce cas la valeur est "Chemin de Gleyzes" (avec un 'z')
>
> je trouve cela bizarre que la relation porte
> un tag name et indirectement au travers d'un de ses membres (le way) un
> autre tag name
> avec un risque possible d'incohérence comme dans ce cas
>
> ça me fait penser un  peu à de la double saisie...
> j'imagine qu'osmose est capable de faire le job mais dans mon cas il ne doit
> pas tester cela car je n'ai rien vu.
>
> Laurent
>
>
> ___
> 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] relation associatedStreet

[Tyndare]

Le 10 novembre 2015 20:38, Laurent Combe  a écrit :
> Niconil
> c'est moi

Ça simplifie grandement les choses pour résoudre le conflit ;-)

> La bonne nouvelle : j'ai accès au tableau de classement de la voirie de la
> commune.
> Après vérification c'est effectivement la version avec un 'z'
> je corrige ...

Vu que sur le cadastre le nom est mal orthographié avec un 's', ça
aurais était bien je pense de laisser la note ou de la remplacer par
le plus classique source:name=survey histoire de lever l'incohérence
avec le tag source actuel et dissuader d'autres
 tentatives de changement dans le futur.

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

Re: [OSM-talk-fr] Tuto pour les ronds points

[Tyndare]

Les astuces qui simplifient la vie avec JOSM c'est de tracer un chemin
entre 2 points pour représenter la diagonale du rond-point et de
cliquer dans le menu Outils/Créer un Cercle (Maj-O), ensuite on peut
utiliser les combinaisons de touches Controle-Shift ou Controle-Alt
pour changer avec la souris l'orientation ou la taille du cercle.
Sinon il y a le préréglage Préréglages/Routes/Routes/Giratoire (pas
besoins de précisé qu'il est a sens unique, c'est toujours le cas par
défaut)
L'important c'est de bien faire les connexions avec les routes arrivant dessus.

Le 10 novembre 2015 21:03, Ludovic Hirlimann  a écrit :
> J'aimerais ajouter un ou deux ronds points, avec soit jsom ou l'intreface
> web de base. Y a un tuto quelquepart ?
>
> Ludo
>
> --
> http://sietch-tabr.tumblr.com/
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>

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

Re: [OSM-talk-fr] Extractions du cadastre indisponibles

[Tyndare]

Normalement s'ils sont alignés il sont supprimés lors de la
simplification des chemins des bâtiments, je n'ai pas tout compris à
l'algorithme de simplification de JOSM que je me suis contenté de
recopier, mais je crois que le paramètre 0.2 doit aussi correspondre à
une distance de 20cm.
J'ai corrigé quelques pb depuis vendredi (problème de projection, bug
empêchant la génération du fichier -houses-simplifie.osm pour
certaines villes),
mais n'hésitez pas a remonter ceux que vous rencontrez par un message ici ou là:
http://trac.openstreetmap.fr/newticket?component=export%20cadastre=tyndare


Le 8 novembre 2015 12:09, Gaël Simon <gael.simon...@gmail.com> a écrit :
> Bonjour,
> Une source de simplification supplémentaire pourrait être de supprimer les 
> points "alignés" (à moins de 20 cm ?). Ça pourrait éviter de surcharger la 
> base avec des points inutiles, générés souvent aux limites de parcelle.
>
> Gaël


Le 8 novembre 2015 12:09, Gaël Simon <gael.simon...@gmail.com> a écrit :
> Bonjour,
> Une source de simplification supplémentaire pourrait être de supprimer les 
> points "alignés" (à moins de 20 cm ?). Ça pourrait éviter de surcharger la 
> base avec des points inutiles, générés souvent aux limites de parcelle.
>
> Gaël
>
> Le 6 nov. 2015 à 23:32, Tyndare <tynd...@wanadoo.fr> a écrit :
>
>> Le 6 novembre 2015 22:37, David Crochet <david.croc...@free.fr> a écrit :
>> Le 06/11/2015 21:59, Tyndare a écrit :
>>>
>>>  - merge (M) des nœuds proches (20 cm)
>>
>>
>> En gros :
>>
>> si un point déjà existant dans la base OSM se trouve à moins de x cm d'un
>> point de l'extraction de la base cadastre, alors c'est le même.
>> c'est ca ?
>
> En fait non, il n'y a aucun lien avec la base OSM, c'est juste une
> simplification du fichier extrait du cadastre, qui contient souvent
> des points beaucoup trop proches les uns des autres pour que sa vaille
> la peine de les distinguer.
>
>>
>>>  - join (J) des nœuds au chemin proche (20 cm)
>>
>> si un point déjà existant dans la base OSM se trouve à moins de x cm d'un
>> chemin de l'extraction de la base cadastre, alors ajoute ce point au chemin,
>> comme cela la prochaine fois, ça fera simplement un "merge".
>> j'ai bien compris ?
>
> Non, il ne s'agit toujours pas de merge avec les données de la base OSM.
> Le merge est un sujet bien plus compliqué qui est traité ici:
> - https://github.com/jecor/bati-fusion
> ou là:
> - https://github.com/sebastien-bugzilla/BatiOsm
>
> Ici je ne parle toujours que d'extraction brute des données du
> cadastre, rien de changé par rapport a avant.
>
>>
>>>  - simplify (Shift-Y) des chemins avec un threshold=0.2
>>
>> en d'autres termes ?
>
> Je fais juste référence à la fonction JOSM de simplification des
> chemins, comme expliqué sur le Wiki d'import semi automatique du bâti:
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Extractions du cadastre indisponibles

[Tyndare]

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

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

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

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

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

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

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

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

Re: [OSM-talk-fr] Extractions du cadastre indisponibles

[Tyndare]

Bonjour,

Merci Vincent, je profite du retour du service
cadastre.openstreeetmap.fr pour proposer le test d'un script de
simplification du résultat d'extractions des buildings (fichier
-houses.osm)

Vous trouverez désormais un nouveau fichier généré: -houses-simplifie.osm
qui correspond en gros aux modifications suivantes:
 - merge (M) des nœuds proches (20 cm)
 - join (J) des nœuds au chemin proche (20 cm)
 - simplify (Shift-Y) des chemins avec un threshold=0.2

Le but est de réduire le nombre d'opérations manuelles nécessaires ou
d'erreurs lors de l'intégration du bâti.

Pour l'instant faites attention, j'attends vos retours pour les bug ou
problèmes que ça pourrait générer.
Je suis peut-être allé trop loin (ou pas assez selon les goûts) dans
les paramètres de simplification.

Pensez vous que cette version -simplifie.osm pourrait devenir la seule
qu'on rende disponible sur le site ?

PS: Pour ceux que ça intéresse le code est ici:
https://github.com/osm-fr/export-cadastre/blob/master/bin/cadastre-housenumber/simplify_qadastre_houses.py

Le 6 novembre 2015 20:46, Vincent de Château-Thierry
 a écrit :
> Le service est rétabli sur http://cadastre.openstreetmap.fr/ au moins en ce
> qui concerne le bâti et les limites administratives.
>
> À vous de jouer !
>
> vincent

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

Re: [OSM-talk-fr] Démolition église

[tyndare]

Tant que le bâtiment et les points de repères sont visibles dans des sources de 
données servant a cartographier, comme la cadastre et l'imagerie Bing, je 
trouve qu'il est utile de les conserver dans OSM, en remplaçant les tag 
principaux par la versions préfixée de demolished:

 http://wiki.openstreetmap.org/wiki/Lifecycle_prefix

Ça évite aussi qu'un contributeurs non local, depuis son canapé, redessine tout 
ce qu'il voit qu'il manque d'après Bing (expérience vecue)



Le 12 août 2015 08:42:09 GMT+02:00, David Crochet david.croc...@free.fr a 
écrit :
Bonjour

Le 12/08/2015 00:32, Donat ROBAUX a écrit :
 Sachant que sur les églises, il y a en général un ou plusieurs points
 géodésiques (clocher ou borne granit?

Si le point géodésique disparaît, il disparaît puisque OSM ne recense 
que l’existant.

Cordialement

-- 
David Crochet

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


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

Re: [OSM-talk-fr] name=Boulangerie

[tyndare]

Merci Jérôme pour ces détails.
Je ne connaissait pas cette classification, ça a le mérite de coller 
parfaitement à la réglementation française mais ref:FR:NAF je ne trouve pas ça 
très parlant comme tag pour les non spécialistes-francais... 


Le 28 juillet 2015 20:07:10 GMT+02:00, Jérôme Seigneuret 
jseigneuret-...@yahoo.fr a écrit :
Il n'y a pas que la cuisson qui entre en jeu il me semble. Il faut que
ce
ne soit pas surgelé et que la pâte à pain soit aussi fabriqué sur place
(pas de la pâte industrielle).

Il y a surement qu'en France que le pain est protéger ainsi. Le terme
boulangerie et ses déclinaison sont réglementés de fait. Ducoup tous
les
autres types ne peuvent pas être renseigné ainsi si on prend les code
APE
on a :

   -
   - 10.71A  Fabrication industrielle de pain et de pâtisserie fraîche
   - 10.71B  Cuisson de produits de boulangerie
   - *10.71C Boulangerie et boulangerie-pâtisserie *
   - 10.71D  Pâtisserie

Celui qui est protéger c'est celui dont l'activité correspond à du
1071C.
Même s'il ne fait pas de pâtisserie.

Après comment traiter l'info... En anglais, il n'y a pas de distinction
entre un dépôt de pain et une boulangerie...

Entre commerce et industrie oui shop= factory=

bakery=craft/industrial
Ça c'est problématique car un boulanger peut être un industriel. A
partir
du moment où il produit sur place avec des matières première ça pose
pas de
problème et c'est le cas de Marie B. ainsi ils peuvent utiliser le
terme de
boulangerie.

J'aime bien l'idée du homemade=yes/no mais ça ne dit pas que le produit
n'est pas surgelé. Ce terme pose déjà problème en restauration...

Comme c'est une spécificité en France on peut peut-être se baser sur
*ref:FR:NAF
*et laisser shop=bakery pour rester globalement cohérent




Le 28 juillet 2015 17:19, Francescu GAROBY windu...@gmail.com a écrit
:

 Pour différencier les (vraies) boulangeries des dépôts de
pain,pourquoi ne
 pas ajouter un tag du genre homemade=yes/no.
 Il resterait alors à définir si, en l'absence de ce tag, on considère
que
 c'est quand même le cas (pour ne pas changer le comportement actuel),
ou au
 contraire, si c'est seulement en ajoutant l'info qu'une boulangerie
est
 vraiment une boulangerie (cuisson sur place).

 Francescu

 Le 28 juillet 2015 17:05, Jean-Baptiste Holcroft
jb.holcr...@gmail.com
 a écrit :

 Bonjour, tu peux voir du côté de proposal sur bakery et pastry, il y
a
 une proposition sur le wiki mais depuis mon téléphone je ne retrouve
pas la
 page.

 Pour moi que ce soit un dépôt une boulangerie reste un shop=bakery.
C'est
 le fait que ce soit fait sur place qu'il faut réussir à retrouver.

 Peut-être peux-tu retrouver une discussion proche datant de l'an
dernier
 dans laquelle je suis intervenu.
 Le 27 juil. 2015 20:23, Tyndare tynd...@wanadoo.fr a écrit :

 Bonjour,

 Ma boulangerie ayant fermé pour les vacances, OSM ne m'a été que de
 peu d'utilité pour en trouver une autre étant donné que dans la
base
 de donnée, autour de chez moi, les shop=bakery référencent
 majoritairement des dépôts de pains et non pas de vraies
boulangeries.

 D'après Wikipedia [1]
 « Depuis la loi du 25 mai 1998 née sous l'impulsion de Jean-Pierre
 Raffarin, et suite au « décret pain » du 13 septembre 1993, les
 dénominations « boulanger » et « boulangerie » sont réservées aux
 professionnels artisans qui choisissent leurs matières premières,
 pétrissent la pâte, en contrôlent la fermentation ainsi que la mise
en
 forme et enfin cuisent le pain sur le lieu de vente. »

 Comme les name=Boulangerie ont tendance à se faire caviarder
d'OSM
 pour cause de généricité [2]
 Qu'elle est la bonne façon de tagger (et donc de trouver) une vraie
 Boulangerie par oppositions aux dépôts de pains qui ne font que
le
 cuire sur place ?

 trollSi on suit la loi, faudrait-il par sécurité retagger
 automatiquement tous les shop=bakery de France qui n'ont pas
 Boulangerie ou Boulanger dans leur nom ou description en shop=bread
 ?/troll

 Faudrait-il rajouter un tag pour préciser que le pain est fabriqué
sur
 place ?
 Je n'ai rien trouvé sur le wiki, je pensais à
 craft=bakery (19 dans le monde d'après taginfo)
 bakery=craft/industrial
 homemade=yes/no (pourrait aussi s'appliquer aux fait maison
des
 restaurants mais en fait cet dénomination sonne tellement marketing
 qu'elle ne me parait pas correcte)

 Existe-t-il d'autres solutions ou avez-vous d'autres idées ?


 Tyndare.


 [1] https://fr.wikipedia.org/wiki/Boulanger
 [2]

https://lists.openstreetmap.org/pipermail/talk-fr/2014-December/thread.html#74187

 ___
 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




 --
 Francescu

 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https

Re: [OSM-talk-fr] name=Boulangerie

[Tyndare]

Ah oui effectivement il y a beaucoup de choses très intéressantes dans cette 
proposition, merci Jean-Baptist.
http://wiki.openstreetmap.org/wiki/Proposal/Shop%3Dbakery,confectionery

produced_on_site=yes/only/most/some/few/no 
Whether goods were produced at the location where they are sold. 
craft=*
The shop employs a certified specialist, 
or meets regulatory requirements for restricted
use of names or certification


produced_on_site=yes + craft=bakery pourrait donc être considéré comme 
équivalent à notre réglementation pour Boulanger/Boulangerie ?


De : Jean-Baptiste Holcroft 
Bonjour, tu peux voir du côté de proposal sur bakery et pastry, il y a une 
proposition sur le wiki mais depuis mon téléphone je ne retrouve pas la page.

Pour moi que ce soit un dépôt une boulangerie reste un shop=bakery. C'est le 
fait que ce soit fait sur place qu'il faut réussir à retrouver.

Peut-être peux-tu retrouver une discussion proche datant de l'an dernier dans 
laquelle je suis intervenu.


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

Re: [OSM-talk-fr] name=Boulangerie

[tyndare]

Le 28 juillet 2015 22:07:34 GMT+02:00, Jérôme Seigneuret 
jseigneuret-...@yahoo.fr a écrit :

D'après la proposition si tu veux que ce soit un vrai boulanger (pas de
surgelé) il faut
*bread:artisan=only*
*bread:produced_on_site=only*
Il me semble que la réglementation n’impose pas que la pâtisserie soit
fait
sur place

* Places that are widely accepted as shops should not be transformed to
crafts*

*Donc on ne met pas craft vu que c'est déjà un shop=bakery*

Je ne voulais pas transformer en craft mais rajouter craft, par rapport a la 
conformite à la réglementation qui impose une façon de faire proche de 
l'artisanat.



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

[OSM-talk-fr] name=Boulangerie

[Tyndare]

Bonjour,

Ma boulangerie ayant fermé pour les vacances, OSM ne m'a été que de
peu d'utilité pour en trouver une autre étant donné que dans la base
de donnée, autour de chez moi, les shop=bakery référencent
majoritairement des dépôts de pains et non pas de vraies boulangeries.

D'après Wikipedia [1]
« Depuis la loi du 25 mai 1998 née sous l'impulsion de Jean-Pierre
Raffarin, et suite au « décret pain » du 13 septembre 1993, les
dénominations « boulanger » et « boulangerie » sont réservées aux
professionnels artisans qui choisissent leurs matières premières,
pétrissent la pâte, en contrôlent la fermentation ainsi que la mise en
forme et enfin cuisent le pain sur le lieu de vente. »

Comme les name=Boulangerie ont tendance à se faire caviarder d'OSM
pour cause de généricité [2]
Qu'elle est la bonne façon de tagger (et donc de trouver) une vraie
Boulangerie par oppositions aux dépôts de pains qui ne font que le
cuire sur place ?

trollSi on suit la loi, faudrait-il par sécurité retagger
automatiquement tous les shop=bakery de France qui n'ont pas
Boulangerie ou Boulanger dans leur nom ou description en shop=bread
?/troll

Faudrait-il rajouter un tag pour préciser que le pain est fabriqué sur place ?
Je n'ai rien trouvé sur le wiki, je pensais à
craft=bakery (19 dans le monde d'après taginfo)
bakery=craft/industrial
homemade=yes/no (pourrait aussi s'appliquer aux fait maison des
restaurants mais en fait cet dénomination sonne tellement marketing
qu'elle ne me parait pas correcte)

Existe-t-il d'autres solutions ou avez-vous d'autres idées ?


Tyndare.


[1] https://fr.wikipedia.org/wiki/Boulanger
[2] 
https://lists.openstreetmap.org/pipermail/talk-fr/2014-December/thread.html#74187

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

Re: [OSM-talk-fr] Cadastre et riverbank

[Tyndare]

Pas d'accord.
D'après le wiki il n'est jamais question de riverbank pour un
waterway=stream, c'est à considérer qu'a partir de waterway=river et
seulement si elle est suffisamment large.
Un waterway=stream c'est un ruisseau au dessus duquel une personne bien
portante est capable de sauter (donc pas trop large). La précision d'un
riverbank ne serait qu’illusoire à ce niveau de détail (surtout en
montagne), il faut le supprimer. On peut mettre un tag width sur le
waterway si on veut préciser sa largeur.

De plus il faut faire attention aux données du cadastre, elles ne sont pas
homogènes et les riverbanks importés ressemblent parfois au lit ordinaire,
parfois au lit majeur.
Le 3 juin 2015 09:07, Jérôme Seigneuret jseigneuret-...@yahoo.fr a
écrit :

 Salut,
 Les riverbank sont à conserver pour les cours d'eau! il faut ajouter un
 filaire par dessus en son centre pour y mettre le nom du cours d'eau et
 autre. Je viens de retoucher une partie vers argelès sur mer. Reste à
 refaire la relation pour le cours d'eau La Riberette. J'ai utiliser la BD
 Carthage mais le cours d'au à un nom différent suivant la portion parcouru
 d'apèrs Wikipédia... A voir donc pour les locaux.

 Le 3 juin 2015 00:44, Balaitous balait...@mailoo.org a écrit :

 Bonjour,

 J'essaye de corriger les imports de riverbank du cadastre.

 Pour les petits cours d'eau (j'interviens essentiellement sur les
 Pyrénées ariégeoises), j'ai tendance à supprimer le riverbank du
 cadastre. J'ai constaté que d'autres contributeurs laissent le riverbank
 et ajoutent un warterway=stream au milieu.

 Y a t-il des recommandations à ce sujet ?

 Balaitous


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



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


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

Re: [OSM-talk-fr] SeFaireConnaitre :(

[Tyndare]

Les quelques ajouts que j'ai regardé ces derniers jour m'ont semblé
correctement repositionnés, j'en ai pas vu qui mériteraient vraiment un
revert.
 Le 3 juin 2015 09:51, Pierre-Yves Berrard pierre.yves.berr...@gmail.com
a écrit :

 La difficulté est qu'il y a un changeset par POI, donc autant de reverts.

 2015-06-03 9:34 GMT+02:00 Tony Emery tony.em...@yahoo.fr:

 Du coup, qui s'occupe du Revert ?



 -
 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/SeFaireConnaitre-tp5846293p5846908.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


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

Re: [OSM-talk-fr] comment taguer des panneaux biche (dot com) / animaux sauvages

[Tyndare]

Le 2 juin 2015 10:34, Florian LAINEZ winner...@free.fr a écrit :


 Le 1 juin 2015 22:07, Christian Quest cqu...@openstreetmap.fr a écrit :

 un tag pour indiquer de quel côté de la route se trouve le panneau ???
left/right/both/above ???


 Je ne trouve rien sur le wiki ni sur tag info pour cela. Il faut donc
créer. Peut être tout simplement position=left/right/both/above ?

Ça n'existe peut être pas car non nécessaire, un highway=traffic_sign peut
être mis a côté de la route à la position exacte du panneau.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] comment taguer des panneaux biche (dot com) / animaux sauvages

[Tyndare]

Le 2 juin 2015 23:16, David Crochet david.croc...@free.fr a écrit :
 Bonjour

 Le 02/06/2015 11:42, François Lacombe a écrit :

 donc le simple fait de placer le panneau d'un côté du chemin indique à
 quel sens il s'applique


 Tout comme le panneau (et donc son étiquette)  highway=stop ou
 highway=give_way vis-à-vis de la distance le séparant d'une intersection, et
 pourtant il est placé sur le chemin et non à coté

highway=give_way ce n'est pas un panneau c'est une restriction. A la
restriction highway=give_way sur le way correspond le panneau
traffic_sign=give_way sur le bord de la route.
Le panneau se tag surtout pour des raisons de documentation, la
restriction elle se tag sur le way.
Donc moi je mettrais un noeud traffic_sign a la position exacte du
panneau biche, sur le ou les bords de la route,
et je mettrais hazard=animal_crossing sur toute la section du way concernée.

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

Re: [OSM-talk-fr] BANBO = BANO belge : vos ideés pour faire un BANO belge svp. Merci

[Tyndare]

Le 27 mai 2015 08:26, Christian Quest cqu...@openstreetmap.fr a écrit :
 si on a un noeud addr:* et aussi un ou plusieurs POI à la même adresse (par
 exemple des commerces) il faut utiliser contact:* pour indiquer leur
 adresse, mais pas addr:*... malheureusement de nombreuses appli mobiles ne
 procèdent pas comme ça :(

Cela correspond à la proposition Bremen_Schema[1] mais si on se fie au
wiki ce n'est toujours pas officiellement reconnu donc difficile
d'accuser les applis.
Intuitivement j’interpréterais plutôt
contact:street,contact:housenumber,... comme une adresse pour
contacter l'entité par courrier par opposition à une adresse physique
qui serait différente.
L'utilisation de contact:* a le mérite d'être simple, mais pour éviter
la redondance on peut aussi préciser une unique adresse (addr:*) sur
un polygone englobant tout les POIs concernés, ou alors il y a une
proposition pour l'utilisation d'une relation provides_feature[2]

[1] http://wiki.openstreetmap.org/wiki/House_numbers/Bremen_Schema
[2] http://wiki.openstreetmap.org/wiki/Relations/Proposed/Provides_feature

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

Re: [OSM-talk-fr] Bano, BAN, Ripart et IGN

[Tyndare]

J'ai essayé d'ouvrir un fichier shapefile de la BAN avec JOSM et de
regarder ce que ça apportait en plus par rapport aux adresses du
cadastre pour une petite ville.
En terme d'exhaustivité c'est incomparablement meilleur.
Si on fait abstraction de tous les numéros  5000 , les numéros en
plus me semblent assez fiables quand à leur existence réelle.
Par contre en terme de géolocalisation je suis plutôt déçus. Sans
autre source d'information ça vas souvent être difficile de contribuer
directement à OSM avec ces données, il y a trop souvent une maison
d'écart voire plus.
Avec les données du cadastre on pouvait sans ambiguïté rattacher un
numéro a sa parcelle donc à une maison ou un immeuble, avec les
données que la BAN apporte en plus c'est bien plus sujet à erreur à
mon avis, je déconseillerais donc de rattacher les adresses de la BAN
à des bâtiments sans une autre source d'info pour corroborer.
Pour l'instant je n'ai pas assez confiance pour viser une intégration
semi automatique à partir de la BAN.


Le 24 avril 2015 02:25, Jérôme Amagat jerome.ama...@gmail.com a écrit :
 J'ai regarder un peu le rendu BANO :
 Alors déjà juste avec les numéros et pas les noms de rue c'est difficile de
 ce rendre compte à part dans sa rue.
 Sinon, et bien beaucoup plus de points malheureusement beaucoup sont des
 5000 ou 6000 et quelques donc pas des numéros.
 Sinon je trouve que ça apporte beaucoup de numéro dans des lotissements pas
 très vieux ou il n'y avait rien dans bano. des ajouts aussi dans des rues
 pauvres en numeros dans bano qui ont l'air justes.
 Sinon dans les communes vide dans bano des points gris apparaissent mais
 5XXX pour la plupart, j'ai regarder les nom de rue et là, pareil, pas grand
 chose d'utile là ou j'ai regarder, c'est le nom de lieu dit donné dans le
 cadastre. donc ces points sont inutiles, à part pour nous dire qu'il y a une
 porte pas loin. Peut être est-il possible de faire un tri à ce niveau pour
 enlevé les point qui n'ont pas de numéro et où ce qui est censé être la rue
 n'est pas un nom de voie.

 Ces numéro 5XXX veulent dire quelque chose de particulier où c'est juste une
 adresse où ils n'ont pas le numéro et ils ont besoin de ça pour faire
 correspondre avec une personne?




 ___
 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] Vie et mort des magasins

[Tyndare]

Le 16 févr. 2015 10:41, Xavier Cremaschi omega.xav...@gmail.com a écrit
:
 PS : question bonus : les magasins qui n'existent plus doivent-ils être
conservés d'une façon ou d'une autre ? ou l'historique des commits
suffit-il ?

Si le magasin a juste fermé je conserve le nœud mais je change le tag en
disused:shop=yes
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Vie et mort des magasins

[Tyndare]

Même constat pour ma part mais j'ai grand espoir qu'on pour ça tirer partie
de la mise en open data du registres des tribunaux de commerces (
infogreffe.fr) qui fait je crois partie de la loi Macron.
 Le 16 févr. 2015 10:46, Francescu GAROBY windu...@gmail.com a écrit :

 Bonjour,
 Être toujours à la page, en ce qui concerne les magasins est, selon moi,
 le truc le plus dur à faire dans OSM : il y a un tel turn-over que tu peux
 repasser 6 mois après et refaire une bonne partie d'une rue commerçante...
 Une solution pourrait être d'entrer en contact avec l'association locale
 des commerçants, quand elle existe, et leur proposer de tenir eux-mêmes à
 jour OSM, ou voir s'ils ne publient pas une liste exhaustive et à jour des
 commerces (avec adresse, nom, type de commerce, coordonnées, ...).

 Francescu

 Le 16 février 2015 10:40, Xavier Cremaschi omega.xav...@gmail.com a
 écrit :

 Bonjour,
 je croyais la carte d'Antibes assez complète, mais en faisant plus
 attention je me rends compte que beaucoup de restaurants et de magasins du
 centre ville changent régulièrement (beaucoup se lancent et ne tiennent pas
 la durée on dirait).

 Vous avez une stratégie pour gérer ça ? À part un quadrillage
 systématique et régulier de la zone, qui serait assez contraignant. On peut
 consulter les commerces qui se créent/qui font faillite quelque part pour
 affiner le travail en amont ?

 Xavier.
 PS : question bonus : les magasins qui n'existent plus doivent-ils être
 conservés d'une façon ou d'une autre ? ou l'historique des commits
 suffit-il ?

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




 --
 Francescu

 ___
 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] Vie et mort des magasins

[Tyndare]

Quelle est la licence d'utilisation de ces données ?
Bonjour

Le 16/02/2015 11:55, David Crochet a écrit :

 Existe t'il l'inverse, c'est à dire l'enregistrement d'une entreprise ?


Ha oui, je viens de trouver :
http://www.score3.fr/liste-creations-entreprises.shtml

O_o

Cordialement

-- 
David Crochet

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

Re: [OSM-talk-fr] [BANO] noms non trouvés sur cadastre

[Tyndare]

hrtp://cadastre.openstreetmap.fr/adresses exporte aussi en fichier .osm la
pluspart des noms dessinés sur l'export pdf.
Le 2 janv. 2015 14:31, David Crochet david.croc...@free.fr a écrit :

 Bonjour

 Le 02/01/2015 14:08, Art Penteur a écrit :

 Ce cas là est, a mon avis, un manque du cadastre, pas de FANTOIR.


 Il y a un piège dans le cadastre en ligne :
 Si je comprend bien le principe, il (JOSM) télécharge, au format image,
 des carrées de données enregistré en vectoriel. Chaque image étant fabriqué
 indépendamment des autres : il y a parfois des morceau de texte sur l'un
 des carrées puis plus rien sur l'autre, on zoom, tiens, c'est l'inverse, on
 dézomme, tout le texte apparait.

 La solution : demander, sur le cadastre en ligne, un export en PDF : il
 est encore plus net que les images téléchargé par JOSM. Ce PDF, je le fout
 en arrière plan dans JOSM ou alors je travaille côte-côte.

 Cordialement

 --
 David Crochet

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

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

[OSM-talk-fr] Changements massif sur les noms génériques de shop et amenity

[Tyndare]

On parlais récemment de changements massifs non discutés.
Personnellement je ne suis pas d'accord avec ce genre de changements:
https://www.openstreetmap.org/changeset/27664504
https://www.openstreetmap.org/changeset/27664458
...

Quand on voyage à l'étranger et qu'on ne maitrise pas parfaitement la
langue locale c'est vraiment pratique de savoir quelle nom chercher
quand on veut repérer quelque chose, donc savoir qu'il faut qu'on
cherche une indication WC quand on cherche un amenity=toilets, ou
une devanture avec écrit en gros Boulangerie quand on cherche un
amenity=bakery c'est vraiment une information supplémentaire  et pas
tout a fait redondante.

Quel est l'avis de la communauté sur ce sujet ?

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

Re: [OSM-talk-fr] Changements massif sur les noms génériques de shop et amenity

[Tyndare]

Je ne veux pas de rajouter des noms génériques partout, je demande
juste de ne pas supprimer les noms correspondant à la réalité du
terrain, à ce qui est écrit sur la devanture du magasin, ou du
service.

On cherche une fonctionnalité quand on est sur internet ou dans son
smartphone, mais quand on est sur place c'est bien pratique de
connaitre le nom effectif pour le trouver.


Le 24 décembre 2014 11:11, Vincent Pottier vpott...@gmail.com a écrit :
 Le 24/12/2014 10:47, Éric Gillet a écrit :

 Je suis totalement d'accord avec ces changements. Le tag name représente
 le nom des entités, et non pas leur fonction, qui est représentée dans les
 tags tels que shop=bakery. Sinon il faudrait rajouter name=* sur tout les
 entités...

 +1
 Si un étranger cherche des toilettes ou un boulanger sans savoir le terme
 local, l'application doit pouvoir lui proposer amenity=toilets | shop=bakery
 dans sa langue, avec la traduction française, en javanais...
 Le gars recherche une fonctionnalité, pas un nom.

 Je retire souvent des tags name=parking sur les parkings...
 --
 FrViPofm


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

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

Re: [OSM-talk-fr] Changements massif sur les noms génériques de shop et amenity

[Tyndare]

Je ne suis toujours pas d'accord, dans un village que je connais bien,
des wayside_cross il y en a plusieurs, mais si vous demandez aux gens
le Calvaire, dans leur esprit il n'y en qu'un et ça correspond à une
croix bien particulière.
Dans le même genre, un cas avec deux cimetières, celui historique que
tout le monde appelle le Cimetière, et le nouveau appelé Cimetière
Sud, c'est d'ailleurs bien comme ça qu'il sont indiqués sur les
panneaux de direction, mais le cimetière historique n'aurais pas le
droit d'avoir de nom, sous prétexte que son nom est générique et
correspond aussi à une description, alors que l'autre si, je ne trouve
pas ça logique.

Le 24 décembre 2014 12:50, Yves Pratter yves.prat...@gmail.com a écrit
 Dans le même genre, je vire le name=calvaire surtout si on a déjà 
 historic=wayside_cross (sinon je le rajoute).

 Donc +1 pour virer les noms qui sont des descriptions :-)

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

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

Re: [OSM-talk-fr] Rapprochement IGN / La Poste / OSM-FR sur la Base Adresse Nationale

[Tyndare]

Ah oui, chapeau bas !

Le 14 novembre 2014 18:53, Christian Quest cqu...@openstreetmap.fr a écrit :
 J'ai donc signé ce soir une déclaratio d'intention avec l'IGN et La Poste
 pour travailler ensemble sur la Base Adresse Nationale en présence de
 Thierry Mandon et d'Henri Verdier.

 Voici l'essentiel:

 Les Parties, qui sont concernées par le développement d’une base d’adresses
 géolocalisées, déclarent leur intention de coopérer au développement d’une
 base adresse nationale adaptée aux besoins des particuliers, des
 collectivités publiques et des professionnels.

 En particulier, elles souhaitent :
 - définir un dispositif collaboratif de collecte de l'adresse tant auprès
 des acteurs publics que des acteurs privés et du grand public ;
 - créer une base de données d’adresses unique, de référence, dont la qualité
 est attestée par l’IGN et La Poste ;
 - diffuser ces données auprès des utilisateurs selon des licences adaptées à
 leurs besoins respectifs (licence libre ODBL, licence avec repartage des
 bases dérivées et licence payante).

 Les parties s'accordent pour tout mettre en œuvre afin que l'accord projeté
 puisse être signé d'ici le 30 mars 2015. Chaque partie conserve la liberté
 d’exploiter et de diffuser ses ressources propres dans cet intervalle.

 Une gouvernance collégiale est instituée, présidée par l’Administrateur
 général des données et réunissant les parties prenantes ainsi que le Conseil
 National de l’Information Géographique.

 Cette gouvernance définira les dispositions qui lui paraîtront les plus
 adaptées pour mener à bien les travaux ainsi que la nature des livrables à
 produire. Elle rendra compte périodiquement de l'avancée de ces travaux.


 Nous sommes donc associé à la mise en place de la fameuse BAN, qui sera
 ouverte et donc un peu BANO en même temps.

 Dans les semaines et mois qui viennent nous allons travailler sur les
 données pour compléter les bases de part et d'autre, l'idée étant qu'elles
 soient les plus proches possibles.

 Nous avons commencé par définir il y a quelques semaines avec l'IGN une Clé
 d'Interopérabilité des Adresses afin de permettre le rapprochement de la
 multitude de bases contenant des adresses. Cette clé ressemble beaucoup à
 celle qui avait été créée pour BANO... code insee _ code fantoir _ numéro _
 extension (bis/ter)

 Le BAN(O) Tour démarrera avec PACA le 4 décembre. Son objectif est
 d'expliquer ce qui va être mis en place et aussi d'avoir un maximum de
 retours des utilisateurs et producteurs de données adresse pour définir au
 mieux la plateforme nationale...

 --
 Christian Quest - OpenStreetMap France

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


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

[OSM-talk-fr] Licences à réciprocité

[Tyndare]

Pour aller à contre-courant des discussions passées à propos des
pressions sur la fondation pour adopter une licence type domaine
publique, ou aux qualifications d'OSM ultra libéral, je remonte un
article que je trouve intéressant à propos des licences à réciprocité:

http://scinfolex.com/2014/11/14/les-licences-a-reciprocite-une-piste-pour-la-transformation-numerique-de-leconomie/

C'est des licences qui obligent à contribuer si on fait un usage
commercial (contribution directe ou indirecte au(x) commun(s), ou
contribution financière), et qui envisagent pour certaines de
récompenser les contributeurs (mais ça c'est encore plus polémique car
ça casse le coté altruiste des projets collaboratifs).

Je me dis que pour l'instant ça ne pourrait que gêner l'adoption
d'OSM, mais dans le futur proche où le projet sera utilisé par toutes
les grosses boites de cartographie et que le nombre de contributeur
régressera comme c'est arrivé sur Wikipédia, c'est sûrement une piste
à considérer.

Vous pensez que ce genre de licence serait adaptable et bénéfique au
projet OSM ?

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

Re: [OSM-talk-fr] Poubelle nucléaire de Bure

[Tyndare]

Le 5 nov. 2014 18:21, Pieren pier...@gmail.com a écrit :
jseigneuret-...@yahoo.fr
 Ca rejoint ma discussion sur a partir de quand un lieu-dit existe.
 Certains disent qu'il suffit qu'un groupe utilise cette dénomination
 ou qu'il suffit que cela soit mentionné dans la presse (ou une
 certaine presse) pour valider un nom d'usage. On voit bien les
 limites de tels critères.

On voit bien les limites aussi de ta proposition d'attendre qu'un nom
soit admis par tout le monde avant de pouvoir faire apparaître quelque
chose dans OSM.

On ne peut pas rayer de la carte toute les zones conflictuelles.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Extraction cadastre et FANTOIR sur lieux-dit

[Tyndare]

Le 31 octobre 2014 10:50, Pieren pier...@gmail.com a écrit :
 Il ne peut pas y avoir de addr:housename tiré du cadastre. Sauf à
 changer la signification de ce tag.

Le choix de place=isolated_dweling me convient bien, mais dans les
exemples donnés par Christophe les noms extraits du cadastre semblent
correspondre à chaque fois à un seul numéro de maison[1], donc j'ai du
mal à comprendre où est l'incompatibilité avec le tag addr:housename,
tu peux préciser ?

[1] http://www.openstreetmap.org/#map=17/43.52703/-0.25208

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

Re: [OSM-talk-fr] Extraction cadastre et FANTOIR sur lieux-dit

[Tyndare]

Le 31 oct. 2014 17:27, Jérôme Seigneuret jseigneuret-...@yahoo.fr a
écrit :
 Dans tous les cas c'est pas un housename si il n'y a pas une belle place
comme pour les résidences (ne pas confondre avec une enseigne)

Je ne suis pas d'accord, il y a beaucoup de lieu qui ont un nom connu et
utilisé sans qu'aucune plaque ou panneau ne le mentionne.

 Le cadastre à des particularités territoriale. Même si le nom n'est que
dans une parcelle ça peut être un lieudit. Voir Saudouze sur Toujouse (32)
(Je parle de ce cas que je le connais)
 Le nom en capitale est A SAUDOUZE n'est pas mentionné sur le terrain
c'est juste pour la gestion cadastrale (ensemble de parcelles) Christophe
c'est ce dont tu parles bien différente des lieux-dits cadastraux .

Saudouze me fait penser au cas typique où le nom d'une maison
(addr:housename) de part son côté prédominant a donné son nom au lieu-dit
(A SAUDOUZE).


 Sur les planche cadastrales (observation générale), quand cela correspond
au bâtiment, il y a un trait pour le rattachement ou c'est écrit
sur le bâtiment en question ou c'est aligné sur le tracé du bâtiment.
 Le problème d'extraire les petits noms c'est de pas avoir cette dernière
info avec un point pour les repères et les traits ou le sens d'alignement
pour les nom de bâtiment.

L'extraction c'est juste pour aider mais il faut bien sur l'utiliser en
complément du fond cadastre, ca ne remplace pas.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] A partir de quand un lieu-dit existe ?

[Tyndare]

Le 30 octobre 2014 10:39, Pieren pier...@gmail.com a écrit :
 Il y a des camps de réfugiés qui exitent depuis des décennies. Et
 j'espère qu'on peut faire la difference entre un village de
 centaines/milliers de tentes qui dure des mois ou des années et un
 simple point de rendez-vous au milieu d'un pré...

Je ne sais pas si c'est exactement au même endroit mais Gazad occupe
les lieux depuis presque un an, ils ont construit un isolated_dweling
[1] et  un camp_site[2]. Ils ont même essayé de faire constater par
huissier que c'était habité. Mais vu que tout a été détruit
place=locality ne me parait pas un si mauvais tag que ça (a défaut
d'avoir un tag pour les ZAD).

[1] https://tantquilyauradesbouilles.files.wordpress.com/2013/12/barrage008.jpg
[2] 
https://2.bp.blogspot.com/-VR5XGUYs8ec/VBXU05uHczI/BZQ/Axz65IiafXg/s1600/gazad.jpg

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

Re: [OSM-talk-fr] A partir de quand un lieu-dit existe ?

[Tyndare]

Le 30 octobre 2014 10:23, Vincent Calame vincent.cal...@exemole.fr a écrit :
 Il ne faudrait pas qu'OpenStreetMap se transforme comme Wikipédia où seules
 les informations validées par d'autres sources (qui plus est des sources «
 officielles ») sont autorisées. Je trouve un peu paradoxal d'avoir d'un côté
 le discours sur « tout le monde peut contribuer » et de l'autre supprimer
 aussi rapidement une contribution (le contributeur a-t-il été contacté ?).

Bien d'accord, je ne voudrais pas qu'OSM se mette pas à faire la
police pour ne garder que la version officielle du territoire,
manquerait plus qu'on se prenne pour l'IGN tiens ;-)

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

Re: [OSM-talk-fr] A partir de quand un lieu-dit existe ?

[Tyndare]

Le 30 octobre 2014 11:38, Pieren pier...@gmail.com a écrit :
 J'espère que vous êtes quand même d'accord pour éviter que n'importe
 quel quidam puisse inventer son nom de lieu-dit et le mette dans OSM.
 Alors, au lieu de protester de manière un peu stérile, aidez-nous à
 trouver les critères qui fixerait les limites.

En dehors des sources officiels, pour moi un lieu-dits devrais pouvoir
exister dans OSM à partir du moment ou son nom est ancré dans l'usage
local, cad connu par une majorité des voisins et employé par une
proportion non négligeable d'entre eux, mais ça c'est très difficile à
vérifier à distance.

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

Re: [OSM-talk-fr] Extraction cadastre et FANTOIR sur lieux-dit

[Tyndare]

Le 30 octobre 2014 09:39, Christophe Merlet red...@redfoxcenter.org a écrit :
 Effectivement, sur la commune de Baliracq-Maumusson, le texte écrit en
 diagonale n'est pas extrait. Une analyse visuel du cadastre reste donc
 toujours utile.

Je n'avais jamais rencontré de petits noms écrits en diagonal, je
voulais mettre des règles strictes pour ne pas extraire n'importe quoi
mais manifestement c'était très con de ma part de les filtrer selon
l'angle, j'ai supprimé ce filtre.

 À l'inverse tu as extrait des noms que je n'avais pas vu moi-même et
 même plus, un nom qui n'apparait pas dans le cadastre avec JOSM !

 Donc c'est vraiment complémentaire :)

Si les noms sont en bordure de tuiles ils sont effectivement parfois
tronqués. Si ça peut être utile j'ai donc aussi mis à disposition les
mots dessinés sur le cadastre qui correspondent aux noms de rues et
noms de lieux-dits. Maintenant je génère un fichiers zip qui contient
trois fichiers .osm:
http://cadastre.openstreetmap.fr/data/064/PB090-BALIRACQ%20MAUMUSSON-mots.zip


 Sinon, ce matin j'ai eu l'idée de regarder dans le bon vieil annuaire
 des pages blanches à quoi ressemblait les adresses sur la commune de
 Baliracq-Maumusson, et effectivement, la plupart sont de type maison
 bidule.
 Donc je m’interroge encore plus sur comment faire la distinction entre
 addr:housename et place=isolated_dwelling :/

A partir du terrain, je dirais que si le nom est indiqué sur un
panneau (panneau de direction ou de lieu-dit) c'est
place=isolated_dwelling, sinon c'est addr:housename.
A partir du cadastre, avant j'aurais dit que si il y a un code FANTOIR
c'est place=isolated_dwelling, sinon c'est addr:housename, mais les
exemples que tu donnes me font douter.

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

Re: [OSM-talk-fr] Extraction cadastre et FANTOIR sur lieux-dit

[Tyndare]

J'ai rajouté le code FANTOIR pour les lieux-dits.

Pour les noms de maisons, c'est plus compliqué.
Dans les infos textuelles associées aux parcelles on ne retrouve pas
ces noms là (on n'y trouve que les adresses ou les lieux-dits).
Il faut donc se baser sur l'interprétation du dessin vectoriel du texte.
J'ai rajouté la génération d'un fichier -petits_noms.osm (il n'est pas
listé sur la page web, il faut aller le chercher dans le lien Accès
aux fichiers),
par exemple 
http://cadastre.openstreetmap.fr/data/064/PB237-GELOS-petits_noms.osm

Il contient les mots écrits en petit à l'horizontal sur le cadastre,
mais en général chaque mots est découpés donc il y aura plusieurs
nœuds si un nom est composé de plusieurs mots.
Ça ne me semble pas possible de les regrouper simplement car j'ai
trouvé des cas ou les mots sont très espacés (verticalement) et pas
alignés du tout.

J'avais déjà rencontré ces petits noms écrits en minuscules sur le
cadastre mais pour des noms de lotissements, des noms de  places
(genre place du village), des noms d'écoles ou des noms de parcs, mais
pas pour des noms de maisons. J'ai peur qu'en fait chaque commune ou
département utilise cette notation pour des choses différentes. Si ces
noms n'apparaissent pas dans le fichier FANTOIR on a aucun moyen de
vérification pour les qualifier automatiquement..

Ce fichier -petits_noms.osm est donc dangereux si des contributeurs
l'envoient tel quel sur OSM,
Dites moi si il faut mieux le supprimer ou alors comment mieux le
protéger (j'ai juste mis le flag upload=false).


Le 29 octobre 2014 20:08, Christophe Merlet red...@redfoxcenter.org a écrit :
 Le 29/10/2014 19:10, Vincent de Château-Thierry a écrit :
 Bonsoir,

 Le 29/10/2014 09:52, Christophe Merlet a écrit :

 Ne serait-il pas possible que l'appli d'extraction des adresses du
 cadastre http://cadastre.openstreetmap.fr/ ajoute le code FANTOIR sur
 les lieux-dits ?

 De plus, sur les communes sans aucun numéro de rue, on trouve à priori,
 à la place le nom des maisons écrit en plus petits.
 Ce serait pas mal d'extraire ces noms et de les mettre dans un fichier
 (isolated_dwelling ou addr:housename ?)

 À partir de quand un nom de maison devient un nom de lieu-dit ? C'est un
 clin d'oeil au fil que vient d'ouvrir Pieren, mais aussi une demande de
 cas que tu aurais repérés, je n'ai pas souvenir d'un tel distinguo entre
 noms, j'ai l'impression que les noms sont tous assimilables à des
 lieux-dits dans le cadastre.

 Prenons la commune de Baliracq-Maumusson (64090)
 Dans le Cadastre, les lieux-dits sont écrits en majuscules et ce que je
 considère être les noms de maison/propriété en minuscules.
 Souvent la maison/propriété donne son nom à la voie qui y mène.
 Les noms en minuscules sont toujours proche d'un bâtiment, alors que les
 noms en majuscules peuvent être au milieu de nul part.


 http://ftp.redfoxcenter.org/pub/RedFox/Divers/OpenStreetMap/JOSM%20-%2020141029%20-%20Lieux-dits.png

 C'est, semble t'il, une constante dans le 64.

 Ces lieux-dits en majuscules correspondent exactement aux lieux-dits
 avec un code FANTOIR sur la couche BANO (bien que n'étant pas positionné
 aux mêmes endroits)


 Prenons la commune de Gelos
 Si on lit l'histoire de la commune et que l'on regarde les cartes (issu
 du cadastre, du SIG de la CAPP et du PLU)
 http://paupyreneescommunesetpatrimoines.wordpress.com/2014/08/11/histoire-et-patrimoines-urbains-de-gelos/

 Même chose, les noms en majuscules du cadastre correspondent aux lieux
 dits avec code FANTOIR de la couche BANO. Et sur le PLU à des
 quartiers de la communes.
 Tandis que les noms en minuscules correspondent à des maison/propriété
 inclus à l'intérieur du lieux-dit... que l'on ne retrouve pas sur BANO

 Auparavant, je ne me souciais pas de ces noms en minuscules, mais je
 m'aperçois avec le temps que cela représente un véritable patrimoine
 historique et culturel qu'il serait dommage de ne pas intégrer à OSM (et
 donc de l'extraire du cadastre autant que possible...)
 Et c'est encore plus important dans les zones non numérotés.


 Pour ce qui est de l'extraction, le travail a commencé sur l'initiative
 de Tyndare, ensuite en ajoutant les lieux-dits dans BANO j'ai testé leur
 rapprochement avec Fantoir, qui est plutôt direct. Reste à consolider
 ces morceaux, en effet, pas juste vers BANO mais vers le service
 d'extraction d'adresses, en ajoutant une heuristique pour catégoriser
 les valeurs de tag place.



 Librement,
 --
 Christophe Merlet (RedFox)

 ___
 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, un projet ultralibéral ?

[Tyndare]

2014-10-10 1:13 GMT+02:00 Christian Quest cqu...@openstreetmap.fr:
 BD Adresse + BANO ça par contre c'est en gros ce sur quoi il semblait qu'on
 ait trouvé un rapprochement. La plateforme de contribution de BANO (séparée
 d'OSM) pouvant alimenter tant OSM d'un côté que l'IGN de l'autre à travers
 des termes du contributeur le permettant via une forme de double licence sur
 les données collectées.

En gros on garde des silos, c'est juste qu'ils pourront être mis à
jour petit à petit par le même guichet unique dans l'espoir d'avoir
convergé dans 20 ou 30 ans ?
Et au final l'IGN vas profiter à fond du travail collaboratif sans
rien avoir a redistribuer en échange ?

Le 10 octobre 2014 18:07, Pieren pier...@gmail.com a écrit :
 Désavantage pour BANO^2 :
 - on ne sait pas trop si les modifications seront possibles de la part
 du public. Ou même si un retour terrain autre que les administrations
 et epic est envisagé. En fait, on ne sait pas trop si OpenStreetMap
 est encore concerné, si ce n'est comme possible utilisateur des
 données.
 - licence double et suivant les sources. C'est très confus. Il serait
 alors possible d'extraire des données sous une license ou l'autre ? Ca
 veut dire des jeux de données différentes et incomplètes suivant la
 licence ? Ingérable. Aucun projet ne fonction avec une licence ouverte
 ET une licence fermée. Il faudra choisir, quitte à se couper
 complètement de l'IGN.

Je ne sais pas dans le domaine de l'open data, mais dans le domaine du
logiciel il y a plusieurs projets qui fonctionnent sur le principe de
la double licence (fermée et ouverte), MySQL ou les anciennes versions
de la bibliothèque QT par exemple. En général la société qui gère le
projet s’approprie le copyright des contributeurs pour avoir le droit
de faire ce qu'elle veut.
Comme la fondation OpenStreetMap s'approprie notre copyright quand on
contribue, elle pourrait tout a fait légalement  (si ses statuts le
lui permettent) décider de diffuser les données du projet (ou une
partie des données) sous n'importe quelle autre licence qu'ODbL (du
totalement propriétaire payant jusqu'au domaine public)
Concernant les adresses, Denis Helfer m'avait signalé ce site
http://geobretagne.fr/signalement/ qui demande à ce que les
contributions soient dans le domaine public, pour qu'il n'y ait aucun
problème pour les intégrer à n'importe quel jeu de données.

Mais je rejoins tes inquiétudes Pieren, dans l'état actuel ce problème
de licence empêcheras de se servir des données d'OpenStreetMap pour
contribuer au guichet BANO^2.
Ne se pourrait-il pas que le guichet BANO^2 n'ai même pas le droit
d'utiliser le fond de carte OpenStreetMap pour géolocaliser les
adresses ? (ou alors peut être un rendu où n’apparaisse pas les
adresses OSM) ?
Aux vu des chiffres et des annonces, on peut sérieusement se demander
si BANO^2 aura besoins du projet OpenStreetMap.
De l'opendata qui circule qu'en sens unique c'est quand même bien dommage.


Tyndare.

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

Re: [OSM-talk-fr] OpenStreetMap, un projet ultralibéral ?

[Tyndare]

Pour moi la qualification d'«ultralibéralisme» était surtout
l'expression de la crainte, notamment de la part de l'IGN, de la
disparition du service public.
La force de projets tel qu'OpenStreetMap (ou même BANO), c'est la
création de «biens communs» (non épuisable car on est dans le
numérique). Et effectivement les services publics étatiques doivent
réussir à trouver leur place dans ce phénomène populaire qui les
dépassent un peu et concurrence certaines de leur prérogatives.

Le 9 octobre 2014 15:31, Christophe Merlet red...@redfoxcenter.org a écrit :
 Le 09/10/2014 15:20, Ab_fab a écrit :
 Première réaction sans vraiment chercher à étayer : est-ce qu'OSM ne
 serait pas ultra-libéral, mais plutôt dans le sens anglo-saxon ?
 http://en.wikipedia.org/wiki/Liberalism

 (Vous avez quatre heures)

 Comme pour tout projet libre, certains essaye de catégoriser dans une
 des quelques cases avec lesquelles ils regardent le monde.
 Pour certains ce sera du communisme, pour d'autres du libéralisme, voire
 de l’ultra-libéralisme.

 Bref, ces gens là nécessite une mise à jour de leur logiciel de pensée
 pour rajouter la case Libre


 Le 9 octobre 2014 14:37, Pieren pier...@gmail.com
 mailto:pier...@gmail.com a écrit :

 Récemment, un syndicat de l'IGN a présenté OSM comme un projet à la
 limite de l'ultralibéral ([1]).
 Effectivement, on pourrait le voir comme ça puisque le projet est
 gratuit et que la plupart des contributeurs travaillent gratuitement
 (donc dans une forme d'exploitation). Mais lorsque nous présentons
 OSM, on dit souvent qu'en libérant les données géographiques, on ne
 sait pas ce qui en sera fait, ce qui permet des usages innovants ou
 inattendus. C'est en cela qu'il est, c'est vrai, le plus libéral, en
 réduisant les contraintes d'utilisation à leur stricte minimum
 (attribution, partage à l'identique) et qu'il le fait pour la planète
 entière.

 Un exemple récent illustre, de mon point de vue, parfaitement ce propos:
 Deux chercheurs français viennent de publier une étude montrant qu'en
 appliquant des méthodes d'analyses mathématiques, toutes les grandes
 villes du monde utiliseraient en fait seulement 4 types de topologies
 ([2]).

 Ce genre d'étude sur 131 villes à travers le monde serait très
 difficile sans OpenStreetMap. Car même si de nombreuses agences
 nationales ou collectivités locales publient leurs données
 géographiques avec des licences souvent compatibles pour la recherche
 (et l'éducation), leur disponibilité est loin d'être exhaustive et il
 aurait été très difficile et très long pour ces chercheurs d'obtenir
 un jeu de données assez cohérent pour être comparé sans passer par
 OSM. Ce type de recherches qui pouvait se faire auparavant à une
 échelle nationale peut maintenant s'étendre à un niveau mondial grâce
 à OpenStreetMap.
 Mais notre projet n'est pas ultralibéral dans le sens que notre
 licence OdBL empêche l'accaparement de notre travail bénévol par une
 société privée ou un groupe d'individus. Personne n'est forcé de
 travailler pour OSM et plus il y aura d'utilisations et
 d'utilisateurs, plus nos contributeurs bénévoles auront la sensation
 d'avoir oeuvré au service du public, de tous les publics, une notion
 que les services du même nom perdrent parfois de vue au profit
 d'intérêts particuliers.
 A la rigueur, on pourra bien taxer OSM de projet où règne un esprit
 libertaire ([3]), mais sans tomber non plus dans l'anarchisme ([4]).

 Pieren,
 qui ne fait partie d'aucun courant de pensée autre que le sien

 [1]
 http://cgtgeo.wordpress.com/2014/09/25/la-base-adresse-de-lign-en-danger/
 [2]
 
 http://phys.org/news/2014-10-openstreetmap-mathematics-reveals-unique-city.html
 [3] http://fr.wikipedia.org/wiki/Libertaire
 [4] http://wiki.openstreetmap.org/wiki/Vandalism



 Librement,
 --
 Christophe Merlet (RedFox)

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

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

[OSM-talk-fr] Itinéraires cyclo-touristiques de l'Ardéchoise

[Tyndare]

Bonjour,

Avant de me lancer, je souhaiterais avoir votre avis sur le caractère
approprié ou non d'ajouter des relations type=route route=bicycle pour
ce genre de parcours cycliste:

«Sur les Routes de l'Ardéchoise» vous ouvre toute l'année 13
itinéraires balisés dans les roues de la célèbre manifestation...
http://www.ardechoise.com/

Ces itinéraires sont balisés mais Il n'y a aucun aménagement cyclable,
l’intérêt est surtout touristique et sportif (Ils éditent un
topo-guide).

Est-ce qu'ils ont leur place dans OSM ?

Merci,

Tyndare.

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

Re: [OSM-talk-fr] Itinéraires cyclo-touristiques de l'Ardéchoise

[Tyndare]

Le 7 octobre 2014 14:59, Pieren pier...@gmail.com a écrit :

 S'ils sont balisés, oui. Sinon, non.


Ok merci. Je n'ai pas l'intention de vérifier sur tous les parcours
mais normalement tout est balisé [1].
J'avais eu l'autorisation de la part de l'office de tourisme de
Saint-Félicien de rentrer dans OSM leur itinéraires de randonnée
balisés, je vais demander confirmation que l'autorisation comprends
bien aussi les itinéraires de l'Ardéchoise.

[1] 
http://www.monardechoise.com/Decouvrir/Sur-les-Routes-de-l-Ardechoise/Le-balisage-sur-les-parcours

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

[OSM-talk-fr] Ajout de POI pas très bien géocodés par une agence de com

[Tyndare]

Il y a une agence de com [1], qui rajoute des POIs dont la qualité du
géocodage me parait discutable (cad équivalente à celui de Google) [2]

Les ajouts sont faits un par un, mais 1+1+1+... ça finit par faire un
import de masse.
Vous en pensez quoi ?

[1] https://www.openstreetmap.org/user/SeFaireConnaitre
[2] https://www.openstreetmap.org/node/3084157533

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

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

[Tyndare]

Je fais une proposition de nouveau format pour le fichier des noms de
lieux-dits générés depuis le cadastre, voir un exemple ici:
http://dl.free.fr/bOdG4FdS9

Les différences par rapport à avant:
- fichier zip à part
- tag place= laissé vide
- plus de fixme
- fichiers nommés lieux-dits*.osm au lieu de QUARTIERS*.osm
- LISEZ-MOI.txt
- nouveau fichier limites_lieux-dits_-_NE_PAS_ENVOYER_SUR_OSM.osm qui
contient juste des limites (un multipolygon par lieu-dit), je pense
que c'est utile pour évaluer le nombre de maisons et donc remplir le
tag place correctement (enfin pour ceux qui arrivent à comprendre le
tag place...)

J'attends vos commentaires avant de potentiellement rendre ça dispo
sur cadastre.openstreetmap.fr


Le 29 juillet 2014 13:38, Pieren pier...@gmail.com a écrit :
 2014-07-29 9:18 GMT+02:00 Christian Quest cqu...@openstreetmap.fr:
 Ce n'est pas tant le problème du tag fixme généré automatiquement, en fait
 il est bien pratique pour repérer/retrouver les imports fait en aveugle.
 Le véritable problème est bien l'envoi tel quel de données brutes qui ont
 besoin d'être revues et améliorées au préalable et qui ne l'on pas été.

 Je pense qu'il faudrait recontacter les auteurs de ces fixme et leur
 demander ce qu'ils comptent faire. Sans réponse après quelques jours :
 revert. S'ils disent qu'ils n'ont pas le temps ou laissent le job a
 d'autres : revert. En fait, ne garder que ceux qui s'engagent à
 nettoyer leur(s) commune(s) dans un délai raisonnable.
 Au delà des cas déjà présents, je ne voie pas d'inconvénient à
 remettre en ligne ce genre d'extractions avec des fixme à condition de
 bien avertir les gens qu'ils doivent nettoyer les fixme avant upload
 et de mieux surveiller leur apparition éventuelle dans la base (avec
 un revert plus rapide si les gens ne respectent pas la procédure)

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

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

[Tyndare]

Le 2 août 2014 16:32, sly (sylvain letuffe) lis...@letuffe.org a écrit :
 - nouveau fichier limites_lieux-dits_-_NE_PAS_ENVOYER_SUR_OSM.osm qui
 Miam... ça me semble avoir plus de potentiel que ça, quand je vois un bois,
 ça me semble tout à fait adapté à du surfacique.
 Je pousserais même à dire que de nombreux villages pourraient (aussi) être
 uploadé en surfacique.

Sûrement mais il faudrait arriver simplifier correctement ce fichier,
en l'état ce n'est pas utilisable.

 Le risque étant qu'il se trouvera bien un gus pour nous uploader ce fichier
 sans retouche malgré l'énorme NE_PAS_ENVOYER_SUR_OSM
 Ajout d'un tag bidon dans le but de plus facilement repérer les upload
 sauvages de ce fichier ?

Tu veux dire un tag fixme ? ;-)

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

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

[Tyndare]

Le 2 août 2014 16:44, Christian Quest cqu...@openstreetmap.fr a écrit :
 D'ailleurs dans les fichiers .osm il est possible d'ajouter un champ qui
 indique à JOSM que c'est un fichier à ne pas importer en l'état... et qui
 affichera des alertes avant tout upload.

Je l'ai mis.

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

Re: [OSM-talk-fr] import lieux-dits (avec fixme)

[Tyndare]

Le 28 juillet 2014 09:53, Pierre-Yves Berrard
pierre.yves.berr...@gmail.com a écrit :
 Est-ce quelqu'un est au courant d'un import pour les lieux-dits avec ajout
 d'un fixme à vérifier: lieu créé automatiquement à partir des adresses du
 coin.

 Il me semblait qu'on ne devait pas créer des fixme de façon automatique. Et
 la mention adresses du coin me paraît étrange. Une nouvelle source ?

Les données sont extraites automatiquement depuis les adresses des
parcelles du cadastre et disponibles ici
http://cadastre.openstreetmap.fr/

Le point est positionné au barycentre des adresses sans numéro.
Il y aurais certainement moyen d'affiner le résultat en analysant les
buildings présent dans les parcelles mais si les adresses des
parcelles ayant une maison ont un numéro elle ne seront pas prises en
compte donc ça restera imprécis.

La qualité peut varier d'une commune à l'autre, c'est pourquoi j'ai
laissé un fixme, mais on peut au choix:
 - ne plus mettre de fixme
 - ne plus rendre ces données disponibles (comme pour l'eau)

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