Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[lenny]

Le 27/07/2017 à 08:26, Christian Quest a écrit :

Oui, pas très malin comme remarque...

Le problème pour moi est plutôt indiquer l'adresse d'un POI avec 
addr:* plutôt que contact:* car le POI n'est pas "l'adresse", mais à 
l'adresse...


On a du coup des positions d'adresses souvent peu homogènes lorsqu'on 
abuse des addr:*


Ensuite ça s'aggrave quand on doublonne en un vrai point définissant 
l'adresse et un addr:* rajouté à un POI proche.


Dans les scripts BANO, il y a un traitement spécifique lorsqu'on a de 
multiples addr:* pour une même adresse, pour éliminer ceux qui 
potentiellement devraient être un contact:*, en regardant si il y a 
d'autres tags (shop, etc)... mais c'est un pis aller.


le problème quand on fait porter les addr: sur un POI, c'est (comme je 
viens de voir un exemple) un magasin (correspondant au POI) a fermé et 
un contributeur a supprimé le node qui portait le POI et les addr: 
résultat : le node adresse a disparu



Le 26 juillet 2017 à 20:34, lenny.libre > a écrit :


Par contre dans les remarques qui leur sont faites, je ne vois pas
pourquoi on devrait supprimer le addr:street, c'est nouveau ?

Le commentaire : "Le positionnement géographique permet de savoir
que le "2" fait référence à la Place de la Nuit du 6 Août 1944".
Un addr:street=Place de la Nuit du 6 Août 1944 serait donc
inutile. Si vous ne comprenez pas, allez sur place et regardez les
numéros de rue : y figurent juste un nombre, sans nom de rue. "

me parait un brin radical, car ce n'est pas toujours le cas, on
met la rue en tant que addr:street ou relation

:https://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_des_b%C3%A2timents#Ajout_des_adresses



Dans le cas que tu as cité, il faisait partie d'une relation (donc
on pouvait supprimer le addr:street) mais s'il n'y a pas de
relation, il ne faut pas le supprimer.

Maintenant SeFaireConnaitre supprime les addr:street même quand il
n'y a pas de relation
https://www.openstreetmap.org/node/507550316#map=19/44.63221/-1.14615



En autre, s'ils mettent des contact:phone, contact:fax ils
pourraient mettre contact:housenumber, ...

https://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Bremen_Schema




cordialement

Leni


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

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[osm . sanspourriel]

Et l'associatedStreet n'a aucun de ces inconvénients (j'aurai 
effectivement dû dire à SeFaireConnaitre de mettre le POI dans 
l'associatedStreet.


Jean-Yvon


Le 28/07/2017 à 09:47, Leni - lenny.li...@orange.fr a écrit :


Le 27/07/2017 à 08:26, Christian Quest a écrit :

Oui, pas très malin comme remarque...

Le problème pour moi est plutôt indiquer l'adresse d'un POI avec 
addr:* plutôt que contact:* car le POI n'est pas "l'adresse", mais à 
l'adresse...


On a du coup des positions d'adresses souvent peu homogènes lorsqu'on 
abuse des addr:*


Ensuite ça s'aggrave quand on doublonne en un vrai point définissant 
l'adresse et un addr:* rajouté à un POI proche.


Dans les scripts BANO, il y a un traitement spécifique lorsqu'on a de 
multiples addr:* pour une même adresse, pour éliminer ceux qui 
potentiellement devraient être un contact:*, en regardant si il y a 
d'autres tags (shop, etc)... mais c'est un pis aller.


le problème quand on fait porter les addr: sur un POI, c'est (comme je 
viens de voir un exemple) un magasin (correspondant au POI) a fermé et 
un contributeur a supprimé le node qui portait le POI et les addr: 
résultat : le node adresse a disparu



Le 26 juillet 2017 à 20:34, lenny.libre > a écrit :


Par contre dans les remarques qui leur sont faites, je ne vois
pas pourquoi on devrait supprimer le addr:street, c'est nouveau ?

Le commentaire : "Le positionnement géographique permet de savoir
que le "2" fait référence à la Place de la Nuit du 6 Août 1944".
Un addr:street=Place de la Nuit du 6 Août 1944 serait donc
inutile. Si vous ne comprenez pas, allez sur place et regardez
les numéros de rue : y figurent juste un nombre, sans nom de rue. "

me parait un brin radical, car ce n'est pas toujours le cas, on
met la rue en tant que addr:street ou relation

:https://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_des_b%C3%A2timents#Ajout_des_adresses



Dans le cas que tu as cité, il faisait partie d'une relation
(donc on pouvait supprimer le addr:street) mais s'il n'y a pas de
relation, il ne faut pas le supprimer.

Maintenant SeFaireConnaitre supprime les addr:street même quand
il n'y a pas de relation
https://www.openstreetmap.org/node/507550316#map=19/44.63221/-1.14615



En autre, s'ils mettent des contact:phone, contact:fax ils
pourraient mettre contact:housenumber, ...

https://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Bremen_Schema




cordialement

Leni





___
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] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Leni]

Le 27/07/2017 à 08:26, Christian Quest a écrit :

Oui, pas très malin comme remarque...

Le problème pour moi est plutôt indiquer l'adresse d'un POI avec 
addr:* plutôt que contact:* car le POI n'est pas "l'adresse", mais à 
l'adresse...


On a du coup des positions d'adresses souvent peu homogènes lorsqu'on 
abuse des addr:*


Ensuite ça s'aggrave quand on doublonne en un vrai point définissant 
l'adresse et un addr:* rajouté à un POI proche.


Dans les scripts BANO, il y a un traitement spécifique lorsqu'on a de 
multiples addr:* pour une même adresse, pour éliminer ceux qui 
potentiellement devraient être un contact:*, en regardant si il y a 
d'autres tags (shop, etc)... mais c'est un pis aller.


le problème quand on fait porter les addr: sur un POI, c'est (comme je 
viens de voir un exemple) un magasin (correspondant au POI) a fermé et 
un contributeur a supprimé le node qui portait le POI et les addr: 
résultat : le node adresse a disparu



Le 26 juillet 2017 à 20:34, lenny.libre > a écrit :


Par contre dans les remarques qui leur sont faites, je ne vois pas
pourquoi on devrait supprimer le addr:street, c'est nouveau ?

Le commentaire : "Le positionnement géographique permet de savoir
que le "2" fait référence à la Place de la Nuit du 6 Août 1944".
Un addr:street=Place de la Nuit du 6 Août 1944 serait donc
inutile. Si vous ne comprenez pas, allez sur place et regardez les
numéros de rue : y figurent juste un nombre, sans nom de rue. "

me parait un brin radical, car ce n'est pas toujours le cas, on
met la rue en tant que addr:street ou relation

:https://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_des_b%C3%A2timents#Ajout_des_adresses



Dans le cas que tu as cité, il faisait partie d'une relation (donc
on pouvait supprimer le addr:street) mais s'il n'y a pas de
relation, il ne faut pas le supprimer.

Maintenant SeFaireConnaitre supprime les addr:street même quand il
n'y a pas de relation
https://www.openstreetmap.org/node/507550316#map=19/44.63221/-1.14615



En autre, s'ils mettent des contact:phone, contact:fax ils
pourraient mettre contact:housenumber, ...

https://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Bremen_Schema




cordialement

Leni


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

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Philippe Verdy]

"contact:*" n'est pas nécessairement "à" l'adresse du point, ce qui est
indiqué est une adresse de contact postal qui peut être complètement
ailleurs et même pas géolocalisée (par exemple une boite postale ou un
CEDEX), ou l'adresse d'un service tiers de gestion de relations client, ou
l'adresse du siège social gérant tout une série d'établissements.
On aura donc besoin de "contact:*" et "addr:*". Je suis juste d'accord sur
le fait que "addr:*" doit être géolocalisé au POI, et ne désigner alors
qu'un unique établissement.

Le 27 juillet 2017 à 08:26, Christian Quest  a
écrit :

> Oui, pas très malin comme remarque...
>
> Le problème pour moi est plutôt indiquer l'adresse d'un POI avec addr:*
> plutôt que contact:* car le POI n'est pas "l'adresse", mais à l'adresse...
>
> On a du coup des positions d'adresses souvent peu homogènes lorsqu'on
> abuse des addr:*
>
> Ensuite ça s'aggrave quand on doublonne en un vrai point définissant
> l'adresse et un addr:* rajouté à un POI proche.
>
> Dans les scripts BANO, il y a un traitement spécifique lorsqu'on a de
> multiples addr:* pour une même adresse, pour éliminer ceux qui
> potentiellement devraient être un contact:*, en regardant si il y a
> d'autres tags (shop, etc)... mais c'est un pis aller.
>
>
>
> Le 26 juillet 2017 à 20:34, lenny.libre  a écrit :
>
>> Par contre dans les remarques qui leur sont faites, je ne vois pas
>> pourquoi on devrait supprimer le addr:street, c'est nouveau ?
>>
>> Le commentaire :  "Le positionnement géographique permet de savoir que
>> le "2" fait référence à la Place de la Nuit du 6 Août 1944".
>> Un addr:street=Place de la Nuit du 6 Août 1944 serait donc inutile. Si
>> vous ne comprenez pas, allez sur place et regardez les numéros de rue : y
>> figurent juste un nombre, sans nom de rue. "
>>
>> me parait un brin radical, car ce n'est pas toujours le cas, on met la
>> rue en tant que addr:street ou relation :https://wiki.openstreetmap.or
>> g/wiki/WikiProject_France/Tracer_des_b%C3%A2timents#Ajout_des_adresses
>>
>> Dans le cas que tu as cité, il faisait partie d'une relation (donc on
>> pouvait supprimer le addr:street) mais s'il n'y a pas de relation, il ne
>> faut pas le supprimer.
>>
>> Maintenant SeFaireConnaitre supprime les addr:street même quand il n'y a
>> pas de relation https://www.openstreetmap.org/
>> node/507550316#map=19/44.63221/-1.14615
>>
>>
>> En autre, s'ils mettent des contact:phone, contact:fax ils pourraient
>> mettre contact:housenumber, ... https://wiki.openstreetmap.org
>> /wiki/Proposed_features/House_numbers/Bremen_Schema
>>
>>
>> cordialement
>>
>> Leni
>>
>>
>>
>> Le 24/07/2017 à 22:42, Romain MEHUT a écrit :
>>
>> Ce n'est pas une question de motivation, c'est juste que via l'outil
>> WhoDidIt j'ai défini un flux RSS pour les zones que je connais et je
>> regarde donc les contributions qui les concernent. S'agissant des
>> contributions de SeFaireConnaitre, mes corrections ne concernent que ces
>> zones et donc c'est très loin d'être exhaustif. Dans le cas présent des
>> Crédit Mutuel de Bretagne, il faudrait tous les passer en revue... pour
>> retirer les tags en trop.
>>
>> Ils ont à nouveau commenté en nous remerciant des remarques faites et
>> disent qu'ils mettront à jour les données.
>>
>> Romain
>>
>> Le 22 juillet 2017 à 11:58, marc marc  a
>> écrit :
>>
>>> Tu es motivé Romain !
>>> J'ai regaré au hazard quelques changet.. la qualité laisse en effet à
>>> désirer.
>>> Par contre je pense pas qu'un "je surveille" trimestre va les faire
>>> s'améliorer même s'ils se sont déjà pris 3 blocages.
>>> Le plus utile me semble être soit un copier/coller d'un message
>>> explicatif (genre vos modifs sont en grande partie inutilisable voir
>>> erroné) si possible par email à la direction, à défaut à l'email
>>> générale + copie dans le chanset.
>>> Soit si cela ne suffit pas, là oü cela fait mal càd aux clients : les
>>> prévenir qu'ils payent pour un service ce mauvaise qualité
>>> Si l'un d'eux demande des comptes à son prestataire, les choses peuvent
>>> s'améliorer
>>> On peux aussi se "partager" l'envois de message. si plusieurs personnes
>>> écrivent, cela montre que ce n'est pas juste Romain qui chipote mais
>>> qu'il y a un problème chez eux.
>>> On peux aussi leur montrer cette conversation
>>> Dernière solution : leur proposer une formation (payante) ou un contrôle
>>> qualité :-)
>>>
>>> mes 2 cents..
>>>
>>
>>
>>
>> ___
>> Talk-fr mailing 
>> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>>
>> ___
>> 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
> 

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Christian Quest]

Oui, pas très malin comme remarque...

Le problème pour moi est plutôt indiquer l'adresse d'un POI avec addr:*
plutôt que contact:* car le POI n'est pas "l'adresse", mais à l'adresse...

On a du coup des positions d'adresses souvent peu homogènes lorsqu'on abuse
des addr:*

Ensuite ça s'aggrave quand on doublonne en un vrai point définissant
l'adresse et un addr:* rajouté à un POI proche.

Dans les scripts BANO, il y a un traitement spécifique lorsqu'on a de
multiples addr:* pour une même adresse, pour éliminer ceux qui
potentiellement devraient être un contact:*, en regardant si il y a
d'autres tags (shop, etc)... mais c'est un pis aller.



Le 26 juillet 2017 à 20:34, lenny.libre  a écrit :

