Re: [OSM-talk-fr] Data Item à la place de *:wikidata

[Yves P.]

> Je pense que le problème c'est que ?wikidata_from_dataitem c'est juste 
> "Q215657" alors que wikidata attend quelque chose qu'il affiche wd:Q215657.
Je n'ai pas regardé ce que Noémie à fait, mais ça me parait ça.

Q215657 est seulement un identifiant d'un "objet" XML, pas l'objet lui même.

> On le voit dans le requête qui marche avec brand:wikidata, il affiche bien un 
> wd:Qid avec un lien vers http://www.wikidata.org/entity/Qid 
> 
> Il ne faut pas donner à wikidata juste la référence, le Qid mais l’élément en 
> entier.
C'est ça :)

> Mais j'ai essayé en lui donnant "wd:Q215657" ou 
> "http://www.wikidata.org/entity/ Q215657" 
> mais ça ne marche pas.
> Je ne sais pas comment on obtient l’élément wikidata à partir de son Qid, je 
> n'ai pas trouvé…
J'avais fait des requêtes SparQL (sur les phares ?) qui interrogeait Wikidata 
et OSM.
Je l'avais envoyé comme exemple sur cette liste.
Si j'ai du temps aujourd'hui, je vais essayer de les retrouver. (Sinon, j'en ai 
plein dans ma machine).

> Sinon, sur le fait de se servir des data item de osm, je ne vois pas 
> l'utilité de recopier une partie de wikidata dans ces data item, autant se 
> servir de wikidata directement. ça évite d'avoir à maintenir les info dans 
> osm.
Oui, d'autant que des contributeurs Wikidata ont fait et/ou feront une partie 
du travail utile aux projets OSM (NSI : osmlab/name-suggestion-index 
)

> Par contre il n'y a pas vraiment toutes les marques dans wikidata. Par 
> exemple pour les supermarchés, il y a toutes les enseignes de la marque 
> Carrefour mais pas de Casino ou U.
Oui, il faut les rajouter dans Wikidata et/ou NSI.

bmillemathias  contribue fortement à NSI. Et 
il y a peut-être d'autres contributeurs francophones ?
Pour ma part j'essaie d'ajouter les marques manquantes dans Wikidata.

Vous pouvez aussi simplement rédiger une demande d'ajout (issue) dès que vous 
trouvez une marque qui n'est pas proposée par iD ou JOSM.

On pourrait automatiser en partie ça avec une requête Overpass ou SparQL qui 
liste les marques trouvées dans OSM et absentes de wikidata.

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

Re: [Talk-cat] Sobre les importacions: bones, regulars i irregulars

[Jan Esquerra]

Bon dia,

arrel del projecte "És obert" he fet un cop d'ull a les farmàcies de la
meva zona.

De les 5 que he mirat, 3 tenen errors (importats): dues mal ubicades en el
mapa (una bastant lluny i duplicant un node pre-existen que sí està al seu
lloc) i/o amb l'adreça incorrecta (el numero del carrer concretament).

A més a més, sé d'una farmàcia que no ha sigut importada (entenc que no hi
és a la base de dades).

Així doncs, dedueixo que la base de dades d'on s'ha extret la informació
per la importació té errors (uns quants) i no és completa.

Ja ho he rectificat a mà en el OSM, i convido a que feu un repàs a les
farmàcies que conegueu.

Cuideu-vos,

Jan

PD. aprofito per preguntar, hi ha grup de Telegram d'àmbit català?

Missatge de Joan Quintana  del dia dc., 25 de març 2020 a
les 18:13:

> Hola!
> Sóc el Joan Quintana (joanillo), el responsable de les importacions de
> dels ancoratges de bici, horts urbans, punts verds, arbres singulars de
> Barcelona i parkings amb l'etiqueta de car sharing.
> He estat parlant amb el Lanxana per tal de què els canvis fets s'ajustin a
> la normativa. Bàsicament es tracta de nodes (d'horts urbans hi ha 6 vies i
> aquí és possible que node estigui duplicat amb la via).
> Tot i que no coneixia la paraula 'conflació' tenia clar que no es pot
> matxacar la feina que que hi ha a sobre.
> els scripts que he fet servir són interactius (permetien comparar la
> informació existent amb els tags afegits/modificats, i cancelar si fos
> necessari).
>
> En tot cas començaré pels parkings que tenen la possibilitat de
> car-sharing (només n'hi ha 25), i compartiré el script al github per tal de
> què el reviseu),
>
> Com li comentava al Lanxana, suposo que s'ha de distingir entre importació
> i documentació. Ho dic perquè amb els dòlmens i menhirs de Catalunya s'ha
> fet una feina molt gran (que d'altra banda ja sé que no interessa a ningú
> :-)) i podem dir que estan tots els dòlmens de Catalunya ben catalogats:
> *http://wiki.joanillo.org/index.php/Fitxer:Dolmens_menhirs.png
>
> Joan Quintana
> www.joanillo.org
>
> Missatge de fadelkon  del dia dc., 25 de març 2020 a
> les 11:50:
>
>> E moltes gràcies! Quina bona notícia i resultat! :D
>>
>> El 25/3/20 a les 9:07, Lanxana . ha escrit:
>> >
>> > Bon dia,
>> >
>> > aquests dies hem estat en el punt de mira de la comunitat OSM, arrel
>> > de la importació de les farmàcies. Per a qui no hagi estat pendent de
>> > llistes i TG, faig un petit resum:
>> >
>> > El dia que es va decretar l’estat d’alarma per covid-19, ens vam
>> > plantejar què podíem fer per ajudar des del nostre confinament. De
>> > tots els conjunts de dades de fonts amb llicència, vam triar les
>> > farmàcies, com a primer pas. De les farmàcies hi havia 2 conjunts
>> > possibles: un catàleg sense coordenades publicat amb llicència CC0 i
>> > el conjunt d’equipaments, on entre altres moltes dades hi ha les
>> > farmàcies, tot georreferenciat. Es va muntar la wiki d’importació i el
>> > projecte al Gestor de Tasques, mentre es discutia amb la comunitat
>> > espanyola i s’escrivia tant a la espanyola com a la de imports, que és
>> > qui finalment té la potestat d’acceptar o no la importació com a vàlida.
>> >
>> > I aquí van començar els problemes... el conjunt triat, per facilitat
>> > de treball, va ser el dels equipaments, i la carta que tenim de la
>> > Generalitat autoritzant el seu ús és “contradictòria” segons Imports.
>> > Qui vulgui seguir el fil, aquí el pot trobar:
>> >
>> https://lists.openstreetmap.org/pipermail/imports/2020-March/006194.html
>> >
>> > Amb correus més o menys desafortunats, la tensió pujant per moments i
>> > el projecte a punt de ser revertit, en paral·lel es van iniciar
>> > gestions amb els propietaris de les dades (els gestors corresponents a
>> > la Generalitat), i finalment es va aconseguir que el dataset d’on
>> > havíem agafat les dades (i que ja us avanço que conté moltíssimes més
>> > i de molt interès per a OSM), canviés la seva llicència a CC0, que és
>> > totalment compatible amb OSM i no requereix cap autorització expressa.
>> >
>> > Gràcies a tots els que heu col·laborat tant en la importació en sí com
>> > en aconseguir que el que semblava una bona importació, i va passar a
>> > ser irregular, ha tornat a ser bona.
>> >
>> > Així les coses, convido a fer una reflexió de grup:
>> >
>> > - a vegades les ganes ens poden, volem fer ja el que sabem que és bo,
>> > però quan estem parlant d’importacions, necessitem seguir totes les
>> > passes per donar-li validesa, perquè sinó tota la feina, tot el temps
>> > invertit, quedaran en no res. Una importació no vàlida pot comportar
>> > des de revertir tota la feina que s’ha fet, fins al bloqueig de
>> > l’usuari que l’hagi fet.  Deixant pel camí ofenses, bronques,
>> > malentesos...
>> >
>> > - tenim moltes dades interessants i moltes ganes de que siguin a OSM.
>> > Això és bo, però cada cop hi ha més dades al mapa i hi ha una corrent
>> > dins d’OSM contrària a les importacions, així 

Re: [OSM-talk-fr] Data Item à la place de *:wikidata

[Jérôme Amagat]

Le lun. 13 avr. 2020 à 19:11, Noémie Lehuby via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Hello,
>
> j'ai un peu expérimenté sur le sujet des data item, mais j'arrive pas à
> grand chose.
> Je résume l'objectif : éviter de mettre des tags qui veulent dire à peu
> près la même chose dans OSM, à savoir brand et brand:wikidata.
>
> Pour l'exercice, imaginons que j'essaye de récupérer les logos de quelques
> magasins franchisés.
> Aujourd'hui, je peux le faire en faisant un lien entre OSM et Wikimédia
> Commons en passant par Wikidata à l'aide du tag brand:wikidata.
> Par exemple avec une requête de ce type : https://tinyurl.com/rq7uktj
>
> Essayons maintenant de reproduire l'expérience sans le tag brand:wikidata,
> en utilisant le tag brand et les data items du wiki pour faire le lien.
>
> Voici une requête qui récupère des supermarchés avec un tag brand, puis
> qui cherche dans les data items du wiki l'élement brand=ce qui m'intéresse,
> puis récupère son tag wikidata associé et va chercher le logo :
> https://tinyurl.com/r6zofzz
>
> Bon, ça retourne rien, mais ... en vrai, il n'y a aucun data item avec des
> marques de supermarchés (cf aparté ci-dessous)
>
> Si je refais la même requête avec une marque qui a un data item existant :
> https://tinyurl.com/r8kz2d6
>
> ben ça marche toujours pas ... une idée de pourquoi ?
>

Je pense que le problème c'est que ?wikidata_from_dataitem c'est juste
"Q215657"
alors que wikidata attend quelque chose qu'il affiche wd:Q215657.
On le voit dans le requête qui marche avec brand:wikidata, il affiche bien
un wd:Qid avec un lien vers http://www.wikidata.org/entity/Qid
Il ne faut pas donner à wikidata juste la référence, le Qid mais l’élément
en entier.
Mais j'ai essayé en lui donnant "wd:Q215657" ou "
http://www.wikidata.org/entity/Q215657; mais ça ne marche pas.
Je ne sais pas comment on obtient l’élément wikidata à partir de son Qid,
je n'ai pas trouvé...

Sinon, sur le fait de se servir des data item de osm, je ne vois pas
l'utilité de recopier une partie de wikidata dans ces data item, autant se
servir de wikidata directement. ça évite d'avoir à maintenir les info dans
osm.
Par contre il n'y a pas vraiment toutes les marques dans wikidata. Par
exemple pour les supermarchés, il y a toutes les enseignes de la marque
Carrefour mais pas de Casino ou U.

>
>
> Aparté :
>
> Cette requête affiche les data items brand=qqch :
> https://tinyurl.com/ve4fq9r
>
> On constate
> - qu'il y en a 6 en tout
> - que seuls 2 ont un id wikidata
>
> La volumétrie est vraiment donc très faible pour le moment.
>
> Questions : est-ce qu'on peut faire un import des brand dans la base du
> wiki, avec a minima l'id wikidata (en commençant par la France, voire juste
> les supermarchés en France) ?
> Quelles sont les bonnes pratiques ? Quels sont les outils qui
> permettraient de faire ça ?
> Le 27/03/2020 à 20:38, Noémie Lehuby via Talk-fr a écrit :
>
> Bonjour,
>
> Il y a pas mal d'homonymes dans le domaine des transports (même si c'est
> plus network:wikidata ou operator:wikidata que brand:wikidata je te le
> concède) . Personnellement, j'ai découvert ce sujet grâce à / à cause des
> deux réseaux "Arc-en-Ciel" (en Haute-Garonne
>  et dans le Nord
> ) qui ont fait coulé pas mal
> d'encre sur nos listes de diff.
>
> L'idée est intéressante en tout cas, je ne pensais pas qu'on pouvait
> utiliser les Data Item pour cela. Il y a déjà de la doc sur ce sujet et ce
> cas d'usage ?
> Pour que ça puisse remplacer / complémenter wikidata et éviter la saisie
> d'info redondantes dans OSM, il faudrait qu'on puisse savoir facilement si
> une liaison entre un tag brand=qqch et wikidata existe déjà, savoir comment
> accéder à ces infos par APIs ou en téléchargeant un dump de la base, etc
>
> --
> Noémie Lehuby
>
> Le 26/03/2020 à 22:52, François Lacombe a écrit :
>
>
> Le jeu. 26 mars 2020 à 18:10, Yves P.  a écrit :
>
>> > Je suggère de ne taguer les objets OSM qu'avec brand=*
>> Le problème, c’est qu’il y a des homonymes…
>> C’est pour ça qu’il existe wikidata ;)
>>
>
> Oui mais les identifiants wikidata ne sont pas lisibles.
> Le parti pris d'OSM est d'avoir des valeurs lisibles par l'homme il me
> semble?
> Et puis la question qui se pose est d'avoir deux fois la même information
> sur les objets.
>
> Peux-tu me citer un exemple d'homonyme s'il te plait?
>
>
>> > Et dans le DataItem relatif à une marque donné
>> brand=Harley-Davidson -> https://wiki.openstreetmap.org/wiki/Item:Q5371
>>
>> Ok, mais ça revient à recréer wikidata ?
>>
>
> Non parce que wikidata ne va pas te dire sur quelle géométrie peut-être
> utilisé le tag, ou à quelles règles de validation il va répondre.
> Les DataItem c'est la description sémantique propre à OSM.
>
>
>> > Sinon on ne va faire que ça et cette liaison va être modifiée en
>> permanence en plus d'être difficile à maintenir partout.
>> +1
>>
>> > Cela donne un cas d'usage 

