Re: [OSM-talk-fr] osm.org Affichage ville selon zoom - Vichy vs Cusset

2020-11-11 Per discussione Christian Quest

Le 11/11/2020 à 22:34, osm.sanspourr...@spamgourmet.com a écrit :

Et pour que le rendu osm.org s'en sorte bien, il faut une bonne âme pour
faire un PR s'inspirant du travail de Christian.

Christian, tu peux utiliser les relations boundary d'admin_level=8 pour
ajouter la population au nœud label ou admin_centre si la population
n'est pas donnée.



C'est bien trop complexe pour un rendu, car dans les tables générées par 
osm2pgsql ou imposm on n'a pas le détail des relations et des rôles de 
tel ou tel objet.


On peut sûrement bricoler avec osm2pgsql via les tables qui servent à la 
mise à jour, mais pas avec imposm à ce que je sache et bien sûr ceci a 
un coût en perf (et on sature déjà).




Et si tu veux te rappeler si c'est une donnée déduite, tu peux mette un
nombre négatif à condition de ne pas oublier de prendre la valeur
absolue ;-).

Je dis 8 mais au delà ce serait intéressant pour les villes n'ayant pas
capital= : une capitale régionale sera ainsi vue comme plus importante
qu'une ville plus peuplée mais simple sous-préfecture par exemple.

Donc peut-être regarder si on a capital= pour savoir si on doit faire
"déteindre" la population de la relation sur le nœud. Oui c'est un
boulot d'import en plus. 


Pour une amélioration, c'est soit remettre un population=* sur le noeud, 
soit un capital=* (jusqu'à 7 suffit, en France).


Pour info, dans le wiki :

- population est en "useful combination" et encourage de le mettre... 
pas de le retirer


- population n'est même pas mentionné sur boundary=administrative


--

Christian Quest - OpenStreetMap France


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


Re: [OSM-talk-fr] Import des horaires des bureaux de poste

2020-11-11 Per discussione David Faure via Talk-fr
On mercredi 11 novembre 2020 21:48:36 CET osm.sanspourr...@spamgourmet.com 
wrote:
> Il est possible que ce fichier soit de grande qualité comme de
> piètre qualité.

OK, on va voir :-)

> Je te propose de jouer pour ref:FR:LaPoste
> 
> 10115A. Pas d'horaires actuellement, là encore il y a eu les horaires
> covid mais je dois avoir une photo des horaires d'avant - et les connais
> à peu près. C'était du style demi-tordu sans doute à cause d'un temps
> partiel modifié.

10115A|GUIDEL BP|Mo-We,Fr 09:00-12:00,14:00-17:00; Th 09:00-12:00,14:30-17:00; 
Sa 09:00-12:00; Su,PH off

Ah tiens à ce propos, pour les cas où il existe des horaires dans OSM, je vois 
souvent
que la seule différence entre OSM et datanova c'est que je génère "Su,PH off" à 
la fin
alors que dans OSM ça n'y est pas. Je sais que ça revient au même, mais est-ce 
qu'il y
a une bonne pratique par rapport à ça ? Je peux le supprimer de ma génération
pour que ça colle plus aux données existantes, si c'est considéré plus lisible.
Ou le laisser si c'est considéré plus explicite.

Je viens de rajouter un coup de https://github.com/rezemika/oh_sanitizer sur 
les deux données
mais la différence reste, apparement oh_sanitizer n'y touche pas.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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


Re: [OSM-talk-fr] osm.org Affichage ville selon zoom - Vichy vs Cusset

2020-11-11 Per discussione Cyrille37 OSM via Talk-fr

Le 11/11/2020 à 12:11, Christian Quest a écrit :

Le 11/11/2020 à 10:29, Yves P. a écrit :
Sur osm.org la Ville de Vichy n'est affichée qu'à partir du zoom 11, 
avant <=10 c'est la plus petite commune de Cusset qui l'est. Est-ce 
à cause des données ?
Christian avait bien expliqué le problème : Faire un rendu c'est 
compliqué, il y a des choix à faire.


Dans "le" rendu .org, soit il ne tient pas compte de la population 
(tag dans les données OSM), soit il le fait mais va pas voir dans une 
source externe plus complète et plus à jour.


Auriez-vous un lien pour que je vois comment le rendu osm.org priorise ?
Merci
C/.


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


Re: [OSM-talk-fr] Rendu BANO (v2) de retour !

2020-11-11 Per discussione Jean-Claude Repetto

Le 11/11/2020 à 12:05, Christian Quest a écrit :
J'ai mergé la PR de Vincent et remis en route le rendu BANO maintenant 
en v2.


Pas de changement sur le rendu lui même en principe...

URL inchangée, donc il n'y a qu'à activer la couche dans JOSM comme avant.



Bonjour,

Merci à tous ceux qui ont œuvré pour la remise en route.

En relisant la page du wiki: 
https://wiki.openstreetmap.org/wiki/FR:France/WikiProject_Base_Adresses_Nationale_Ouverte_(BANO) 
,
je m'aperçois qu'il y a certains liens obsolètes, et que la légende 
n'est peut-être pas complète (points bleu clair, par exemple).


Pourriez-vous la mettre à jour ?

Merci d'avance !

Jean-Claude



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


Re: [OSM-talk-fr] Import des horaires des bureaux de poste