> Par contre dans les remarques qui leur sont faites, je ne vois pas
> pourquoi on devrait supprimer le addr:street, c'est nouveau ?
>
> Le commentaire :  "Le positionnement géographique permet de savoir que le
> "2" fait référence à la Place de la Nuit du 6 Août 1944".
> Un addr:street=Place de la Nuit du 6 Août 1944 serait donc inutile. Si
> vous ne comprenez pas, allez sur place et regardez les numéros de rue : y
> figurent juste un nombre, sans nom de rue. "
>
> me parait un brin radical, car ce n'est pas toujours le cas, on met la rue
> en tant que addr:street ou relation :https://wiki.openstreetmap.
> org/wiki/WikiProject_France/Tracer_des_b%C3%A2timents#Ajout_des_adresses
>
> Dans le cas que tu as cité, il faisait partie d'une relation (donc on
> pouvait supprimer le addr:street) mais s'il n'y a pas de relation, il ne
> faut pas le supprimer.
>
> Maintenant SeFaireConnaitre supprime les addr:street même quand il n'y a
> pas de relation https://www.openstreetmap.org/node/507550316#map=19/44.
> 63221/-1.14615
>
>
> En autre, s'ils mettent des contact:phone, contact:fax ils pourraient
> mettre contact:housenumber, ... https://wiki.openstreetmap.
> org/wiki/Proposed_features/House_numbers/Bremen_Schema
>
>
> cordialement
>
> Leni
>
>
>
> Le 24/07/2017 à 22:42, Romain MEHUT a écrit :
>
> Ce n'est pas une question de motivation, c'est juste que via l'outil
> WhoDidIt j'ai défini un flux RSS pour les zones que je connais et je
> regarde donc les contributions qui les concernent. S'agissant des
> contributions de SeFaireConnaitre, mes corrections ne concernent que ces
> zones et donc c'est très loin d'être exhaustif. Dans le cas présent des
> Crédit Mutuel de Bretagne, il faudrait tous les passer en revue... pour
> retirer les tags en trop.
>
> Ils ont à nouveau commenté en nous remerciant des remarques faites et
> disent qu'ils mettront à jour les données.
>
> Romain
>
> Le 22 juillet 2017 à 11:58, marc marc  a écrit
> :
>
>> Tu es motivé Romain !
>> J'ai regaré au hazard quelques changet.. la qualité laisse en effet à
>> désirer.
>> Par contre je pense pas qu'un "je surveille" trimestre va les faire
>> s'améliorer même s'ils se sont déjà pris 3 blocages.
>> Le plus utile me semble être soit un copier/coller d'un message
>> explicatif (genre vos modifs sont en grande partie inutilisable voir
>> erroné) si possible par email à la direction, à défaut à l'email
>> générale + copie dans le chanset.
>> Soit si cela ne suffit pas, là oü cela fait mal càd aux clients : les
>> prévenir qu'ils payent pour un service ce mauvaise qualité
>> Si l'un d'eux demande des comptes à son prestataire, les choses peuvent
>> s'améliorer
>> On peux aussi se "partager" l'envois de message. si plusieurs personnes
>> écrivent, cela montre que ce n'est pas juste Romain qui chipote mais
>> qu'il y a un problème chez eux.
>> On peux aussi leur montrer cette conversation
>> Dernière solution : leur proposer une formation (payante) ou un contrôle
>> qualité :-)
>>
>> mes 2 cents..
>>
>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Romain MEHUT]

Bonsoir,

Il a déjà été dit sur cette liste qu'une adresse est un objet en soi qui ne
doit pas être répété. Donc oui les tags contact:housenumber et
contact:street ont toute leur place pour malgré tout préciser l'adresse
d'un objet.

Je viens de finir "le ménage" sur tous les CMB en Bretagne et j'ai
effectivement retiré des addr:street là où l'orthographe de la voie était
incorrect. Pour le reste, j'ai laissé mais il y a peut être bien des
conversions à faire en contact: pour ne pas avoir un doublon avec une
adresse existante par ailleurs.

Romain

Le 26 juillet 2017 à 20:34, lenny.libre  a écrit :

> Par contre dans les remarques qui leur sont faites, je ne vois pas
> pourquoi on devrait supprimer le addr:street, c'est nouveau ?
>
> Le commentaire :  "Le positionnement géographique permet de savoir que le
> "2" fait référence à la Place de la Nuit du 6 Août 1944".
> Un addr:street=Place de la Nuit du 6 Août 1944 serait donc inutile. Si
> vous ne comprenez pas, allez sur place et regardez les numéros de rue : y
> figurent juste un nombre, sans nom de rue. "
>
> me parait un brin radical, car ce n'est pas toujours le cas, on met la rue
> en tant que addr:street ou relation :https://wiki.openstreetmap.or
> g/wiki/WikiProject_France/Tracer_des_b%C3%A2timents#Ajout_des_adresses
>
> Dans le cas que tu as cité, il faisait partie d'une relation (donc on
> pouvait supprimer le addr:street) mais s'il n'y a pas de relation, il ne
> faut pas le supprimer.
>
> Maintenant SeFaireConnaitre supprime les addr:street même quand il n'y a
> pas de relation https://www.openstreetmap.org/
> node/507550316#map=19/44.63221/-1.14615
>
>
> En autre, s'ils mettent des contact:phone, contact:fax ils pourraient
> mettre contact:housenumber, ... https://wiki.openstreetmap.org
> /wiki/Proposed_features/House_numbers/Bremen_Schema
>
>
> cordialement
>
> Leni
>
>
>
> Le 24/07/2017 à 22:42, Romain MEHUT a écrit :
>
> Ce n'est pas une question de motivation, c'est juste que via l'outil
> WhoDidIt j'ai défini un flux RSS pour les zones que je connais et je
> regarde donc les contributions qui les concernent. S'agissant des
> contributions de SeFaireConnaitre, mes corrections ne concernent que ces
> zones et donc c'est très loin d'être exhaustif. Dans le cas présent des
> Crédit Mutuel de Bretagne, il faudrait tous les passer en revue... pour
> retirer les tags en trop.
>
> Ils ont à nouveau commenté en nous remerciant des remarques faites et
> disent qu'ils mettront à jour les données.
>
> Romain
>
> Le 22 juillet 2017 à 11:58, marc marc  a écrit
> :
>
>> Tu es motivé Romain !
>> J'ai regaré au hazard quelques changet.. la qualité laisse en effet à
>> désirer.
>> Par contre je pense pas qu'un "je surveille" trimestre va les faire
>> s'améliorer même s'ils se sont déjà pris 3 blocages.
>> Le plus utile me semble être soit un copier/coller d'un message
>> explicatif (genre vos modifs sont en grande partie inutilisable voir
>> erroné) si possible par email à la direction, à défaut à l'email
>> générale + copie dans le chanset.
>> Soit si cela ne suffit pas, là oü cela fait mal càd aux clients : les
>> prévenir qu'ils payent pour un service ce mauvaise qualité
>> Si l'un d'eux demande des comptes à son prestataire, les choses peuvent
>> s'améliorer
>> On peux aussi se "partager" l'envois de message. si plusieurs personnes
>> écrivent, cela montre que ce n'est pas juste Romain qui chipote mais
>> qu'il y a un problème chez eux.
>> On peux aussi leur montrer cette conversation
>> Dernière solution : leur proposer une formation (payante) ou un contrôle
>> qualité :-)
>>
>> mes 2 cents..
>>
>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://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] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[lenny.libre]

Par contre dans les remarques qui leur sont faites, je ne vois pas 
pourquoi on devrait supprimer le addr:street, c'est nouveau ?


Le commentaire : "Le positionnement géographique permet de savoir que le 
"2" fait référence à la Place de la Nuit du 6 Août 1944".
Un addr:street=Place de la Nuit du 6 Août 1944 serait donc inutile. Si 
vous ne comprenez pas, allez sur place et regardez les numéros de rue : 
y figurent juste un nombre, sans nom de rue. "


me parait un brin radical, car ce n'est pas toujours le cas, on met la 
rue en tant que addr:street ou relation 
:https://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_des_b%C3%A2timents#Ajout_des_adresses


Dans le cas que tu as cité, il faisait partie d'une relation (donc on 
pouvait supprimer le addr:street) mais s'il n'y a pas de relation, il ne 
faut pas le supprimer.


Maintenant SeFaireConnaitre supprime les addr:street même quand il n'y a 
pas de relation 
https://www.openstreetmap.org/node/507550316#map=19/44.63221/-1.14615



En autre, s'ils mettent des contact:phone, contact:fax ils pourraient 
mettre contact:housenumber, ... 
https://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Bremen_Schema



cordialement

Leni



Le 24/07/2017 à 22:42, Romain MEHUT a écrit :
Ce n'est pas une question de motivation, c'est juste que via l'outil 
WhoDidIt j'ai défini un flux RSS pour les zones que je connais et je 
regarde donc les contributions qui les concernent. S'agissant des 
contributions de SeFaireConnaitre, mes corrections ne concernent que 
ces zones et donc c'est très loin d'être exhaustif. Dans le cas 
présent des Crédit Mutuel de Bretagne, il faudrait tous les passer en 
revue... pour retirer les tags en trop.


Ils ont à nouveau commenté en nous remerciant des remarques faites et 
disent qu'ils mettront à jour les données.


Romain

Le 22 juillet 2017 à 11:58, marc marc > a écrit :


Tu es motivé Romain !
J'ai regaré au hazard quelques changet.. la qualité laisse en effet à
désirer.
Par contre je pense pas qu'un "je surveille" trimestre va les faire
s'améliorer même s'ils se sont déjà pris 3 blocages.
Le plus utile me semble être soit un copier/coller d'un message
explicatif (genre vos modifs sont en grande partie inutilisable voir
erroné) si possible par email à la direction, à défaut à l'email
générale + copie dans le chanset.
Soit si cela ne suffit pas, là oü cela fait mal càd aux clients : les
prévenir qu'ils payent pour un service ce mauvaise qualité
Si l'un d'eux demande des comptes à son prestataire, les choses
peuvent
s'améliorer
On peux aussi se "partager" l'envois de message. si plusieurs
personnes
écrivent, cela montre que ce n'est pas juste Romain qui chipote mais
qu'il y a un problème chez eux.
On peux aussi leur montrer cette conversation
Dernière solution : leur proposer une formation (payante) ou un
contrôle
qualité :-)

mes 2 cents..




___
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] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Romain MEHUT]

Ce n'est pas une question de motivation, c'est juste que via l'outil
WhoDidIt j'ai défini un flux RSS pour les zones que je connais et je
regarde donc les contributions qui les concernent. S'agissant des
contributions de SeFaireConnaitre, mes corrections ne concernent que ces
zones et donc c'est très loin d'être exhaustif. Dans le cas présent des
Crédit Mutuel de Bretagne, il faudrait tous les passer en revue... pour
retirer les tags en trop.

Ils ont à nouveau commenté en nous remerciant des remarques faites et
disent qu'ils mettront à jour les données.

Romain

Le 22 juillet 2017 à 11:58, marc marc  a écrit :

> Tu es motivé Romain !
> J'ai regaré au hazard quelques changet.. la qualité laisse en effet à
> désirer.
> Par contre je pense pas qu'un "je surveille" trimestre va les faire
> s'améliorer même s'ils se sont déjà pris 3 blocages.
> Le plus utile me semble être soit un copier/coller d'un message
> explicatif (genre vos modifs sont en grande partie inutilisable voir
> erroné) si possible par email à la direction, à défaut à l'email
> générale + copie dans le chanset.
> Soit si cela ne suffit pas, là oü cela fait mal càd aux clients : les
> prévenir qu'ils payent pour un service ce mauvaise qualité
> Si l'un d'eux demande des comptes à son prestataire, les choses peuvent
> s'améliorer
> On peux aussi se "partager" l'envois de message. si plusieurs personnes
> écrivent, cela montre que ce n'est pas juste Romain qui chipote mais
> qu'il y a un problème chez eux.
> On peux aussi leur montrer cette conversation
> Dernière solution : leur proposer une formation (payante) ou un contrôle
> qualité :-)
>
> mes 2 cents..
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Romain MEHUT]

Ok pour "contact:phone", c'est le revert qui est du coup revenu sur "phone".

Le 22 juillet 2017 à 08:15, Stéphane Péneau  a
écrit :

> contact:phone n'était pas incorrect.
>
> Pour le reste.hum.
>
> Stf
>
>
> Le 21/07/2017 à 23:04, Romain MEHUT a écrit :
>
> Bonsoir,
>
> Je veille au grain cf. https://www.openstreetmap.org/changeset/50457272
>
> Romain
>
> Le 1 mars 2017 à 16:44, Romain MEHUT  a écrit :
>
>> Bonjour,
>>
>> Pour info, les échanges (plus "mordants") avec SeFaireConnaitre
>> continuent cf. https://www.openstreetmap.org/changeset/46490928
>>
>> Romain
>>
>>
>> Le 15 octobre 2015 à 12:04, Romain MEHUT  a
>> écrit :
>>
>>> Bonjour,
>>>
>>> J'ai pointé l'ajout de deux doublons (magasins Decathlon)
>>> https://www.openstreetmap.org/changeset/34586502 et
>>> http://www.openstreetmap.org/changeset/34632382 restés non corrigés à
>>> ce jour. Et vu l'historique du compte http://www.openstreetmap.org/u
>>> ser/SeFaireConnaitre, il y a ailleurs d'autres doublons similaires.
>>>
>>> Romain
>>>
>>> Le 14 octobre 2015 23:35,  a écrit :
>>>
 Bien, merci d'améliorer votre processus de production/validation de
 données afin d'éviter de placer un lieu à 1,3 km de son lieu réel (distance
 en voiture selon OSRM).
 Ici par exemple comme déjà dit un lien sur un emplacement d'arrêt de
 tram doit faire tiquer.
 Ce n'est bon ni pour votre client, ni pour vous ni pour OpenStreetMap.
 Les deux premiers points c'est votre problème.
 Le troisième aussi mais c'est surtout celui qui nous concerne.

 Pour votre pénitence, vous leur proposerez une alternative à ceci :
 http://juvignac.apef-services.fr/contact.html#map
 ;-).

 Jean-Yvon

 Le 14/10/2015 09:23, Support Sefaireconnaitre -
 supp...@sefaireconnaitre.com a écrit :

 Bonjour,
 Merci pour le signalement, j'ai bien repositionné le point de vente.

 Amandine Nicolas - Ubiflow



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