Re: [OSM-talk-fr] Données produits-locaux.bzh

[osm . sanspourriel]

Yann-Gaël, tu recontactes la région pour leur résumer la situation ?

S'ils persistent à mettre à disposition et à nos frais un site que les
utilisateurs n'ont pas le droit d'utiliser, je me propose d'écrire au
Canard Enchaîné, au Télégramme et à Ouest-France pour montrer ce bel
exemple de l'utilisation de l'argent public.

À côté Google est cool, on a le droit d'utiliser (sous certaines
conditions) les informations que des esclaves volontaires ont collectées
pour eux.

Ça fera de la pub pour OSM, caresteouvert... et de la contre pub de la
région administrative Bretagne.

Sur la propriété par l'assos .bzh, ça ne me semble pas en lien avec son
objectif social tel qu'ils l'expriment :

/L’objectif de l’association, à but non lucratif, est d’assurer son
équilibre économique et de pouvoir, à terme, réinvestir ses bénéfices
dans le développement de la communauté numérique bretonne, tout en étant
attentive à conserver des prix attractifs pour le plus grand nombre./

Sauf à penser qu'ils revendent ces données (je doute).

Donc la Licence Ouverte me semble la bonne option.

Ils peuvent aussi basculer en intranet exclusivement ^^.

GarenKreiz, attention, tu as violé la mention légale puisque tu as
reproduit des informations du site !

N'oublions pas que le site se définit comme "La plateforme qui relie
producteurs et consommateurs en Bretagne". Je n'ai pas par ailleurs
apprécié de devoir donner un code postal afin de voir les producteurs de
mon coin et uniquement de mon coin. Certes on est actuellement confinés
mais ça n'a pas vocation à devenir l'était permanent.

Jean-Yvon, assujetti aux impôts levés par la région Bretagne

Le 14/04/2020 à 10:13, PanierAvide - panierav...@riseup.net a écrit :


Hmm, site et données édités par une collectivité territoriale (payé
avec des deniers publics ?) -> document administratif ? contraint
d'être publié sous licence ouverte ? Ça simplifierai pas mal la
question...

Adrien P.
Le 14/04/2020 à 09:51, Nicolas Bétheuil a écrit :

MDR ! Mais pourquoi les mettre en ligne alors ?
Ça mériterais un petit bashing sur la place publique.

Le mar. 14 avr. 2020 à 09:22, GarenKreiz mailto:garenkr...@gmail.com>> a écrit :

Petite perle détectée dans les mentions légales : "Les visiteurs
du site Internet s’interdisent ... l’utilisation, des
informations auxquelles ils ont accès". Alors que l'objectif même
du site est d'utiliser leurs informations pour établir des
contacts entre producteurs et consommateurs!


On Tue, 14 Apr 2020 at 08:50, Yann-Gaël LARGILLET
mailto:yglargil...@lilo.org>> wrote:

Salut à tous, j'ai contacté la Région Bretagne pour savoir si
on pouvait récupérer leurs données concernant le site
produits-locaux.bzh  afin
d'alimenter OSM et in fine çaresteouvert.fr
, mais malheureusement, leur
réponse a été assez simple en disant d'aller voir les
mentions légales (ce que j'aurais pu faire avant) :
https://www.produits-locaux.bzh/mentions-legales/

Si quelqu'un peut confirmer que la réutilisation de leurs
données est clairement impossible ?


Merci d'avance,

Cordialement,

Yann-Gaël

--
"Lentius, Profundius, Suavius" (A.Langer)
_

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

Re: [OSM-talk-fr] Ça reste ouvert et notes : avis et retours

[osm . sanspourriel]

Le 14/04/2020 à 16:19, PanierAvide  a écrit :


Merci d'avoir pris le temps de détailler les différents cas que tu as
rencontré, pour le coup c'est vraiment utile, d'autant plus vu le
volume de notes que tu as résolu


On a même des gens qui se plaignent de pas trouver de note ouverte et
effectivement on a un super-squatteur de notes :-D.

Et non Frantz, tu n'as pas à t'excuser d'avoir fait un bon message.

Le 15/04/2020 à 00:05, Marc M.  a écrit :

Cordialement,
Marc qui fait des retours sans retour


Alors je dis +1.

Le 14/04/2020 à 22:53, Fabienne Morel a écrit :

Le 14/04/2020 à 18:36, Frantz a écrit :

et laisser phone avec sa valeur d'origine.


Même si c'est un numéro de téléphone comme le dit Eric différent de
l'habituel ?


On en est à 39 phone:covid39  en France
mais surtout en Italie.

Le 14/04/2020 à 17:45, Eric SIBERT a écrit :

J'ai mis :
- phone:covid19 = 06 xx -> Ça s'affiche sur le site !!!


J'ai regardé, si tu parles de caresteouvert, non c'est le commentaire
qui est affiché, le numéro phone:covid19 ne l'est pas. Exemple
.

Suivent deux cas où je ne sais pas trop que faire pour contribuer via
caresteouvert (ou directement).

J'ai plusieurs cas où plusieurs producteurs/vendeurs se "regroupent" :
ils acceptent des commandes pour leur magasin et quelques autour, et les
gens viennent chercher ou se font livrer.

Pour celui qui regroupe et livre, c'est simple take_away:covid19 et
delivery:covid19 mais pour les autres ?

Côté base de données je vois bien une relation site avec
shop=convenience (heu, shop:covid19 !) par exemple mais j'imagine que ça
ferait un cas trop particulier à gérer.

Alors pour un magasin fermé mais qui accepte les commandes (téléphone,
courriel, Facebook, rarement site) take_away:covid19 et
delivery:covid19, opening_hours:covid19=off et dans description:covid19,
on dit comment commander et chez qui récupérer ?

Je n'ai pas renseigné opening_hours:covid19, le magasin étant légalement
fermé. Mais il n'apparait pas :-(,je suppose qu'il est nécessaire
d'ajouter opening_hours:covid19=off même s'il n'a pas le droit d'être
ouvert (comme l'exemple du Lézard ci-dessus).

Du coup on ne voit que chez celui chez qui on peut récupérer.

https://www.caresteouvert.fr/@47.789738,-3.488206,19.30/place/n6228071577

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

Donc on se "contente" de citer textuellement l'autre magasin dans le
commentaire ?


Comme je disais sur un ticket
, je pense
qu'un point où on peut s'améliorer c'est entre les enseignes (marques ou
franchises) qui appliquent la même règle partout (Covid_enseignes) et
les cas individuels (caresteouvert), il y a les enseignes qui ont
plusieurs règles.

Par exemple une célèbre enseigne de bricolage a réouvert des cours des
matériaux, donc pour un magasin c'est soit ouvert, soit fermé mais ce
sont toujours les mêmes règles qui s'appliquent si c'est ouvert (ici sur
réservation de créneau horaire et on fait ses emplettes sur place seul).

Je vois plusieurs possibilités :

- dans le bandeau générique Covid_enseignes on met le lien permettant
d'avoir l'info et chacun se tape le boulot. N. B. : ce lien existe dans
le fichier, il suffit de l'afficher.

- mieux (pour l'utilisateur et le contributeur) : on a deux/trois cas
prédéfinis (ici cours des matériaux ouverte ou fermée) et une fois
qu'une personne a lu l'info dans l'url en question il répond si ce
magasin est dans le cas 1 ou 2 et caresteouvert met à jour le magasin en
question (ici un description:covid19 spécifique). C'est juste à coder
par nos codeurs de compète ;-).

Jean-Yvon

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

Re: [OSM-talk-fr] Une borne de téléconsultation médicale

[Marc M.]

Bonjour,

Le 14.04.20 à 01:10, Donat ROBAUX a écrit :
> 1. Il n'est pas dit que dans un avenir proche, il y ait autre chose 
> que des médecins de l'autre côté de la borne.

c'est très probable (voir même probablement déjà le cas), et ce jour
là ce ne serrait plus un "docteur" à distance, mais un mini centre médical.
donc je ne vois pas le soucis à tager le service et non la techno
en tag principal

> 2. J'ai déjà vu des bornes de téléconsultation dans des pharmacies ou des
> mini-centres de santé. Du coup, un médecin dans une pharmacie ou une
> pharmacie chez un médecin. Evidemment sur le même objet. Donc pour moi il
> faut séparer les choses.

oui, il suffit de faire 2 objets :)
comme lorsqu'il y a un pharmacie et un médecin dans le même batiment,
ou une boite aux lettre sur le batiment de la mairie

Cordialement,
Marc

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

Re: [OSM-talk-fr] Ça reste ouvert et notes : avis et retours

[Vincent de Château-Thierry]

Bonsoir,

Le 15/04/2020 à 00:16, Frantz a écrit :


Ce qui est propre à la période covid19 est mis dans des clés :covid19 pour ne 
pas toucher aux valeurs ordinaires.
Et de plus le téléphone fixe doit rester valable lors des permanences au 
magasin.

Donc on pourrait imaginer un phone:covid19, mais le plus simple vu que ce n'est 
pas très fréquent, c'est de l'indiquer dans description:covid19.


A l'instant taginfo compte 39 phone:covid19=* C'est peu en effet. 
Cependant, rien que dans mon rayon de 1km j'ai plusieurs cas de 
téléphone dédié à la période : opticiens, agents immobiliers, pompes 
funèbres. En extrapolant, je pense que ça vaut le coup de pousser ce 
tag, ce sera toujours ça de moins dans les descriptions, par nature 
moins exploitables.


vincent


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

Re: [OSM-talk-fr] Ça reste ouvert et notes : avis et retours

[Frantz]

14 avril 2020 22:53 "Fabienne Morel via Talk-fr"  a 
écrit:

> Le 14/04/2020 à 18:36, Frantz a écrit :
> 
>> et laisser phone avec sa valeur d'origine.
> 
> Même si c'est un numéro de téléphone comme le dit Eric différent de
> l'habituel ?
> qui parait être utilisé pour s'adapter à la situation particulière de
> cette période

Ce qui est propre à la période covid19 est mis dans des clés :covid19 pour ne 
pas toucher aux valeurs ordinaires.
Et de plus le téléphone fixe doit rester valable lors des permanences au 
magasin.

Donc on pourrait imaginer un phone:covid19, mais le plus simple vu que ce n'est 
pas très fréquent, c'est de l'indiquer dans description:covid19.

-- 
Fantz

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

Re: [OSM-talk-fr] Ça reste ouvert et notes : avis et retours

[Marc M.]

Le 14.04.20 à 17:45, Eric SIBERT a écrit :
> takeaway:covid19 -> "Vente à emporter uniquement". 
> Non, c'est plutôt retrait de commande. Comment coder?

takeaway:covid19=no
reservation:covid19=required

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

Re: [OSM-talk-fr] Ça reste ouvert et notes : avis et retours

[Marc M.]

Le 14.04.20 à 15:16, Frantz a écrit :
> 4) "détails" contient des infos qui annulent toutes les autres données : faux 
> signalement, ou commerce déplacé, ou parle du commerce d'à côté

> - pour gérer ce dernier point, toujours le fait du propriétaire du magasin 
> visé, renvoyer les commerçants vers un formulaire exhaustif (ou leur proposer 
> l'alternative) : la plupart seront contents d'enrichir les infos sur leur 
> commerce, et ça pourrait inciter les autres à prendre plus de temps, par 
> exemple pour entrer les horaires hors covid19).
+1 ! un signalement commerce erroné ne doit pas se noyer dans les covid

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

Re: [OSM-talk-fr] Ça reste ouvert et notes : avis et retours

[Marc M.]

Bonjour,

Le 14.04.20 à 12:21, PanierAvide a écrit :
> cumuler contribution directe + note OSM si des détails sont fournis :
> Nous sommes preneurs de vos retours :-)

replay :
tout ce qui peux être mis à jour automatiquement dans osm doit l'être,
il n'y a aucune pluvalue à demander à un humain de copie/coller un tag
d'une note vers l'objet osm.
donc oui diviser la contribution en changeset+note est une évidence
réclamée depuis... enfin bref...

Cordialement,
Marc qui fait des retours sans retour

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

Re: [Talk-hr] Grad Knin i tasking manager za građevine

[Hrvoje Bogner]

Dakle ekipo što ćemo, držati se 2007 ili namještati na DGU DOF svaku dio 
pojedinačno?


Ja sam možda za to da cijeli Knin odradimo na temelju 2007 a na rubnim 
područjima prilagodimo prijelaz na DGU DOF radi kasnijeg lakšeg povezivanja.


Da čujemo i vaša mišljenja kao iskusih mapera...

On 14. 04. 2020. 17:42, Ivan Habunek wrote:

On Tue, 14 Apr 2020, at 17:22, Hrvoje Bogner wrote:

Imaš pravo, to mi je promaklo. Sad sam usporedio i DGU ima fiksne
položaje prometnica na sve 3 godine snimanja, ali se samo kut snimanja
razlikuje pa se krovovi "naginju".  Trebalo bi namjestiti Knin 2007 na
DGU položaje prometnica. Znači Geofoto je Kninu prodao loše
pozicionirane snimke ili sam ja nešto zeznuo u konverziji.

Namjestio sam offset u JOSM za Knin na -2.39; 3.58 i čini se da ga to poravna 
sa DGU.

Možda bi bilo dobro dodati naputak u upute.

Pozdrav,
Ivan

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


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

Re: [OSM-talk-fr] Ça reste ouvert et notes : avis et retours

[Fabienne Morel via Talk-fr]

Le 14/04/2020 à 18:36, Frantz a écrit :

et laisser phone avec sa valeur d'origine.


Même si c'est un numéro de téléphone comme le dit Eric différent de 
l'habituel ?
qui parait être utilisé pour s'adapter à la situation particulière de 
cette période



fabienne



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