2020-11-11 Per discussione Jérôme Amagat
Je sais pas si c'est facile à adapter à ton code mais chaque objet garde la
date de dernière modification (on a pas ce qui a été modifié, ca peut être
n'importe quel tag ou la géométrie), donc peut être modifier les
opening_hours=* existant que si n'a pas été modifié depuis au moins 1 ou 2
ans ..., pour s'adapter aux réticences de ceux qui pense que la source
n'est pas obligatoirement fiable, on peut penser que si le tag
opening_hours=* n'a pas été touché depuis au moins 1 an ou 2 alors les
données osm ne sont pas fiable non plus. Mais je n'ai pas regardé et il est
possible qu'il n'y ai pas beaucoup de bureau de poste non modifier depuis 1
an.

Le mer. 11 nov. 2020 à 22:23,  a écrit :

>
> Le 08/11/2020 à 23:20, David Faure via Talk-fr -
> talk-fr@openstreetmap.org a écrit :
> > Bonjour et merci pour toutes ces réponses !
> >
> > On dimanche 8 novembre 2020 16:43:36 CET
> osm.sanspourr...@spamgourmet.com
> > wrote:
> >>   > (ignore everything after 11:45, that's the max time for sending
> >>> letters, parcels, etc.)
> >> Pourquoi ? Si la poste est ouverte, ça peut être utile pour poster un
> >> colis même s'il part le lendemain, rencontrer un conseiller.
>
> Je vois qu'Yves avait compris ce que tu veux dire. Ce que je ne
> comprends pas c'est ce que tu dis initialement : on se fiche des heures
> de collectes par rapports aux horaires d'ouverture de la Poste ou de
> l'agence postale.
>
> Oui avançons déjà sur opening_hours. Yves déclinera les collection_times
> (qui sont sans doute plus simples) :-D.
>
> >>   > Detect cases like "every other Saturday", which seems to happen.
> >>
> >> Adrien et Cie, on a un moyen de modéliser ça proprement dans OSM ?
> > J'ai trouvé "week 2-53/2" mais ça ne fonctionne pas forcément au
> changement
> > d’année… Fin 2020, la semaine 53 est suivie de la semaine 1, donc deux
> > semaines impaires se suivent.
> > Et justement la Poste de La Boisse (aucune idée de là où ça se trouve)
> > est ouverte le samedi matin les jours suivants: 2020-12-12, 2020-12-26,
> > 2021-01-09, 2021-01-23, donc semaines 50, 52, 1, 3.
> >
> > Au pire il faudra que je fasse "2020 week 2-53/2 Sa [...]" et "2021 week
> > 1-53/2 Sa [...]" en dupliquant la donnée, si y'a pas mieux...
>
> Oui mais ça n'arrive que pour quelques bureaux et seulement au dernier
> trimestre.
>
> Même si le rythme quinzomadaire arrive ailleurs aussi (par exemple
> poubelles jaunes dans mon agglo). Donc semaine paire certaines années,
> impaires d'autres, ça n'a pas l'air d'avoir été défini dans opening_hours.
>
> > Les jours fériés je gère déjà [tant que le bureau fait la même chose
> tous les
> > jours fériés...].
> Je pensais bien, restent donc quelques dates vraiment exceptionnels.
> > Oui si j'arrive à tout automatiser, l'import pourrait se faire
> régulièrement.
> > Les données sont pour les 3 prochains mois, mais je ne sais pas si ça
> garantit
> > ces horaires. C'est peu probable (grêves, arrêts maladie, ...).
> Je pense que les grèves, tu n'auras pas (les grévistes n'ont pas à
> prévenir à l'avance). Les arrêts maladie ? Ça n'a apparaitrait que si le
> bureau n'est tenu que par une personne. Et dans ce cas je crains que
> l'info reste coincée aux niveau des RH. Alors des plages horaires
> réduites pour les bureaux de taille moyenne ? Je ne sais.
> >> Un truc sympa serait d'avoir une carte, par exemple un fond OSM et une
> >> info bulle sur les bureaux avec les horaires actuels, les horaires
> >> déduits et les horaires bruts dont tu pars. Par exemple en important tes
> >> données dans une umap.
> > Euh. Ça c'est du chinois pour moi (je saurais pas faire), et j'ai du mal
> à
> > voir l'intérêt. Si c'est pour débugguer, un simple "grep" sur le fichier
> de
> > départ et le fichier de sortie permet de regarder ça. Si c'est pour
> > l'utilisateur final, le but c'est de voir ça dans OsmAnd et autres :)
>
> C'est bien pour déboguer mais pour que la communauté vérifie.
>
> Bien sûr n'importe qui pourrait si le code est visible de manger le même
> travail de vérification que toi.
>
> umap.openstreetmap.fr, en haut tu te connectes avec ton identifiant OSM.
>
> Tu importes le fichier que tu as généré (csv, geojson, osm,...). Et
> ensuite reste "juste" à formater pour voir les bureaux avec horaires sur
> la carte.
>
> "Juste" c'est dans la couche d'import définir dans les "Options
> d'interaction" le "Gabarit du contenu de la popup".
>
> Et c'est simple :
>
> /Utilisez des variables avec les noms de propriétés de vos éléments
> entre accolades, ex. {name}, elles seront remplacées dynamiquement par
> les valeurs correspondantes./
>
>
>   /Mise en forme du texte/
>
>   * /*simple astérisque pour italique*/
>   * /**double astérisque pour gras**/
>   * /# un dièse pour titre 1/
>   * /## deux dièses pour titre 2/
>   * /### trois dièses pour titre 3/
>   * /Lien simple : [[https://exemple.fr]]/
>   * /Lien avec texte : [[http://exemple.fr|texte du lien]]/
>   * /Image : {{http://image.url.com}}/
>   * /Image avec largeur (en 

Re: [Talk-at] Gefahr durch Internet-Bergrouten

2020-11-11 Per discussione Robert Grübler
Am 11. November 2020 20:02 schrieb Richard:

> das Problem sind die Nichtwanderkarten die niemals vorhatten 
> sac_scale, via_ferrata_scale, uiaa uvm auszuwerten,
> wie soll das jemals funktionieren.

Sie darauf ansprechen - und dann vergessen, für den eigenen Seelenfrieden.
Als Mapper gehört das Kartendesign nicht zu unseren Aufgaben. Wir schauen auf 
die Richtigkeit der Daten.

LG Robert



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


Re: [OSM-talk-fr] Rendu BANO (v2) de retour !

2020-11-11 Per discussione deuzeffe

Le 11/11/2020 à 17:40, Vincent de Château-Thierry a écrit :

Le 11/11/2020 à 16:31, deuzeffe a écrit :

D'ici ce soir, je te fais un ticket circonstancié :)


vincent qui met ça sur sa tout doux


Juste après l'intégration du nouveau Fantoir d'automne confiné ? ;)

'xactement :)


Done!

D'ailleurs, en farfouillant dans adresse.data.gouv.fr, quelle ne fut ma 
surprise de ne trouver plus qu'une base nationale, la... BAN (et les 
fichiers s'appellent adresses.* ^^)


Ayé, le "Produit gratuit issu de la BAN" est définitivement supprimé et 
les données DGFiP 2018 oubliées (enfin !) ?


L'impression d'avoir raté un épisode...
--
deuzeffe, légèrement outdated

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


Re: [OSM-talk-fr] Osmose : documentation interactive de création d'analyse (Jupyter)

2020-11-11 Per discussione Éric Gillet

Le 07/11/2020 à 18:06, Frédéric Rodrigo a écrit :

Bonjour,

Une version interactive de la documentation de création d'analyses 
pour Osmose est disponible en ligne. Le but est de rendre la chose 
accessible à plus de monde.


Bonjour,

Merci pour ce fantastique outil, ça m'a bien aidé pour proposer une 
analyse  ! J'ai pas 
essayé en ligne, mais en local ça marche bien :)


Éric

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


Re: [OSM-talk-fr] osm.org Affichage ville selon zoom - Vichy vs Cusset

2020-11-11 Per discussione osm . sanspourriel

Et pour que le rendu osm.org s'en sorte bien, il faut une bonne âme pour
faire un PR s'inspirant du travail de Christian.

Christian, tu peux utiliser les relations boundary d'admin_level=8 pour
ajouter la population au nœud label ou admin_centre si la population
n'est pas donnée.

Et si tu veux te rappeler si c'est une donnée déduite, tu peux mette un
nombre négatif à condition de ne pas oublier de prendre la valeur
absolue ;-).

Je dis 8 mais au delà ce serait intéressant pour les villes n'ayant pas
capital= : une capitale régionale sera ainsi vue comme plus importante
qu'une ville plus peuplée mais simple sous-préfecture par exemple.

Donc peut-être regarder si on a capital= pour savoir si on doit faire
"déteindre" la population de la relation sur le nœud. Oui c'est un
boulot d'import en plus.

Jean-Yvon

Le 11/11/2020 à 12:11, Christian Quest - cqu...@openstreetmap.fr a écrit :

Le 11/11/2020 à 10:29, Yves P. a écrit :

Sur osm.org la Ville de Vichy n'est affichée qu'à partir du zoom 11,
avant <=10 c'est la plus petite commune de Cusset qui l'est. Est-ce
à cause des données ?



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


Re: [OSM-talk-fr] Import des horaires des bureaux de poste

2020-11-11 Per discussione osm . sanspourriel


Le 08/11/2020 à 23:20, David Faure via Talk-fr -
talk-fr@openstreetmap.org a écrit :

Bonjour et merci pour toutes ces réponses !

On dimanche 8 novembre 2020 16:43:36 CET osm.sanspourr...@spamgourmet.com
wrote:

  > (ignore everything after 11:45, that's the max time for sending

letters, parcels, etc.)

Pourquoi ? Si la poste est ouverte, ça peut être utile pour poster un
colis même s'il part le lendemain, rencontrer un conseiller.


Je vois qu'Yves avait compris ce que tu veux dire. Ce que je ne
comprends pas c'est ce que tu dis initialement : on se fiche des heures
de collectes par rapports aux horaires d'ouverture de la Poste ou de
l'agence postale.

Oui avançons déjà sur opening_hours. Yves déclinera les collection_times
(qui sont sans doute plus simples) :-D.


  > Detect cases like "every other Saturday", which seems to happen.

Adrien et Cie, on a un moyen de modéliser ça proprement dans OSM ?

J'ai trouvé "week 2-53/2" mais ça ne fonctionne pas forcément au changement
d’année… Fin 2020, la semaine 53 est suivie de la semaine 1, donc deux
semaines impaires se suivent.
Et justement la Poste de La Boisse (aucune idée de là où ça se trouve)
est ouverte le samedi matin les jours suivants: 2020-12-12, 2020-12-26,
2021-01-09, 2021-01-23, donc semaines 50, 52, 1, 3.

Au pire il faudra que je fasse "2020 week 2-53/2 Sa [...]" et "2021 week
1-53/2 Sa [...]" en dupliquant la donnée, si y'a pas mieux...


Oui mais ça n'arrive que pour quelques bureaux et seulement au dernier
trimestre.

Même si le rythme quinzomadaire arrive ailleurs aussi (par exemple
poubelles jaunes dans mon agglo). Donc semaine paire certaines années,
impaires d'autres, ça n'a pas l'air d'avoir été défini dans opening_hours.


Les jours fériés je gère déjà [tant que le bureau fait la même chose tous les
jours fériés...].

Je pensais bien, restent donc quelques dates vraiment exceptionnels.

Oui si j'arrive à tout automatiser, l'import pourrait se faire régulièrement.
Les données sont pour les 3 prochains mois, mais je ne sais pas si ça garantit
ces horaires. C'est peu probable (grêves, arrêts maladie, ...).

Je pense que les grèves, tu n'auras pas (les grévistes n'ont pas à
prévenir à l'avance). Les arrêts maladie ? Ça n'a apparaitrait que si le
bureau n'est tenu que par une personne. Et dans ce cas je crains que
l'info reste coincée aux niveau des RH. Alors des plages horaires
réduites pour les bureaux de taille moyenne ? Je ne sais.

Un truc sympa serait d'avoir une carte, par exemple un fond OSM et une
info bulle sur les bureaux avec les horaires actuels, les horaires
déduits et les horaires bruts dont tu pars. Par exemple en important tes
données dans une umap.

Euh. Ça c'est du chinois pour moi (je saurais pas faire), et j'ai du mal à
voir l'intérêt. Si c'est pour débugguer, un simple "grep" sur le fichier de
départ et le fichier de sortie permet de regarder ça. Si c'est pour
l'utilisateur final, le but c'est de voir ça dans OsmAnd et autres :)


C'est bien pour déboguer mais pour que la communauté vérifie.

Bien sûr n'importe qui pourrait si le code est visible de manger le même
travail de vérification que toi.

umap.openstreetmap.fr, en haut tu te connectes avec ton identifiant OSM.

Tu importes le fichier que tu as généré (csv, geojson, osm,...). Et
ensuite reste "juste" à formater pour voir les bureaux avec horaires sur
la carte.

"Juste" c'est dans la couche d'import définir dans les "Options
d'interaction" le "Gabarit du contenu de la popup".

Et c'est simple :

/Utilisez des variables avec les noms de propriétés de vos éléments
entre accolades, ex. {name}, elles seront remplacées dynamiquement par
les valeurs correspondantes./


 /Mise en forme du texte/

 * /*simple astérisque pour italique*/
 * /**double astérisque pour gras**/
 * /# un dièse pour titre 1/
 * /## deux dièses pour titre 2/
 * /### trois dièses pour titre 3/
 * /Lien simple : [[https://exemple.fr]]/
 * /Lien avec texte : [[http://exemple.fr|texte du lien]]/
 * /Image : {{http://image.url.com}}/
 * /Image avec largeur (en pixels) : {{http://image.url.com|largeur}}/
 * /Iframe : {{{http://iframe.url.com}}}/
 * /Iframe avec hauteur (en pixels): {{{http://iframe.url.com|hauteur}}}/
 * /Iframe avec hauteur et largeur (en px) :
   {{{http://iframe.url.com|height*width}}}/
 * /--- pour un séparateur horizontal/

L'intérêt c'est que n'importe qui (les gens de cette liste) peut
vérifier si les horaires que tu as créé sont les horaires actuels tout
en voyant les horaires que tu as utilisé. Sans avoir à installer quoi
que ce soit. C'est toi (et avant Yohan qui a fait ce sympathique
logiciel) qui avez fait le boulot.

Ça multiplie le nombre d'yeux possibles pour une vérification.

C'est une possibilité


Hmm, je veux mettre à jour les horaires, pas supprimer des bureaux de poste,
ça semble dangereux et hors périmètre :-)
Je pense que la création et la suppression seraient plutôt à faire à partir
d'une autre source de données, la liste des bureaux de poste

Re: [OSM-talk-fr] AssociatedStreet Was: Rendu BANO

2020-11-11 Per discussione osm . sanspourriel

Clairement l'associatedStreet est un concept plus propre et facilitant
la gestion des voiries multilingues.

Et donc à privilégier ÀMHA.

Corriger une traduction 10 fois parce que la rue a été découpée, sans
façons.

Les Allemands ont renoncé parce qu'elles étaient mal maintenues en
Allemagne et qu'ils ont eu une politique de passage vers l'autre
système. C'est une version à un coup qui ne permet pas de revenir
facilement au concept d'associatedStreet.

Jean-Yvon

Le 11/11/2020 à 14:43, Jacques Lavignotte - jacq...@lavignotte.org a écrit :

Du coup, pour moi revient à la surface le sujet :

Doit-on / Peut-on systématiser la relation type=associatedStreet

Je sais que nos voisins n'aiment pas beaucoup...

Avons-nous (OSMFr) une politique privilégiée ?

Merci, Jacques




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


Re: [OSM-talk-fr] Import des horaires des bureaux de poste

2020-11-11 Per discussione osm . sanspourriel

Bonjour David et les autres,

Le 11/11/2020 à 15:57, David Faure via Talk-fr -
talk-fr@openstreetmap.org a écrit :

Je pense qu'elles sont bien plus précises que tu ne le penses, et pour info
elles sont mises à jour*tous les jours*  automatiquement.


Il y a deux points importants :
- tous les jours
- automatiquement.

Pendant le confinement saison 1, l'enseigne U remontait les horaires :
- tous les jours
- automatiquement.

Et à côté de chez moi ils étaient donc faux :
- tous les jours
- automatiquement.

On a déjà eu des soucis avec les données de La Poste.
J'avais ainsi repéré une boîte-aux-lettres dont la précision de la
position était selon eux maximale (au numéro).

En fait l'adresse ne comportait que le quartier et la position était à
plus d'un km de la position réelle.

Il est possible que ce fichier soit de grande qualité comme de
piètre qualité.

Je te propose de jouer pour ref:FR:LaPoste

10115A. Pas d'horaires actuellement, là encore il y a eu les horaires
covid mais je dois avoir une photo des horaires d'avant - et les connais
à peu près. C'était du style demi-tordu sans doute à cause d'un temps
partiel modifié.

Jean-Yvon




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


[Talk-gb-westmidlands] Thimblemill Brook, Warley

2020-11-11 Per discussione Andy Mabbett
I'm trying to make sense of the stream or sreams listed below.

This one:

 https://www.openstreetmap.org/way/171647724

is labelled Thimblemill Brook, and runs westwards to the River Tame;
but a few yards away, this one:

https://www.openstreetmap.org/way/171553553

is unnamed, but joins:

https://www.openstreetmap.org/way/171553560

which is also named "Thimblemill Brook" and runs eastwards to:

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

where it disappears. Why? It then flows out of Thimblemill Pool as:

   https://www.openstreetmap.org/way/171553562

before disappearing abruptly. Where does it go?

Do we really have two thimblemill Brooks, rising a few yards apart and
running in opposite directions?

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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


Re: [OSM-talk-fr] Import des horaires des bureaux de poste

2020-11-11 Per discussione Yannick


Le 11/11/2020 à 20:00, David Faure via Talk-fr a écrit :

>
> Tu as moyen de vérifier les horaires réels ?
>

Bonsoir,

Un seul moyen fiable le terrain

Amitiés

--
Yannick VOYEAUD
Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
(Camille JOUFFRAY 1841-1924, maire de Vienne)
http://www.voyeaud.org
Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
Journées du Logiciel Libre: http://jdll.org
Généalogie en liberté avec Ancestris https://www.ancestris.org


OpenPGP_0x235AFD4F087CE6E6.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-it] R: Lavori stratali/strade chiuse

2020-11-11 Per discussione Andreas Lattmann
Scusami, quando calcoli un percorso puoi cliccare sulla strada che vuoi
"evitare" e poi clicchi su evita strada. Funziona anche senza calcolare il
percorso.
Nella mappa risulterà il simbolo dei lavori in corso.
Ciao
Andreas

Il mer 11 nov 2020, 09:50 Martin Koppenhoefer  ha
scritto:

>
>
> sent from a phone
>
> > On 11. Nov 2020, at 09:34, canfe  wrote:
> >
> > Su WAZE le strade chiuse sono ben evidenziate con un tratteggio bianco e
> rosso.
> > Ovviamente ci vuole qualcuno che le inserisca comprese le date di
> chiusura.
> > Se contattate il vostro Area Manager di WAZE e gli fornite prova delle
> chiusure son sicuro che le inserirà.
> > Così servirà a tutta la comunità dei viaggiatori.
>
>
> su openroute service si possono marcare aree da evitare, e il routing poi
> gira attorno (lo so, non è la stessa cosa)
>
> Ciao Martin
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-at] Gefahr durch Internet-Bergrouten

2020-11-11 Per discussione Richard
On Tue, Nov 10, 2020 at 08:21:47PM +0100, Robert Grübler wrote:

> Ich denke, man sollte zwischen Wanderkarten – richten sich ausdrücklich an 
> Wanderer -  und Nichtwander-Karten unterscheiden. 
> Die *Nichtwander-Karten* sollten die alpine Pfade (>T2) nicht oder nur sehr 
> unauffällig rendern. Toursprung 
> https://maptoolkit.net/#/@11.78448,47.44822,15,0,0,terrain/themes  macht das 
> mMn recht gut. Andernfalls sie darauf ansprechen, so wie du es vorhast.

das Problem sind die Nichtwanderkarten die niemals vorhatten sac_scale, 
via_ferrata_scale,
uiaa uvm auszuwerten,wie soll das jemals funktionieren.
Im Carto Tracker vergammelt das entsprechende Ticket seit einem halben Jahrzent 
und 
vermutlich dient Carto als Vorbild für viele andere Projekte.

Solange es Spezialisten gibt die schwierige Kletterrouten und Ferratas als 
highway=path einzeichnen sollten "Nichtwanderkarten" eigentlich überhaupt keine
path auswerten um auf der sicheren Seite zu sein.

Richard


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


Re: [OSM-talk-fr] Import des horaires des bureaux de poste

2020-11-11 Per discussione David Faure via Talk-fr
On mercredi 11 novembre 2020 18:32:53 CET Brice wrote:
> Le 11/11/2020 à 15:57, David Faure via Talk-fr a écrit :
> > Dis moi où tu habites et j'aurai des infos super précises sur les horaires
> > d'ouverture de ton bureau de Poste :)
> 
> OK pour un mini-mini échantillonnage, je vérifierai :
> https://www.openstreetmap.org/node/326243219
> https://www.openstreetmap.org/node/6140793094
> https://www.openstreetmap.org/node/249560489
> mais horaires très simples, on est pas vraiment dans le rural;-)

Voilà ce que sort mon script, sur la base des données datanova :

14181A|PARIS BELLEVILLE BP|Mo-Fr 09:00-19:00; Sa 09:00-13:00; Su,PH off
14266A|PARIS SAMBRE ET MEUSE|Mo-Fr 09:00-20:00; Sa 09:00-13:00; Su,PH off
14298A|PARIS PERNETY PLAISANCE|Mo-Fr 08:30-19:30; Sa 09:00-13:00; Su,PH off

Apparemment c'est donc stable sur les 3 prochains mois, pas de cas particulier.
Ce qui est intéressant c'est que OSM n'a pas les mêmes horaires :

Paris Belleville : Mo-Fr 10:00-16:00
(marqué comme opening_hours:covid19, je ne vois pas de tag opening_hours tout 
court)

Paris Sambre et Meuse : Mo-Fr 09:00-20:00; Sa 09:00-13:00 --> sur celui là on 
est d'accord.

Paris Pernety / Plaisance : Mo-Fr 08:00-20:00; Sa 09:00-13:00  --> différent

Tu as moyen de vérifier les horaires réels ?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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


Re: [OSM-talk-fr] Import des horaires des bureaux de poste

2020-11-11 Per discussione Jérôme Amagat
Le mer. 11 nov. 2020 à 16:44, Georges Dutreix via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Le 10/11/2020 à 17:55, Jérôme Amagat a écrit :
> >
> > Si tu attends que tous les bureaux de poste soient present dans osm
> > pour faire ton ajout des heures d'ouverture, tu risque d'attendre
> > longtemps, on voit ici  :
> > http://osmose.openstreetmap.fr/fr/errors/graph.png?item=8020 que les
> > non intégrés ne diminue plus depuis plusieurs mois...
>
> Bonjour,
>
> J'essaie de comprendre l'intégration des bureaux de postes suite aux
> messages échangés. Pas fastoche !
>
> De nombreux bureaux de postes "non intégrés" (dans osmose) sont en fait
> des changements de référence, mais le POI existe.
> exemple :
>
> https://osmose.openstreetmap.fr/fr/error/caf7b4e5-028a-3d50-d98e-4e097d52adb1
> existe bien sur la carte mais avec ref=08912A :
> https://www.openstreetmap.org/#map=19/47.06170/-0.89610
>
> Question 1 : est-ce qu'un item Osmose est capable de détecter (et
> proposer) ces éventuels changements de références ?
>
> J'ai vu qu'Osmose détecte les codes faux et les classe avec les bureaux de
poste sans ref dans "Bureau de poste sans attribut “ref:FR:LaPoste” ou
incorrect"
http://osmose.openstreetmap.fr/fr/map/#item=7050
Par contre j'ai trouvé au moins 2 détections de mauvais code d'après osmose
mais qui apparaissent bien dans le fichier source donc actif
Les bureau de poste d'Ambérieu en bugey (
http://osmose.openstreetmap.fr/fr/error/4692dcb9-d1e0-d41e-f3d8-d1d8d15f4516)
et d'Anglefort (
http://osmose.openstreetmap.fr/fr/error/0a7230a2-d3f6-7908-b180-3245bca4248a)
que l'on voit ici :
http://osmose.openstreetmap.fr/fr/map/#item=7050=11=45.9115=5.6867=1%2C2%2C3==
Il sont bien present dans la source :
https://datanova.legroupe.laposte.fr/explore/dataset/laposte_poincont/table/?disjunctive.code_postal_insee=identifiant_a


> Question 2 : D'autres bureaux de poste (je découvre) sont des
> "post_partner" qui sont dans des magasins, des bureaux tabacs, des
> mairies, etc. :
> exemple :
>
> https://osmose.openstreetmap.fr/fr/error/b610b6d3-6e55-abdc-18c3-e21576754fd3
> dont l'adresse est "Bar tabac Le Crocodile"
>
> Qu'en fait-on de ces derniers, on ajoute un POI post_office dans le
> bureau de tabac ? Ou on ajoute une étiquette post_partner au bureau de
> tabac ?
> En effet ce dernier peut sans doute vendre des boissons, du tabac, du
> service postal voire aussi réparer des clés ? Est-ce logique d'ajouter
> un POI pour le "service postal" qui physiquement est au même endroit que
> la vente de tabac ?
>
> Merci.
> Georges
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Import des horaires des bureaux de poste

2020-11-11 Per discussione Brice

Le 11/11/2020 à 15:57, David Faure via Talk-fr a écrit :

Dis moi où tu habites et j'aurai des infos super précises sur les horaires
d'ouverture de ton bureau de Poste :)


OK pour un mini-mini échantillonnage, je vérifierai :
https://www.openstreetmap.org/node/326243219
https://www.openstreetmap.org/node/6140793094
https://www.openstreetmap.org/node/249560489
mais horaires très simples, on est pas vraiment dans le rural;-)


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


[Talk-pe] Microsoft Open Maps en Perú

2020-11-11 Per discussione Kana Lee (Insight Global Inc) via Talk-pe
Hola a todos,

El equipo de Microsoft Open Maps  
comenzará a editar en los datos de OSM en Perú, enfocado en la red de 
carreteras y también investigará otras características del mapa. Investigaremos 
características que incluyen los nombres de las carreteras, la geometría, las 
señales de destino, las restricciones de giro y usaremos imágenes a nivel de 
calle e imágenes aéreas disponibles para agregar cuando sea posible. Se 
publican más detalles en nuestro Github, que se encuentra aquí 
. Nuestro equipo no utilizará 
importaciones automáticas o ediciones de robots para mejorar el mapa. 
Agradeceríamos cualquier comentario o inquietud de la comunidad cartográfica en 
Perú. Utilice openmaps(at)microsoft.com para ponerse en contacto y esperamos 
tener noticias suyas.

Microsoft Open Maps team  will begin 
work on the OSM data in Peru, focusing on the road network, and will 
investigate other map features as well. Road names, geometry, destination 
signs, turn restrictions, are all part of the effort, and we will use available 
street level imagery and aerial imagery to add where possible. Further details 
are posted on our Github, located here 
. Our team will not use 
automatic imports or robot edits to improve the map. We would be grateful for 
any comments or concerns from the mapping community in Peru. Please use 
openmaps(at)microsoft.com to get in touch, and look forward to hearing from you.

Gracias,
Kana
Microsoft Open Maps

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


Re: [talk-cz] ququruzka a "test bulk edit"

2020-11-11 Per discussione Miroslav Suchy
Dne 11. 11. 20 v 17:59 Jan Martinec napsal(a):
> Napsal jsem mu pod (celkem 3) CS dotaz, ale každý z nich je revertní 
> materiál: bulk, bez manuální kontroly, a bez OTG
> (jinak edituje jen na Ukrajině). Podezírám spíš splašený skript...
> 
> https://www.openstreetmap.org/changeset/93928568

Mno, zkontroloval jsem 3 náhodné entity z tohoto changesetu a vypadá to jako 
správná editace. Takže bych neřekl splašený
skript, ale spíše "docela dobrý skript".

IMO to bude někdo z Maps.me. Když koukneš třeba na

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

Tak opravoval

https://www.openstreetmap.org/changeset/75007833#map=19/50.03275/14.51845

Což vznike (vznikalo?) v Maps.me tak, že když je někde

name=foo

a já to poedituji v Maps.me na "bar", tak to změní
  name:cs=bar
ale **nechá**
  name=foo

Předpokládám, že idea za tím byla že angličan upraví "Karlův most" na "Charles 
bridge". Ale bohužel to nefunguje na
hospody a shopy, které se mění každé dva roky. :(

#my2cents

Mirek


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


[talk-cz] ququruzka a "test bulk edit"

2020-11-11 Per discussione Jan Martinec

Ahoj,

FYI: procházel jsem OsmCha a zahlédl uživatele ququruzka, jak 
(automaticky?) kopíruje name:cs do name. Zatím jsem ho požádal o 
vysvětlení - ty tagy, kde natrefil na rozdílný, jsou sice blbě (např. 
překlepy), ale tohle je non-oprava: name:cs není pokaždý ta správná 
verze, ani ta aktuální.


Napsal jsem mu pod (celkem 3) CS dotaz, ale každý z nich je revertní 
materiál: bulk, bez manuální kontroly, a bez OTG (jinak edituje jen na 
Ukrajině). Podezírám spíš splašený skript...


https://www.openstreetmap.org/changeset/93928568
https://www.openstreetmap.org/changeset/93928193
https://www.openstreetmap.org/changeset/93927683

Zdar,
Honza Piškvor Martinec

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


Re: [OSM-talk-fr] Import des horaires des bureaux de poste

2020-11-11 Per discussione Yves P.
> De nombreux bureaux de postes "non intégrés" (dans osmose) sont en fait des 
> changements de référence, mais le POI existe.
> exemple : 
> https://osmose.openstreetmap.fr/fr/error/caf7b4e5-028a-3d50-d98e-4e097d52adb1 
> existe bien sur la carte mais avec ref=08912A : 
> https://www.openstreetmap.org/#map=19/47.06170/-0.89610
> 
> Question 1 : est-ce qu'un item Osmose est capable de détecter (et proposer) 
> ces éventuels changements de références ?
Apparement non vu ton message.

L'analyseur peut-être amélioré :)
J'imagine que l'ancienne référence ne se trouve plus dans le fichier Datanova. 
Osmose pourrait donc en déduire qu'il ne s'agit "que" d'une mise à jour.

> Question 2 : D'autres bureaux de poste (je découvre) sont des "post_partner" 
> qui sont dans des magasins, des bureaux tabacs, des mairies, etc. :

C'est aussi le cas : 
https://www.ouest-france.fr/pays-de-la-loire/cholet-49300/cholet-apres-deux-ans-le-tabac-de-mocrat-rouvre-5579892


> Qu'en fait-on de ces derniers, on ajoute un POI post_office dans le bureau de 
> tabac ?
Tu peux mettre 2 POI superposés avec le même nom.
L'un bureau de tabac, journaux…
L'autre bureau de poste

Fusionner les 2 peut fonctionner mais ne sera pas forcément lisible et/ou 
maintenance.

> Ou on ajoute une étiquette post_partner au bureau de tabac ?

Avec uniquement ce tag le bureau de poste ne pourra pas être trouvé par 
Nominatim.


> En effet ce dernier peut sans doute vendre des boissons, du tabac, du service 
> postal voire aussi réparer des clés ?

> Est-ce logique d'ajouter un POI pour le "service postal" qui physiquement est 
> au même endroit que la vente de tabac ?

Oui car quelqu'un peut vouloir chercher le bureau de poste le plus près ;)

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


Re: [OSM-talk-fr] Rendu BANO (v2) de retour !

2020-11-11 Per discussione Vincent de Château-Thierry

Le 11/11/2020 à 16:31, deuzeffe a écrit :

D'ici ce soir, je te fais un ticket circonstancié :)


vincent qui met ça sur sa tout doux


Juste après l'intégration du nouveau Fantoir d'automne confiné ? ;)

'xactement :)

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


Re: [talk-cz] Připojení el. vedení na trafostanice

2020-11-11 Per discussione Tomáš Oslzlý
Díky za odpověď,
nedalo mi to, a kouknul jsem do zahraničí (Rakousko, Francie, Itálie apod.)
a všude mají právě v názvu uvedeny rozvodny, které vedení/kabel propojuje.
Číslo vedení je uvedeno jako ref, proto mi nedává moc smysl uvádět ho
dvakrát jak do reference, tak do názvu.

Pokud tedy vedení mají ještě jiný název, který je veřejně nedostupný, asi
nemá smysl ho uvádět a řešit ho.

Vím, že by se OSM neměli editovat dle obrazu svému ale dle skutečné reality
bez přikrášlení, ale tady mi skutečně přijde lepší, když jsou v názvu
vedení uvedeny rozvodny, aspoň je hned na pohled jasné, jaké rozvodny
vedení spojuje, stejně tak jako je to v zahraničí.

Co si o tom myslíte?



st 11. 11. 2020 v 10:16 odesílatel Václav Kroupar  napsal:

> Optal jsem se kamaráda z ČEZu:
> "Ahoj Vašku,
> všechna vedení vvn a vn mají čísla.
> U vedení vvn si s čísly vystačíme. To co je napsané dole jsou názvy
> transformoven mezi kterým vedení stojí. Myslím, že se na internetu dají
> najít mapy s čísly vedení 110 kV a výše.
> Vedení vn mají navíc i jména, která máme historicky daná a často nedávají
> laikovi smysl. Netuším, jestli jsou někde čísla a názvy oficiálně uvedeny."
>
> Takže toto nejsou oficiální názvy vedení.
> Mějte se Vašek
>
> -- Původní e-mail --
> Od: Tomáš Oslzlý 
> Komu: OpenStreetMap Czech Republic 
> Datum: 11. 11. 2020 1:28:15
> Předmět: Re: [talk-cz] Připojení el. vedení na trafostanice
>
> Je vhodné pojmenovávat 220/400 kV vedení, například "Prosenice –
> Sokolnice" ? Všiml jsem si, že takhle pár vedení je již pojmenovaných,
> nevím zda je to správně a zda v tom pokračovat, když vidím že někde chybí
> název.
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz


Re: [OSM-talk-fr] Rendu BANO (v2) de retour !

2020-11-11 Per discussione Rpnpif via Talk-fr

Merci à vous tous !

--
Rpnpif

Le 11/11/2020 à 16:34, Christian Quest a écrit :
Il y a sûrement des ajustements à faire, liés à la nouvelle 
organisation des données et aux nouvelles sources.


Beaucoup de rouge nouveau semble concerner des points adresse liés à 
des noms de lieux-dits qu'il ne me semble pas avoir vu avant, ou au 
moins pas aussi souvent.



Là, la base PG est en cours d'upgrade, donc un peu de patience pour 
que ça revienne ;)



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


Re: [OSM-talk-fr] L'OD ça bouge par ici

2020-11-11 Per discussione Jacques Lavignotte



Le 11/11/2020 à 16:39, Christian Quest a écrit :

Le 11/11/2020 à 16:09, Jacques Lavignotte a écrit :



https://twitter.com/Grand_Poitiers/status/1326193511591530498


Un petit effet d'annonce... ce portail et ses jeux de données existe 
depuis bien longtemps.


Certains sont assez récents. Mais l'ensemble était peu connu du 
grand-public et des politiques.


Toutes les Comcom' n'en font pas autant.

Encore bravo.

J.

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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


Re: [Talk-GB] Turn Restrictions at roundabouts

2020-11-11 Per discussione Mateusz Konieczny via Talk-GB



Nov 11, 2020, 16:04 by talk-gb@openstreetmap.org:

> >After a quick look at his edits locally he has also been removing ref
> >tags from roundabouts which seems an odd thing to do.
>
> This seems perfectly reasonable to me - the roundabout is a junction of 
> various roads and I do not consider it to be part of a referenced highway.
>
> I note that the wiki indicates that the ref should be added to roundabouts to 
> allow fluid routing, but this has relatively recently been added (April 2019) 
> and I do not agree. It smacks of tagging for the renderer (in this case a 
> routing engine). It seems bizarre to specify that for naming it should not 
> use the name of a road it connects, but it should use the ref of a road that 
> connects!
>
I reworded this recommendation in
https://wiki.openstreetmap.org/w/index.php?title=Tag:junction%3Droundabout=2059754=1972469
to 
"{{Tag|ref}} and {{Tag|int_ref}} tags from those ways should be added to that 
roundabout if roundabout is also part of that routes."
(in Poland roundabout would be part of route with assigned ref, in UK situation 
may be different,
I removed part that based in on tagging for router)
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [OSM-talk-fr] Import des horaires des bureaux de poste

2020-11-11 Per discussione Georges Dutreix via Talk-fr

Le 10/11/2020 à 17:55, Jérôme Amagat a écrit :


Si tu attends que tous les bureaux de poste soient present dans osm 
pour faire ton ajout des heures d'ouverture, tu risque d'attendre 
longtemps, on voit ici  : 
http://osmose.openstreetmap.fr/fr/errors/graph.png?item=8020 que les 
non intégrés ne diminue plus depuis plusieurs mois...


Bonjour,

J'essaie de comprendre l'intégration des bureaux de postes suite aux 
messages échangés. Pas fastoche !


De nombreux bureaux de postes "non intégrés" (dans osmose) sont en fait 
des changements de référence, mais le POI existe.
exemple : 
https://osmose.openstreetmap.fr/fr/error/caf7b4e5-028a-3d50-d98e-4e097d52adb1 
existe bien sur la carte mais avec ref=08912A : 
https://www.openstreetmap.org/#map=19/47.06170/-0.89610


Question 1 : est-ce qu'un item Osmose est capable de détecter (et 
proposer) ces éventuels changements de références ?


Question 2 : D'autres bureaux de poste (je découvre) sont des 
"post_partner" qui sont dans des magasins, des bureaux tabacs, des 
mairies, etc. :
exemple : 
https://osmose.openstreetmap.fr/fr/error/b610b6d3-6e55-abdc-18c3-e21576754fd3

dont l'adresse est "Bar tabac Le Crocodile"

Qu'en fait-on de ces derniers, on ajoute un POI post_office dans le 
bureau de tabac ? Ou on ajoute une étiquette post_partner au bureau de 
tabac ?
En effet ce dernier peut sans doute vendre des boissons, du tabac, du 
service postal voire aussi réparer des clés ? Est-ce logique d'ajouter 
un POI pour le "service postal" qui physiquement est au même endroit que 
la vente de tabac ?


Merci.
Georges

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


Re: [OSM-talk-fr] L'OD ça bouge par ici

2020-11-11 Per discussione Christian Quest

Le 11/11/2020 à 16:09, Jacques Lavignotte a écrit :



https://twitter.com/Grand_Poitiers/status/1326193511591530498


Un petit effet d'annonce... ce portail et ses jeux de données existe 
depuis bien longtemps.



--
Christian Quest - OpenStreetMap France


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


Re: [OSM-talk-fr] Import des horaires des bureaux de poste

2020-11-11 Per discussione Christian Quest

Le 11/11/2020 à 15:57, David Faure via Talk-fr a écrit :

Merci pour ton retour, c'est utile qu'on en discute.
Est-ce que tu as regardé les données datanova ?
Je pense qu'elles sont bien plus précises que tu ne le penses, et pour info
elles sont mises à jour *tous les jours* automatiquement.

Les données datanova nous disent par exemple que le bureau de Poste de
DENEUILLE LES MINES sera ouvert le mardi de 09:00 à 12:00
aux dates suivantes :
   2020-11-03 2020-11-10 2020-11-17 2020-11-24
et de 08:15 à 12:15 aux dates suivantes :
   2020-10-27 2020-12-01 2020-12-08 2020-12-15 2020-12-22 2020-12-29 2021-01-05
2021-01-12 2021-01-19 2021-01-26
... ce qui veut dire qu'il y a un changement temporaire en Novembre.
Quelle est la probabilité que quelqu'un aille noter ce changement temporaire
dans OSM manuellement ? Et surtout, quelle est la probabilité que cette donnée
soit fausse, et que les horaires affichés sur la porte soient plus corrects ?

Dans le même style, datanova contient les changements horaires qui auront lieu
à partir du premier janvier 2021, toujours avec une précision jour par jour.
J'ai aussi détecté bureaux qui sont ouverts un samedi sur deux, ou qui sont
fermés le dernier samedi de chaque mois. Et d'autres avec des cas encore plus
tordus de fermetures exceptionnelles ou d'alternance entre deux horaires sans
récurrence détectable. Tout ça pour dire que c'est super précis.

En cas de désaccord entre le opening_hours existant dans OSM et la donnée
datanova.laposte.fr, qu'est-ce qui est le plus probable ? Que datanova se
trompe ou que la donnée OSM ne soit pas à jour ? Au vu de la précision des
données publiées, je dirais que c'est le second cas, à coup sûr.

Dis moi où tu habites et j'aurai des infos super précises sur les horaires
d'ouverture de ton bureau de Poste :)



Et si vous voulez voir à quelle vitesse ces données opendata changent, 
il y a les archives d'opendatArchives ;)


http://files.opendatarchives.fr/datanova.laposte.fr/archives/laposte_ouvertur/

On est pas loin d'une évolution quotidienne.


--
Christian Quest - OpenStreetMap France


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


Re: [OSM-talk-fr] Rendu BANO (v2) de retour !

2020-11-11 Per discussione Christian Quest
Il y a sûrement des ajustements à faire, liés à la nouvelle organisation 
des données et aux nouvelles sources.


Beaucoup de rouge nouveau semble concerner des points adresse liés à des 
noms de lieux-dits qu'il ne me semble pas avoir vu avant, ou au moins 
pas aussi souvent.



Là, la base PG est en cours d'upgrade, donc un peu de patience pour que 
ça revienne ;)



Le 11/11/2020 à 16:07, Vincent de Château-Thierry a écrit :


Bonjour,

Le 11 novembre 2020 15:35:23 GMT+01:00, deuzeffe  a 
écrit :


Échantillon sur demande ;p

Volontiers ! C'est toujours plus pratique pour inspecter :)

Merci

vincent qui met ça sur sa tout doux

___
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] Rendu BANO (v2) de retour !

2020-11-11 Per discussione deuzeffe

Le 11/11/2020 à 16:07, Vincent de Château-Thierry a écrit :

Bonjour,


Pareil


Le 11 novembre 2020 15:35:23 GMT+01:00, deuzeffe  a 
écrit :


Échantillon sur demande ;p


Volontiers ! C'est toujours plus pratique pour inspecter :)

Merci


D'ici ce soir, je te fais un ticket circonstancié :)


vincent qui met ça sur sa tout doux


Juste après l'intégration du nouveau Fantoir d'automne confiné ? ;)
--
deuzeffe


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


[OSM-talk-fr] L'OD ça bouge par ici

2020-11-11 Per discussione Jacques Lavignotte



https://twitter.com/Grand_Poitiers/status/1326193511591530498


--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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


Re: [OSM-talk-fr] Rendu BANO (v2) de retour !

2020-11-11 Per discussione Vincent de Château-Thierry


Bonjour,

Le 11 novembre 2020 15:35:23 GMT+01:00, deuzeffe  a 
écrit :

>Échantillon sur demande ;p

Volontiers ! C'est toujours plus pratique pour inspecter :)

Merci

vincent qui met ça sur sa tout doux

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


Re: [Talk-GB] Turn Restrictions at roundabouts

2020-11-11 Per discussione Mike Baggaley via Talk-GB
>After a quick look at his edits locally he has also been removing ref
>tags from roundabouts which seems an odd thing to do.

This seems perfectly reasonable to me - the roundabout is a junction of various 
roads and I do not consider it to be part of a referenced highway.

I note that the wiki indicates that the ref should be added to roundabouts to 
allow fluid routing, but this has relatively recently been added (April 2019) 
and I do not agree. It smacks of tagging for the renderer (in this case a 
routing engine). It seems bizarre to specify that for naming it should not use 
the name of a road it connects, but it should use the ref of a road that 
connects!

Regards,
Mike


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


Re: [OSM-talk-fr] Import des horaires des bureaux de poste

2020-11-11 Per discussione David Faure via Talk-fr
On mercredi 11 novembre 2020 13:31:02 CET Brice wrote:
> > ensuite pour les autre questions :
> (...)
> 
> > - tes données ont beaucoup plus de chance d'être à jour que celles
> > présentes dans osm donc moi je dirais qu'il faut remplacer l'existant
> > qui peut être là depuis des années.
> 
> Pas trop d'accord, il serait dommage de partir d'un à priori qu'un
> organisme central connaisse parfaitement les horaires de toutes ses
> implantations, quand se comptent en milliers : pas sûr du tout.
> Je suis pour ne compléter que les bureaux de poste avec horaires non
> encore renseignés et laisser tels quels les horaires existants pour
> qu'ils soient corrigés, si nécessaire, au fur et à mesure.

Merci pour ton retour, c'est utile qu'on en discute.
Est-ce que tu as regardé les données datanova ?
Je pense qu'elles sont bien plus précises que tu ne le penses, et pour info 
elles sont mises à jour *tous les jours* automatiquement.

Les données datanova nous disent par exemple que le bureau de Poste de 
DENEUILLE LES MINES sera ouvert le mardi de 09:00 à 12:00 
aux dates suivantes :
  2020-11-03 2020-11-10 2020-11-17 2020-11-24
et de 08:15 à 12:15 aux dates suivantes :
  2020-10-27 2020-12-01 2020-12-08 2020-12-15 2020-12-22 2020-12-29 2021-01-05 
2021-01-12 2021-01-19 2021-01-26
... ce qui veut dire qu'il y a un changement temporaire en Novembre.
Quelle est la probabilité que quelqu'un aille noter ce changement temporaire 
dans OSM manuellement ? Et surtout, quelle est la probabilité que cette donnée 
soit fausse, et que les horaires affichés sur la porte soient plus corrects ?

Dans le même style, datanova contient les changements horaires qui auront lieu 
à partir du premier janvier 2021, toujours avec une précision jour par jour.
J'ai aussi détecté bureaux qui sont ouverts un samedi sur deux, ou qui sont 
fermés le dernier samedi de chaque mois. Et d'autres avec des cas encore plus 
tordus de fermetures exceptionnelles ou d'alternance entre deux horaires sans 
récurrence détectable. Tout ça pour dire que c'est super précis.

En cas de désaccord entre le opening_hours existant dans OSM et la donnée 
datanova.laposte.fr, qu'est-ce qui est le plus probable ? Que datanova se 
trompe ou que la donnée OSM ne soit pas à jour ? Au vu de la précision des 
données publiées, je dirais que c'est le second cas, à coup sûr.

Dis moi où tu habites et j'aurai des infos super précises sur les horaires 
d'ouverture de ton bureau de Poste :)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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


Re: [OSM-talk-fr] AssociatedStreet Was: Rendu BANO (v2) de retour !

2020-11-11 Per discussione Christian Rogel


> Le 11 nov. 2020 à 14:59, Jacques Lavignotte  a écrit :
> 
> Du coup, pour moi revient à la surface le sujet :
> 
> Doit-on / Peut-on systématiser la relation type=associatedStreet
> 
> Je sais que nos voisins n'aiment pas beaucoup...
> 
> Avons-nous (OSMFr) une politique privilégiée ?

La question est mal posée, puisqu’une association, même reconnue comme 
importante, ne peut, en aucun cas, agir comme si elle était la communauté des 
mappeurs en France. Elle peut faire des recommandations qui seront suivies ou 
non.
Je ne peux que citer ma pratique, une parmi d’autres : comme je ne crée pas les 
adresses dans des relations, il a pu m’arriver de compléter une ou deux rues 
qui avaient été commencées en associated. Mais, j’ai pu aussi 1 ou 2 fois 
intégrer des numéros à une relation existante.
Il n’y a pas que les pratiques allemandes qui expliquent que les relations ne 
soient pas employées, il y a aussi iD qui automatise très bien le schéma 
traditionnel.

Christian R.

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


Re: [OSM-talk-fr] Rendu BANO (v2) de retour !

2020-11-11 Per discussione deuzeffe

Le 11/11/2020 à 12:05, Christian Quest a écrit :

Bonjour,

J'ai mergé la PR de Vincent et remis en route le rendu BANO maintenant 
en v2.


Mer-ci (à vous deux) !


Pas de changement sur le rendu lui même en principe...


Mmmhh, je viens de tester dans ma zone de confort. Il y a des points 
rouges qui ne correspondraient pas à la légende donnée ici 
https://wiki.openstreetmap.org/wiki/FR:France/WikiProject_Base_Adresses_Nationale_Ouverte_(BANO)#L.C3.A9gende


En regardant de plus près, mais rapidement, il reste des 5000 et des 
6000 (marqués en rouge, donc) : à virer ? Et des points adresses proches 
d'une highway bien présente et correctement nommée (d'après ce que je 
vois) suivant le cadastre/Fantoir.
De plus, les numéros en gris ne correspondent plus à la légende, il me 
semble ?


Échantillon sur demande ;p
--
deuzeffe

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


Re: [OSM-talk-fr] Import des horaires des bureaux de poste

2020-11-11 Per discussione David Faure via Talk-fr
On lundi 9 novembre 2020 19:10:26 CET Jérôme Amagat wrote:
> Ce qu'il est possible de faire, il y a surement d'autre façon de faire,
> mais je n'ai essayé que ça :
> - obtenir les bureaux de poste avec l'overpass api via une requête de ce
> type : https://overpass-turbo.eu/s/ZUw (pour josm il faut du xml et out
> meta)
> -  faire un script qui va lire le xml, détecter les tags ref:FR:LaPoste=*
> et ajouter les opening_hours=* au bon élément, il faut pour que josm sache
> que l'élément a été modifié et qu'il faut envoyer l'élément au serveur,
> ajouter un action='modify' au bon endroit pour chaque élément modifié.
> - une fois modifié, ouvrir avec josm ce fichier enregistré en .osm
> - envoyer les modification

Merci beaucoup pour ces instructions.

Je viens de les utiliser pour soumettre mon premier changeset avec JOSM :
https://www.openstreetmap.org/changeset/93931921
Est-ce que tout semble correct ?
En particulier la suppression de la source de l'objet (déprécié), l'ajout des 
horaires bien sûr, le created_by et la "source" du changeset, et le 
commentaire avec le lien wiki.

Si ça semble bon je vais pouvoir industrialiser :-)

PS: J'ai utilisé https://github.com/mvexel/overpass-api-python-wrapper
et 5 lignes de python pour faire la requête overpass en ligne de commande, 
c'est plus pratique.
Mes scripts sont maintenant en ligne sur 
https://github.com/dfaure/DataNovaImportScripts

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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


[OSM-talk-fr] AssociatedStreet Was: Rendu BANO (v2) de retour !

2020-11-11 Per discussione Jacques Lavignotte

Du coup, pour moi revient à la surface le sujet :

Doit-on / Peut-on systématiser la relation type=associatedStreet

Je sais que nos voisins n'aiment pas beaucoup...

Avons-nous (OSMFr) une politique privilégiée ?

Merci, Jacques

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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


Re: [OSM-talk-fr] Import des horaires des bureaux de poste

2020-11-11 Per discussione Brice

ensuite pour les autre questions :

(...)
- tes données ont beaucoup plus de chance d'être à jour que celles 
présentes dans osm donc moi je dirais qu'il faut remplacer l'existant 
qui peut être là depuis des années.


Pas trop d'accord, il serait dommage de partir d'un à priori qu'un 
organisme central connaisse parfaitement les horaires de toutes ses 
implantations, quand se comptent en milliers : pas sûr du tout.
Je suis pour ne compléter que les bureaux de poste avec horaires non 
encore renseignés et laisser tels quels les horaires existants pour 
qu'ils soient corrigés, si nécessaire, au fur et à mesure.


Britzz

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


Re: [OSM-talk-fr] Rendu BANO (v2) de retour !

2020-11-11 Per discussione Jacques Lavignotte

YES !

Merci tous les acteurs.



Le 11/11/2020 à 12:05, Christian Quest a écrit :
J'ai mergé la PR de Vincent et remis en route le rendu BANO maintenant 
en v2.


Pas de changement sur le rendu lui même en principe...

URL inchangée, donc il n'y a qu'à activer la couche dans JOSM comme avant.



--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

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


Re: [OSM-talk-fr] osm.org Affichage ville selon zoom - Vichy vs Cusset

2020-11-11 Per discussione Christian Quest

Le 11/11/2020 à 10:29, Yves P. a écrit :

Sur osm.org la Ville de Vichy n'est affichée qu'à partir du zoom 11, avant <=10 
c'est la plus petite commune de Cusset qui l'est. Est-ce à cause des données ?

Christian avait bien expliqué le problème : Faire un rendu c'est compliqué, il 
y a des choix à faire.

Dans son rendu .fr il récupère la population (wikidata, INSEE… je ne sais plus) 
pour prioriser les communes plus importantes à un niveau de zoom donné.

Dans "le" rendu .org, soit il ne tient pas compte de la population (tag dans 
les données OSM), soit il le fait mais va pas voir dans une source externe plus complète 
et plus à jour.

Christian corrigera si j'ai dit des bêtises :D



Je complète juste:

- il me semble que le rendu .org ne prend en compte que place=* pour 
prioriser


- à mon grand chagrin, population=* a été retiré sur un grand nombre de 
noeuds place=* de commune, du coup le rendu FR n'arrive plus à toujours 
prioriser


- le rendu FR utilise aussi capital=* pour prioriser les préfectures, 
sous-préfectures...


--
Christian Quest - OpenStreetMap France


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


[OSM-talk-fr] Rendu BANO (v2) de retour !

2020-11-11 Per discussione Christian Quest
J'ai mergé la PR de Vincent et remis en route le rendu BANO maintenant 
en v2.


Pas de changement sur le rendu lui même en principe...

URL inchangée, donc il n'y a qu'à activer la couche dans JOSM comme avant.

--
Christian Quest - OpenStreetMap France


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


Re: [OSM-talk-fr] osm.org Affichage ville selon zoom - Vichy vs Cusset

2020-11-11 Per discussione Yves P.
> Sur le rendu Humanitaire on voit Vichy mais pas Cusset :
>
> https://www.openstreetmap.org/#map=10/46.1332/3.2767=H


C'est un rendu mais au point par un français, ceci explique cela 

Le rendu vectoriel s'en sort bien aussi :
https://projetdumois.fr/projects/2020-09_aed/map#map=7.72/45.967/3.351
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] osm.org Affichage ville selon zoom - Vichy vs Cusset

2020-11-11 Per discussione Arnaud Champollion

Sur le rendu Humanitaire on voit Vichy mais pas Cusset :

https://www.openstreetmap.org/#map=10/46.1332/3.2767=H




Le 11/11/2020 à 08:27, Cyrille37 OSM via Talk-fr a écrit :

Hello

Sur osm.org la Ville de Vichy n'est affichée qu'à partir du zoom 11, 
avant <=10 c'est la plus petite commune de Cusset qui l'est. Est-ce à 
cause des données ?


https://www.openstreetmap.org/#map=10/46.1332/3.4483

Merci de vos lumières
Cyrille37.



___
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] osm.org Affichage ville selon zoom - Vichy vs Cusset

2020-11-11 Per discussione Yves P.
> Sur osm.org la Ville de Vichy n'est affichée qu'à partir du zoom 11, avant 
> <=10 c'est la plus petite commune de Cusset qui l'est. Est-ce à cause des 
> données ?

Christian avait bien expliqué le problème : Faire un rendu c'est compliqué, il 
y a des choix à faire.

Dans son rendu .fr il récupère la population (wikidata, INSEE… je ne sais plus) 
pour prioriser les communes plus importantes à un niveau de zoom donné.

Dans "le" rendu .org, soit il ne tient pas compte de la population (tag dans 
les données OSM), soit il le fait mais va pas voir dans une source externe plus 
complète et plus à jour.

Christian corrigera si j'ai dit des bêtises :D

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


Re: [talk-cz] Připojení el. vedení na trafostanice

2020-11-11 Per discussione Václav Kroupar
Optal jsem se kamaráda z ČEZu:
"Ahoj Vašku,
všechna vedení vvn a vn mají čísla.
U vedení vvn si s čísly vystačíme. To co je napsané dole jsou názvy
transformoven mezi kterým vedení stojí. Myslím, že se na internetu dají
najít mapy s čísly vedení 110 kV a výše.
Vedení vn mají navíc i jména, která máme historicky daná a často nedávají
laikovi smysl. Netuším, jestli jsou někde čísla a názvy oficiálně uvedeny."

Takže toto nejsou oficiální názvy vedení.
Mějte se Vašek

-- Původní e-mail --
Od: Tomáš Oslzlý 
Komu: OpenStreetMap Czech Republic 
Datum: 11. 11. 2020 1:28:15
Předmět: Re: [talk-cz] Připojení el. vedení na trafostanice
"
Je vhodné pojmenovávat 220/400 kV vedení, například "Prosenice – Sokolnice"
? Všiml jsem si, že takhle pár vedení je již pojmenovaných, nevím zda je to
správně a zda v tom pokračovat, když vidím že někde chybí název.

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz
"___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz


Re: [Talk-it] R: Lavori stratali/strade chiuse

2020-11-11 Per discussione Martin Koppenhoefer


sent from a phone

> On 11. Nov 2020, at 09:34, canfe  wrote:
> 
> Su WAZE le strade chiuse sono ben evidenziate con un tratteggio bianco e 
> rosso.
> Ovviamente ci vuole qualcuno che le inserisca comprese le date di chiusura.
> Se contattate il vostro Area Manager di WAZE e gli fornite prova delle 
> chiusure son sicuro che le inserirà.
> Così servirà a tutta la comunità dei viaggiatori.


su openroute service si possono marcare aree da evitare, e il routing poi gira 
attorno (lo so, non è la stessa cosa)

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


[Talk-it] R: Lavori stratali/strade chiuse

2020-11-11 Per discussione canfe
Su WAZE le strade chiuse sono ben evidenziate con un tratteggio bianco e rosso.
Ovviamente ci vuole qualcuno che le inserisca comprese le date di chiusura.
Se contattate il vostro Area Manager di WAZE e gli fornite prova delle chiusure 
son sicuro che le inserirà.
Così servirà a tutta la comunità dei viaggiatori.

 

Ferruccio Cantone (canfe)

 

Da: Alessandro Vitali [mailto:vitoplu...@gmail.com] 
Inviato: martedì 10 novembre 2020 21:10
A: openstreetmap list - italiano
Oggetto: [Talk-it] Lavori stratali/strade chiuse

 

Ciao!

 

Premetto che io mi dedico al solo aggiornamento di numeri civici e vie, quindi 
non conosco le funzioni avanzate di osm!

Premessa: 

al 118 (trentino emergenza) abbiamo in dotazione dei tablet per la ricezione 
delle missioni e possiamo appoggiarci a 3 navigatori diversi installati:
- OsmAnd (che amo)
- Google Maps

- Waze

Le comunicazioni sulla chiusura delle strade/manifestazioni/lavori in corso ci 
arriva ancora via fax dai vari comuni. Attualmente i fax vengono visionati e 
affissi ad una bacheca ma, ovviamente, è un sistema obsoleto.

Domanda:

c'è un sistema semplice (anche come mappa online da sovrapporre alla mappa 
offline di osmand) che permetta di assegnare ad un punto un tag/simbolo di 
strada chiusa che si attiva secondo una serie di parametri:
- da quando
- a quando
- in che fascia oraria

???

 

 

Grazie!!!

Ale Vit

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