>>>
>>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://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] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[marc marc]

Tu es motivé Romain !
J'ai regaré au hazard quelques changet.. la qualité laisse en effet à 
désirer.
Par contre je pense pas qu'un "je surveille" trimestre va les faire 
s'améliorer même s'ils se sont déjà pris 3 blocages.
Le plus utile me semble être soit un copier/coller d'un message 
explicatif (genre vos modifs sont en grande partie inutilisable voir 
erroné) si possible par email à la direction, à défaut à l'email 
générale + copie dans le chanset.
Soit si cela ne suffit pas, là oü cela fait mal càd aux clients : les 
prévenir qu'ils payent pour un service ce mauvaise qualité
Si l'un d'eux demande des comptes à son prestataire, les choses peuvent 
s'améliorer
On peux aussi se "partager" l'envois de message. si plusieurs personnes 
écrivent, cela montre que ce n'est pas juste Romain qui chipote mais 
qu'il y a un problème chez eux.
On peux aussi leur montrer cette conversation
Dernière solution : leur proposer une formation (payante) ou un contrôle 
qualité :-)

mes 2 cents..

Le 22. 07. 17 à 11:15, osm.sanspourr...@spamgourmet.com a écrit :
> Exact, mais si on ne fait que corriger leurs conneries, ils s'y 
> retrouvent : sauf erreur, Romain n'est pas payé par Ubiflow pour faire 
> ce contrôle qualité.
> 
> J'allais même dire twitter:facebook et contact:facebook aussi.
> 
> Car la page facebook permet bien de contacter mais non le CMB de Plouhay 
> mais le CMB en général.
> 
> Donc contact:facebook n'a rien à faire ici.
> 
> Y a-t-il des outil de contrôle qualité qui vérifient si certaines infos 
> sont uniques ?
> 
> Je pense à tous les contact:*, web et wikidata. Il peut y avoir des 
> exceptions, comme un restaurant ayant deux lieux mais un seul numéro de 
> réservation.
> 
> Par contre ici les "informations" ne portaient pas sur le CMB de Plouhay 
> mais sur le CMB.
> 
> Peut-être qu'un jour on essayera de travailler sur les brand/operator 
> qui peuvent comme ici offrir des services communs qui sont à mettre sur 
> ces objets (qui n'existent pas dans OSM sauf à faire une relation avec 
> tous les problèmes associés).
> 
> En fait les brand/operator portent sur des relations ou des points, les 
> ways sont rares et peu susceptibles aux problèmes des cassages de 
> relations styles frontières administratives. Je me trompe ?
> 
> Jean-Yvon
> 
> 
> Le 22/07/2017 à 08:15, Stéphane Péneau - stephane.pen...@wanadoo.fr a 
> écrit :
>> contact:phone n'était pas incorrect.
>>
>> Pour le reste.hum.
>>
>> Stf
>>
>> Le 21/07/2017 à 23:04, Romain MEHUT a écrit :
>>> Bonsoir,
>>>
>>> Je veille au grain cf. https://www.openstreetmap.org/changeset/50457272
>>>
>>> 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] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[osm . sanspourriel]

Exact, mais si on ne fait que corriger leurs conneries, ils s'y 
retrouvent : sauf erreur, Romain n'est pas payé par Ubiflow pour faire 
ce contrôle qualité.


J'allais même dire twitter:facebook et contact:facebook aussi.

Car la page facebook permet bien de contacter mais non le CMB de Plouhay 
mais le CMB en général.


Donc contact:facebook n'a rien à faire ici.

Y a-t-il des outil de contrôle qualité qui vérifient si certaines infos 
sont uniques ?


Je pense à tous les contact:*, web et wikidata. Il peut y avoir des 
exceptions, comme un restaurant ayant deux lieux mais un seul numéro de 
réservation.


Par contre ici les "informations" ne portaient pas sur le CMB de Plouhay 
mais sur le CMB.


Peut-être qu'un jour on essayera de travailler sur les brand/operator 
qui peuvent comme ici offrir des services communs qui sont à mettre sur 
ces objets (qui n'existent pas dans OSM sauf à faire une relation avec 
tous les problèmes associés).


En fait les brand/operator portent sur des relations ou des points, les 
ways sont rares et peu susceptibles aux problèmes des cassages de 
relations styles frontières administratives. Je me trompe ?


Jean-Yvon


Le 22/07/2017 à 08:15, Stéphane Péneau - stephane.pen...@wanadoo.fr a 
écrit :

contact:phone n'était pas incorrect.

Pour le reste.hum.

Stf

Le 21/07/2017 à 23:04, Romain MEHUT a écrit :

Bonsoir,

Je veille au grain cf. https://www.openstreetmap.org/changeset/50457272

Romain


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

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Stéphane Péneau]

contact:phone n'était pas incorrect.

Pour le reste.hum.

Stf

Le 21/07/2017 à 23:04, Romain MEHUT a écrit :

Bonsoir,

Je veille au grain cf. https://www.openstreetmap.org/changeset/50457272

Romain

Le 1 mars 2017 à 16:44, Romain MEHUT > a écrit :


Bonjour,

Pour info, les échanges (plus "mordants") avec SeFaireConnaitre
continuent cf. https://www.openstreetmap.org/changeset/46490928


Romain


Le 15 octobre 2015 à 12:04, Romain MEHUT > a écrit :

Bonjour,

J'ai pointé l'ajout de deux doublons (magasins Decathlon)
https://www.openstreetmap.org/changeset/34586502
 et
http://www.openstreetmap.org/changeset/34632382
 restés non
corrigés à ce jour. Et vu l'historique du compte
http://www.openstreetmap.org/user/SeFaireConnaitre
, il y a
ailleurs d'autres doublons similaires.

Romain

Le 14 octobre 2015 23:35, > a écrit :

Bien, merci d'améliorer votre processus de
production/validation de données afin d'éviter de placer
un lieu à 1,3 km de son lieu réel (distance en voiture
selon OSRM).
Ici par exemple comme déjà dit un lien sur un emplacement
d'arrêt de tram doit faire tiquer.
Ce n'est bon ni pour votre client, ni pour vous ni pour
OpenStreetMap.
Les deux premiers points c'est votre problème.
Le troisième aussi mais c'est surtout celui qui nous concerne.

Pour votre pénitence, vous leur proposerez une alternative
à ceci :
http://juvignac.apef-services.fr/contact.html#map

;-).

Jean-Yvon

Le 14/10/2015 09:23, Support Sefaireconnaitre -
supp...@sefaireconnaitre.com
 a écrit :

Bonjour,
Merci pour le signalement, j'ai bien repositionné le
point de vente.

Amandine Nicolas - Ubiflow




___
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] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Romain MEHUT]

Bonsoir,

Je veille au grain cf. https://www.openstreetmap.org/changeset/50457272

Romain

Le 1 mars 2017 à 16:44, Romain MEHUT  a écrit :

> Bonjour,
>
> Pour info, les échanges (plus "mordants") avec SeFaireConnaitre continuent
> cf. https://www.openstreetmap.org/changeset/46490928
>
> Romain
>
>
> Le 15 octobre 2015 à 12:04, Romain MEHUT  a écrit
> :
>
>> Bonjour,
>>
>> J'ai pointé l'ajout de deux doublons (magasins Decathlon)
>> https://www.openstreetmap.org/changeset/34586502 et
>> http://www.openstreetmap.org/changeset/34632382 restés non corrigés à ce
>> jour. Et vu l'historique du compte http://www.openstreetmap.org/u
>> ser/SeFaireConnaitre, il y a ailleurs d'autres doublons similaires.
>>
>> Romain
>>
>> Le 14 octobre 2015 23:35,  a écrit :
>>
>>> Bien, merci d'améliorer votre processus de production/validation de
>>> données afin d'éviter de placer un lieu à 1,3 km de son lieu réel (distance
>>> en voiture selon OSRM).
>>> Ici par exemple comme déjà dit un lien sur un emplacement d'arrêt de
>>> tram doit faire tiquer.
>>> Ce n'est bon ni pour votre client, ni pour vous ni pour OpenStreetMap.
>>> Les deux premiers points c'est votre problème.
>>> Le troisième aussi mais c'est surtout celui qui nous concerne.
>>>
>>> Pour votre pénitence, vous leur proposerez une alternative à ceci :
>>> http://juvignac.apef-services.fr/contact.html#map
>>> ;-).
>>>
>>> Jean-Yvon
>>>
>>> Le 14/10/2015 09:23, Support Sefaireconnaitre -
>>> supp...@sefaireconnaitre.com a écrit :
>>>
>>> Bonjour,
>>> Merci pour le signalement, j'ai bien repositionné le point de vente.
>>>
>>> Amandine Nicolas - Ubiflow
>>>
>>>
>>>
>>> ___
>>> 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-be] (no subject)

[guy vanvuchelen]

In Tienen op de Zuidelijke ring mag je op een stuk richting Leuven 90 km
rijden want er staat een rood bord met 90. In de andere richting staat een
bord met 70 en daar een streep door, dus 70!!, I" ben nog geen enkel bord
met 70 tegen gekomen dat verwijderd werd...en dat na meer dan 4 maanden!

Guy Vanvuchelen

Op 15-mei-2017 16:00 schreef "Marc Gemis" :

welke van de tientallen ? :-)  http://www.openstreetmap.org/
user/Ilona_S/history
N16 is al gecorrigeerd, tenminste waar ik zeker weet dat het nog 90 is.

Via Joost te weten gekomen dat dit BeMobile is die AWV data gebruikt.
We hebben nu rechtstreeks contact opgenomen met hen.

Er is hier ook wat op de mailing list gepasseerd bij de vorige 90->70
discussie

m.

2017-05-15 15:53 GMT+02:00 Glenn Plas :
> changeset ID ?
>
> Dit is altijd zo frustrerend... doe-maar-op-mappers met
> ik-heb-mijn-eigen-regels voor OSM
>
> Glenn
>
>
> On 15-05-17 12:24, Marc Gemis wrote:
>> Ik heb dit weekend de N16 tussen Willebroek en Temse terug naar 90
>> km/h gebracht.
>> Een overijverige mapster heeft volgens mij gewoon alle 90 door 70
>> vervangen zonder lokale kennis.
>> Misschien best eens in je eigen buurt kijken, want ze heeft behoorlijk
>> wat wijzigingen gedaan
>>
>> Op mijn Nederlandstalige changeset comment, reageerde ze in het Engels.
>>
>> mvg
>>
>> m
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

[OSM-talk-be] (no subject)

[Marc Gemis]

welke van de tientallen ? :-)  http://www.openstreetmap.org/user/Ilona_S/history
N16 is al gecorrigeerd, tenminste waar ik zeker weet dat het nog 90 is.

Via Joost te weten gekomen dat dit BeMobile is die AWV data gebruikt.
We hebben nu rechtstreeks contact opgenomen met hen.

Er is hier ook wat op de mailing list gepasseerd bij de vorige 90->70 discussie

m.

2017-05-15 15:53 GMT+02:00 Glenn Plas :
> changeset ID ?
>
> Dit is altijd zo frustrerend... doe-maar-op-mappers met
> ik-heb-mijn-eigen-regels voor OSM
>
> Glenn
>
>
> On 15-05-17 12:24, Marc Gemis wrote:
>> Ik heb dit weekend de N16 tussen Willebroek en Temse terug naar 90
>> km/h gebracht.
>> Een overijverige mapster heeft volgens mij gewoon alle 90 door 70
>> vervangen zonder lokale kennis.
>> Misschien best eens in je eigen buurt kijken, want ze heeft behoorlijk
>> wat wijzigingen gedaan
>>
>> Op mijn Nederlandstalige changeset comment, reageerde ze in het Engels.
>>
>> mvg
>>
>> m
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Philippe Verdy]

En effet ils continuent d'ajouter des tas de noeuds, même en doublon de
ceux qui existent, ou de modifier des noeuds existants en mettant dessus
des tags incorrects ou inutiles noms de rue par exemple quand le noeud est
déjà référencé sur une relation suffisante et quand la rue est déjà validée
pour BANO.
Mais cette fois SeFaireConnaitre (ou son employé) demande qu'on ne les
dérange plus. Visibilement il manque un interlocuteur crédible chez ce
prestataire, capable de faire respecter chez lui les engagements pris, y
compris chez les nouveaux employés (à lui de les former, c'est tout de même
son domaine de compétence, qu'il vend aussi comme tel à ses clients en leur
"garantissant" un référencement non seulement exact mais péreine).
De plus ce service semble déjà prêt à supprimer d'OSM certains anciens
clients qui ne voudraient plus continuer avec ce service ou supprimer les
tags utiles permettant de les trouver dans des recherches ciblées sur OSM.
Il pourrait même modifier les infos saisies ou corrigées par ce client
lui-même dans OSM, histoire de faire rebondir leurs ventes.