Re: [Talk-dk] Søer

[Anders Wegge Keller]

På Tue, 14 Apr 2020 22:08:37 +0200
Jørgen Elgaard Larsen  skrev:

> Når du filtrerer på flere ting i Osmium, bruger den logisk ELLER.

Ja, så kan jeg godt se mit datasæt skal blive stort.

...

> Den sidste - angiver, at osmium nr. 2 skal læse fra stdin, dvs. dvs 
> output fra den første.

Jeg takker.

-- 
//Wegge

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

Re: [Talk-dk] Søer

[Jørgen Elgaard Larsen]

Michael Andersen skrev:

Mindre områder i Danmark kan du sikkert downloade via
https://overpass-turbo.eu/. Vær her opmærksom på at der er grænser for
hvor store datamængder browsere kan håndtere.



Man kan hente det med f.x. cUrl eller wget fra Overpass Turbos API:

http://overpass-api.de/api/interpreter?data=%5Bout%3Ajson%5D%5Btimeout%3A325%5D%3B%0A%0A%2F%2F%20Find%20Denmark%0Aarea%5Badmin_level%3D%222%22%5D%5Bname%3D%22Danmark%22%5D%5Bboundary%3D%22administrative%22%5D-%3E.dk%3B%0A%0A%2F%2F%20Find%20lakes%20in%20Denmark%0A%28%20%20%0A%20%20way%5B%22water%22%3D%22lake%22%5D%5Bnatural%3Dwater%5D%28area.dk%29%3B%0A%20%20relation%5B%22water%22%3D%22lake%22%5D%5Bnatural%3Dwater%5D%28area.dk%29%3B%0A%29%3B%0A%0A%0A%2F%2F%20print%20results%0Aout%20body%3B%0A%3E%3B%0Aout%20skel%20qt%3B%0A%0A


Mennesker kan se søgningen her:

http://overpass-turbo.eu/s/SPr


- Jørgen

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

Re: [Talk-dk] Søer

[Jørgen Elgaard Larsen]

Når du filtrerer på flere ting i Osmium, bruger den logisk ELLER.

Dvs. at din søgning finder alle ways/relations med ENTEN natural=water 
ELLER water=lake.


Så du finder også alle vandløb, der er tagget natural=water + 
water=river.



Det nemmeste er nok bare KUN at lede efter water=lake.

Ellers kan du gøre noget i retning af:

osmium tags-filter denmark-latest.osm.pbf wr/water=lake | osmium -o 
water_dk.osm.pbf wr/natural=water -



Så finder du først alle water=lake, derefter filtrerer du en gang til på 
natural=water.


Den sidste - angiver, at osmium nr. 2 skal læse fra stdin, dvs. dvs 
output fra den første.


- Jørgen



Anders Wegge Keller skrev:
osmium tags-filter denmark-latest.osm.pbf wr/natural=water 
wr/water=lake -o

water_dk.osm.pbf

Det ser ud til at give mig de søer der har en størrelse der vil give
kedelige billeder. Men desværre får jeg også en hel masse vandløb med, 
så

det bliver en jævnt stor fil at arbejde med. Kender du tilfældigvis det
værktøj godt nok til at give et hint om hvad jeg gør forkert?



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

Re: [Talk-dk] Søer

[Michael Andersen]

tirsdag den 14. april 2020 21.20.38 CEST skrev Anders Wegge Keller:
> På Tue, 14 Apr 2020 19:46:40 +0200
> 
> Michael Andersen  skrev:
> > I JOSM har jeg lige forsøgt mig med Overpass API og søgningen
> > "natural=water & water=lake & (type:way or type:relation) in Danmark".
> > 
> > Det fungerer fint, bortset fra at ikke alle større søer endnu er tagget
> > water=lake, mens et stort antal vandhuller, der måske med fordel kunne
> > tagges water=pond, omvendt kommer med.
> > 
> > Mindre områder i Danmark kan du sikkert downloade via
> > https://overpass-turbo.eu/. Vær her opmærksom på at der er grænser for
> > hvor store datamængder browsere kan håndtere.
> 
>  Jeg er totalt novice i det her, så jeg bliver desværre nødt til at spørge
> om noget endnu mere basalt. Jeg kan se at min browser ganske rigtigt timer
> ud, når jeg prøver at gøre noget i hele Danmark. Så jeg har downloadet et
> dump i pbf format for at rode med det lokalt. Jeg har så brugt osmium
> kommandolinieværktøjet til at lave den samme filtrering som du har ovenfor:
> 
> osmium tags-filter denmark-latest.osm.pbf wr/natural=water wr/water=lake -o
> water_dk.osm.pbf
> 
> Det ser ud til at give mig de søer der har en størrelse der vil give
> kedelige billeder. Men desværre får jeg også en hel masse vandløb med, så
> det bliver en jævnt stor fil at arbejde med. Kender du tilfældigvis det
> værktøj godt nok til at give et hint om hvad jeg gør forkert?

Jeg har desværre ingen som helst erfaring med osmium.

Men jeg har lige søgt på alle søer i DK, som var tagget "wiki*" og på den måde 
fundet endnu ~150 søer, som nu også er tagget water=lake :-).

Jeg har ingen erfaring med det heller, men hvis man på 
https://overpass-turbo.eu/  klikker på tabben "Eksporter"->"Søgning" kommer man 
frem et vindue 
der tilbyder "Download direkte fra Overpass-API". Jeg vil gætte på det vil 
kunne gøre det. Ellers er måske en der kan fikse et script der kan snakke 
direkte med API'et. 




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

Re: [Talk-hr] Grad Knin i tasking manager za građevine

[Hrvoje Bogner]

On 14. 04. 2020. 17:42, Ivan Habunek wrote:

On Tue, 14 Apr 2020, at 17:22, Hrvoje Bogner wrote:

Imaš pravo, to mi je promaklo. Sad sam usporedio i DGU ima fiksne
položaje prometnica na sve 3 godine snimanja, ali se samo kut snimanja
razlikuje pa se krovovi "naginju".  Trebalo bi namjestiti Knin 2007 na
DGU položaje prometnica. Znači Geofoto je Kninu prodao loše
pozicionirane snimke ili sam ja nešto zeznuo u konverziji.

Namjestio sam offset u JOSM za Knin na -2.39; 3.58 i čini se da ga to poravna 
sa DGU.

Možda bi bilo dobro dodati naputak u upute.

Pozdrav,
Ivan


Različiti krajevi imaju različite offsete, nema jedinstvenog za Knin, 
ako koristim tvoje brojeve moj task odleti na suprotnu stranu.



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

Re: [Talk-dk] Søer

[Anders Wegge Keller]

På Tue, 14 Apr 2020 19:46:40 +0200
Michael Andersen  skrev:


> I JOSM har jeg lige forsøgt mig med Overpass API og søgningen
> "natural=water & water=lake & (type:way or type:relation) in Danmark".
> 
> Det fungerer fint, bortset fra at ikke alle større søer endnu er tagget
> water=lake, mens et stort antal vandhuller, der måske med fordel kunne
> tagges water=pond, omvendt kommer med.
> 
> Mindre områder i Danmark kan du sikkert downloade via
> https://overpass-turbo.eu/. Vær her opmærksom på at der er grænser for
> hvor store datamængder browsere kan håndtere.

 Jeg er totalt novice i det her, så jeg bliver desværre nødt til at spørge
om noget endnu mere basalt. Jeg kan se at min browser ganske rigtigt timer
ud, når jeg prøver at gøre noget i hele Danmark. Så jeg har downloadet et
dump i pbf format for at rode med det lokalt. Jeg har så brugt osmium
kommandolinieværktøjet til at lave den samme filtrering som du har ovenfor:

osmium tags-filter denmark-latest.osm.pbf wr/natural=water wr/water=lake -o
water_dk.osm.pbf

Det ser ud til at give mig de søer der har en størrelse der vil give
kedelige billeder. Men desværre får jeg også en hel masse vandløb med, så
det bliver en jævnt stor fil at arbejde med. Kender du tilfældigvis det
værktøj godt nok til at give et hint om hvad jeg gør forkert?

-- 
//Wegge

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

Re: [OSM-talk-nl] BAG straatnamen (ook?) in OSM

[g . idema]

On 14-04-2020 19:48, Colin Smale wrote:

Als je op GitHub kijkt, zijn de extracten (gratis) per gemeente te 
downloaden. Heb je daar wat aan?

https://github.com/lvbag/BAG-2.0-Extract/tree/master/BAG%202.0%20gemeente%20extracten%20productie

Interessent. Ik ga hier zeker eens naar kijken. Wel jammer dat die 14 
grootste gemeenten apart gedownload moeten worden.



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

Re: [OSM-talk] Overpass API version 0.7.56

[mmd]

Thank you for the update!

On 2020-04-14 07:09, Roland Olbricht wrote:
> I intend to bundle them with the necessary changes to use
> ways and relations directly as areas,
> but that is not implemented yet.


Although this sounds like a minor topic, it has quite some impact for a
number of users. Rather frequently, people are puzzled that they cannot
query for buildings without a housenumber node inside, or residential
areas without buildings, etc.

This is mainly due to a static set of rules on the Overpass server that
define, which objects qualify for area queries. You've probably seen
various Q site answers along the lines of: in theory it would work if
your object had a name=* tag, but as it doesn't have one, sadly, you're
out of luck.

By eliminating those static rules in the equation and directly using
(almost arbitrary) ways and relations, we expect that all those new use
cases can be covered out of the box.


A few examples as sneak preview:

- https://overpass-turbo.eu/s/SP9 - unnamed landuse=residential
ways/relations without buildings inside

- https://overpass-turbo.eu/s/FaQ - misuse of barrier=line on leisure=pitch

- https://overpass-turbo.eu/s/Fbv - buildings without housenumber on way
and no respective nodes inside

(mandatory disclaimers: actual implementation and syntax *will* change,
data on the server may be outdated, server may be unavailable, prototype
only!)

-- 

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

Re: [OSM-talk-nl] BAG straatnamen (ook?) in OSM

[Colin Smale]

On 2020-04-14 18:52, g.id...@zonnet.nl wrote:

> Hoi Richard,
> 
> De adressen in OSM worden bijgewerkt op basis van de BAG WFS. Daarin staan 
> echter geen BAG adres id's, maar BAG verblijfsobject id's. Dat is de reden 
> dat geen BAG id's op de adressen in OSM zitten. Wat ik zelf overigen ook een 
> groot gemis vind.
> Op de panden zitten wel BAG id's. Op de straten weer niet.
> 
> Voor de straten is er de optie om de tag alt_name te gebruiken voor de BAG 
> naam, als deze afwijkt van de uitgeschreven naam. Dit zie je bijvoorbeeld in 
> Bunnik en Odijk. Dan zijn echter de namen op de straten en niet op de 
> adressen. Een tag voor de officiele straatnaam op een adress heb ik niet 
> kunnen vinden. Dat zou iets als addr:street:official of zo moeten worden.

Dit gaat niet echt over straatnamen, maar over de schrijfwijze ervan. Er
is maar één bron van de officiële volledige schrijfwijze: het
gemeentebesluit waarin de naam wordt toegekend. Daarnaast zijn er
verschillende erkende schrijfwijzen in gebruik, met eigen regels voor
afkortingen, leestekens, accenten, hoofdletters, numerieke delen, enz. 

https://www.digitaleoverheid.nl/overzicht-van-alle-onderwerpen/basisregistraties-en-afsprakenstelsels/stelsel-van-basisregistraties/schrijfwijze-registreren-en-presenteren-adressen-stelsel-basisregistraties/


De straatnaam zoals die in de BAG staat, is misschien niet helemaal
gelijk aan het gemeentebesluit - en dan heb je altijd de mogelijkheid
van een typefout. 

Of een straatnaam (bijvoorbeeld) met puntjes of zonder geschreven wordt,
verandert niets aan de eigenlijke straatnaam; een mens ziet misschien
makkelijker dan een computer dat het om dezelfde straat gaat. 

> Ik kan op dit moment eenvoudige oplossing bedenken. Dan kom je toch geo 
> oplossingen zoals die van Bas, of koppelingen op basis van 
> postcode-huisnummer. In het verleden (2015) heb ik wel eens een vergelijking 
> gemaakt tussen OSM en BAG straten (zie bijlage). Misschien heb je daar iets 
> aan.
> 
> Nu er een prijskaartje aan de BAG hangt, is de drempel voor dat soort hobby 
> projectjes toch wat hoger.

Als je op GitHub kijkt, zijn de extracten (gratis) per gemeente te
downloaden. Heb je daar wat aan? 
https://github.com/lvbag/BAG-2.0-Extract/tree/master/BAG%202.0%20gemeente%20extracten%20productie___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [Talk-dk] Søer

[Michael Andersen]

tirsdag den 14. april 2020 17.32.14 CEST skrev Anders Wegge Keller:
> Jeg kører en dansk Twitterkonto, @DanskKvadrat. Kontoen
> finder et tilfældigt punkt indenfor DAGI500 shapefilen, og downloader 4 km²
> billeder fra google maps. Det virker rimeligt godt, men en gang imellem
> rammer den et tilfældigt punkt ude i en sø, som emsempelvis:
> 
> https://twitter.com/DanskKvadrat/status/1249823489906917381
> 
> Den slags billeder bliver lidt kedelige at se på i længden, så jeg kunne
> godt tænke mig at maske de områder der er tagget som water=lake ud af valget
> af tilfældige lokationer. Findes der en nogenlunde tilgængelig opskrift på
> hvordan man får pillet sådan et subset ud?

I JOSM har jeg lige forsøgt mig med Overpass API og søgningen "natural=water & 
water=lake & (type:way or type:relation) in Danmark".