Ils ne font pas dans le détail: si leur client leur donne un fichier
d'adresses, il les ajoutent toutes sans distinction, et modifient des
données existantes pourtant plus exactes. Et au besoin il remplacera des
tags précis par des tags plus génériques dont il sait qu'ils sont mieux
rendus et plus visibles que d'autres. Et ils ne semblent pas suivre les
évolutions des recommandations et usages (visiblement ils n'utilisent pas
pour cela nos outils open source, qui contiennent divers vérificateurs,
mais leur propre outil créé par Ubiflow.net qui ne connait que ce qui est
dans leur base ou les fichiers plus ou moins précis fournis par leurs
clients, pour lesquels les clients payent justement une prestation vissant
à nettoyer ou affiner ces fichiers, et l'outil et ne s'intéresse pas du
tout au reste.

A ce stade, cet outil ne devrait servir qu'à créer des fichiers .osm à
valider ensuite dans un de nos éditeurs ouverts pour faire le travail de
fusion. Mais leurs employés ne sont pas formés pour apprendre à utiliser
JOSM par exemple et traiter les lots en attente de validation (ou bien les
publier sur un service à part en Open Data, par exemple sur Umap ou
Framacarte). C'est sûr cela leur demande une personne de plus ou délégeur
un temps sufffisant consacré à ça et ils sont plus perturbés par la volonté
de faire vite pour répondre aux client: le travail est fait, maintenant
payez et vous aurez les lots suivants... Mais il n'y a apparemment aucun
système de veille et service après-vente pour régler les problèmes: ils
considèrent que c'est aux contributeurs bénévoles non payés de le faire à
leur place.



Le 1 mars 2017 à 16:44, Romain MEHUT  a écrit :

> Bonjour,
>
> Pour info, les échanges (plus "mordants") avec SeFaireConnaitre continuent
> cf. https://www.openstreetmap.org/changeset/46490928
>
> Romain
>
>
> Le 15 octobre 2015 à 12:04, Romain MEHUT  a écrit
> :
>
>> Bonjour,
>>
>> J'ai pointé l'ajout de deux doublons (magasins Decathlon)
>> https://www.openstreetmap.org/changeset/34586502 et
>> http://www.openstreetmap.org/changeset/34632382 restés non corrigés à ce
>> jour. Et vu l'historique du compte http://www.openstreetmap.org/u
>> ser/SeFaireConnaitre, il y a ailleurs d'autres doublons similaires.
>>
>> Romain
>>
>> Le 14 octobre 2015 23:35,  a écrit :
>>
>>> Bien, merci d'améliorer votre processus de production/validation de
>>> données afin d'éviter de placer un lieu à 1,3 km de son lieu réel (distance
>>> en voiture selon OSRM).
>>> Ici par exemple comme déjà dit un lien sur un emplacement d'arrêt de
>>> tram doit faire tiquer.
>>> Ce n'est bon ni pour votre client, ni pour vous ni pour OpenStreetMap.
>>> Les deux premiers points c'est votre problème.
>>> Le troisième aussi mais c'est surtout celui qui nous concerne.
>>>
>>> Pour votre pénitence, vous leur proposerez une alternative à ceci :
>>> http://juvignac.apef-services.fr/contact.html#map
>>> ;-).
>>>
>>> Jean-Yvon
>>>
>>> Le 14/10/2015 09:23, Support Sefaireconnaitre -
>>> supp...@sefaireconnaitre.com a écrit :
>>>
>>> Bonjour,
>>> Merci pour le signalement, j'ai bien repositionné le point de vente.
>>>
>>> Amandine Nicolas - Ubiflow
>>>
>>>
>>>
>>> ___
>>> 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] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Romain MEHUT]

Bonjour,

Pour info, les échanges (plus "mordants") avec SeFaireConnaitre continuent
cf. https://www.openstreetmap.org/changeset/46490928

Romain

Le 15 octobre 2015 à 12:04, Romain MEHUT  a écrit :

> Bonjour,
>
> J'ai pointé l'ajout de deux doublons (magasins Decathlon)
> https://www.openstreetmap.org/changeset/34586502 et
> http://www.openstreetmap.org/changeset/34632382 restés non corrigés à ce
> jour. Et vu l'historique du compte http://www.openstreetmap.org/
> user/SeFaireConnaitre, il y a ailleurs d'autres doublons similaires.
>
> Romain
>
> Le 14 octobre 2015 23:35,  a écrit :
>
>> Bien, merci d'améliorer votre processus de production/validation de
>> données afin d'éviter de placer un lieu à 1,3 km de son lieu réel (distance
>> en voiture selon OSRM).
>> Ici par exemple comme déjà dit un lien sur un emplacement d'arrêt de tram
>> doit faire tiquer.
>> Ce n'est bon ni pour votre client, ni pour vous ni pour OpenStreetMap.
>> Les deux premiers points c'est votre problème.
>> Le troisième aussi mais c'est surtout celui qui nous concerne.
>>
>> Pour votre pénitence, vous leur proposerez une alternative à ceci :
>> http://juvignac.apef-services.fr/contact.html#map
>> ;-).
>>
>> Jean-Yvon
>>
>> Le 14/10/2015 09:23, Support Sefaireconnaitre -
>> supp...@sefaireconnaitre.com a écrit :
>>
>> Bonjour,
>> Merci pour le signalement, j'ai bien repositionné le point de vente.
>>
>> Amandine Nicolas - Ubiflow
>>
>>
>>
>> ___
>> 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-be] (no subject)

[Guy Vanvuchelen]

Fijne leerrijke discussie. Daar kun je wat van opsteken. 


Guy Vanvuchelen

-Oorspronkelijk bericht-
Van: Glenn Plas [mailto:gl...@byte-consult.be] 
Verzonden: vrijdag 13 januari 2017 18:16
Aan: OpenStreetMap Belgium
Onderwerp: Re: [OSM-talk-be] (no subject)

On 13-01-17 17:52, Jasper Michels wrote:
> Dank voor je antwoord Marc!
> 
> -Gevoelsmatig vind ik de tag "scrub" te veel eer doen aan de struikjes 
> tussen de autostrades met zwerfvuil.
>  Als ik in google afbeeldingen zoek op "scrub terrain" dan krijg ik 
> toch iets mooiere landschappen te zien.

Schoonheid is zeer subjectief van criteria.  Een lelijke auto is nogaltijd een 
auto.

> 
> -Ik ben zo iemand die momenteel elk rijtje bomen als forest map. 

is nochthans een andere voor :
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree_row

> Indien de maprendering niet wijzigd zal ik dit ook niet veranderen. 
> Indien dit wel moet zal ik vrees ik snel de zin om dit te mappen verliezen.

Taggen voor de renderer is een slecht idee.  (voor 1 welbepaalde dan nog)

> (resultaat naar werk is bij mij nodig)

Het resultaat reken je toch niet af op de render stijl van standaard OSM
tegels?   Maak je eigen kaart, render hoe je wil.

>  Van zodra men ook de landcover zou renderen, is dit een ander verhaal.


> 
> -Het ideale geval van de 3 polygonen boven één ben ik volledig akkoord mee.
>  Zolang men de landcover niet rendert is dit echter onmogelijk. Indien 
> we masaal landuse vervangen door landcover zal de kaart al maar witter 
> worden. (ik weet dat we niet mogen mappen voor de kaart, maar niet 
> iedereen is  een medogenloze databese-addict...)

Heeft er niks mee te maken hoe addict je bent, je kan beter lobbyen om 
landcover te ondersteunen, eventueel zelf in de tagging lijst discussies gaan 
mengen.

Massaal vervangen is al evengoed slecht idee trouwens, dus gaan we gewoon niet 
doen


Glenn


> 
> Op 13 januari 2017 om 17:39 schreef Sus Verhoeven <sus...@gmail.com
> <mailto:sus...@gmail.com>>:
> 
> Of niet meer durven mappen. ;-)
> 
> Sus
> 
> 
> 2017-01-13 16:55 GMT+01:00 Santens Seppe <seppe.sant...@stad.gent
> <mailto:seppe.sant...@stad.gent>>:
> 
> Even binnenkijken in Marc zijn diepste zielenroerselen :-)
> Maar wel een erg nuttige uitleg vind ik, bedankt! En nu nog
> alles verbeteren wat we ooit verkeerd gemapt hebben :-)
> 
> Seppe
> 
> -Oorspronkelijk bericht-
> Van: Marc Gemis [mailto:marc.ge...@gmail.com
>     <mailto:marc.ge...@gmail.com>]
> Verzonden: vrijdag 13 januari 2017 14:14
> Aan: OpenStreetMap Belgium
> Onderwerp: [OSM-talk-be] (no subject)
> 
> Sorry voor de lange mail, maar het is toch slecht weer, dus heb
> je wat om te lezen :-)
> 
> Jasper,
> 
> De oorspronkelijke betekenis van landuse=forest was een
> bosgebied waarvan het hout gekapt wordt voor industriële
> doeleinden (bosbouw).
> Daarnaast had je natural=wood voor natuurlijk, niet onderhouden bos.
> Omdat het meeste bos hier niet meer natuurlijk is, maar
> aangeplant en onderhouden zijn meer mensen landuse=forest
> beginnen gebruiken. Hoewel niet elk onderhouden bos echt voor
> bosbouw is.
> 
> Verder plakken sommige mappers gewoon op alles wat op een
> luchtfoto op een groepje bomen lijkt als landuse=forest. Er is
> geen echte tag voor een groepje bomen.
> 
> Het volgende probleem is dan dat ook bosjes, zonder echte bomen
> maar met grote struiken via luchtfoto's als landuse=forest
> worden gemapped.
> 
> Dit laatste kan je verhelpen door natural=scrub te gebruiken,
> ook voor struiken in meer stedelijke gebieden, ik denk dus ook
> voor het stukje grond dat jij aangeeft. scrub wordt ook wel als
> struikgewas of kreupelhout vertaalt (google translate). Dus dat
> pas wel.
> 
> Dus in jouw geval zou natural=scrub beter zijn dan
> landuse=forest , toch als er meer struiken zijn dan bomen. Maar
> wat als er dan toch wat onderhoud aan te pas komt ?
> 
> Voor je golf terrein, de belangrijkste tag daar is  leisure=golf
> natuurlijk. Ik zou nu voor landcover=trees gaan. Het is helemaal
> geen bosbouw, noch een bos. Dat het niet op de standaard kaart
> komt, het zij zo. Als er genoeg landcover tags gebruikt worden,
> gaan ze die ook wel tonen.
> 
> Over het verschil tussen landcover=grass en landuse=grass
> Landuse zou het gebruik van het land moeten aangeven. Hier wonen
> mensen, hier werken ze, hier wordt gerec

Re: [OSM-talk-be] (no subject)

[Glenn Plas]

On 13-01-17 17:52, Jasper Michels wrote:
> Dank voor je antwoord Marc!
> 
> -Gevoelsmatig vind ik de tag "scrub" te veel eer doen aan de struikjes
> tussen de autostrades met zwerfvuil.
>  Als ik in google afbeeldingen zoek op "scrub terrain" dan krijg ik toch
> iets mooiere landschappen te zien.

Schoonheid is zeer subjectief van criteria.  Een lelijke auto is
nogaltijd een auto.

> 
> -Ik ben zo iemand die momenteel elk rijtje bomen als forest map. 

is nochthans een andere voor :
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree_row

> Indien de maprendering niet wijzigd zal ik dit ook niet veranderen. Indien dit
> wel moet zal ik vrees ik snel de zin om dit te mappen verliezen.

Taggen voor de renderer is een slecht idee.  (voor 1 welbepaalde dan nog)

> (resultaat naar werk is bij mij nodig)

Het resultaat reken je toch niet af op de render stijl van standaard OSM
tegels?   Maak je eigen kaart, render hoe je wil.

>  Van zodra men ook de landcover zou renderen, is dit een ander verhaal.


> 
> -Het ideale geval van de 3 polygonen boven één ben ik volledig akkoord mee.
>  Zolang men de landcover niet rendert is dit echter onmogelijk. Indien
> we masaal landuse vervangen door landcover zal de kaart al maar witter
> worden. (ik weet dat we niet mogen mappen voor de kaart, maar niet
> iedereen is  een medogenloze databese-addict...)

Heeft er niks mee te maken hoe addict je bent, je kan beter lobbyen om
landcover te ondersteunen, eventueel zelf in de tagging lijst discussies
gaan mengen.

Massaal vervangen is al evengoed slecht idee trouwens, dus gaan we
gewoon niet doen


Glenn


> 
> Op 13 januari 2017 om 17:39 schreef Sus Verhoeven <sus...@gmail.com
> <mailto:sus...@gmail.com>>:
> 
> Of niet meer durven mappen. ;-)
> 
> Sus
> 
> 
> 2017-01-13 16:55 GMT+01:00 Santens Seppe <seppe.sant...@stad.gent
> <mailto:seppe.sant...@stad.gent>>:
> 
> Even binnenkijken in Marc zijn diepste zielenroerselen :-)
> Maar wel een erg nuttige uitleg vind ik, bedankt! En nu nog
> alles verbeteren wat we ooit verkeerd gemapt hebben :-)
> 
> Seppe
> 
> -Oorspronkelijk bericht-
> Van: Marc Gemis [mailto:marc.ge...@gmail.com
>     <mailto:marc.ge...@gmail.com>]
> Verzonden: vrijdag 13 januari 2017 14:14
> Aan: OpenStreetMap Belgium
> Onderwerp: [OSM-talk-be] (no subject)
> 
> Sorry voor de lange mail, maar het is toch slecht weer, dus heb
> je wat om te lezen :-)
> 
> Jasper,
> 
> De oorspronkelijke betekenis van landuse=forest was een
> bosgebied waarvan het hout gekapt wordt voor industriële
> doeleinden (bosbouw).
> Daarnaast had je natural=wood voor natuurlijk, niet onderhouden bos.
> Omdat het meeste bos hier niet meer natuurlijk is, maar
> aangeplant en onderhouden zijn meer mensen landuse=forest
> beginnen gebruiken. Hoewel niet elk onderhouden bos echt voor
> bosbouw is.
> 
> Verder plakken sommige mappers gewoon op alles wat op een
> luchtfoto op een groepje bomen lijkt als landuse=forest. Er is
> geen echte tag voor een groepje bomen.
> 
> Het volgende probleem is dan dat ook bosjes, zonder echte bomen
> maar met grote struiken via luchtfoto's als landuse=forest
> worden gemapped.
> 
> Dit laatste kan je verhelpen door natural=scrub te gebruiken,
> ook voor struiken in meer stedelijke gebieden, ik denk dus ook
> voor het stukje grond dat jij aangeeft. scrub wordt ook wel als
> struikgewas of kreupelhout vertaalt (google translate). Dus dat
> pas wel.
> 
> Dus in jouw geval zou natural=scrub beter zijn dan
> landuse=forest , toch als er meer struiken zijn dan bomen. Maar
> wat als er dan toch wat onderhoud aan te pas komt ?
> 
> Voor je golf terrein, de belangrijkste tag daar is  leisure=golf
> natuurlijk. Ik zou nu voor landcover=trees gaan. Het is helemaal
> geen bosbouw, noch een bos. Dat het niet op de standaard kaart
> komt, het zij zo. Als er genoeg landcover tags gebruikt worden,
> gaan ze die ook wel tonen.
> 
> Over het verschil tussen landcover=grass en landuse=grass
> Landuse zou het gebruik van het land moeten aangeven. Hier wonen
> mensen, hier werken ze, hier wordt gerecreëerd, hier wordt aan
> landbouw of veeteelt gedaan, enz.
> Maar wat is "hier wordt aan gras gedaan" ? Vandaar dat
> landuse=grass niet echt juist is, misschien enkel voor gebieden
> waar graszodes geteeld worden. Maar omda

Re: [OSM-talk-be] (no subject)

[Jasper Michels]

Dank voor je antwoord Marc!

-Gevoelsmatig vind ik de tag "scrub" te veel eer doen aan de struikjes
tussen de autostrades met zwerfvuil.
 Als ik in google afbeeldingen zoek op "scrub terrain" dan krijg ik toch
iets mooiere landschappen te zien.

-Ik ben zo iemand die momenteel elk rijtje bomen als forest map. Indien de
maprendering niet wijzigd zal ik dit ook niet veranderen. Indien dit wel
moet zal ik vrees ik snel de zin om dit te mappen verliezen. (resultaat
naar werk is bij mij nodig)
 Van zodra men ook de landcover zou renderen, is dit een ander verhaal.

-Het ideale geval van de 3 polygonen boven één ben ik volledig akkoord mee.
 Zolang men de landcover niet rendert is dit echter onmogelijk. Indien we
masaal landuse vervangen door landcover zal de kaart al maar witter worden.
(ik weet dat we niet mogen mappen voor de kaart, maar niet iedereen is  een
medogenloze databese-addict...)

Op 13 januari 2017 om 17:39 schreef Sus Verhoeven <sus...@gmail.com>:

> Of niet meer durven mappen. ;-)
>
> Sus
>
>
> 2017-01-13 16:55 GMT+01:00 Santens Seppe <seppe.sant...@stad.gent>:
>
>> Even binnenkijken in Marc zijn diepste zielenroerselen :-)
>> Maar wel een erg nuttige uitleg vind ik, bedankt! En nu nog alles
>> verbeteren wat we ooit verkeerd gemapt hebben :-)
>>
>> Seppe
>>
>> -Oorspronkelijk bericht-
>> Van: Marc Gemis [mailto:marc.ge...@gmail.com]
>> Verzonden: vrijdag 13 januari 2017 14:14
>> Aan: OpenStreetMap Belgium
>> Onderwerp: [OSM-talk-be] (no subject)
>>
>> Sorry voor de lange mail, maar het is toch slecht weer, dus heb je wat om
>> te lezen :-)
>>
>> Jasper,
>>
>> De oorspronkelijke betekenis van landuse=forest was een bosgebied waarvan
>> het hout gekapt wordt voor industriële doeleinden (bosbouw).
>> Daarnaast had je natural=wood voor natuurlijk, niet onderhouden bos.
>> Omdat het meeste bos hier niet meer natuurlijk is, maar aangeplant en
>> onderhouden zijn meer mensen landuse=forest beginnen gebruiken. Hoewel niet
>> elk onderhouden bos echt voor bosbouw is.
>>
>> Verder plakken sommige mappers gewoon op alles wat op een luchtfoto op
>> een groepje bomen lijkt als landuse=forest. Er is geen echte tag voor een
>> groepje bomen.
>>
>> Het volgende probleem is dan dat ook bosjes, zonder echte bomen maar met
>> grote struiken via luchtfoto's als landuse=forest worden gemapped.
>>
>> Dit laatste kan je verhelpen door natural=scrub te gebruiken, ook voor
>> struiken in meer stedelijke gebieden, ik denk dus ook voor het stukje grond
>> dat jij aangeeft. scrub wordt ook wel als struikgewas of kreupelhout
>> vertaalt (google translate). Dus dat pas wel.
>>
>> Dus in jouw geval zou natural=scrub beter zijn dan landuse=forest , toch
>> als er meer struiken zijn dan bomen. Maar wat als er dan toch wat onderhoud
>> aan te pas komt ?
>>
>> Voor je golf terrein, de belangrijkste tag daar is  leisure=golf
>> natuurlijk. Ik zou nu voor landcover=trees gaan. Het is helemaal geen
>> bosbouw, noch een bos. Dat het niet op de standaard kaart komt, het zij zo.
>> Als er genoeg landcover tags gebruikt worden, gaan ze die ook wel tonen.
>>
>> Over het verschil tussen landcover=grass en landuse=grass Landuse zou het
>> gebruik van het land moeten aangeven. Hier wonen mensen, hier werken ze,
>> hier wordt gerecreëerd, hier wordt aan landbouw of veeteelt gedaan, enz.
>> Maar wat is "hier wordt aan gras gedaan" ? Vandaar dat landuse=grass niet
>> echt juist is, misschien enkel voor gebieden waar graszodes geteeld worden.
>> Maar omdat het op de kaart getoond wordt, zie je landuse=grass overal
>> verschijnen. (ipv het correctere landcover=grass)
>>
>> Landcover slaat op wat je op de grond vindt.
>>
>> Volgens mij moet in een ideale OSM map, elke plek op aarde [1] tot 2
>> polygonen behoren:
>> eentje met een landuse tag een eentje met een landcover tag. De ene geeft
>> de bestemming aan, de andere wat je op de grond vindt. En dan kan je ook
>> nog in sommige gevallen het type recreatie (leisure) of faciliteiten
>> (amenity), etc. daarboven op gaan mappen.
>>
>> Dus voor een park
>> - leisure=park (doen we nu al)
>> - landuse=xxx (nog te definiëren)
>> - dan voor verschillende delen landcover=trees of grass of bushes of
>> sand, rocks, etc.
>> -
>> Momenteel mappen we meestal enkel leisure=park, en misschien al eens een
>> landuse=grass of forest.
>>
>>
>> Bij een woning met tuin
>> - landuse=residential
>> - landcover (zoals bij park) voor de tuin, misschien voor oprit, de plek
>> van het huis, terras

Re: [OSM-talk-be] (no subject)

[Sus Verhoeven]

Of niet meer durven mappen. ;-)

Sus

2017-01-13 16:55 GMT+01:00 Santens Seppe <seppe.sant...@stad.gent>:

> Even binnenkijken in Marc zijn diepste zielenroerselen :-)
> Maar wel een erg nuttige uitleg vind ik, bedankt! En nu nog alles
> verbeteren wat we ooit verkeerd gemapt hebben :-)
>
> Seppe
>
> -Oorspronkelijk bericht-
> Van: Marc Gemis [mailto:marc.ge...@gmail.com]
> Verzonden: vrijdag 13 januari 2017 14:14
> Aan: OpenStreetMap Belgium
> Onderwerp: [OSM-talk-be] (no subject)
>
> Sorry voor de lange mail, maar het is toch slecht weer, dus heb je wat om
> te lezen :-)
>
> Jasper,
>
> De oorspronkelijke betekenis van landuse=forest was een bosgebied waarvan
> het hout gekapt wordt voor industriële doeleinden (bosbouw).
> Daarnaast had je natural=wood voor natuurlijk, niet onderhouden bos.
> Omdat het meeste bos hier niet meer natuurlijk is, maar aangeplant en
> onderhouden zijn meer mensen landuse=forest beginnen gebruiken. Hoewel niet
> elk onderhouden bos echt voor bosbouw is.
>
> Verder plakken sommige mappers gewoon op alles wat op een luchtfoto op een
> groepje bomen lijkt als landuse=forest. Er is geen echte tag voor een
> groepje bomen.
>
> Het volgende probleem is dan dat ook bosjes, zonder echte bomen maar met
> grote struiken via luchtfoto's als landuse=forest worden gemapped.
>
> Dit laatste kan je verhelpen door natural=scrub te gebruiken, ook voor
> struiken in meer stedelijke gebieden, ik denk dus ook voor het stukje grond
> dat jij aangeeft. scrub wordt ook wel als struikgewas of kreupelhout
> vertaalt (google translate). Dus dat pas wel.
>
> Dus in jouw geval zou natural=scrub beter zijn dan landuse=forest , toch
> als er meer struiken zijn dan bomen. Maar wat als er dan toch wat onderhoud
> aan te pas komt ?
>
> Voor je golf terrein, de belangrijkste tag daar is  leisure=golf
> natuurlijk. Ik zou nu voor landcover=trees gaan. Het is helemaal geen
> bosbouw, noch een bos. Dat het niet op de standaard kaart komt, het zij zo.
> Als er genoeg landcover tags gebruikt worden, gaan ze die ook wel tonen.
>
> Over het verschil tussen landcover=grass en landuse=grass Landuse zou het
> gebruik van het land moeten aangeven. Hier wonen mensen, hier werken ze,
> hier wordt gerecreëerd, hier wordt aan landbouw of veeteelt gedaan, enz.
> Maar wat is "hier wordt aan gras gedaan" ? Vandaar dat landuse=grass niet
> echt juist is, misschien enkel voor gebieden waar graszodes geteeld worden.
> Maar omdat het op de kaart getoond wordt, zie je landuse=grass overal
> verschijnen. (ipv het correctere landcover=grass)
>
> Landcover slaat op wat je op de grond vindt.
>
> Volgens mij moet in een ideale OSM map, elke plek op aarde [1] tot 2
> polygonen behoren:
> eentje met een landuse tag een eentje met een landcover tag. De ene geeft
> de bestemming aan, de andere wat je op de grond vindt. En dan kan je ook
> nog in sommige gevallen het type recreatie (leisure) of faciliteiten
> (amenity), etc. daarboven op gaan mappen.
>
> Dus voor een park
> - leisure=park (doen we nu al)
> - landuse=xxx (nog te definiëren)
> - dan voor verschillende delen landcover=trees of grass of bushes of sand,
> rocks, etc.
> -
> Momenteel mappen we meestal enkel leisure=park, en misschien al eens een
> landuse=grass of forest.
>
>
> Bij een woning met tuin
> - landuse=residential
> - landcover (zoals bij park) voor de tuin, misschien voor oprit, de plek
> van het huis, terras, e.d. nog andere landcovers Dus hier geen
> landuse=forest om de tuin aan te duiden. Er is geen bosbouw, er is ook geen
> bos om te recreëren, dus waarom landuse=forest ? Dat is taggen voor de
> renderer [1].
>
> Dat is volgens mij het doel van de landcover, om los van het gebruik
> bomen, struiken enz te kunnen aangeven. En dan kan landuse=forest terug
> voor bosbouw gebruikt worden. Eventueel kan het ook gebruikt worden voor
> bossen met een recreatieve of natuurbeschermende bestemming.
>
> Landcovers kunnen nooit overlappen. Ik heb nog niet hard genoeg nagedacht
> over landuses.
>
> Maar daar zijn we nog helemaal niet. En is het nu een zootje :-)
>
> m
>
> p.s.  Een van de problemen waar ik regelmatig mee worstel is dat je goed
> moet nadenken over de betekenis van een woord voor je het kan mappen. Wat
> is een park ? Wat is een tuin ? (of iets heel anders: ) wat is een
> parking/parkeerterrein ? (dit is niet hetzelfde als een
> parkeerplaats)
> p.s.  Ik ben al een half jaar aan het nadenken over dit thema, ik had me
> er vroeger nooit zo bezig gehouden met het mappen van
> landuse/landcover/natural, maar ik zag teveel fouten of gewijzgde
> situtaties en wou weten hoe ik ze kon verbeteren. Dan begin je te lezen
> over het thema, vr

[OSM-talk-be] (no subject)

[Marc Gemis]

Sorry voor de lange mail, maar het is toch slecht weer, dus heb je wat
om te lezen :-)

Jasper,