Det fungerer fint, bortset fra at ikke alle større søer endnu er tagget 
water=lake, mens et stort antal vandhuller, der måske med fordel kunne tagges 
water=pond, omvendt kommer med.

Mindre områder i Danmark kan du sikkert downloade via 
https://overpass-turbo.eu/. Vær her opmærksom på at der er grænser for hvor 
store datamængder browsere kan håndtere.




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

Re: [OSM-talk-fr] Ça reste ouvert et notes : avis et retours

[Frantz]

14 avril 2020 17:45 "Eric SIBERT"  a écrit:

>> 1) "détails" contient juste une précision qui pourrait être saisie
>> directement dans "description:covid19" (ex : "permanence
>> téléphonique")
> 
> Dans le style, opticien qui assure une permanence de 15h à 16h pour les
> livraisons. Pour les nouvelles commandes (lentilles, lunettes) ou les
> réparations, prendre rendez-vous avec un numéro de téléphone différent
> de l'habituel.
> 
> J'ai mis :
> - phone:covid19 = 06 xx -> Ça s'affiche sur le site !!!
> - takeaway:covid19 -> "Vente à emporter uniquement". Non, c'est plutôt
> retrait de commande. Comment coder? La pizzeria voisine fait pareil :
> uniquement retrait des commandes faites par téléphone.

Je verrais juste :
opening_hours:covid19=open
description:covid19="Commandes (lentilles, lunettes) ou rendez-vous réparation 
: appelez le 06xxx. Permanence uniquement pour retrait des commandes de 15h à 
16h."

et laisser phone avec sa valeur d'origine.

-- 
Frantz

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

Re: [OSRM-talk] Need help: Customizing weights in Profile shows inconsistent results with Dijsktra

[Daniel Patterson via OSRM-talk]

I would say that the first thing to do to diagnose the problem is to find
the shortest possible path (fewest edges) that exhibit this problem for you.

At first glance, I'd say that your BPR values aren't what you think they
are somewhere along your route, but it's impossible to say exactly where
they might be incorrect.

daniel

On Tue, Apr 14, 2020 at 2:39 AM Niharika Shrivastava <
chunnushrivast...@gmail.com> wrote:

> Hello, I'm new to OSRM and I went through previous issues and couldn't
> find much related to this, hence posting it here.
>
> I had used a python library OSMnx to extract Singapore's data and changed
> certain edge attributes for it. I calculated an edge attribute `"BPR"`
> (float) and stored it in the graph (This is travel time in case of real
> traffic data). I then converted this modified graph into a shapefile and
> then converted the shapefile into OSM XML using JOSM. I fed this to OSRM in
> order to use CH. I want to find the shortest route between two points
> wherein my weights (or cost) are the BPR value I had calculated. I
> understand I have to specify that in the car profile. This is how I
> specified it:
>
> ```
> function setup()
>   return {
> properties = {
>   ...
>   weight_name = 'congestion',
>   ...
> },
>   ...
> }
>
>
> function process_way(profile, way, result, relations)
>   local data = {
> -- prefetch tags
> ...
> BPR = way:get_value_by_key('BPR')
>   }
>
>   result.weight = data.BPR
>   ...
> }
> ```
>
> This is the JSON response I get for a certain query:
> ```
> {'code': 'Ok',
>  'routes': [{'geometry': 's}gG{ijyReEnNdm@|Wpl@~}@b\\lfAw\\twAbFjt@wM
> `ZwSpAGnNgN|Dvm@fWwHhb@bErz@qFxeAzVfkAfr@b{Ak_@rr@ocA~dAgCda@ji@dz@`j@di
> @`Sfi@PfQcRpc@ySyCgw@~XjEx]dHDkEl\\ju@lf@ii@n}@oVqEiKlR_Elw@bJd[lc@wFdKf
> [',
>'legs': [{'steps': [],
>  'distance': 32298.2,
>  'duration': 2308.4,
>  'summary': '',
>  'weight': 2179.6}],
>'distance': 32298.2,
>'duration': 2308.4,
>'weight_name': 'congestion',
>'weight': 2179.6}],
>  'waypoints': [{'hint':
> 'YwYBgG8GAYALAQAAHN-XQWpx4j0AAA0BAAAJyOIxBiSzFADI4jEGJLMUzwFqJcKJ',
>'distance': 0,
>'name': 'Tampines Avenue 8',
>'location': [103.932616, 1.35658]},
>   {'hint':
> 'EAYBgBcGAYAUPzfZQQAAABkJ6oIuBlR3FADqgi4GVHcULwpqJcKJ',
>'distance': 0,
>'name': 'Boon Lay Drive',
>'location': [103.711466, 1.341268]}]}
> ```
>
> Looking at this part from the JSON:
>  ```
>  'duration': 2308.4,
>   'weight': 2179.6}],
> ```
> As I understand, weight is the summation of BPR values for each edge.
> Duration is estimated free flow time:` length/max_speed for each edge`. The
> `value of weight should be >= duration` which is true when I use Dijkstra
> for routing using edge weights as BPR value (`3155.27`). But over here,
> thats not the case.
>
> BPR = duration*(some delay based on traffic) >= duration in case of no
> traffic
>
> Can someone please point out if my Profile is wrongly written or if I've
> missed any steps?
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [Talk-it] Import Farmacie

[Andrea Musuruane]

Ciao,

On Tue, Apr 14, 2020 at 2:39 PM Andrea Musuruane  wrote:

> [...]
>
> Tra l'altro, sulla prima farmacia che ho controllato, sono stati inseriti
> dei dati errati:
> https://www.openstreetmap.org/node/7082514124#map=17/45.34317/8.17588
>

Oppure in questo caso, dove per inserire una farmacia (fonte per il
posizionamento?) è stato cancellato il tag highway=tertiary da una strada:
https://nrenner.github.io/achavi/?changeset=83407489

Ciao,

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

Re: [Talk-it] Import Farmacie

[Cascafico Giovanni]

Il giorno mar 14 apr 2020 alle ore 17:33 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:
> > On 14. Apr 2020, at 15:13, Cascafico Giovanni 
wrote:
> > ma sempre appoggiandomi ad umap
>
> Non capisco, pensavo che umap non fosse una fonte, ma un strumento, i
dati sono sempre quelli dal dataset del ministero, o forse mi sfugge un
dettaglio?

Certo, umap è uno strumento a cui mi "appoggio", cioè che mi è utile per
visualizzare della posizione derivata dai dati del ministero :-)
Quando si apre una della due mappe (o quando si preme il link inbasso
"informazioni", "about") si legge che la fonte del layer in blu è il
"Ministero delle Salute".
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Ça reste ouvert et notes : avis et retours

[Eric SIBERT]

1) "détails" contient juste une précision qui pourrait être saisie
directement dans "description:covid19" (ex : "permanence
téléphonique")


Dans le style, opticien qui assure une permanence de 15h à 16h pour les 
livraisons. Pour les nouvelles commandes (lentilles, lunettes) ou les 
réparations, prendre rendez-vous avec un numéro de téléphone différent 
de l'habituel.


J'ai mis :
- phone:covid19 = 06 xx -> Ça s'affiche sur le site !!!
- takeaway:covid19 -> "Vente à emporter uniquement". Non, c'est plutôt 
retrait de commande. Comment coder? La pizzeria voisine fait pareil : 
uniquement retrait des commandes faites par téléphone.


Eric


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

Re: [Talk-hr] Grad Knin i tasking manager za građevine

[Ivan Habunek]

On Tue, 14 Apr 2020, at 17:22, Hrvoje Bogner wrote:
> Imaš pravo, to mi je promaklo. Sad sam usporedio i DGU ima fiksne 
> položaje prometnica na sve 3 godine snimanja, ali se samo kut snimanja 
> razlikuje pa se krovovi "naginju".  Trebalo bi namjestiti Knin 2007 na 
> DGU položaje prometnica. Znači Geofoto je Kninu prodao loše 
> pozicionirane snimke ili sam ja nešto zeznuo u konverziji.

Namjestio sam offset u JOSM za Knin na -2.39; 3.58 i čini se da ga to poravna 
sa DGU.

Možda bi bilo dobro dodati naputak u upute.

Pozdrav,
Ivan

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

Re: [Talk-it] Import Farmacie

[Martin Koppenhoefer]

sent from a phone

> On 14. Apr 2020, at 15:13, Cascafico Giovanni  wrote:
> 
> ma sempre appoggiandomi ad umap


Non capisco, pensavo che umap non fosse una fonte, ma un strumento, i dati sono 
sempre quelli dal dataset del ministero, o forse mi sfugge un dettaglio?


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

[Talk-dk] Søer

[Anders Wegge Keller]

Jeg kører en dansk Twitterkonto, @DanskKvadrat. Kontoen
finder et tilfældigt punkt indenfor DAGI500 shapefilen, og downloader 4 km²
billeder fra google maps. Det virker rimeligt godt, men en gang imellem
rammer den et tilfældigt punkt ude i en sø, som emsempelvis: 

https://twitter.com/DanskKvadrat/status/1249823489906917381

Den slags billeder bliver lidt kedelige at se på i længden, så jeg kunne
godt tænke mig at maske de områder der er tagget som water=lake ud af valget
af tilfældige lokationer. Findes der en nogenlunde tilgængelig opskrift på
hvordan man får pillet sådan et subset ud?

-- 

//Wegge

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

Re: [OSM-talk-nl] BAG straatnamen (ook?) in OSM

[Sebastiaan Couwenberg]

On 4/14/20 5:08 PM, Richard Duivenvoorde wrote:
> Is er dan een andere mogelijkheid om, gegeven een officieel adres of
> straatnaam, een koppeling te maken met een OSM straat of pand?

Op basis van de coordinaten in de BAG kan de node of way met dat adres
in OSM gevonden worden, en op basis daarvan kan de dichtsbijzijnde
straat met die naam gevonden bijvoorbeeld met een algoritme zoals
geimplementeerd in de FixAddresses plugin:

 https://wiki.openstreetmap.org/wiki/JOSM/Plugins/FixAddresses

De meeste mappers zijn actief op het forum, daar zal je vraag meer
mensen berijken:

 https://forum.openstreetmap.org/viewforum.php?id=12

Mvg,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [Talk-hr] Grad Knin i tasking manager za građevine

[Hrvoje Bogner]

On 14. 04. 2020. 16:52, Ivan Habunek wrote:

On Tue, 14 Apr 2020, at 14:23, Hrvoje Bogner wrote:

Vrijeme je da organizirano iskoristimo već spomenuti Digitalni ortofoto
Grada Knina
.

Bok Hrvoje,

Novi OSM projekti su super za ubijanje dosade ovih dana. :)

Primjećujem da snimke koje se spominju u projektu nisu poravnate. Usporedba:
http://0x0.st/iQBR.png (Knin 2007)
http://0x0.st/iQB7.png (DGU 2017)

Da li možemo Knin 2007 smatrati točnim i referentnim ili je potrebno neko 
podešavanje? Ne mogu potegnuti do Knina snimiti situaciju GPSom. :)

Bit će potrebno i ceste točnije ucrtati jer će se inače preklapati s kućama pa 
da ne radimo hrpu posla koje će kasnije trebati ispravljati.

Pozdrav,
Ivan


Cilj mi je i bio da vas zainteresiram s nečim ovih dana :)

Imaš pravo, to mi je promaklo. Sad sam usporedio i DGU ima fiksne 
položaje prometnica na sve 3 godine snimanja, ali se samo kut snimanja 
razlikuje pa se krovovi "naginju".  Trebalo bi namjestiti Knin 2007 na 
DGU položaje prometnica. Znači Geofoto je Kninu prodao loše 
pozicionirane snimke ili sam ja nešto zeznuo u konverziji.


Prometnice su sljedeći task, nisam stigao sve to napraviti, a nisam bio 
siguran je li trebalo sve u jedan taks staviti.


Ima li zainteresiranih za pomoć oko kreiranja dodatnih taskova?

Pozdrav, Hrvoje


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

[OSM-talk-nl] BAG straatnamen (ook?) in OSM

[Richard Duivenvoorde]

Hoi,

Iemand probeert hier nederlandse BAG adressen te koppelen aan
OpenStreetMap straatnamen. Nu wil het geval dat de OSM straatnamen in de
adressen niet (altijd) overeenkomen met de BAG.

Even googlen geeft mij:

https://wiki.openstreetmap.org/wiki/NL:BAGimport_via_ODS_plugin#STAP_4_Nabewerking

Waarin expliciet staat dat het een OSM conventie is om straatnamen UIT
te schrijven. Dus waarschijnlijk krijg ik problemen wanneer ik de
straatnamen BAG conform zou aanpassen :-)

Is er dan een andere mogelijkheid om, gegeven een officieel adres of
straatnaam, een koppeling te maken met een OSM straat of pand?
Ik dacht dat er misschien wel BAG-id's in de data zouden zitten, maar ik
zie ze niet in de verschillende editors die ik online kon bekijken.

Een andere optie zou natuurlijk zijn om een 'way' een alternatieve naam
te geven (net zoals plaatsnamen alternatieve namen hebben)? Een
'bag-spelling' ofzo?

Iemand hier een idee over. Of kan iemand me wijzen waar hier eerder over
gesproken is?

Vriendelijke Groet,

Richard Duivenvoorde

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

Re: [Talk-hr] Grad Knin i tasking manager za građevine

[Ivan Habunek]

On Tue, 14 Apr 2020, at 14:23, Hrvoje Bogner wrote:
> Vrijeme je da organizirano iskoristimo već spomenuti Digitalni ortofoto 
> Grada Knina 
> .

Bok Hrvoje, 

Novi OSM projekti su super za ubijanje dosade ovih dana. :)

Primjećujem da snimke koje se spominju u projektu nisu poravnate. Usporedba:
http://0x0.st/iQBR.png (Knin 2007) 
http://0x0.st/iQB7.png (DGU 2017)

Da li možemo Knin 2007 smatrati točnim i referentnim ili je potrebno neko 
podešavanje? Ne mogu potegnuti do Knina snimiti situaciju GPSom. :)

Bit će potrebno i ceste točnije ucrtati jer će se inače preklapati s kućama pa 
da ne radimo hrpu posla koje će kasnije trebati ispravljati.

Pozdrav,
Ivan

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

Re: [OSM-talk-fr] Une borne de téléconsultation médicale

[Donat ROBAUX]

Et donc?
Toutes ces lignes inutiles pour ne pas répondre à la question...

Donat



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] Ça reste ouvert et notes : avis et retours

[PanierAvide]

Bonjour Frantz,

Merci d'avoir pris le temps de détailler les différents cas que tu as 
rencontré, pour le coup c'est vraiment utile, d'autant plus vu le volume 
de notes que tu as résolu ;-)


Cordialement,

Adrien P.

Le 14/04/2020 à 15:16, Frantz a écrit :

Bonjour,

parmi les cas restant en saisie manuelle, je vois en gros :
1) "détails" contient juste une précision qui pourrait être saisie directement dans 
"description:covid19" (ex : "permanence téléphonique")
2) "détails" contient juste une info simple à intégrer (ex : "http://maboutique.fr;, 
"i...@maboutique.com", "01 23 45 76 89")
3) "détails" contient une correction  de la plage horaire : opening_hours:covid19="Mo-Fr 
08:00-19:00" et détails "fermé de 12h à 13h.
4) "détails" contient des infos qui annulent toutes les autres données : faux 
signalement, ou commerce déplacé, ou parle du commerce d'à côté

Pour 1 et 2 l'intégration auto de "détails" pourrait se faire mais c'est plus 
un choix politique, savoir si on laisse entrer des données libres sans contrôle. 
L'intégration auto des autres champs ferait gagner du temps.
Pour le 3 l'intégration auto des autres champs ajouterait des données fausses 
car incomplètes, éventuellement corrigées quand la note sera traitée, et sans 
gain de temps.
Pour le 4 l'intégration auto des autres champs obligerait à des corrections 
après coups lors du traitement de la note, donc perte de temps et données 
fausses qui risquent de se balader.

Donc l'éventuel gain de temps réside dans la proportion de chaque cas, et sa contrepartie 
est la présence de données fausses à corriger (exemple type : opening_hours:covid19=off 
concerne le "commerce d'en face, au 52" et en attendant on a écrasé les 
horaires de la boutique sélectionnée).

Dans les améliorations à méditer pour faciliter la vie des intégrateurs de 
notes, je vois :
- simplifier la saisie des horaires, trop complexe, source de précisions dans 
"détails"
- permettre la reprise/l'édition des valeurs en place : certains commerçants 
refont un signalement pour ajouter un détail, et on se retrouve à comparer tous 
les champs pour trouver la petite modif. Et parfois se trompent dans la 
re-saisie des horaires. Voir on se retrouve avec 2 notes simultanées (moins 
d'une minute), en se demandant quelle version est la bonne :D
- restreindre la taille du champs détails !!! Certains commerçants mettent une 
tartine à résumer pour rentrer dans les 255 caractères permis dans OSM. En 
français c'est déjà du temps, maintenant en allemand en plus je galère :D
- pour gérer ce dernier point, toujours le fait du propriétaire du magasin visé, renvoyer 
les commerçants vers un formulaire exhaustif (ou leur proposer l'alternative) : la 
plupart seront contents d'enrichir les infos sur leur commerce, et ça pourrait inciter 
les autres à prendre plus de temps, par exemple pour entrer les horaires hors covid19). 
Et ils auraient une case "détails commerciaux (255 caractères max)".

Désolé pour la longueur, j'espère au moins que c'est compréhensible :D

Frantz

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


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

Re: [Talk-es] conoces 'MapCyL'?

[José Muñoz]

Hello,

 I'm José, responsible for the development of the MapCyL application; 
This application is used as a critical resource in the Castilla y 
León's forest fire fighting. Due to changes we made in recent months, 
we had incorporated the reverse search function using the Nominatim 
service, and apparently this function is triggered erroneously every 
minute. We are going to proceed to remove this feature on all user's 
devices on an update that we are going to release this week. I 
apologize for all the problems caused.


Best regards,

José Muñoz

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

[Talk-it] Uberto, Umberto

[Cascafico Giovanni]

Come per il Comune di Milano Uberto [1] diventa Umberto:

IDMASTER: 1351
NUMEROCOMPLETO: 16
STATOCIVICO: applicato
TIPO: Via
DENOMINAZIONE:VISCONTI DI MODRONE UBERTO
DESCRITTIVO: UMBERTO VISCONTI DI MODRONE
addr:street (compilato da me): Via Umberto Visconti di Modrone
CAP: 20122
LAT_WGS84: 45.4650791419
LONG_WGS84: 9.200278951

Me l'ha segnalato la mappa di audit [2], marcando come posizionati male i
civici OSM. In realtà i civici ci sono e su Openstreetmap portano
correttamente nell'addr:street "Uberto".

[1] https://it.wikipedia.org/wiki/Uberto_Visconti_di_Modrone
[2] http://audit.osmz.ru/run/MI-addrs/node2269143190
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Ça reste ouvert et notes : avis et retours

[Frantz]

Bonjour,

parmi les cas restant en saisie manuelle, je vois en gros :
1) "détails" contient juste une précision qui pourrait être saisie directement 
dans "description:covid19" (ex : "permanence téléphonique")
2) "détails" contient juste une info simple à intégrer (ex : 
"http://maboutique.fr;, "i...@maboutique.com", "01 23 45 76 89")
3) "détails" contient une correction  de la plage horaire : 
opening_hours:covid19="Mo-Fr 08:00-19:00" et détails "fermé de 12h à 13h.
4) "détails" contient des infos qui annulent toutes les autres données : faux 
signalement, ou commerce déplacé, ou parle du commerce d'à côté

Pour 1 et 2 l'intégration auto de "détails" pourrait se faire mais c'est plus 
un choix politique, savoir si on laisse entrer des données libres sans 
contrôle. L'intégration auto des autres champs ferait gagner du temps.
Pour le 3 l'intégration auto des autres champs ajouterait des données fausses 
car incomplètes, éventuellement corrigées quand la note sera traitée, et sans 
gain de temps.
Pour le 4 l'intégration auto des autres champs obligerait à des corrections 
après coups lors du traitement de la note, donc perte de temps et données 
fausses qui risquent de se balader.

Donc l'éventuel gain de temps réside dans la proportion de chaque cas, et sa 
contrepartie est la présence de données fausses à corriger (exemple type : 
opening_hours:covid19=off concerne le "commerce d'en face, au 52" et en 
attendant on a écrasé les horaires de la boutique sélectionnée).

Dans les améliorations à méditer pour faciliter la vie des intégrateurs de 
notes, je vois :
- simplifier la saisie des horaires, trop complexe, source de précisions dans 
"détails"
- permettre la reprise/l'édition des valeurs en place : certains commerçants 
refont un signalement pour ajouter un détail, et on se retrouve à comparer tous 
les champs pour trouver la petite modif. Et parfois se trompent dans la 
re-saisie des horaires. Voir on se retrouve avec 2 notes simultanées (moins 
d'une minute), en se demandant quelle version est la bonne :D
- restreindre la taille du champs détails !!! Certains commerçants mettent une 
tartine à résumer pour rentrer dans les 255 caractères permis dans OSM. En 
français c'est déjà du temps, maintenant en allemand en plus je galère :D
- pour gérer ce dernier point, toujours le fait du propriétaire du magasin 
visé, renvoyer les commerçants vers un formulaire exhaustif (ou leur proposer 
l'alternative) : la plupart seront contents d'enrichir les infos sur leur 
commerce, et ça pourrait inciter les autres à prendre plus de temps, par 
exemple pour entrer les horaires hors covid19). Et ils auraient une case 
"détails commerciaux (255 caractères max)".

Désolé pour la longueur, j'espère au moins que c'est compréhensible :D

Frantz

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

Re: [Talk-it] Import Farmacie

[Cascafico Giovanni]

Per quel che mi riguarda, pur non avendo la possibilità di andarci di
persona, ho importato dettagli MSAL di una decina di farmacie a Padova [1]
ed una ventina a Treviso [2], ma sempre appoggiandomi ad umap [3], [4] e
dando priorità alle coordinate in OSM o Mapillary. Al moment non ricordo,
ma laddove non c'erano dati geografici attendibili/riscontabili ho
semplicemente saltato.

Insomma: non è un'attività particolarmente complicata, basta prendere il
dataset MSAL con le pinze :-)



[1] http://overpass-turbo.eu/s/SOu
[2] http://overpass-turbo.eu/s/SOt
[3]
http://umap.openstreetmap.fr/it/map/farmacie-padova_435056#13/45.4195/11.8764
[4]
http://umap.openstreetmap.fr/it/map/farmacie-treviso_434815#12/45.6804/12.2408

Il giorno mar 14 apr 2020 alle ore 14:40 Andrea Musuruane <
musur...@gmail.com> ha scritto:

> Ciao a tutti,
> sono un po' perplesso.
>
> Credo sia stato spiegato abbastanza bene, che prendere i dati dal
> ministero della salute e portarli in OSM è un import - indipendentemente
> dallo strumento che si vuole usare - e quindi deve seguire le apposite
> linee guida.
> https://lists.openstreetmap.org/pipermail/imports/2020-March/006227.html
>
> Mi sembra inoltre che la maggior parte della comunità italiana condivida
> il fatto che questi dati non sono dati affidabili:
> https://lists.openstreetmap.org/pipermail/talk-it/2020-April/069329.html
>
> Già questo dovrebbe bastare per fermarsi.
>
> Invece vedo che questo import sta andando avanti e mi piacerebbe sapere
> perché.
> 
> https://www.openstreetmap.org/user/canfe/history
> https://www.openstreetmap.org/user/francians/history
> https://overpass-turbo.eu/s/SOf
>
> Sarebbe anche interessante sapere come sono state posizionate le farmacie,
> perché nella maggior parte dei casi non ci sono immagini Mapillary
> disponibili per una verifica e ovviamente una verifica sul campo non è
> possibile perché siamo tutti in lockdown.
>
> Tra l'altro, sulla prima farmacia che ho controllato, sono stati inseriti
> dei dati errati:
> https://www.openstreetmap.org/node/7082514124#map=17/45.34317/8.17588
>
> Grazie,
>
> Andrea
>
> ___
> 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-it] pipeline sotteranee senza layer=-1

[Martin Koppenhoefer]

sent from a phone

> On 14. Apr 2020, at 11:36, Volker Schmidt  wrote:
> 
> PS: ci sono 367  ways  con "man_made=pipeline" e "location=underground" e 
> "layer=-1" in Italia e 1168 in Germania, quindi i concetti di base non sono 
> chiari a tanti mappatori.


per me layer=-1 non è un problema, volevo semplicemente dire che non indica 
“sotto terra”

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

Re: [Talk-it] [Milano] Esercizi con consegna a domicilio

[Cascafico Giovanni]

Sulla qualità dei dati ds959 ho individuato un problema [1] che
potenzialmente potrebbe riguardare altri PDI.

In questa [1] zona, il pin in alto a sinistra è stato geocodificato dal
comune sulla strada "Bastioni di Porta Volta" al civico 5, mentre il campo
indirizzo contiene sì il civico 5 ma di "Via Volta". Nella realtà [2] in
"Bastioni di Porta Volta" non sembra esserci tale latteria-salumificio,
mentre in Via Volta, per quel poco che si vede [3] sembra essserci una
latteria.

Forse dovremmo considerare un geocoding autonomo, se vogliamo portare
avanti queso piccolo import.



[1]
http://umap.openstreetmap.fr/en/map/milano-esercizi-che-fanno-consegne_443267#18/45.47972/9.18385
[2] https://www.mapillary.com/app/?lat=45.480217=9.182359=16
[3] https://www.mapillary.com/map/im/lVhjhZqIXfXSJJxZcYarBQ

Il giorno sab 11 apr 2020 alle ore 09:43 Cascafico Giovanni <
cascaf...@gmail.com> ha scritto:

> Nel frattempo che si liberi il dataset ds959 ho preparato una umap [1]
> così potete valutare dati ed il lavoro.
>
> Ho cercato velocemente di sistemare con openrefine, ma purtroppo, come
> ogni dato non ben strutturato, i campi della tipologia ed orari hanno
> bisogno di interventi manuali.
> Comunque, visto il numero limitato di record, un import manuale condiviso
> non prenderà molto.
> Il mio approccio sarà con l'editor Level0.
>
> La umap ha due layer: il dataset ed una query al volo per evidenziare
> quelli fatti (basata su source=ds959).
>
> Al momento non sappiano se la delivery è limitata al periodo di emergenza,
> per cui non saprei se impostare
> delivery=yes
> delivery:covid19=yes
>
>
> Segnalatemi pure in telegram o qui problemi o chiarimenti.
>
>
>
> [1]
> http://umap.openstreetmap.fr/en/map/milano-esercizi-che-fanno-consegne_443267
>
> Il sab 11 apr 2020, 01:57 Alessandro Sarretta <
> alessandro.sarre...@gmail.com> ha scritto:
>
>> Ciao, so che è in corso una richiesta per l'inclusione in OSM e speriamo
>> arrivi una conferma a breve.
>>
>> Ale
>> On 10/04/20 12:25, Andrea Musuruane wrote:
>>
>> No. L'uso dei dati CC-BY 4.0 è problematico:
>> https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/
>>
>> Serve o una liberatoria (tipo questa:
>> https://drive.google.com/file/d/0B3PN5zfbzThqeTdWR1l3SzJVcTg/view 
>> dovrebbe anche esserci una traduzione da qualche parte) oppure un addendum
>> come avevano già fatto per i civici - che però erano rilasciati in CC-BY
>> 2.5 (https://geoportale.comune.milano.it/sit/toponomastica/).
>>
>> Ciao,
>>
>> Andrea
>>
>>
>> On Fri, Apr 10, 2020 at 12:17 PM Cascafico Giovanni 
>> wrote:
>>
>>> E' passata in talk-it sotto altro titolo ("Webinar su OpenStreetMap e il
>>> suo possibile uso durante l'emergenza coronavirus") la pubblicazione [1] da
>>> parte del Comune di Milano di un dataset con 348 record.
>>>
>>> Leggo Licenza CC "open data" e cliccando nei dettagli vengo portato alla
>>> definizione di CC-BY
>>>
>>> Prima di intraprendere una conflation (tra l'altro  un po' difficoltosa,
>>> vista la catalogazione unica "bar-ristorante-tavolacalda-pizzeria"),
>>> possiamo usare questi dati per importare?
>>>
>>>
>>>
>>> [1]
>>> http://dati.comune.milano.it/dataset/ds959-esercizi-di-vicinato-in-sede-fissa-consegna-domicilio
>>> ___
>>> Talk-it mailing list
>>> Talk-it@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-it
>>>
>>
>> ___
>> Talk-it mailing 
>> listTalk-it@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-it
>>
>> ___
>> 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

[Talk-it] Import Farmacie

[Andrea Musuruane]

Ciao a tutti,
sono un po' perplesso.

Credo sia stato spiegato abbastanza bene, che prendere i dati dal ministero
della salute e portarli in OSM è un import - indipendentemente dallo
strumento che si vuole usare - e quindi deve seguire le apposite linee
guida.
https://lists.openstreetmap.org/pipermail/imports/2020-March/006227.html

Mi sembra inoltre che la maggior parte della comunità italiana condivida il
fatto che questi dati non sono dati affidabili:
https://lists.openstreetmap.org/pipermail/talk-it/2020-April/069329.html

Già questo dovrebbe bastare per fermarsi.

Invece vedo che questo import sta andando avanti e mi piacerebbe sapere
perché.

https://www.openstreetmap.org/user/canfe/history
https://www.openstreetmap.org/user/francians/history
https://overpass-turbo.eu/s/SOf

Sarebbe anche interessante sapere come sono state posizionate le farmacie,
perché nella maggior parte dei casi non ci sono immagini Mapillary
disponibili per una verifica e ovviamente una verifica sul campo non è
possibile perché siamo tutti in lockdown.

Tra l'altro, sulla prima farmacia che ho controllato, sono stati inseriti
dei dati errati:
https://www.openstreetmap.org/node/7082514124#map=17/45.34317/8.17588

Grazie,

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

Re: [OSM-talk-fr] Ça reste ouvert et notes : avis et retours

[Nicolas Bétheuil]

Quand la contribution directe à été ajoutée plutôt que les notes, j'ai
trouvé ça top.
Maintenant, j'ai du mal à voir ce qu'il resterait à mettre dans la note.
Il m'est arrivé d'abandonner un signalement dans çaresteouvert mais plus
pour des problèmes d'usage : décaler une heure d'ouverture, en format OSM
c'est simple, en format où il y a une ligne par jour, beaucoup moins. Du
coup j'ai fait une photo que j'ai traité en rentrant.

Le mar. 14 avr. 2020 à 13:22, PanierAvide  a écrit :

> Effectivement, tout ce qui peut être retranscrit sous forme de tags est
> déjà affiché dans la note (opening_hours:covid19, delivery:covid19,
> takeaway:covid19) avec la syntaxe key=value. Ça fonctionne dans JOSM et
> iD (si le champ de tags est basculé en mode "plein texte"/textarea).
> Pour ce qui est d'aller plus loin sur la contribution directe, je
> partage ton avis, mais j'ai eu également des retours contraires. D'où
> l'idée d'avoir plus de retours pour qu'on soit fixé ;-)
>
> Adrien P.
>
> Le 14/04/2020 à 13:05, Yves P. a écrit :
> > Si la note contient aussi les données formatter, le contributeur peut
> > faire un copier/coller dans JOSM ou iD.
>
> ___
> 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-hr] Grad Knin i tasking manager za građevine

[Hrvoje Bogner]

https://osm-hr.org/2020/04/14/grad-knin-i-tasking-manager-za-gradevine/

Vrijeme je da organizirano iskoristimo već spomenuti Digitalni ortofoto 
Grada Knina 
.


Keriran je zadatak označavanja građevina 
 na području pokrivenom tim zračnim 
snimkama. Snimke su rezolucije 20cm ali su iz 2007. godine. Zbog toga ih 
je potrebno usporediti sa novijim DGU snimkama rezolucije 50cm, te ako 
nema promjena građevina koristiti starije ali detaljnije snimke.


Uputstva za označavanje nalaze se u opisu zadatka.

Prošli zadatak označavanja rtova  
počeo je sa 429 rtova, te smo došli na 1736 rtova u OSM bazi što je 
ogroman pomak. Odrađeno je 100%, ali je validirano samo 15% do sad, te 
se nadamo 100% validacije u skoro vrijeme.
Taj poduhvat ne bi bio moguć bez OSM korisnika koji su sudjelovali u 
označavanju i validaciji, te im se ovim putem i zahvaljujemo, a to su:

Ivan Habunek , simulator1, north79, jhabijan, Janjko, te debeli75

Sretno mapiranje.

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

Re: [OSM-talk] Overpass API version 0.7.56

[Dave F via talk]

Thanks for the expansion of Type Shortcuts. It's going to save a lot of 
typing, especially with 'count'.


DaveF

On 14/04/2020 06:09, Roland Olbricht wrote:

Dear all,

I'm back with providing updates. After more than a year I'm proud to
present a new release. This release provides some smaller new features.

It is possible to use _angle()_ to filter ways by the angles of their
inner vertices. This way, you can find e.g. non-rectangular buildings or
unintended whiskers.
https://dev.overpass-api.de/blog/total_0_7_56.html#angle

A recurse can now be restricted by the relative position of the entry in
the object. I.e. you can obtain only the first or only the last node of
a way.
https://dev.overpass-api.de/blog/total_0_7_56.html#memberpos

The idea of _nwr_ has been extended both to variants _nw_, _wr_, and
_nr_. And it is now possible with the count evaluator as well.
https://dev.overpass-api.de/blog/total_0_7_56.html#type_shortcuts

For the users of own instances, queries can now be passed by the command
line parameter _--request=_ as well.

Two larger features have been hold back because they break the database
layout, and I do not want to do that too often: support for large
objects (which are necessary to have Antarctica as an area) and a
reoriganization of access to attribution data (changeset ids, user ids,
user names). I intend to bundle them with the necessary changes to use
ways and relations directly as areas,
but that is not implemented yet.

Best regards,

Roland

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



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

Re: [OSM-talk-fr] Données produits-locaux.bzh (et le sud-ouest aussi)

[PanierAvide]

+1 pour madada.fr, même si techniquement la question de la propriété 
individuelle des contributions a du sens, rien ne semble créditer les 
auteurs originels des informations affichées. Les mentions légales 
indiquent que c'est bien la région et l'asso www.bzh qui sont 
propriétaires des informations (cession de droits par les contributeurs 
?). Donc ça ressemble plus à du bottage en touche qu'une vraie politique 
de droits individualisés :-)


Adrien P.

Le 14/04/2020 à 12:55, Vincent Bergeot a écrit :

Bonjour,
c'est mis en place par la même boite aussi ici 
https://plateforme.produits-locaux-nouvelle-aquitaine.fr/
Pour avoir échangé avec eux, le problème viendrait du fait que les 
points sont créés directement par les producteurs. Ces producteurs, 
lorsqu'ils créent leur compte, n'ont pas d'information claire sur le 
fait que les données qu'ils saisissent peuvent être utilisées ailleurs 
que sur ces sites.



Le 14/04/2020 à 10:13, PanierAvide a écrit :
Hmm, site et données édités par une collectivité territoriale (payé 
avec des deniers publics ?) -> document administratif ? contraint 
d'être publié sous licence ouverte ? Ça simplifierai pas mal la 
question...



c'est ce que j'ai évoqué aussi mais mais ce n'est pas la collectivité 
qui a "créée" cette donnée. J'essaie de refaire une passe demain avec 
l'agence régionale et non la boite qui a mis en place le site.


Peut-être faut-il une demande madada.fr ?

à plus








Adrien P.
Le 14/04/2020 à 09:51, Nicolas Bétheuil a écrit :

MDR ! Mais pourquoi les mettre en ligne alors ?
Ça mériterais un petit bashing sur la place publique.

Le mar. 14 avr. 2020 à 09:22, GarenKreiz > a écrit :


Petite perle détectée dans les mentions légales : "Les visiteurs
du site Internet s’interdisent ... l’utilisation, des
informations auxquelles ils ont accès". Alors que l'objectif
même du site est d'utiliser leurs informations pour établir des
contacts entre producteurs et consommateurs!



On Tue, 14 Apr 2020 at 08:50, Yann-Gaël LARGILLET
mailto:yglargil...@lilo.org>> wrote:

Salut à tous, j'ai contacté la Région Bretagne pour savoir
si on pouvait récupérer leurs données concernant le site
produits-locaux.bzh  afin
d'alimenter OSM et in fine çaresteouvert.fr
, mais malheureusement, leur
réponse a été assez simple en disant d'aller voir les
mentions légales (ce que j'aurais pu faire avant) :
https://www.produits-locaux.bzh/mentions-legales/

Si quelqu'un peut confirmer que la réutilisation de leurs
données est clairement impossible ?


Merci d'avance,

Cordialement,

Yann-Gaël

-- 
"Lentius, Profundius, Suavius" (A.Langer)

___
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



--
Vincent Bergeot

___
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] Ça reste ouvert et notes : avis et retours

[PanierAvide]

Effectivement, tout ce qui peut être retranscrit sous forme de tags est 
déjà affiché dans la note (opening_hours:covid19, delivery:covid19, 
takeaway:covid19) avec la syntaxe key=value. Ça fonctionne dans JOSM et 
iD (si le champ de tags est basculé en mode "plein texte"/textarea). 
Pour ce qui est d'aller plus loin sur la contribution directe, je 
partage ton avis, mais j'ai eu également des retours contraires. D'où 
l'idée d'avoir plus de retours pour qu'on soit fixé ;-)


Adrien P.

Le 14/04/2020 à 13:05, Yves P. a écrit :
Si la note contient aussi les données formatter, le contributeur peut 
faire un copier/coller dans JOSM ou iD. 


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

Re: [OSM-talk-fr] Ça reste ouvert et notes : avis et retours

[Yves P.]

> Ainsi, nous aimerions avoir des retours d'expérience des personnes ayant 
> contribué à la résolution des notes : envoyer les changements directement à 
> OSM en parallèle de la note vous aurait-il aidé à aller plus vite ?

Ça fait 2 changesets pour un seul signalement.

Si la note contient aussi les données formatter, le contributeur peut faire un 
copier/coller dans JOSM ou iD.

__
Yves



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

Re: [OSM-talk-fr] Données produits-locaux.bzh (et le sud-ouest aussi)

[Vincent Bergeot]

Bonjour,
c'est mis en place par la même boite aussi ici 
https://plateforme.produits-locaux-nouvelle-aquitaine.fr/
Pour avoir échangé avec eux, le problème viendrait du fait que les 
points sont créés directement par les producteurs. Ces producteurs, 
lorsqu'ils créent leur compte, n'ont pas d'information claire sur le 
fait que les données qu'ils saisissent peuvent être utilisées ailleurs 
que sur ces sites.



Le 14/04/2020 à 10:13, PanierAvide a écrit :
Hmm, site et données édités par une collectivité territoriale (payé 
avec des deniers publics ?) -> document administratif ? contraint 
d'être publié sous licence ouverte ? Ça simplifierai pas mal la 
question...



c'est ce que j'ai évoqué aussi mais mais ce n'est pas la collectivité 
qui a "créée" cette donnée. J'essaie de refaire une passe demain avec 
l'agence régionale et non la boite qui a mis en place le site.


Peut-être faut-il une demande madada.fr ?

à plus








Adrien P.
Le 14/04/2020 à 09:51, Nicolas Bétheuil a écrit :

MDR ! Mais pourquoi les mettre en ligne alors ?
Ça mériterais un petit bashing sur la place publique.

Le mar. 14 avr. 2020 à 09:22, GarenKreiz > a écrit :


Petite perle détectée dans les mentions légales : "Les visiteurs
du site Internet s’interdisent ... l’utilisation, des
informations auxquelles ils ont accès". Alors que l'objectif même
du site est d'utiliser leurs informations pour établir des
contacts entre producteurs et consommateurs!



On Tue, 14 Apr 2020 at 08:50, Yann-Gaël LARGILLET
mailto:yglargil...@lilo.org>> wrote:

Salut à tous, j'ai contacté la Région Bretagne pour savoir si
on pouvait récupérer leurs données concernant le site
produits-locaux.bzh  afin
d'alimenter OSM et in fine çaresteouvert.fr
, mais malheureusement, leur
réponse a été assez simple en disant d'aller voir les
mentions légales (ce que j'aurais pu faire avant) :
https://www.produits-locaux.bzh/mentions-legales/

Si quelqu'un peut confirmer que la réutilisation de leurs
données est clairement impossible ?


Merci d'avance,

Cordialement,

Yann-Gaël

-- 
"Lentius, Profundius, Suavius" (A.Langer)

___
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



--
Vincent Bergeot

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

[OSM-talk-fr] Ça reste ouvert et notes : avis et retours

[PanierAvide]

Bonjour à tous,

Comme vous le savez, l'outil "Ça reste ouvert" s'appuie sur les notes 
OpenStreetMap pour enregistrer une partie des retours faits via le site. 
Depuis quelques temps, la contribution se fait en édition directe 
d'OpenStreetMap si aucun commentaire n'est ajouté par les utilisateurs 
(champ "détails" en fin de formulaire). Cela a permis de faire tomber le 
nombre de notes ouvertes à 25% du total des contributions reçues.


Afin de faciliter la tâche aux contributeurs, en particulier dans les 
pays sur lesquels le service a ou va être déployé, une suggestion est 
faite de cumuler contribution directe + note OSM si des détails sont 
fournis : https://github.com/osmontrouge/caresteouvert_backend/issues/20


Ainsi, nous aimerions avoir des retours d'expérience des personnes ayant 
contribué à la résolution des notes : envoyer les changements 
directement à OSM en parallèle de la note vous aurait-il aidé à aller 
plus vite ? Pensez-vous que cela ne doit concerner que les lieux notés 
comme ouvert pendant le confinement ? Nous sommes preneurs de vos 
retours :-)


Cordialement,

--
Adrien P.


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

[OSRM-talk] Need help: Customizing weights in Profile shows inconsistent results with Dijsktra

[Niharika Shrivastava]

Hello, I'm new to OSRM and I went through previous issues and couldn't find
much related to this, hence posting it here.

I had used a python library OSMnx to extract Singapore's data and changed
certain edge attributes for it. I calculated an edge attribute `"BPR"`
(float) and stored it in the graph (This is travel time in case of real
traffic data). I then converted this modified graph into a shapefile and
then converted the shapefile into OSM XML using JOSM. I fed this to OSRM in
order to use CH. I want to find the shortest route between two points
wherein my weights (or cost) are the BPR value I had calculated. I
understand I have to specify that in the car profile. This is how I
specified it:

```
function setup()
  return {
properties = {
  ...
  weight_name = 'congestion',
  ...
},
  ...
}