De oorspronkelijke betekenis van landuse=forest was een bosgebied
waarvan het hout gekapt wordt voor industriële doeleinden (bosbouw).
Daarnaast had je natural=wood voor natuurlijk, niet onderhouden bos.
Omdat het meeste bos hier niet meer natuurlijk is, maar aangeplant en
onderhouden zijn meer mensen landuse=forest beginnen gebruiken. Hoewel
niet elk onderhouden bos echt voor bosbouw is.

Verder plakken sommige mappers gewoon op alles wat op een luchtfoto op
een groepje bomen lijkt als landuse=forest. Er is geen echte tag voor
een groepje bomen.

Het volgende probleem is dan dat ook bosjes, zonder echte bomen maar
met grote struiken via luchtfoto's als landuse=forest worden gemapped.

Dit laatste kan je verhelpen door natural=scrub te gebruiken, ook voor
struiken in meer stedelijke gebieden, ik denk dus ook voor het stukje
grond dat jij aangeeft. scrub wordt ook wel als struikgewas of
kreupelhout vertaalt (google translate). Dus dat pas wel.

Dus in jouw geval zou natural=scrub beter zijn dan landuse=forest ,
toch als er meer struiken zijn dan bomen. Maar wat als er dan toch wat
onderhoud aan te pas komt ?

Voor je golf terrein, de belangrijkste tag daar is  leisure=golf
natuurlijk. Ik zou nu voor landcover=trees gaan. Het is helemaal geen
bosbouw, noch een bos. Dat het niet op de standaard kaart komt, het
zij zo. Als er genoeg landcover tags gebruikt worden, gaan ze die ook
wel tonen.

Over het verschil tussen landcover=grass en landuse=grass
Landuse zou het gebruik van het land moeten aangeven. Hier wonen
mensen, hier werken ze, hier wordt gerecreëerd, hier wordt aan
landbouw of veeteelt gedaan, enz.
Maar wat is "hier wordt aan gras gedaan" ? Vandaar dat landuse=grass
niet echt juist is, misschien enkel voor gebieden waar graszodes
geteeld worden. Maar omdat het op de kaart getoond wordt, zie je
landuse=grass overal verschijnen. (ipv het correctere landcover=grass)

Landcover slaat op wat je op de grond vindt.

Volgens mij moet in een ideale OSM map, elke plek op aarde [1] tot 2
polygonen behoren:
eentje met een landuse tag een eentje met een landcover tag. De ene
geeft de bestemming aan, de andere wat je op de grond vindt. En dan
kan je ook nog in sommige gevallen het type recreatie (leisure) of
faciliteiten (amenity), etc. daarboven op gaan mappen.

Dus voor een park
- leisure=park (doen we nu al)
- landuse=xxx (nog te definiëren)
- dan voor verschillende delen landcover=trees of grass of bushes of
sand, rocks, etc.
-
Momenteel mappen we meestal enkel leisure=park, en misschien al eens
een landuse=grass of forest.


Bij een woning met tuin
- landuse=residential
- landcover (zoals bij park) voor de tuin, misschien voor oprit, de
plek van het huis, terras, e.d. nog andere landcovers
Dus hier geen landuse=forest om de tuin aan te duiden. Er is geen
bosbouw, er is ook geen bos om te recreëren, dus waarom landuse=forest
? Dat is taggen voor de renderer [1].

Dat is volgens mij het doel van de landcover, om los van het gebruik
bomen, struiken enz te kunnen aangeven. En dan kan landuse=forest
terug voor bosbouw gebruikt worden. Eventueel kan het ook gebruikt
worden voor bossen met een recreatieve of natuurbeschermende
bestemming.

Landcovers kunnen nooit overlappen. Ik heb nog niet hard genoeg
nagedacht over landuses.

Maar daar zijn we nog helemaal niet. En is het nu een zootje :-)

m

p.s.  Een van de problemen waar ik regelmatig mee worstel is dat je
goed moet nadenken over de betekenis van een woord voor je het kan
mappen. Wat is een park ? Wat is een tuin ? (of iets heel anders: )
wat is een parking/parkeerterrein ? (dit is niet hetzelfde als een
parkeerplaats)
p.s.  Ik ben al een half jaar aan het nadenken over dit thema, ik had
me er vroeger nooit zo bezig gehouden met het mappen van
landuse/landcover/natural, maar ik zag teveel fouten of gewijzgde
situtaties en wou weten hoe ik ze kon verbeteren. Dan begin je te
lezen over het thema, vragen op mailing lists te volgen,  en dan ben
je nog niet wijzer.
p.s. Joost, je schreef ooit dat het gemakkelijker wordt als je meer
weet over OSM, maar dat is niet waar, zie de vorige p.s. :-)

[1] toch in de bewoonde wereld, op Antartica is landuse misschien niet nodig
[2] https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer

2017-01-13 13:24 GMT+01:00 Jasper Michels :
> De discussie ook gelezen.
> Wat voor mij echter niet duidelijk is.
> Hoe tag je niet onderhoud bermen met struiken en enkele kleine boompjes
> (struiken die tot bomen uitgroeien) langs de straat.
> Zoals je nogal veel ziet langs grote wegen, of op het platteland.
> https://www.openstreetmap.org/#map=18/50.84018/3.60314
>
> Momenteel gebruik ik hier: Landuse=forest
> Maar volgens de wiki is dit enkel voor echte bossen.
> Dienen we dan landcover=bushes te gebruiken?
>
> de tag garden vindt ik hiervoor echt niet kunnen.
> Een garden beschouw ik een aangelegd stuk grond, dat 

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Romain MEHUT]

Bonjour,

J'ai pointé l'ajout de deux doublons (magasins Decathlon)
https://www.openstreetmap.org/changeset/34586502 et
http://www.openstreetmap.org/changeset/34632382 restés non corrigés à ce
jour. Et vu l'historique du compte
http://www.openstreetmap.org/user/SeFaireConnaitre, il y a ailleurs
d'autres doublons similaires.

Romain

Le 14 octobre 2015 23:35,  a écrit :

> Bien, merci d'améliorer votre processus de production/validation de
> données afin d'éviter de placer un lieu à 1,3 km de son lieu réel (distance
> en voiture selon OSRM).
> Ici par exemple comme déjà dit un lien sur un emplacement d'arrêt de tram
> doit faire tiquer.
> Ce n'est bon ni pour votre client, ni pour vous ni pour OpenStreetMap.
> Les deux premiers points c'est votre problème.
> Le troisième aussi mais c'est surtout celui qui nous concerne.
>
> Pour votre pénitence, vous leur proposerez une alternative à ceci :
> http://juvignac.apef-services.fr/contact.html#map
> ;-).
>
> Jean-Yvon
>
> Le 14/10/2015 09:23, Support Sefaireconnaitre -
> supp...@sefaireconnaitre.com a écrit :
>
> Bonjour,
> Merci pour le signalement, j'ai bien repositionné le point de vente.
>
> Amandine Nicolas - Ubiflow
>
>
>
> ___
> 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] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Support Sefaireconnaitre]

Bonjour,
Merci pour le signalement, j'ai bien repositionné le point de vente.

Amandine Nicolas - Ubiflow

Le 10 octobre 2015 20:52, Jérôme Seigneuret  a
écrit :

> Bonjour j'ai laissé un commentaire sur l'un des changeset.
>
> https://www.openstreetmap.org/changeset/32186586#map=19/43.61747/3.81009
>
> Le 31 août 2015 15:30, Support Sefaireconnaitre <
> supp...@sefaireconnaitre.com> a écrit :
>
>> Bonjour,
>>
>> Suite aux différents éléments que vous avez remontés, nous avons lancé
>> des travaux traiter les différents points d'amélioration.
>>
>> Ces travaux visent dans un premier temps à :
>>
>> - nous permettre de traiter les localisations en amont de l'envoi sur OSM.
>> - faibiliser ces localisations et les synchroniser avec BANO (via
>> l'API quand c'est possible et/ou manuellement avec le layer BANO)
>>
>> Nous avons intégré ces travaux à nos différents outils, et nous avons
>> traité une centaine de points de vente, à vocation de test.
>> Nous allons publier ces 100 POI cette semaine et refaire un point
>> suite à cela pour mesurer les progrès et voir les éventuels autres
>> points à traiter.
>>
>> N'hésitez pas à nous faire des retours, on les prendra en compte !
>>
>> bonne journée,
>>
>> Le 17 août 2015 21:40,   a écrit :
>> > Effectivement.
>> > En espérant voir les mêmes progrès sur les autres points soulevés.
>> > Cordialement,
>> >
>> > Jean-Yvon
>> >
>> > Le 17/08/2015 11:59, Support Sefaireconnaitre -
>> supp...@sefaireconnaitre.com
>> > a écrit :
>> >
>> > OK.
>> > c'est fait.
>> > on a retiré les éléments de tracling situés dans les URL.
>> >
>> > Le 14 août 2015 21:30,   a écrit :
>> >
>> > Je prends acte du mea culpa (merci).
>> > Pour la prise en compte, j'attends encore de voir.
>> > À ce jour encore 101 liens pistants "Ubiflow".
>> > Mon critère :
>> > node["website"~"ubiflow"]["website"!~"source=ubiflow"];
>> >
>> > Quand ce compteur sera à zéro, les fourmis pourront à nouveau tracer les
>> > pistes et le travail des fourmis ne servira plus à ce que d'autres
>> soient
>> > pistés à leur insu.
>> >
>> > Le faire passer à zéro est un gage de bonne foi, gage facile à réaliser.
>> >
>> > Jean-Yvon
>> >
>> > Le 14/08/2015 13:01, Brice MALLET - brice...@free.fr a écrit :
>> >
>> > Bonjour,
>> >
>> > Merci de vos explications sur cette liste quant à la prise en compte des
>> > remarques de la communauté des fourmis et ainsi VousFaire(re)Connaitre
>> :) au
>> > sein de celle-ci.
>> >
>> > Brice
>> >
>> >
>> >
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-fr
>> >
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-fr
>> >
>> >
>> >
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-fr
>> >
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Philippe Verdy]

Et pas corrigé le format de "website=*" qui doit être une URL complète,
avec le protocole http:// ou https:// approprié ; certes, les navigateurs
masquent le protocole dans la barre d'adresse quand c'est http ou https
(pour le second il utilise une icône de sécurité cliquable pour afficher
l'état du certificat), mais normalement il le conserve quand on copie-colle
depuis la barre d'adresse et il le rend visible en édition.



Autres remarques sur les liens utilisables (pour la sécurité, le respect de
la vie privée, l'accessibilité générale, et les performances à
l'utilisation avec un minimum d'échanges réseau à l'utilisation dans un
navigateur) :

(1) Ne pas oublier non plus "www." dans les noms de domaine canoniques,
s'il est nécessaire pour éviter une redirection immédiate ou une
non-validation d'un certificat de sécurité pour HTTPS (ce n'est pas le cas
ici)

Cela peut paraître redondant pour l'utilisateur, mais pas pour les outils
automatisés de vérification qui risquent d'ignorer le lien totalement en
cas de non-validation. Dans un rendu cartographique avec des icones
cliquables donnant un panneau d'information, cela n'empêche pas du tout ces
panneaux de faire le même traitement que les navigateurs pour **afficher**
un lien simplifié mais malgré tout rendre la cible du lien avec l'URL
complète (comme le font aussi les moteurs de recherche, bien que ceux-ci
utilisent une cible de lien modifiée pour transiter par un redirecteur,
hébergé par le moteur de recherche lui-même et destiné au comptage des
liens suivis et au profilage).

(2) Sur OSM on doit aussi s'interdire d'utiliser des adresses transitant
par des redirecteurs de profilage (y compris les "URL raccourcies" / tiny
URL, hébergés sur des domaines ouverts redirigeant vers des tas de sites
dont des sites malveillants avec des niveaux de sécurité différents : le
nom de domaine final après redirection doit être identifiable directedment
depuis le lien indiqué, et nombre de ces redirecteurs ont une durée de vie
faible, ou peuvent au final ne plus rediriger vers le site voulu) :

Donc merci de vérifier tous les liens avant de les mettre et ne garder que
la cible finale (seule exception : le nom de la page d'accueil par défaut
du site tel que "index.html" ou "index.asp" ou home.html" peut être omis
tant que la page par défaut "/" pour HTTP(S) reste sur le même domaine). En
cas de présence de paramètres de requête (après un "?"), ôter les
paramètres opionnels non indispensables qui ont des valeurs codées
spécifiques au suivi d'une session ou d'un droit d'accès, ne garder que les
paramètres identifiant une page sur le site.

(3) Si le lien final obtenu est seulement temporaire et spécifique à une
session ou à un utilisateur connecté au site, ce lien n'est pas utilisable,
on ne le met pas du tout (exemple, les liens vers des articles de presse
lisibles uniquement par les abonnés : on ne peut mettre que le lien vers la
page publique de résumé ne nécessitant aucune identification préalable).
Même chose sir le lien n'est utilisable qu'après avoir d'abord visité une
autre page du même site.

(4) Ne pas mettre le lien non plus vers une page s'il y a une indication
technique "no robots" demandant de ne pas indexer une page dans un moteur
de recherche, chercher plutôt une page indexable (cela interdit notamment
de mentionner les liens vers des pages d'annuaires de sites, très souvent
publicitaires). Cette vérification peut être automatisée, de tels liens
pourraient être supprimés automatiquement d'OSM s'ils sont présents dans la
base.

(5) Et sur les sites HTTPS, vérifier la validité des certificats utilisés :
un navigateur moderne ne devrait afficher aucune alerte de sécurité
demandant à l'utilisateur de vérifier manuellement l'émetteur ou d'accepter
un founisseur PKI non reconnu comme stable et sûr, ou d'accepter une
certificat expiré ou limité à un autre sous-domaine que celui pour lequel
le certificat a été signé (exemple lien avec "www2." alors que le
certificat ne signe que le sous-domaine "www." et aucun autre
sous-domaine). Sinon demander à l'administrateur du site de corriger en
installant de nouveaux certificats sur le site pour inclure les
sous-domaines manquants ou renouveler la signature chez son prestataire
PKI, ou corriger le sous-domaine approprié dans le lien public.

Ce genre de choses devrait être documenté sur le wiki d'OSM en tant que
règles de bonne conduite pour les liens acceptables.

Le 14 octobre 2015 09:23, Support Sefaireconnaitre <
supp...@sefaireconnaitre.com> a écrit :

> Bonjour,
> Merci pour le signalement, j'ai bien repositionné le point de vente.
>
> Amandine Nicolas - Ubiflow
>
> Le 10 octobre 2015 20:52, Jérôme Seigneuret  a
> écrit :
>
>> Bonjour j'ai laissé un commentaire sur l'un des changeset.
>>
>> https://www.openstreetmap.org/changeset/32186586#map=19/43.61747/3.81009
>>
>> Le 31 août 2015 15:30, Support Sefaireconnaitre <
>> supp...@sefaireconnaitre.com> a écrit :
>>
>>> Bonjour,
>>>
>>> 

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[osm . sanspourriel]

Bien, merci d'améliorer votre processus de production/validation de 
données afin d'éviter de placer un lieu à 1,3 km de son lieu réel 
(distance en voiture selon OSRM).
Ici par exemple comme déjà dit un lien sur un emplacement d'arrêt de 
tram doit faire tiquer.

Ce n'est bon ni pour votre client, ni pour vous ni pour OpenStreetMap.
Les deux premiers points c'est votre problème.
Le troisième aussi mais c'est surtout celui qui nous concerne.

Pour votre pénitence, vous leur proposerez une alternative à ceci :
http://juvignac.apef-services.fr/contact.html#map
;-).

Jean-Yvon

Le 14/10/2015 09:23, Support Sefaireconnaitre - 
supp...@sefaireconnaitre.com a écrit :

Bonjour,
Merci pour le signalement, j'ai bien repositionné le point de vente.

Amandine Nicolas - Ubiflow



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

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Philippe Verdy]

Au passage, les tags ne sont pas bons. Dans l'état c'est juste un
"office=company" avec un nom (mais aucune indication de l'activité réelle,
même pas une description à défaut de trouver un tag approprié), un
téléphone une page Facebook et un compte twitter.

Mais là le website n'est pas valide (ce n'est pas une URL sans le préfixe
"http(s)://").

Il est fort probable que le client n'a pasz indiqué son adresse exacte et
qu'il s'est situé "à peu près" sur cette station de RER, mais il n'y a eu
aucune rélle validation de l'adresse qui reste à chercher parmi les rues
autour, ce qui est complètement à côté de l'objectif d'une géolocalisation.
Polluer ainsi une station RER, c'est manifestement une tenative de se
positionner dessus pour faire de la publicité gratuite et cacher en fait
cette gare. Si son client ne veut pas donner d'adresse précise (même s'il
indique téléphone ou des sites web de contact), il n'a rien à faire dans
OSM où les éléments sont obligatoirement géolocalisés.

Il ne manquerait plus que "SeFaireConnaitre" prenne un contrat avec McDo ou
Quick ou autres pour mettre des noeuds dans toutes les gares des villes où
ils ont des restaurants, même s'ils ne sont pas présents dans ces gares
mais ont louent juste des panneaux publicitaires indiquant la direction à
300 mètres de là et 5 rues plus loin.

Mais là, SeFaireConnaitre n'a eu rien d'autre comme indication que
"Juvignac" et a choisi de se mettre à l'emplacement trouvé dans OSM pour la
gare et son parking. S'il n'a pas d'adresse précise, il doit savoir
***qu'il ne doit RIEN mettre dans OSM***, même si son client l'a payé pour
son  référencement (sans doute pas d'ailleurs pour être présent directement
dans OSM mais dans des annuaires de sites internet, mais SeFaireConnaitre
vend un "pack" et ne fait pas le détail : il lui crée des pages Facebook et
Twitter, lui crée ou héberge une page de site web. A-t-il seulement fait
une inscription de son client dans les pages jaunes sans indiquer
d'adresse? Il n'a même rien demandé à son client pour avoir des précisions.
Une société sans adresse physique est forcément un peu douteuse (le minimum
étant de chercher s'il y a une inscription au RCS pour avoir l'adresse
légale du siège et celle de son établissement principal).


Le 10 octobre 2015 20:52, Jérôme Seigneuret  a
écrit :

> Bonjour j'ai laissé un commentaire sur l'un des changeset.
>
> https://www.openstreetmap.org/changeset/32186586#map=19/43.61747/3.81009
>
> Le 31 août 2015 15:30, Support Sefaireconnaitre <
> supp...@sefaireconnaitre.com> a écrit :
>
>> Bonjour,
>>
>> Suite aux différents éléments que vous avez remontés, nous avons lancé
>> des travaux traiter les différents points d'amélioration.
>>
>> Ces travaux visent dans un premier temps à :
>>
>> - nous permettre de traiter les localisations en amont de l'envoi sur OSM.
>> - faibiliser ces localisations et les synchroniser avec BANO (via
>> l'API quand c'est possible et/ou manuellement avec le layer BANO)
>>
>> Nous avons intégré ces travaux à nos différents outils, et nous avons
>> traité une centaine de points de vente, à vocation de test.
>> Nous allons publier ces 100 POI cette semaine et refaire un point
>> suite à cela pour mesurer les progrès et voir les éventuels autres
>> points à traiter.
>>
>> N'hésitez pas à nous faire des retours, on les prendra en compte !
>>
>> bonne journée,
>>
>> Le 17 août 2015 21:40,   a écrit :
>> > Effectivement.
>> > En espérant voir les mêmes progrès sur les autres points soulevés.
>> > Cordialement,
>> >
>> > Jean-Yvon
>> >
>> > Le 17/08/2015 11:59, Support Sefaireconnaitre -
>> supp...@sefaireconnaitre.com
>> > a écrit :
>> >
>> > OK.
>> > c'est fait.
>> > on a retiré les éléments de tracling situés dans les URL.
>> >
>> > Le 14 août 2015 21:30,   a écrit :
>> >
>> > Je prends acte du mea culpa (merci).
>> > Pour la prise en compte, j'attends encore de voir.
>> > À ce jour encore 101 liens pistants "Ubiflow".
>> > Mon critère :
>> > node["website"~"ubiflow"]["website"!~"source=ubiflow"];
>> >
>> > Quand ce compteur sera à zéro, les fourmis pourront à nouveau tracer les
>> > pistes et le travail des fourmis ne servira plus à ce que d'autres
>> soient
>> > pistés à leur insu.
>> >
>> > Le faire passer à zéro est un gage de bonne foi, gage facile à réaliser.
>> >
>> > Jean-Yvon
>> >
>> > Le 14/08/2015 13:01, Brice MALLET - brice...@free.fr a écrit :
>> >
>> > Bonjour,
>> >
>> > Merci de vos explications sur cette liste quant à la prise en compte des
>> > remarques de la communauté des fourmis et ainsi VousFaire(re)Connaitre
>> :) au
>> > sein de celle-ci.
>> >
>> > Brice
>> >
>> >
>> >
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-fr
>> >
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Jérôme Seigneuret]

Bonjour j'ai laissé un commentaire sur l'un des changeset.

https://www.openstreetmap.org/changeset/32186586#map=19/43.61747/3.81009

Le 31 août 2015 15:30, Support Sefaireconnaitre <
supp...@sefaireconnaitre.com> a écrit :

> Bonjour,
>
> Suite aux différents éléments que vous avez remontés, nous avons lancé
> des travaux traiter les différents points d'amélioration.
>
> Ces travaux visent dans un premier temps à :
>
> - nous permettre de traiter les localisations en amont de l'envoi sur OSM.
> - faibiliser ces localisations et les synchroniser avec BANO (via
> l'API quand c'est possible et/ou manuellement avec le layer BANO)
>
> Nous avons intégré ces travaux à nos différents outils, et nous avons
> traité une centaine de points de vente, à vocation de test.
> Nous allons publier ces 100 POI cette semaine et refaire un point
> suite à cela pour mesurer les progrès et voir les éventuels autres
> points à traiter.
>
> N'hésitez pas à nous faire des retours, on les prendra en compte !
>
> bonne journée,
>
> Le 17 août 2015 21:40,   a écrit :
> > Effectivement.
> > En espérant voir les mêmes progrès sur les autres points soulevés.
> > Cordialement,
> >
> > Jean-Yvon
> >
> > Le 17/08/2015 11:59, Support Sefaireconnaitre -
> supp...@sefaireconnaitre.com
> > a écrit :
> >
> > OK.
> > c'est fait.
> > on a retiré les éléments de tracling situés dans les URL.
> >
> > Le 14 août 2015 21:30,   a écrit :
> >
> > Je prends acte du mea culpa (merci).
> > Pour la prise en compte, j'attends encore de voir.
> > À ce jour encore 101 liens pistants "Ubiflow".
> > Mon critère :
> > node["website"~"ubiflow"]["website"!~"source=ubiflow"];
> >
> > Quand ce compteur sera à zéro, les fourmis pourront à nouveau tracer les
> > pistes et le travail des fourmis ne servira plus à ce que d'autres soient
> > pistés à leur insu.
> >
> > Le faire passer à zéro est un gage de bonne foi, gage facile à réaliser.
> >
> > Jean-Yvon
> >
> > Le 14/08/2015 13:01, Brice MALLET - brice...@free.fr a écrit :
> >
> > Bonjour,
> >
> > Merci de vos explications sur cette liste quant à la prise en compte des
> > remarques de la communauté des fourmis et ainsi VousFaire(re)Connaitre
> :) au
> > sein de celle-ci.
> >
> > Brice
> >
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[Support Sefaireconnaitre]

Bonjour,

Suite aux différents éléments que vous avez remontés, nous avons lancé
des travaux traiter les différents points d'amélioration.

Ces travaux visent dans un premier temps à :

- nous permettre de traiter les localisations en amont de l'envoi sur OSM.
- faibiliser ces localisations et les synchroniser avec BANO (via
l'API quand c'est possible et/ou manuellement avec le layer BANO)

Nous avons intégré ces travaux à nos différents outils, et nous avons
traité une centaine de points de vente, à vocation de test.
Nous allons publier ces 100 POI cette semaine et refaire un point
suite à cela pour mesurer les progrès et voir les éventuels autres
points à traiter.

N'hésitez pas à nous faire des retours, on les prendra en compte !

bonne journée,

Le 17 août 2015 21:40,   a écrit :
> Effectivement.
> En espérant voir les mêmes progrès sur les autres points soulevés.
> Cordialement,
>
> Jean-Yvon
>
> Le 17/08/2015 11:59, Support Sefaireconnaitre - supp...@sefaireconnaitre.com
> a écrit :
>
> OK.
> c'est fait.
> on a retiré les éléments de tracling situés dans les URL.
>
> Le 14 août 2015 21:30,   a écrit :
>
> Je prends acte du mea culpa (merci).
> Pour la prise en compte, j'attends encore de voir.
> À ce jour encore 101 liens pistants "Ubiflow".
> Mon critère :
> node["website"~"ubiflow"]["website"!~"source=ubiflow"];
>
> Quand ce compteur sera à zéro, les fourmis pourront à nouveau tracer les
> pistes et le travail des fourmis ne servira plus à ce que d'autres soient
> pistés à leur insu.
>
> Le faire passer à zéro est un gage de bonne foi, gage facile à réaliser.
>
> Jean-Yvon
>
> Le 14/08/2015 13:01, Brice MALLET - brice...@free.fr a écrit :
>
> Bonjour,
>
> Merci de vos explications sur cette liste quant à la prise en compte des
> remarques de la communauté des fourmis et ainsi VousFaire(re)Connaitre :) au
> sein de celle-ci.
>
> Brice
>
>
>
> ___
> 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] était Subject=Re: SeFaireConnaitre :(, devient SeFaireConnaitre :|

[Support Sefaireconnaitre]

OK.
c'est fait.
on a retiré les éléments de tracling situés dans les URL.

Le 14 août 2015 21:30,  osm.sanspourr...@spamgourmet.com a écrit :
 Je prends acte du mea culpa (merci).
 Pour la prise en compte, j'attends encore de voir.
 À ce jour encore 101 liens pistants Ubiflow.
 Mon critère :
 node[website~ubiflow][website!~source=ubiflow];

 Quand ce compteur sera à zéro, les fourmis pourront à nouveau tracer les
 pistes et le travail des fourmis ne servira plus à ce que d'autres soient
 pistés à leur insu.

 Le faire passer à zéro est un gage de bonne foi, gage facile à réaliser.

 Jean-Yvon

 Le 14/08/2015 13:01, Brice MALLET - brice...@free.fr a écrit :

 Bonjour,

 Merci de vos explications sur cette liste quant à la prise en compte des
 remarques de la communauté des fourmis et ainsi VousFaire(re)Connaitre :) au
 sein de celle-ci.

 Brice



 ___
 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] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

[osm . sanspourriel]

Effectivement.
En espérant voir les mêmes progrès sur les autres points soulevés.
Cordialement,

Jean-Yvon

Le 17/08/2015 11:59, Support Sefaireconnaitre - 
supp...@sefaireconnaitre.com a écrit :