function process_way(profile, way, result, relations)
  local data = {
-- prefetch tags
...
BPR = way:get_value_by_key('BPR')
  }

  result.weight = data.BPR
  ...
}
```

This is the JSON response I get for a certain query:
```
{'code': 'Ok',
 'routes': [{'geometry': 's}gG{ijyReEnNdm@|Wpl@~}@b\\lfAw\\twAbFjt@wM
`ZwSpAGnNgN|Dvm@fWwHhb@bErz@qFxeAzVfkAfr@b{Ak_@rr@ocA~dAgCda@ji@dz@`j@di
@`Sfi@PfQcRpc@ySyCgw@~XjEx]dHDkEl\\ju@lf@ii@n}@oVqEiKlR_Elw@bJd[lc@wFdKf[',
   'legs': [{'steps': [],
 'distance': 32298.2,
 'duration': 2308.4,
 'summary': '',
 'weight': 2179.6}],
   'distance': 32298.2,
   'duration': 2308.4,
   'weight_name': 'congestion',
   'weight': 2179.6}],
 'waypoints': [{'hint':
'YwYBgG8GAYALAQAAHN-XQWpx4j0AAA0BAAAJyOIxBiSzFADI4jEGJLMUzwFqJcKJ',
   'distance': 0,
   'name': 'Tampines Avenue 8',
   'location': [103.932616, 1.35658]},
  {'hint':
'EAYBgBcGAYAUPzfZQQAAABkJ6oIuBlR3FADqgi4GVHcULwpqJcKJ',
   'distance': 0,
   'name': 'Boon Lay Drive',
   'location': [103.711466, 1.341268]}]}
```

Looking at this part from the JSON:
 ```
 'duration': 2308.4,
  'weight': 2179.6}],
```
As I understand, weight is the summation of BPR values for each edge.
Duration is estimated free flow time:` length/max_speed for each edge`. The
`value of weight should be >= duration` which is true when I use Dijkstra
for routing using edge weights as BPR value (`3155.27`). But over here,
thats not the case.

BPR = duration*(some delay based on traffic) >= duration in case of no
traffic

Can someone please point out if my Profile is wrongly written or if I've
missed any steps?
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [Talk-it] pipeline sotteranee senza layer=-1

[Volker Schmidt]

>
> Comunque, quando ci sono più elementi allo stesso punto ma su altezze
> diverse, è necessario indicare l’ordine con un tag layer, a prescindere
> della presenza del tag location.
>

Salvo nei casi, come quello che avevo incontrato (per puro caso), dove due
condotte di acqua sotterranee si incrociano (secondo i dati importati) e
non si sa quale è sopra.
Ma in realtà è una cosa rara e possiamo lasciare la decisione a futuri
archeologi industriali.

PS: ci sono 367  ways  con "man_made=pipeline" e "location=underground" e
"layer=-1" in Italia e 1168 in Germania, quindi i concetti di base non sono
chiari a tanti mappatori.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] pipeline sotteranee senza layer=-1

[Martin Koppenhoefer]

sent from a phone

> On 13. Apr 2020, at 15:30, Volker Schmidt  wrote:
> 
> Dice solo che location=* e layer=* sono due concetti diversi:
> location descrive la posizione relativa alla superficie del terreno
> layer è una posizione relativa che serve solo al rendere


+1, layer serve a definire l’ordine verticale degli elementi (solo in caso ci 
sono più oggetti allo stesso punto il tag da significato, e solo in confronto 
ad altri elementi ed i loro layer). Un pipeline potrebbe avere un tag layer=3 e 
stare sotto terra, non c’è contraddizione. Comunque, quando ci sono più 
elementi allo stesso punto ma su altezze diverse, è necessario indicare 
l’ordine con un tag layer, a prescindere della presenza del tag location.

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

Re: [Talk-it] Traduzione dei place

[Martin Koppenhoefer]

sent from a phone

> On 12. Apr 2020, at 23:57, totera  wrote:
> 
> Anche il limite di abitanti è oscillato nel tempo, prima di 200 era 100,
> quando abbiamo importato le località abitate con il tool GFOSS veniva usato
> village soltanto per quelle con più di 1000 abitanti.


si, il limite di abitanti è indicativo, ma in fine dei conti non è decisivo, 
quello che interessa è la struttura (servizi presenti, ruolo storico culturale, 
ecc.)
Questo si è evoluto con il tempo, perché si è riflettuto di più sul tema della 
classificazione dei centri abitati.
(C’è ovviamente in genere anche una correlazione tra servizi presenti, 
importanza relativa e numero di abitanti).



> 
> Problema quartieri: all'inizio esisteva soltanto suburb e molti di noi che
> hanno inserito i quartieri tanto tempo fa lo hanno usato perché non c'era
> altra scelta, poi sono stati introdotti neighbourhood e quarter.


si, potrebbe convenire di rivedere questi place=suburb non modificati da oltre 
10 anni


> Prima della traduzione però, abbiamo ben chiaro il criterio con cui usare la
> gerarchia suburb/quarter/neighbourhood?


in che senso? Più o meno potrebbe essere così: quarter per le parti di 
cittadine, neighbourhood per le parti di quarter (o al meno per parti di 
cittadine significativamente più piccole di quarter) e in generale per le parti 
più piccole dei centri abitati.

suburb per le parti più grandi. Per esempio a Roma ho usato place=suburb per i 
Quartieri (iniziato ad usare): https://www.openstreetmap.org/relation/5460386
In questo caso si tratta di un’area con decine di migliaia di abitanti, e si 
tratta di un quartiere toponomastico (limiti ben definiti) ufficiale, cosa non 
sarebbe necessario.
Dentro questo suburb si trovano alcuni place=quarter come San Paolo, 
Garbatella, e loro sono a loro volta suddivisibili (per esempio zone che 
prendono il nome da una piazza)

Mentre le aree amministrative sono sempre ben definite e perfettamente 
coincidenti (quasi sempre) (intendo dire che per ogni livello amministrativo, 
tutto il territorio è suddiviso in maniera che tutto è coperto, e solo una 
volta/da un ente, salvo eccezioni chaotiche, dispute di confini ecc.), le aree 
toponomastiche possono anche sovraporrsi.

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

Re: [Talk-es] Plazo Re: sigueabierto.openstreetmap.es -> (www.)sigueabierto.es ¿¿OK?? [was:] Re: Mapa COVID19

[Jordi Miró Ferrer]

Hola,
Yo no veo ningún problema en que sea sigueabierto.es. De hecho, me gusta más. 
Creo que es más "usable" y fácil de compartir.
Saludos.


De: Jean-Baptiste Richard 
Enviat el: dimarts, 14 d’abril de 2020 8:31
Per a: Discusión en Español de OpenStreetMap 
Tema: Re: [Talk-es] Plazo Re: sigueabierto.openstreetmap.es -> 
(www.)sigueabierto.es ¿¿OK?? [was:] Re: Mapa COVID19

Hola,
PD: sólo aclarar que a pesar del plazo de dos días, si alguien quiere opinar 
(bienvenido está), cuanto antes mejor, de cara a reconsiderar planes según haga 
falta.

S2

Best regards / Cordialement / Un saludo / Mit freundlichen Grüßen / Kenavo,
Jean-Baptiste Richard

--
Sent from mobile. Please excuse my brevity, and typos if any.


From: Jean-Baptiste Richard 
Sent: 14 April 2020 00:21:30 CEST
To: "Discusión en Español de OpenStreetMap" 
Subject: [Talk-es] Plazo Re: sigueabierto.openstreetmap.es -> 
(www.)sigueabierto.es ¿¿OK?? [was:] Re: Mapa COVID19

Hola todxs,

Para poder cerrar el asunto:
Si alguien tiene comentarios, por fa que lo comenté antes del jueves por la 
mañana. Ese día actuaremos en consecuencias, si no es que haya arrancado un 
debate que no se haya cerrado para entonces.

Salud y mapa,

Best regards / Cordialement / Un saludo / Mit freundlichen Grüßen / Kenavo,
Jean-Baptiste Richard

--
Sent from mobile. Please excuse my brevity, and typos if any.


From: "in...@jeanbaptisterichard.eu" 
Sent: 13 April 2020 01:43:40 CEST
To: "Discusión en Español de OpenStreetMap" 
Subject: [Talk-es] sigueabierto.openstreetmap.es?==?utf-8?q? -> 
(www.)sigueabierto.es?==?utf-8?q? ¿¿OK?? [was:]?==?utf-8?q? Re:?==?utf-8?q? 
Mapa COVID19

Hola todxs,

Cómo mencionado antes, lo gordo de la conversación sobre el desarollo hacia el 
publico español de la initiativa originalmente nombrada "ça reste ouvert", se 
ha apartado en el chat telegram/riot de openstreetmap España.

Sin embargo hay un tema que, aún que allí esté consensuado ente l@s quienes 
opinamos al respecto, hemos hablado de consultar aquí ya que es el medio de 
comunicación oficial, por si alguén más quiere opinar.

Antes de confirmar, pido que si alguién pone en duda el tema, que se manifeste 
lo antes posible y hablamos según haga falta. No sé que plazo poner (24h?), 
pero es el punto que ahora pone en pausa el empezar pasar el proyecto a su 
dominio dedicado, lo cual a su vez entiendo que es un paso previo importante 
para dinamizar la comunicación externa sobre la iniciativa. Y aún que de cara 
al publico español hayan cosas mejorables todavía (siempre las hay), la 
herramienta probablemente ya tiene bastante buena pinta cómo para, menos esto, 
empezar a difundir ya o dentro de muy poco.

El tema es que, en la hypothesis de que vayamos a usar el dominio 
sigueabierto.es (en principio, bajo su subdominio www), el mapa ya no podrá 
aparecer bajo la url "sigueabierto.openstreetmap.es". Eso, debido a que los 
gestores de la estructura global han puesto cómo regla de sólo habilitar un 
dominio por idioma (que ya es bastante complicado así).

No nos malentendemos:
-> para retrocompatibiliad, las urls basadas en 
"sigueabierto.openstreetmap.es/*", estarían redirigidas hacía lo 
"[www.]sigueabierto.es/*" correspondiente.
-> les he pedido que haya un periodo de transición, es decir, en resumen, que 
esa redirección sólo se habilite una vez comprobado que [www.]sigueabierto.es 
funccione todo OK.

¿Alguien le ve alguna traba? Si eso por fa manifestarse.

Y por supuesto, los demás quienes estáis metidos en el proyecto (Yopaseopor, 
Juanjo, Alejandro, Jmontane, ... ¿olvido a alguién?), si os parece oportuno 
aportar cualquier aclaración, según veais. Por mí, sin problema.

¡Gracias por la atención!

Jean-Baptiste

El Sábado, Abril 11, 2020 17:04 CEST, in...@jeanbaptisterichard.eu 
 Ha escrito:


Resumen de la situación actual, ya que después de este correo se ha hablado por 
el chat de telegram:

- droguerias (shop=chemist) añadidas
- logos en castellano, catalá, gallego, hechos (por el equipo francés con 
inputs de las comunidades respectivas) y pendiente publicar
- dominio sigueabierto.es alquilado para un año, redirección pendiente.

Saludos

El Viernes, Abril 10, 2020 22:03 CEST, in...@jeanbaptisterichard.eu 
 Ha escrito:


Hola otra vez,

- veo que "shop=chemist" falta en la lista en github y por tanto no aparecen en 
la página  (correspondiendo a "productos  higiénicos", linea 4 del punto 2 del 
Anexo del BOE). Lo iba a comentar en el hilo de github pero mejor comentarlo 
primero aquí. ¿Les pedimos que lo añadan?

- ¿Se ha considerado alquilar el dominio "sigueabierto.es", u otro tld? (Para 
tener una dirección más user-friendly y más fácil de comunicar a prensa, en 
tweets, etc.)

- respecto a mi pregunta "¿Se ha automatizado parte del trabajo?", veo que al 
mismo tiempo que escribía, han publicado un nuevo billete en el blog de 
caresteouvert.fr, "Contribuidores de 

Re: [OSM-talk-fr] Données produits-locaux.bzh

[PanierAvide]

Hmm, site et données édités par une collectivité territoriale (payé avec 
des deniers publics ?) -> document administratif ? contraint d'être 
publié sous licence ouverte ? Ça simplifierai pas mal la question...


Adrien P.

Le 14/04/2020 à 09:51, Nicolas Bétheuil a écrit :

MDR ! Mais pourquoi les mettre en ligne alors ?
Ça mériterais un petit bashing sur la place publique.

Le mar. 14 avr. 2020 à 09:22, GarenKreiz > a écrit :


Petite perle détectée dans les mentions légales : "Les visiteurs
du site Internet s’interdisent ... l’utilisation, des informations
auxquelles ils ont accès". Alors que l'objectif même du site est
d'utiliser leurs informations pour établir des contacts entre
producteurs et consommateurs!



On Tue, 14 Apr 2020 at 08:50, Yann-Gaël LARGILLET
mailto:yglargil...@lilo.org>> wrote:

Salut à tous, j'ai contacté la Région Bretagne pour savoir si
on pouvait récupérer leurs données concernant le site
produits-locaux.bzh  afin
d'alimenter OSM et in fine çaresteouvert.fr
, mais malheureusement, leur
réponse a été assez simple en disant d'aller voir les mentions
légales (ce que j'aurais pu faire avant) :
https://www.produits-locaux.bzh/mentions-legales/

Si quelqu'un peut confirmer que la réutilisation de leurs
données est clairement impossible ?


Merci d'avance,

Cordialement,

Yann-Gaël

-- 
"Lentius, Profundius, Suavius" (A.Langer)

___
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] Données produits-locaux.bzh

[Nicolas Bétheuil]

MDR ! Mais pourquoi les mettre en ligne alors ?
Ça mériterais un petit bashing sur la place publique.

Le mar. 14 avr. 2020 à 09:22, GarenKreiz  a écrit :

> Petite perle détectée dans les mentions légales : "Les visiteurs du site
> Internet s’interdisent ... l’utilisation, des informations auxquelles ils
> ont accès". Alors que l'objectif même du site est d'utiliser leurs
> informations pour établir des contacts entre producteurs et consommateurs!
>
>
>
> On Tue, 14 Apr 2020 at 08:50, Yann-Gaël LARGILLET 
> wrote:
>
>> Salut à tous, j'ai contacté la Région Bretagne pour savoir si on pouvait
>> récupérer leurs données concernant le site produits-locaux.bzh
>>  afin d'alimenter OSM et in fine
>> çaresteouvert.fr , mais malheureusement,
>> leur réponse a été assez simple en disant d'aller voir les mentions légales
>> (ce que j'aurais pu faire avant) :
>> https://www.produits-locaux.bzh/mentions-legales/
>>
>> Si quelqu'un peut confirmer que la réutilisation de leurs données est
>> clairement impossible ?
>>
>>
>> Merci d'avance,
>>
>> Cordialement,
>>
>> Yann-Gaël
>> --
>> "Lentius, Profundius, Suavius" (A.Langer)
>> ___
>> 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] Données produits-locaux.bzh

[Yves P.]

Bonjour,

Le site  indique Icci, 
le fond de carte OSM Kericci ;)

Tiens, il y a des doublons ?
https://www.caresteouvert.fr/@48.407545,-4.459084,19.69
https://www.openstreetmap.org/node/4482887573
https://www.openstreetmap.org/way/42521461

Un coup de Maproulette ?

__
Yves

PS: c'est le noeud qui s'appelait Kericci. Il fallait peut-être garder la 
valeur en name:br ou loc_name ?

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

Re: [OSM-talk-fr] [Edition mécanique] virer contact:google_plus et *~plus.google.com

[Stéphane Péneau]

Le 14/04/2020 à 00:41, Marc M. a écrit :

avis ? objection ?


Go !



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

Re: [OSM-talk-fr] Données produits-locaux.bzh

[GarenKreiz]

Petite perle détectée dans les mentions légales : "Les visiteurs du site
Internet s’interdisent ... l’utilisation, des informations auxquelles ils
ont accès". Alors que l'objectif même du site est d'utiliser leurs
informations pour établir des contacts entre producteurs et consommateurs!



On Tue, 14 Apr 2020 at 08:50, Yann-Gaël LARGILLET 
wrote:

> Salut à tous, j'ai contacté la Région Bretagne pour savoir si on pouvait
> récupérer leurs données concernant le site produits-locaux.bzh
>  afin d'alimenter OSM et in fine
> çaresteouvert.fr , mais malheureusement,
> leur réponse a été assez simple en disant d'aller voir les mentions légales
> (ce que j'aurais pu faire avant) :
> https://www.produits-locaux.bzh/mentions-legales/
>
> Si quelqu'un peut confirmer que la réutilisation de leurs données est
> clairement impossible ?
>
>
> Merci d'avance,
>
> Cordialement,
>
> Yann-Gaël
> --
> "Lentius, Profundius, Suavius" (A.Langer)
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Données produits-locaux.bzh

[Yann-Gaël LARGILLET]

Salut à tous, j'ai contacté la Région Bretagne pour savoir si on pouvait
récupérer leurs données concernant le site produits-locaux.bzh [1] afin
d'alimenter OSM et in fine çaresteouvert.fr, mais malheureusement, leur
réponse a été assez simple en disant d'aller voir les mentions légales
(ce que j'aurais pu faire avant) :
https://www.produits-locaux.bzh/mentions-legales/ 

Si quelqu'un peut confirmer que la réutilisation de leurs données est
clairement impossible ? 

Merci d'avance, 

Cordialement, 

Yann-Gaël

-- 
"Lentius, Profundius, Suavius" (A.Langer) 

Links:
--
[1] https://www.produits-locaux.bzh/___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-us] Whole-US Garmin Map update - 2020-04-11

[Dave Hansen]

These are based off of Lambertus's work here:

http://garmin.openstreetmap.nl

If you have questions or comments about these maps, please feel
free to ask.  However, please do not send me private mail.  The
odds are, someone else will have the same questions, and by
asking on the talk-us@ list, others can benefit.

Downloads:

http://daveh.dev.openstreetmap.org/garmin/Lambertus/2020-04-11

Map to visualize what each file contains:


http://daveh.dev.openstreetmap.org/garmin/Lambertus/2020-04-11/kml/kml.html


FAQ



Why did you do this?

I wrote scripts to joined them myself to lessen the impact
of doing a large join on Lambertus's server.  I've also
cut them in large longitude swaths that should fit conveniently
on removable media.  

http://daveh.dev.openstreetmap.org/garmin/Lambertus/2020-04-11

Can or should I seed the torrents?

Yes!!  If you use the .torrent files, please seed.  That web
server is in the UK, and it helps to have some peers on this
side of the Atlantic.

Why is my map missing small rectangular areas?

There have been some missing tiles from Lambertus's map (the
red rectangles),  I don't see any at the moment, so you may
want to update if you had issues with the last set.

Why can I not copy the large files to my new SD card?

If you buy a new card (especially SDHC), some are FAT16 from
the factory.  I had to reformat it to let me create a >2GB
file.

Does your map cover Mexico/Canada?

Yes!!  I have, for the purposes of this map, annexed Ontario
in to the USA.  Some areas of North America that are close
to the US also just happen to get pulled in to these maps.
This might not happen forever, and if you would like your
non-US area to get included, let me know. 

-- Dave


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

Re: [Talk-es] Plazo Re: sigueabierto.openstreetmap.es -> (www.)sigueabierto.es ¿¿OK?? [was:] Re: Mapa COVID19

[Jean-Baptiste Richard]

Hola,
PD: sólo aclarar que a pesar del plazo de dos días, si alguien quiere opinar 
(bienvenido está), cuanto antes mejor, de cara a reconsiderar planes según haga 
falta.

S2

Best regards / Cordialement / Un saludo / Mit freundlichen Grüßen / Kenavo,
Jean-Baptiste Richard

-- 
Sent from mobile. Please excuse my brevity, and typos if any.


 Original Message 
From: Jean-Baptiste Richard 
Sent: 14 April 2020 00:21:30 CEST
To: "Discusión en Español de OpenStreetMap" 
Subject: [Talk-es] Plazo Re:  sigueabierto.openstreetmap.es -> 
(www.)sigueabierto.es ¿¿OK?? [was:] Re:  Mapa COVID19

Hola todxs,

Para poder cerrar el asunto:
Si alguien tiene comentarios, por fa que lo comenté antes del jueves por la 
mañana. Ese día actuaremos en consecuencias, si no es que haya arrancado un 
debate que no se haya cerrado para entonces.

Salud y mapa,

Best regards / Cordialement / Un saludo / Mit freundlichen Grüßen / Kenavo,
Jean-Baptiste Richard

-- 
Sent from mobile. Please excuse my brevity, and typos if any.


 Original Message 
From: "in...@jeanbaptisterichard.eu" 
Sent: 13 April 2020 01:43:40 CEST
To: "Discusión en Español de OpenStreetMap" 
Subject: [Talk-es] sigueabierto.openstreetmap.es?==?utf-8?q? -> 
(www.)sigueabierto.es?==?utf-8?q? ¿¿OK?? [was:]?==?utf-8?q? Re:?==?utf-8?q?  
Mapa COVID19


Hola todxs,

Cómo mencionado antes, lo gordo de la conversación sobre el desarollo hacia el 
publico español de la initiativa originalmente nombrada "ça reste ouvert", se 
ha apartado en el chat telegram/riot de openstreetmap España.

Sin embargo hay un tema que, aún que allí esté consensuado ente l@s quienes 
opinamos al respecto, hemos hablado de consultar aquí ya que es el medio de 
comunicación oficial, por si alguén más quiere opinar.

Antes de confirmar, pido que si alguién pone en duda el tema, que se manifeste 
lo antes posible y hablamos según haga falta. No sé que plazo poner (24h?), 
pero es el punto que ahora pone en pausa el empezar pasar el proyecto a su 
dominio dedicado, lo cual a su vez entiendo que es un paso previo importante 
para dinamizar la comunicación externa sobre la iniciativa. Y aún que de cara 
al publico español hayan cosas mejorables todavía (siempre las hay), la 
herramienta probablemente ya tiene bastante buena pinta cómo para, menos esto, 
empezar a difundir ya o dentro de muy poco.

El tema es que, en la hypothesis de que vayamos a usar el dominio 
sigueabierto.es (en principio, bajo su subdominio www), el mapa ya no podrá 
aparecer bajo la url "sigueabierto.openstreetmap.es". Eso, debido a que los 
gestores de la estructura global han puesto cómo regla de sólo habilitar un 
dominio por idioma (que ya es bastante complicado así).

No nos malentendemos:
-> para retrocompatibiliad, las urls basadas en 
"sigueabierto.openstreetmap.es/*", estarían redirigidas hacía lo 
"[www.]sigueabierto.es/*" correspondiente.
-> les he pedido que haya un periodo de transición, es decir, en resumen, que 
esa redirección sólo se habilite una vez comprobado que [www.]sigueabierto.es 
funccione todo OK.

¿Alguien le ve alguna traba? Si eso por fa manifestarse.

Y por supuesto, los demás quienes estáis metidos en el proyecto (Yopaseopor, 
Juanjo, Alejandro, Jmontane, ... ¿olvido a alguién?), si os parece oportuno 
aportar cualquier aclaración, según veais. Por mí, sin problema.

¡Gracias por la atención!

Jean-Baptiste

El Sábado, Abril 11, 2020 17:04 CEST, in...@jeanbaptisterichard.eu 
 Ha escrito:
  Resumen de la situación actual, ya que después de este correo se ha hablado 
por el chat de telegram:

- droguerias (shop=chemist) añadidas
- logos en castellano, catalá, gallego, hechos (por el equipo francés con 
inputs de las comunidades respectivas) y pendiente publicar
- dominio sigueabierto.es alquilado para un año, redirección pendiente.

Saludos

El Viernes, Abril 10, 2020 22:03 CEST, in...@jeanbaptisterichard.eu 
 Ha escrito:
  Hola otra vez,

- veo que "shop=chemist" falta en la lista en github y por tanto no aparecen en 
la página  (correspondiendo a "productos  higiénicos", linea 4 del punto 2 del 
Anexo del BOE). Lo iba a comentar en el hilo de github pero mejor comentarlo 
primero aquí. ¿Les pedimos que lo añadan?

- ¿Se ha considerado alquilar el dominio "sigueabierto.es", u otro tld? (Para 
tener una dirección más user-friendly y más fácil de comunicar a prensa, en 
tweets, etc.)

- respecto a mi pregunta "¿Se ha automatizado parte del trabajo?", veo que al 
mismo tiempo que escribía, han publicado un nuevo billete en el blog de 
caresteouvert.fr, "Contribuidores de OpenStreetMap, ¿Cómo tratar las notas 
#caresteouvert?" [1]. Allí explicitan que "cuando [las] informaciones son 
detalladas o demasiado complejas, no se integran automaticamente a 
OpenStreetMap [,] sino que se crea una nota y que es necesario que un 
colaborador OpenStreetMap (¿Vd?) haga lo necesario".
[1] 
https://blog.caresteouvert.fr/contributeurs-openstreetmap-comment-traiter-les-notes-caresteouvert/