OK.
c'est fait.
on a retiré les éléments de tracling situés dans les URL.

Le 14 août 2015 21:30,  osm.sanspourr...@spamgourmet.com a écrit :

Je prends acte du mea culpa (merci).
Pour la prise en compte, j'attends encore de voir.
À ce jour encore 101 liens pistants Ubiflow.
Mon critère :
node[website~ubiflow][website!~source=ubiflow];

Quand ce compteur sera à zéro, les fourmis pourront à nouveau tracer les
pistes et le travail des fourmis ne servira plus à ce que d'autres soient
pistés à leur insu.

Le faire passer à zéro est un gage de bonne foi, gage facile à réaliser.

Jean-Yvon

Le 14/08/2015 13:01, Brice MALLET - brice...@free.fr a écrit :

Bonjour,

Merci de vos explications sur cette liste quant à la prise en compte des
remarques de la communauté des fourmis et ainsi VousFaire(re)Connaitre :) au
sein de celle-ci.

Brice



___
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] était Subject=Re: SeFaireConnaitre :(, devient SeFaireConnaitre :)

[Brice MALLET]

Bonjour,

Merci de vos explications sur cette liste quant à la prise en compte des 
remarques de la communauté des fourmis et ainsi VousFaire(re)Connaitre 
:) au sein de celle-ci.


Brice

Le 13/08/2015 17:35, Support Sefaireconnaitre a écrit :

Bonjour,

Comme convenu avec Christian, nous avons lancé des développements sur
les différents points que vous avez listés, pour améliorer la qualité
de nos publications, et vous éviter les différents problèmes qu'elles
ont pu causer.

Nous allons désormais traiter les géolocalisation en amont, pour ne
pas avoir à publier un POI et le déplacer ensuite.
Dans la mesure du possible, les POI seront synchronisés avec la base BAN.
Les doublons seront traités, en suppression ou en fusion.

Il y a du passif concernant les publications que nous avons faites
jusqu'ici, nous allons traiter ces différents POI pour les corriger.

Vous trouverez ci dessous le message que nous avons transmis à
Christian suite à son alerte, et evidemment nous serons plus attentifs
à la liste de diffusion pour mieux traiter les anomalies.
Nous sommes à l'écoute de vos retours et suggestions.
bonne journée

L'équipe SFC

Bonjour Christian,

je prends connaissance de votre mail, et de la liste de discussion,
avec de nouveaux messages depuis le mois de mai.
Des messages et des échanges qui ne sont pas satisfaisant, ni pour la
communauté, et évidemment pas pour nous, c'est un euphémisme.
Très clairement notre souhait n'est pas de nous appuyer sur la
communauté pour faire notre travail, nous voulons être autonomes et
corriger nos erreurs lorsque nous en faisons, quand à polluer les
bases, n'en parlons même pas c'est à l'opposé de notre volonté.

Je prends note d'un certain nombre de points, qui sont à traiter de
notre côté car ils correspondent à la réalité de nos process :
- nous utilisons une référence GPS et pas une référence adresse, à ce
stade, nous ne faisons pas le rapprochement strict, mais a minima,
nous vérifions manuellement la cohérence des données soit avec OSM,
soit avec le cadastre, et positionnons le POI sur le batiment.
je note la sortie de la base BAN qui devrait permettre le faire ce
rapprochement automatique sur une partie des POI.
- le fait que nous créions un POI, pour le corriger immédiatement est
vrai, c'est actuellement notre process, nous allons donc le revoir, et
nous créer des outils pour traiter cela en amont
- la vérification des doublons est intégrée dans nos process, si des
doublons sont créés ce sont des erreurs, et donc je vais faire en
sorte que nous soyons plus attentifs sur ce point.

Nous avons fait beaucoup de modifications suite à vos précédents
retours sur nos process (novembre), pour prendre en compte les
éléments que vous aviez remontés.
Nous avons fait des repasses sur les points que nous avions créés pour
améliorer la géolocalisation lorsqu'elle était mauvaise, cette repasse
est toujours en cours étant donné le volume, à date nous avons 3000
POI, nous sommes repassés sur 1500, 500 restent à traiter, et nous
avons 1000 POI qui n'ont pas été publiés.
Le process auparavant automatique est désormais passé en
semi-automatique, pour intégrer les vérifications, permettre une
géolocalisation de meilleure qualité, et ne pas créer de doublons.
Nous allons continuer à travailler dans ce sens et prendre en compte
vos retours dans nos process.

Par rapport aux retours de la mailing list je retiens les points suivants :
- Des personnes remontent que la qualité de la géolocalisation est
meilleure qu'auparavant, sans éluder les autres problèmes ou les
anomalies restantes, je prends cela plutôt positivement car nous avons
travaillé sur ce point.
- Il y a un problème de process, que nous allons revoir, pour ne pas
créer un point mal geolocalisé et le relocaliser ensuite, afin de vous
éviter le bruit que cela génère.
- les points ne sont pas croisés avec les bases d'adresses, nous
allons travailler sur ce point, notamment avec BAN, pour les adresses
qui ne seraient pas accessibles ou vérifiables via ces bases nous
continuerons sur la géolocalisation GPS, et si nous ne pouvons pas
localiser précisément alors nous ne publierons pas.
- nous avons taggué les url de certains POI sur demande d'un de notre
client qui voulait intégrer le tracking dans ses outils, nous ne le
ferons plus

Voila à date ce que je peux vous dire en termes d'action de notre côté.
Effectivement nous n'avons pas été attentifs aux messages de la
mailing list, nous allons faire en sorte de la surveiller plus
attentivement pour être plus réactifs en cas de probleme, et en tout
cas plus constructifs.
Je vais faire en sorte de lancer le dev de ces outils de notre côté,
sur BANO et sur les traitements amont de géolocalisation, en l'attente
de ces outils je vais suspendre les nouvelles publications.
Nous continuerons à traiter les 500 points sur lesquels nous ne sommes
pas encore repassés.

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

Re: [OSM-talk-fr] était Subject=Re: SeFaireConnaitre :(, devient SeFaireConnaitre :|

[osm . sanspourriel]

Je prends acte du mea culpa (merci).
Pour la prise en compte, j'attends encore de voir.
À ce jour encore 101 liens pistants Ubiflow.
Mon critère :
node[website~ubiflow][website!~source=ubiflow];

Quand ce compteur sera à zéro, les fourmis pourront à nouveau tracer les 
pistes et le travail des fourmis ne servira plus à ce que d'autres 
soient pistés à leur insu.


Le faire passer à zéro est un gage de bonne foi, gage facile à réaliser.

Jean-Yvon

Le 14/08/2015 13:01, Brice MALLET - brice...@free.fr a écrit :

Bonjour,

Merci de vos explications sur cette liste quant à la prise en compte 
des remarques de la communauté des fourmis et ainsi 
VousFaire(re)Connaitre :) au sein de celle-ci.


Brice


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

[OSM-talk-ie] (no subject)

[Martin Costello]

Could I have sheet 23/11NW please.  Murt
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [OSM-talk-ie] (no subject)

[Donal Diamond]

On 19 November 2014 17:51, Brian Prangle bpran...@gmail.com wrote:

 Hi

 Can I request sheets 26/25 NW and SW?


Uploaded all 4 in that set.

http://mapwarper.net/maps?field=titlequery=IRL-GSGS-3906-26-25show_warped=0


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

[OSM-talk-ie] (no subject)

[Brian Prangle]

Hi

Can I request sheets 26/25 NW and SW?

Thanks

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

Re: [OSM-talk-ie] (no subject)

[Donal Diamond]

Uploaded:

http://mapwarper.net/maps/4903

Good luck!

D


On 30 October 2014 17:47, Ian Spillane iantheteac...@gmail.com wrote:

 Can I request map 14/11/SE for townland mapping here?
 ___
 Talk-ie mailing list
 Talk-ie@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-ie

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

Re: [OSM-talk-nl] (no subject)

[Jeroen Muris]

Robert,

Dank voor de uitnodiging. Ik hoop nu dan toch eens een Mapping Party mee 
te maken en at mede-mappers te ontmoeten. Tot de 2e of de 9e.


J-.

Jeroen Muris


Op 6-9-2011 20:14, Robert Elsenaar schreef:

Hoi Collega-mappers,
Ook dit jaar, het mag al bijna 
(http://forum.openstreetmap.org/viewtopic.php?id=8906 ) traditie 
genoemd worden, nodig ik jullie allemaal uit voor de Mapping Party 
2011 in Putten op de Veluwe.

http://dl.dropbox.com/u/21144369/DSCF0427.JPG
Ik heb weer een paar leuke stukken werk geselecteerd:

  * *De Groene Scheg*

(http://maps.google.nl/maps?hl=nlll=52.255077,5.59968spn=0.00662,0.021136t=hz=16vpsrc=6

http://maps.google.nl/maps?hl=nlll=52.255077,5.59968spn=0.00662,0.021136t=hz=16vpsrc=6):
een educatief park midden in Putten die recentelijk helemaal is
gemoderniseerd.
  * *Putten Centrum*

(http://maps.google.nl/maps?hl=nlll=52.260468,5.608199spn=0.00331,0.010568t=hz=17vpsrc=6)

http://maps.google.nl/maps?hl=nlll=52.260468,5.608199spn=0.00331,0.010568t=hz=17vpsrc=6:
Ons prachtige toeristische centrum verdient om in alle details op
de kaart gezet te worden.
  * *Buitengebied Putten*

(http://maps.google.nl/maps?hl=nlll=52.261749,5.6777spn=0.052953,0.169086t=hz=13vpsrc=6

http://maps.google.nl/maps?hl=nlll=52.261749,5.6777spn=0.052953,0.169086t=hz=13vpsrc=6):
Putten heeft een 'open' buitengebied. Veel wegen hebben
verschillende access en surface waarde. Het is goed dat deze eens
keurig (door fietsers) in kaart wordt gebracht.

Voor de aanwezigen staat mijn WiFi kanaal open (dit jaar nog sneller). 
Natuurlijk staat ook de traditionele en veel besproken Oud-Brabantse 
Erwtensoep en Roggebrood met Spek klaar.

Als je zin hebt om deze dag mee te maken, dan ben je van harte welkom.
Ik heb 2 datum uitgekozen. Kies een datum:
http://www.doodle.com/gcttvpgvhqzpvgkr
groet
Robert Elsenaar (Alias ZMWandelaar; alias ZondagMiddagWandelaar)


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

[OSM-talk-nl] (no subject)

[Robert Elsenaar]

Hoi Collega-mappers,

Ook dit jaar, het mag al bijna 
(http://forum.openstreetmap.org/viewtopic.php?id=8906 ) traditie genoemd 
worden, nodig ik jullie allemaal uit voor de Mapping Party 2011 in Putten op de 
Veluwe.

http://dl.dropbox.com/u/21144369/DSCF0427.JPG 

Ik heb weer een paar leuke stukken werk geselecteerd:
  a.. De Groene Scheg 
(http://maps.google.nl/maps?hl=nlll=52.255077,5.59968spn=0.00662,0.021136t=hz=16vpsrc=6):
 een educatief park midden in Putten die recentelijk helemaal is 
gemoderniseerd. 
  b.. Putten Centrum 
(http://maps.google.nl/maps?hl=nlll=52.260468,5.608199spn=0.00331,0.010568t=hz=17vpsrc=6):
 Ons prachtige toeristische centrum verdient om in alle details op de kaart 
gezet te worden. 
  c.. Buitengebied Putten” 
(http://maps.google.nl/maps?hl=nlll=52.261749,5.6777spn=0.052953,0.169086t=hz=13vpsrc=6):
 Putten heeft een 'open' buitengebied. Veel wegen hebben verschillende access 
en surface waarde. Het is goed dat deze eens keurig (door fietsers) in kaart 
wordt gebracht.

Voor de aanwezigen staat mijn WiFi kanaal open (dit jaar nog sneller). 
Natuurlijk staat ook de traditionele en veel besproken Oud-Brabantse 
Erwtensoep en Roggebrood met Spek klaar.

Als je zin hebt om deze dag mee te maken, dan ben je van harte welkom.

Ik heb 2 datum uitgekozen. Kies een datum:
http://www.doodle.com/gcttvpgvhqzpvgkr 

groet
Robert Elsenaar (Alias ZMWandelaar; alias ZondagMiddagWandelaar)___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

[OSM-talk-nl] (no subject)

[Christiaan Roeterdink]

Christiaan Roeterdink
Den Bosch
The Netherlands
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl

Re: [OSM-talk-nl] (no subject)

[Rob Aerts]

haha, dat is nog eens een introductie !

2007/10/3, Danny Maas [EMAIL PROTECTED]:
 Nou. Welkom ;-)



 On 10/3/07, Christiaan Roeterdink [EMAIL PROTECTED] wrote:
 
  Christiaan Roeterdink
  Den Bosch
  The Netherlands
 
  ___
  Talk-nl mailing list
  Talk-nl@openstreetmap.org
 
 http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
 
 


 ___
 Talk-nl mailing list
 Talk-nl@openstreetmap.org
 http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl



___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl

Re: [OSM-talk-nl] (no subject)

[joris meijerink]

hopelijk heb je in de toekomst meer te melden ;)

On 10/3/07, Christiaan Roeterdink [EMAIL PROTECTED] wrote:
 Christiaan Roeterdink
 Den Bosch
 The Netherlands

 ___
 Talk-nl mailing list
 Talk-nl@openstreetmap.org
 http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl



___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl