date:20200416

> Je n'ai pas tout compris à tes interrogations métaphysiques, mais…
Il parait que je me pose beaucoup (trop?) de questions :D

L'idée de départ était de trouver un outils simple et fiable (pour des 
débutants) pour contribuer avec si besoin des photos.
Les notes me paraissent bien car il FAUT un traitement manuel par un 
contributeur (si possible expérimenté).

SC m'a paru très bien.

Le hic, c'est que je pensais qu'il envoyait des photos en pleine résolution, et 
du coup j'ai cadré mes prises de vues en conséquence.
Dans l'absolu ce n'est pas grave, il faut juste le savoir avant :)

Le débutant ne va pas envoyé ses photos dans Wikimedia Commons, mais elles 
pourraient très bien l'être dans Mapillary.
(il y a tellement de photos floues, mal cadrées, avec une mauvaise résolution: 
ici, les clichés ont plus de chance d'être "meilleurs").

Quand à moi, j'essai autant que possible de conserver des photos correctes dans 
Commons (ou Mapillary) pour lier par exemple une boutique dans OSM à la photo 
de sa devanture…
Ou un poteau incendie à une photo de situation (ils sont parfois difficile à 
trouver) et une de détail.

Si la photo pleine résolution reste dans mon ordiphone, pas de problème. (ce 
n'est pas le cas et je ne le savais pas)

> Voir ici aussi le pourquoi de "pas de sauvegarde" dans l'ordiphone 
> https://github.com/westnordost/StreetComplete/issues/1162
Je ne sais pas si c'est à cause de la Stasi ou la SS, mais les allemands sont 
très sensibles avec les droits d'accès aux données du téléphone ;)
(Peux-être que les collègues allemand(e)s inscrit(e)s sur cette liste 
pourraient nous éclairer sur cette particularité "culturelle"  ?)

Un contributeur indiquait une solution (passer par l'application galerie ce qui 
ne nécessite pas de droits supplémentaire pour SC).
Le développeur n'a pas considéré cette option, dommage.
De mémoire, l'utilisateur peut aussi refuser ce droit à l'application.

>> Un mode offline serait pratique.
> Il existe !!!
Je le connaissais mais je pensais (à tord) qu'il ne fonctionnait que pour les 
quêtes.

> Regarde dans "les trois petites points verticaux en haut à droite" -> 
> Paramètres : Communication -> Synchronisation automatique : 
> désactivé/seulement en wifi".
Donc par défaut, synchronisation automatique activée veut dire qu'on ne peut 
pas envoyer sa note (et en créer une nouvelle) tant qu'on n'a pas de réseau ?
Et que les deux autres options enregistrent les notes dans l'ordiphone, et 
seront envoyées plus tard (automatiquement en WIFI, sinon manuellement).

Ok, ça me va (mais le fonctionnement n'est pas limpide au premier abord).

Je teste ça aujourd'hui. Merci :)

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

Re: [Talk-it] Import Farmacie

2020-04-16 Per discussione Alessandro Sarretta


Ciao a tutti,

mi aggiungo anch'io—un po' in coda—a questa discussione. In particolare 
mi aggancio a questo intervento di Martin, che condivido.


Non sono un esperto di import, ma anche le pagine sul wiki parlano di 
import quando si intende inserire (upload) in blocco (bulk) un dataset 
esterno per essere incluso in OSM. Questo implica una procedura di 
preparazione e gestione del dataset e della sua integrazione in OSM 
complessa e delicata, che però non passa attraverso il controllo e 
l'inserimento manuale di ogni singolo elemento del dataset.


Nel caso delle farmacie, quello che sto facendo personalmente (ma mi 
pare anche altri stiano seguendo questa modalità) è usare il dataset del 
Ministero come fonte da cui derivare alcune informazioni e poi 
controllare, aggiornare o aggiungere punto per punto tali informazioni 
in OSM. Non so se il fatto che il dataset sia stato inserito in Osmose 
possa di per se essere considerato un processo di import, ma mi pare di 
capire che non ci sia nessun automatismo da Osmose verso il database OSM.


Nel caso di Padova, ad esempio, c'è una pagina della ULSS6 con tutte le 
farmacie (http://www.aulss6.veneto.it/index.cfm?action=farmacie) con 
denominazione, indirizzo, numero di telefono; il portale cartografico 
del Comune di Padova permette di visualizzare tutti i civici, quindi la 
posizione la controllo e la aggiorno dall'incorcio dei 2 dati; poi cerco 
il sito web della farmacia per altre info (email, orari, ...).


In pratica Osmose mi serve per avere un'indicazione di quali farmacie 
possono avere dei dati mancanti e dal dataset del Ministero in 
definitiva prendo solo il ref:msal=*


La procedura è molto lenta e manuale, ma pian pianino i dati in OSM 
migliorano e si aggiornano.


A me non sembra che questo processo possa essere considerato un import. 
Però sono aperto a correzioni e discussioni.


Grazie,

Ale

On 16/04/20 17:35, Martin Koppenhoefer wrote:
OSM normalmente funziona così: tu vedi una cosa in giro e la inserisci 
nella mappa, oppure vedi una cosa nella mappa che nella realtà non c'è 
(più), la rimuovi. Con questo procedere abbiamo sempre dati aggiornati 
dove è passato un mappatore. Se non ci fossero mappatori a sufficienza 
in giro, avremmo dati incompleti, e se non ci fossero mappatori attivi 
in una zona, avremmo anche dati parzialmente superati.


Invece un import è un altra cosa. Si prende la lista di qualcun altro, 
spesso parliamo di copie di copie di copie di copie di liste, che sono 
state compilate anni fa, poi sono state verificate, aggiornate (anche 
parzialmente), approvate, e dopo un po' pubblicate. Come tutti, anche 
chi fa queste liste e le verifiche commette degli errori, ma anche se 
non ci fossero, ci sono comunque i problemi dovuti al lungo processo 
di pubblicazione. Quindi anche se la lista delle farmacie fosse stata 
pubblicata ieri, sarebbe già un pocchino vecchia e superata.


Per questo, e anche perché chi fa import può avere più leva sui tags 
in uso, c'è la procedura che descrive come fare gli import. La DWG non 
autorizza mai import, al massimo fa un revert oppure una redaction, 
secondo la gravità del caso.


Prendere dati da un sito web (i dati su un esercizio commerciale, dal 
loro proprio sito), lo considero legitimo e legale, mentre prendere 
dati da facebook probabilmente non lo è.


Con il import in discussione, oltre alla precisione delle coordinate, 
c'è sempre il problema dell'attualità: al momento non possiamo andare 
in giro per verificare i dati (tranne quelli sotto casa nostra, dove 
probabilmente abbiamo già inserite le farmacie in precedenza). Se sono 
stato controllati una a una in altra maniera (sito web della farmacia, 
idealmente chiamata telefonica alla farmacia, ecc.), per me andrebbe 
bene e non lo considererei più un import.


Ciao
Martin


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

Re: [OSM-talk-fr] Application smartphone pour mettre simplement et rapidement une note avec photo(s) ?


> Ce n'est pas possible de prendre des photos individuelles et de les mettre 
> efficacement sur le serveur de Mapillary.
On peut, mais il faut créer une série pour une seule photo.
C'est lourd.

Pas grand chose à "modifier", il faudrait que l'API accepte une valeur spéciale 
pour la série (par exemple "0", "-1", Null)


> Je pense que Mapillary pourrait reconsidérer et commencer à intégrer des 
> photos individuelles dans l'avenir proche.
> (fingers crossed). 
Oui, moi aussi.

Stuart, connais-tu une "Issue" sur ce sujet sur laquelle on pourrait rajouter 
des ?

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

Re: [OSM-talk-fr] formatage no de téléphone

2020-04-16 Per discussione Philippe Verdy

Le ven. 17 avr. 2020 à 03:11, Philippe Verdy  a écrit :
>
> Voir aussi cette expression régulière (syntaxe PCRE) qui mâche le
> travail d'analyse (validée et testée pour plein de pays et plain de
> formats):
> https://regex101.com/r/4wY5xA/48
> utilisée sur Wikidata (comme condition informative, non impérative),
> elle valide plein de numéros et le reste est réellement mal formaté
> (plusieurs numéros accolés, syntaxe ambigüe)

Note: le numéro "0800 130 000" est bien accepté comme valide et
reconnu comme un numéro local (non international non éligible au
préfixe "+CC" du format E.164, donc il n'y a rien dans le groupe de
capture 1 pour le code pays explicite, ou 2 pour le code implicite des
numéros nord-américains +1 ou russes +7)
L'expression détecte tous les groupes de chiffres significatif et
préserve leur groupement (mais crée un groupe dans le dernier groupe
s'il contient plus de 4 chiffres).

Elle détecte aussi certains suffixes d'extension (après "EXT" ou "X")
ajoutés après le numéro
Elle détecte correctement la longueur des codes pays mais ne les
valide pas (elle reconnait des codes encore réservés) et donc ne
traite pas ensuite spécialement les formats selon le code pays reconnu
(pour valider qu'il y a assez de chiffres; de plus divers pays ont des
numéros de téléphone de longueur variable selon les premiers groupes
de chiffres, par exemple l'Allemagne ou l'Italie (les formats
diffèrent aussi selon que c'est un numéro fixe ou mobile plus longs).
Elle ne sait pas dire (selon le pays) s'il faut ou pas composer le 0
initial du numéro national (on ne doit pas le supprimer au Royaume-Uni
par exemple, ce 0 initial est significatif au début du code régional,
dans la plupart des autres dont la France, ce 0 doit être supprimé des
appels internationaux quand on compose le préfixe international et le
code pays "+CC").

Améliorations possibles (à tester, syntaxe à étudier):

Elle ne supporte pas les procédures d'appel sur automates vocaux ("*"
suivi de codes numériques) car elle ne détecte pas encore les codes
"*" et "#" de ces procédures, ni les procédures vocales "pour joindre
un conseiller, dites CONSEILLER" qu'ont pourrait ajouter aussi en
mettant ce mot à prononcer entre guillemets, ou dans une autre
propriété de qualification (wikidata) ou un autre tag (OSM)
Elle pourrait aussi ajouter les codes spéciaux "P[nombre de secondes]"
ou "," pour les pauses nécessaires (codes déjà reconnus par les modem
ou fax via leur interface série).
Elle pourrait supporter toute procédure manuelle (sans automate au
bout pour la réaliser mais à effectuer oralement avec le premier
correspondant pour qu'il renvoie l'appel au bon service/la bonne
personne.
Elle ne détecte pas non plus les horaires possibles "@" suivi d'un
format comme pour opening_hours
D'autres préfixes par pays sont possibles et pourraient être reconnus
(par exemple le 8 en Russie est le code interrégional, le 810 est le
code correspondant au préfixe international "+").

Certains numéros peuvent être appelés en mode interrégional ou en mode
international (au sein du plan nord-américain, le "1" composé seul
appelle n'importe quel pays de la zone, en Russie et plusierus pays
ex-sociétiques, le "8" a aussi cette fonction et il faut analyser le
code régional pour savoir à quel pays cela correspond pour appeler
d'un autre pays, et un numéro kazakhe indiqué par "8(XXX)N..."
devra remplacer le "8" par + suivi du code du Kazakhstan, ou le "+7"
si c'est un numéro russe...). On a le cas aussi en France pour les
outre-mer et les numéros de Monaco, intégrés au plan français dit "à
10 chiffres" (mais qui ont aussi leur propre préfixe international).

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

Re: [OSM-talk-fr] formatage no de téléphone

2020-04-16 Per discussione Philippe Verdy

Voir aussi cette expression régulière (syntaxe PCRE) qui mâche le
travail d'analyse (validée et testée pour plein de pays et plain de
formats):
https://regex101.com/r/4wY5xA/48
utilisée sur Wikidata (comme condition informative, non impérative),
elle valide plein de numéros et le reste est réellement mal formaté
(plusieurs numéros accolés, syntaxe ambigüe)


Le jeu. 16 avr. 2020 à 16:00, Pierre-Olivier GREGOIRE
 a écrit :
>
> C'est la bibliothèque que google utilise dans android si j'ai bien compris 
> donc ca doit couvrir tous les pays je pense ;)
>
> Le jeu. 16 avr. 2020 à 14:38, Yves P.  a écrit :
>>
>>
>> Pour info Il y a une bibliotheque libre fournie par Google en js et java qui 
>> permet de passer de la forme locale a l'international et inversement :: 
>> https://github.com/google/libphonenumber
>> La page liste des portages en python et autre
>>
>> Merci cool :)
>>
>> Ça évite de réinventer la roue et ça marche pour plein de pays (tous ?)
>> Un détail, la bibliothèque indique que mon n° de mobile est chez SFR : perdu 
>> :D
>>
>> Comme me l'on fait remarqué 2 personnes assidues, le formatage de n° comme 
>> "0800 130 000" est cassé.
>> Dans CRO, on peut par exemple ne pas reformater un n° si il contient des 
>> espaces (pour la France).
>> Ou alors laisser ça aux éditeurs (c'est le cas actuellement dans CRO).
>>
>> Et pour les données ouvertes, faire ça automatiquement à l'import, en 
>> prévenant l'opérateur en cas de doute.
>> (en France, un groupement de 3 chiffres est probablement voulu).
>>
>> Pour les développeurs de JOSM, cette bibliothèque est faite pour vous ;)
>>
>> __
>> Yves
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Recouvrements highway et waterway sur Osmose

2020-04-16 Per discussione GarenKreiz

Bonsoir,

Au temps pour moi,j'avais laissé trainé un filtre sur le niveau de gravité!
Merci

Cdt

   Garenkreiz


On Thu, 16 Apr 2020 at 20:44,  wrote:

> Osmose détecte toujours.
>
> Ici ce n'est pas le message usuel mais :
> *Intersection d’objets sans rapports relatifs à la voirie et aux cours
> d’eau*
> *way 172715101 * josm
> 
> iD  edit
> 
> *way 789623290 * josm
> 
> iD  edit
> 
> osm-show
> 
> osm-edit 
> josm-zone
> 
> détails
> 
> Signalement du : 2020-04-16
> × 
> Gravité
> Avec correction
> Le 16/04/2020 à 18:38, GarenKreiz - garenkr...@gmail.com a écrit :
>
> Bonjour,
>
> Il me semblait qu'Osmose détectait les recouvrements non déclarés entre
> les chemins "highway" et les chemins "waterway". Pourtant il n'indique rien
> pour https://www.openstreetmap.org/way/172715101 , une rue de Puteaux qui
> tente de traverser la Seine à gué.
>
> Y a-t-il un paramétrage à faire?
>
> Garenkreiz
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] HS2 Phase 1 Construction NTP

2020-04-16 Per discussione Jez Nicholson

Thanks Andy, this is opportunity for OSM to be *the* best source of HS2
rails data.

On Wed, 15 Apr 2020, 17:48 Andy Robinson,  wrote:

> Government issued Notice to Procced for Phase 1 today, which means the
> main contracts construction between London and Birmingham will start
> imminently so keep an eye out for major new works in your area soon (though
> I expect these will be slow to spot while we are in lockdown!)
>
>
>
> Till now all works relating to HS2 have been enabling works or design
> related.
>
>
>
> Cheers
>
> Andy
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Coronapiste : piste cyclable temporaire qui dure

Bonjour,

Le 16.04.20 à 22:59, Florimond Berthoux a écrit :
> Si comme à Nantes la piste remplace un aménagement (bande ou voie bus)
> on pourrait mettre :
> was:cycleway=lane|*

bonne idée

> Et pour l'aspect temporaire :
> cycleway:conditional=yes @ covid19

oui mais un oui par défaut + un oui conditionnel,
cela risque de faire réagir des QA (donc provoquer
leur suppression ou pire une correction incorrecte)
je mettrais à la place description:covid19=piste cyclabe temporaire

Cordialement,
Marc

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

[OSM-talk-fr] Coronapiste : piste cyclable temporaire qui dure

2020-04-16 Per discussione Florimond Berthoux

Bonsoir,

Il y a dans le monde un mouvement de création de piste cyclable temporaire
afin de favoriser la distanciation sociale contre le covid19.
Voir une liste par ici
https://twitter.com/Lelievre_Adrien/status/124462002223488
Et en France aussi ça bouge, par exemple une première à Nantes
https://twitter.com/thomasquero/status/1250842503403708420

Comment mapper ça ?
Mon avis est qu'elles sont faites pour durer quelques temps, plusieurs mois
au moins. Donc autant les tagguer en "dur" avec les tags habituels
(cycleway=*, voire highway=cycleway). Ainsi la donnée sera utilisable par
tous sans modification de code.

Si comme à Nantes la piste remplace un aménagement (bande ou voie bus) on
pourrait mettre :
was:cycleway=lane|*

Et pour l'aspect temporaire :
cycleway:conditional=yes @ covid19

Qu'en pensez vous ?

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

[Talk-it] WMI alla riunione del direttivo di OSMF

2020-04-16 Per discussione Laurentius

A partire da questo mese, il consiglio direttivo di OpenStreetMap
Foundation inizierà ad invitare un capitolo a turno nelle loro
riunioni. Non sanno ancora bene come organizzare queste chiamate: hanno
in mente che vogliono fare qualcosa per avere maggiori contatti con i
capitoli, e stanno facendo qualche prova. L'onore di essere i primi
spetterà a Wikimedia Italia come capitolo italiano.

Secondo voi:
 * c'è qualcosa che dovremmo chiedere al board?
 * c'è qualcosa che potremmo offrire?
 * ci sono delle esigenze da segnalare?
 * c'è qualcosa che succede in Italia che è importante far conoscere al
   board o al resto del mondo?

Credo che loro stessi non abbiano le idee chiarissime su come
organizzare questi incontri, quindi sta a noi proporre.

Credo che sia importante in particolare la partecipazione di Sabas (in
quanto rappresentante dell'associazione nell'advisory board) e
Alessandro Sarretta (in quanto coordinatore nazionale dell'associazione
per OpenStreetMap), e naturalmente ci sarò anch'io, ma secondo me è una
buona occasione per tutti per partecipare (e non ricapiterà a breve!). 
La riunione è domani (venerdì 17 aprile), è pubblica (in ascolto) ed è
possibile collegarsi da:
https://osmvideo.cloud68.co/user/ror-nt7-6tu
Inizia alle 18, ma non so quando saremo noi: probabilmente alla fine,
fra le 19 e le 20.

Lorenzo



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

Re: [Talk-GB] Talk-GB Digest, Vol 163, Issue 23

2020-04-16 Per discussione Mike Baggaley

Hi Dave,

I have been using this data for several years and it appears to be updated 
around about weekly. It is probable that the review date refers to the page, 
not the data that it links to, which is on an entirely different server - The 
actual CSV is at http://media.nhschoices.nhs.uk/data/foi/Pharmacy.csv . I 
haven't noticed any corruptions - it could be a code page issue.

>Are you sure it's upto date?:
>
>Page last reviewed: 15 December 2016
>Next review due: 15 December 2019
>
>The 'GPs' is corrupted with Chines symbols.

Cheers,
Mike


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

Re: [Talk-GB] Q2 2020 Quarterly project GP Surgeries and health sites

2020-04-16 Per discussione Dave F via Talk-GB


Are you sure it's upto date?:

Page last reviewed: 15 December 2016
Next review due: 15 December 2019


The 'GPs' is corrupted with Chines symbols.



On 16/04/2020 17:18, Mike Baggaley wrote:

The data at https://data.gov.uk/dataset/e373eb6a-fffd-48e5-b306-71eb17f97af2/pharmacies looks like 
an out of date copy of the NHS data to me. You can use the data at 
https://www.nhs.uk/about-us/nhs-website-datasets/ which is regularly updated. It even includes an 
opening hours file which can be linked to the pharmacies. You will need to use "¬" as the 
column separator. Instead of double clicking on the csv file, open Excel with an empty spreadsheet 
and use import file. You can then choose the column separator. If you follow the "About our 
data downloads" link it tells you how to import the data.  I assume the data is combined from 
various regions which use their own systems, hence the variety of ways of holding the address data.

Regards,
Mike


Yes, the first two links at
https://data.gov.uk/dataset/e373eb6a-fffd-48e5-b306-71eb17f97af2/pharmacies
are broken for me as well. For the third link, it looks like they
tried to do CSV, but didn't understand how to escape commas within the
fields, and so opted to use a different character "¬" instead. If you
import this into a spreadsheet, and tell it to use just "¬" as the
column separator, I think it works out fine, with all the entries in
the right place. (You can certainly do this with LibreOffice; I'm not
sure about Excel.) The address lines seem to be used inconsistently,
but everything is back aligned when you get to the postcode field.



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


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

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

2020-04-16 Per discussione Niharika Shrivastava

Thank you for your reply! I analyzed the full JSON response using the
"steps" parameter to check individual weight values for each edge. It looks
like the weights are dependent on the duration value calculated. I did not
specify how to calculate the duration value at all and assumed its the
length/max_speed as given in OSM data. I also didn't specify any
relationship between the duration and BPR. "BPR" is just another
pre-calculated edge attribute like "max speed" in OSM.

This is what is happening right now:

I used OSMnx to see the edge attributes for a particular road:

{'osmid': 536661786,
 'oneway': True,
 'name': 'Tampines Avenue 1',
 'highway': 'secondary',
 'maxspeed': '60.0',
 'length': 16.847,
 'travel_time': '1.01082',
 'Location': '(1.3501839, 103.926145, 1.3502606, 103.9261452)',
 'BPR': 1.0297525963481398}

I then used OSRM for the same road:

{'intersections': [{'out': 3,
 'location': [103.926145, 1.350184],
   'mode': 'driving',
   'duration': 3.5,
   'weight': 3.2,
   'distance': 16.8,
   'name': 'Tampines Avenue 1'}

Duration != travel_time and BPR != weight by a huge margin. How is
this being calculated?

I just want to make sure I wrote my profile correctly.

   1. Even if turn penalties or traffic light penalties were added to my
   weights, the cumulative weight value should've been higher than duration.
   2. I saw weight customizations in a `way_function` in the testbot.lua
   examples. Should I be using this function to customize my weights?
   3. How do I make the algorithm use the readily available weights given
   in my OSM data and not be dependent on duration calculated?


Thanking you in advance,
Niharika


On Tue, Apr 14, 2020 at 9:47 PM Daniel Patterson via OSRM-talk <
osrm-talk@openstreetmap.org> wrote:

> 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

Re: [Talk-us] United States Bicycle Route System ballots pending AASHTO approval

2020-04-16 Per discussione stevea


SteveA

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

Re: [Talk-us] United States Bicycle Route System ballots pending AASHTO approval

2020-04-16 Per discussione Kerry Irons

Good work harald. Thanks for your time.

Kerry Irons
Adventure Cycling Association

On Thu, Apr 16, 2020, 2:53 PM Harald Kliems  wrote:

> Another quick update: Work on the relatively short USBR 230 segment is
> complete as well. https://www.openstreetmap.org/relation/10967108
>
>  Harald (hobbesvsboyle)
>
> On Wed, Apr 15, 2020 at 6:37 PM stevea  wrote:
>
>> I just finished entering the last 15% - 20% of USBR 50 in California as a
>> "first draft" into OSM.  Thanks for entering the first 80% or so, Bradley:
>> teamwork!
>>
>> SteveA
>
>
>
> --
> Please use encrypted communication whenever possible!
> Key-ID: 0x34cb93972f186565
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] United States Bicycle Route System ballots pending AASHTO approval

2020-04-16 Per discussione Harald Kliems

Another quick update: Work on the relatively short USBR 230 segment is
complete as well. https://www.openstreetmap.org/relation/10967108

 Harald (hobbesvsboyle)

On Wed, Apr 15, 2020 at 6:37 PM stevea  wrote:

> I just finished entering the last 15% - 20% of USBR 50 in California as a
> "first draft" into OSM.  Thanks for entering the first 80% or so, Bradley:
> teamwork!
>
> SteveA

-- 
Please use encrypted communication whenever possible!
Key-ID: 0x34cb93972f186565
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Recouvrements highway et waterway sur Osmose

2020-04-16 Per discussione osm . sanspourriel


Osmose détecte toujours.

Ici ce n'est pas le message usuel mais :

*Intersection d’objets sans rapports relatifs à la voirie et aux cours
d’eau*
*way 172715101 * josm

iD  edit

*way 789623290 * josm

iD  edit

osm-show

osm-edit

josm-zone

détails


Signalement du : 2020-04-16
× 
Gravité

Avec correction
Le 16/04/2020 à 18:38, GarenKreiz - garenkr...@gmail.com a écrit :

Bonjour,

Il me semblait qu'Osmose détectait les recouvrements non déclarés
entre les chemins "highway" et les chemins "waterway". Pourtant il
n'indique rien pour https://www.openstreetmap.org/way/172715101 , une
rue de Puteaux qui tente de traverser la Seine à gué.

Y a-t-il un paramétrage à faire?

    Garenkreiz


___
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] Application smartphone pour mettre simplement et rapidement une note avec photo(s) ?

2020-04-16 Per discussione deuzeffe


Je n'ai pas tout compris à tes interrogations métaphysiques, mais...

Le 16/04/2020 à 10:22, Yves P. a écrit :
J'ai (re)testé hier. Voici les notes générées 
.



  * pas d'enregistrement en pleine résolution dans la galerie du
smartphone (pour pallier les pb ci-dessus et une perte éventuelle de
données cf. issue #1768
)


Voir ici aussi le pourquoi de "pas de sauvegarde" dans l'ordiphone 
https://github.com/westnordost/StreetComplete/issues/1162



De plus le processus ne semble pas documenté (d'où mes mauvaises surprises).
J'ai déposé un ticket #1781 



Autre détail, sans connexion 3/4/5 G, il me semble pas possible 
d'envoyer la note.

Un mode offline serait pratique.


Il existe !!! Regarde dans "les trois petites points verticaux en haut à 
droite" -> Paramètres : Communication -> Synchronisation automatique : 
désactivé/seulement en wifi".


HTH
--
deuzeffe

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

Re: [Talk-it] R: Import Farmacie

2020-04-16 Per discussione Francesco Ansanelli

Il gio 16 apr 2020, 19:44 canfe  ha scritto:

> Non ho cancellato solo in un caso ma ben in tre (già corretto)
> La cosa mi è davvero inspiegabile dato che, son sicuro, non seleziono mai
> nulla con ID al fuori del nodo che si riferisce alla farmacia.
>


Ciao Ferruccio,

purtroppo credo si tratti di un bug su iD...
Ad una ragazza a cui ho insegnato a mappare è successa esattamente la
stessa cosa a Cuneo:

iD 2.17.2
https://www.openstreetmap.org/changeset/82023968

E avendo seguito passo passo l'inserimento sono sicuro che non avesse
toccato la way, ma credo abbia fatto copia-incolla di un tag da internet
sull'editor...

Non ho evidenza di una issue pubblica, ma visto che ci sono già diversi
casi documentati forse è meglio indagare.

Buona serata,
Francesco

Cantone Ferruccio (canfe)
>
>
>
>
>
> *Da:* Andrea Musuruane [mailto:musur...@gmail.com]
>
> 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
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Uberto, Umberto

sent from a phone

> On 14. Apr 2020, at 15:36, Cascafico Giovanni  wrote:
> 
> 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".

Il cartello, cosa dice? Potrebbe avere senso Umberto nel official_name e Uberto 
in name, casomai i cartelli non fossero stati aggiornati?
Uberto in old_name avrà senso anche dopo che i cartelli sono stati sostituiti...

Sto parlando del nome del highway, per i civici userei la versione ufficiale.

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

Re: [Talk-it] Covid-19 - Buoni acquisto alimentari



sent from a phone

> On 16. Apr 2020, at 19:39, Damjan Gerl  wrote:
> 
> e per segnalare che c'è un bonus del 10% per famiglie con figli che si 
> registrano, ma solo il giovedì, però durante il covid19 anche il martedì ed 
> il mercoledì?


lo fa il mio supermercato, 10% per famiglie con figli il giovedì, mentre adesso 
anche martedì e mercoledì per evitare assembramenti...

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

[Talk-it] R: Import Farmacie

2020-04-16 Per discussione canfe

Quindi non è vietato usare quei dati, è il lavoro che non è abbastanza preciso 
nel posizionare gli esercizi commerciali?

Cantone Ferruccio (canfe)

 

 

Da: Andrea Musuruane [mailto:musur...@gmail.com] 

 

Visto che siamo di nuovo in argomento, puoi cortesemente rispondere alle 
domande che ho fatto. Perché - e vorrei che fosse chiaro una volta per tutte - 
il problema non è l'import in se, il problema è che si stanno importato dei 
dati posizionati male e che la conflation è fatta male (cose che - seguendo le 
guidelines - sarebbero state evitate).

 

Grazie,

 

Andrea

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

[Talk-it] R: Import Farmacie

2020-04-16 Per discussione canfe

Non ho cancellato solo in un caso ma ben in tre (già corretto)
La cosa mi è davvero inspiegabile dato che, son sicuro, non seleziono mai nulla 
con ID al fuori del nodo che si riferisce alla farmacia.

Cantone Ferruccio (canfe)

 

 

Da: Andrea Musuruane [mailto:musur...@gmail.com] 

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

[Talk-it] R: Import Farmacie

2020-04-16 Per discussione canfe

Sì è vero, una l’ho cannata. (ho già corretto)

 

Cantone Ferruccio (canfe)

 

Da: Andrea Musuruane [mailto:musur...@gmail.com] 

 

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: [Talk-it] Covid-19 - Buoni acquisto alimentari

2020-04-16 Per discussione Damjan Gerl


  
  
Martin Koppenhoefer je 16.4.2020 ob
  17:07 napisal:


  
  




  Am Do., 16. Apr. 2020 um
17:04 Uhr schrieb dam...@damjan.net :
  
  Salve a tutti!

Se ho ben capito per segnalare che un esercizio accetta i
buoni alimentari/buoni spesa forniti dal comune dobbiamo
usare il tag:

payment:service_vouchers:covid19=yes

Giusto?
E per segnalare che lo stesso esercizio applica lo sconto p.es. del 10% sugli acquisti
con il buono?
  





e per segnalare che c'è un bonus del 10% per famiglie con
  figli che si registrano, ma solo il giovedì, però durante il
  covid19 anche il martedì ed il mercoledì?

  


???
  


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

Re: [OSM-talk-fr] Recouvrements highway et waterway sur Osmose

Bonjour,

Le 16.04.20 à 18:38, GarenKreiz a écrit :
> Il me semblait qu'Osmose détectait les recouvrements non déclarés entre
> les chemins "highway" et les chemins "waterway". Pourtant il n'indique
> rien pour https://www.openstreetmap.org/way/172715101 , une rue de
> Puteaux qui tente de traverser la Seine à gué.

https://osmose.openstreetmap.fr/fr/error/6edf0147-6726-832a-6ec5-b87d2a1ad420
Intersection d’objets sans rapports relatifs à la voirie et aux cours d’eau

trouvé en activant tous les niveaux de gravité et toutes les rubriques

Cordialement,
Marc

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

[OSM-talk-fr] Recouvrements highway et waterway sur Osmose

2020-04-16 Per discussione GarenKreiz

Bonjour,

Il me semblait qu'Osmose détectait les recouvrements non déclarés entre les
chemins "highway" et les chemins "waterway". Pourtant il n'indique rien
pour https://www.openstreetmap.org/way/172715101 , une rue de Puteaux qui
tente de traverser la Seine à gué.

Y a-t-il un paramétrage à faire?

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

Re: [Talk-GB] Q2 2020 Quarterly project GP Surgeries and health sites

2020-04-16 Per discussione Mike Baggaley

The data at 
https://data.gov.uk/dataset/e373eb6a-fffd-48e5-b306-71eb17f97af2/pharmacies 
looks like an out of date copy of the NHS data to me. You can use the data at 
https://www.nhs.uk/about-us/nhs-website-datasets/ which is regularly updated. 
It even includes an opening hours file which can be linked to the pharmacies. 
You will need to use "¬" as the column separator. Instead of double clicking on 
the csv file, open Excel with an empty spreadsheet and use import file. You can 
then choose the column separator. If you follow the "About our data downloads" 
link it tells you how to import the data.  I assume the data is combined from 
various regions which use their own systems, hence the variety of ways of 
holding the address data.

Regards,
Mike

>Yes, the first two links at
>https://data.gov.uk/dataset/e373eb6a-fffd-48e5-b306-71eb17f97af2/pharmacies
>are broken for me as well. For the third link, it looks like they
>tried to do CSV, but didn't understand how to escape commas within the
>fields, and so opted to use a different character "¬" instead. If you
>import this into a spreadsheet, and tell it to use just "¬" as the
>column separator, I think it works out fine, with all the entries in
>the right place. (You can certainly do this with LibreOffice; I'm not
>sure about Excel.) The address lines seem to be used inconsistently,
>but everything is back aligned when you get to the postcode field.



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

Re: [OSM-talk-fr] Et si on prenait soin de nos EHPAD ?

2020-04-16 Per discussione Jean-Guilhem Cailton

Bonjour,

D’après ce que j’ai compris de Nicolas et toi Pascal, l’Hérault doit en
effet être fait.

Par ailleurs, l’équipe « ROJLP », qui avait fait le Gard, et vient de
terminer l’Ardèche, attaque la Drôme.

Et d’après les réponses sur la liste talk-fr qui mentionnent des
départements :
- Après la Haute-Savoie, Yves parlait du Jura (en commençant par un
Ehpad dans l’Ain (?), VillA Charlotte).
- Paul se balade dans toute l’Isère, bien équipé en umap et overpass-turbo.

(Fil
https://lists.openstreetmap.org/pipermail/talk-fr/2020-April/thread.html#98295
)

Pour ma part, j’en fait un peu autour de chez moi en Haute-Garonne
(hors de la carte de Kalksten)


Ça laisse pas mal de départements dont il serait bien que de bonnes
volontés prennent soin…

N’hésitez pas à partager vos avancées et contributions sur ce thème,

Je vous embrasse (comme, par courriel, on peut),

Jean-Guilhem


Le 16/04/2020 à 10:30, ARNOUX Pascal (Free) a écrit :
> Bonjour,
>
> A-t-on un bilan sur ce qui a été fait et sur ce qu'il reste à faire ?
> J'ai consulté les deux liens fournis, je n'ai pas trop vu
> d'indications sur le Gard et l'Hérault.
> -- 
> Bien cordialement, Pascal ARNOUX
> Président de Montpel'libre - Les logiciels logiquement libres
> https://montpellibre.fr - 06.47.85.59.42
>
>
> Le 09/04/2020 à 19:30, Jean-Guilhem Cailton a écrit :
>> Bonjour,
>>
>> Il reste beaucoup à améliorer sur la cartographie des EHPAD dans OSM.
>> Y compris de ceux dont la presse nous donne des nouvelles terribles.
>>
>> Nicolas avait aussi signalé que, au moins pour les sapeurs-pompiers
>> de l’Hérault, la cartographie des EHPAD faisait partie des
>> thématiques à améliorer, pour leur système d’alerte…
>>
>>
>> Grâce aux données ouvertes FINESS, intégrées dans Osmose, il est
>> relativement facile de compléter les informations des établissements
>> déjà présents, ou d’ajouter ceux qui manquent.
>>
>> Pour ma part, j’ai appris à utiliser http://osmose.openstreetmap.fr à
>> cette occasion. Je sélectionne « Gravité=Toutes », « Avec
>> correction=JOSM » (c’est l’éditeur que j’utilise), et « Thème=merge ».
>> Puis dans la rubrique Intégration, je clique sur « rien » pour tout
>> décocher, puis « Structure sociale » et « Structure sociale à intégrer ».
>>
>> J’ai activé dans JOSM l’option « Télécharger dans un nouveau calque »
>> du contrôle à distance. Puis, pour une puce Osmose donnée, j’utilise
>> les liens josm-zone et fix-josm pour charger la zone, et un objet
>> avec les nouvelles balises, chacun dans un calque. Je préfère ça pour
>> m’y retrouver, et savoir ce que j’édite avant de le charger dans OSM.
>> Si nécessaire, j’ajoute aussi à la main nom et adresse.
>>
>> Je remplace aussi le group_home proposé par défaut par Osmose,
>> actuellement, par social_facility=nursing_home, pour les vrais EHPAD,
>> conformément au consensus dans le fil « Listes d’EHPAD et tag », sur
>> talk-fr les 24 et 25 mars.
>>
>> Au passage, je fais une petite recherche web sur le nom de
>> l’établissement. Ils ont souvent leur propre site web, ou au moins
>> des pages qui les décrivent, et permettent de distinguer les EHPAD
>> des foyers-logements, par exemple, pour lesquels group_home peut être
>> mieux adapté. Et du coup, ça fait aussi un attribut website à ajouter.
>>
>>
>> Pour se coordonner, au niveau élémentaire, on peut cliquer sur la
>> coche verte « corrigé » d’Osmose une fois qu’on a intégré les
>> informations d’une puce dans OSM.
>>
>> À un niveau plus global, par exemple par département (je crois que
>> l’Hérault et le Gard ont déjà été faits), peut-être qu’on peut se le
>> dire simplement en répondant à ce message. À moins que quelqu’un
>> mette en place un meilleur système, comme une page wiki ?
>>
>>
>> Pour ma part, je vais prioriser en fonction de nouvelles de presse
>> qui sont cartographiées sur cette umap (et de leurs alentours) :
>> https://umap.openstreetmap.fr/fr/map/liste-des-ephad-concernes-par-le-covid-19_439161
>> (surtout par Kalksten — https://twitter.com/Kalkspat1)
>>
>> Attention, ça peut être assez éprouvant de regarder ce genre de
>> nouvelles de trop près…
>>
>>
>> Prenez bien soin de vous, et de nos aînés en cartographiant leurs
>> EHPAD, si ça vous dit,
>>
>> Jean-Guilhem

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

Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata

Bonjour,

Le 16.04.20 à 17:14, Baptiste Jonglez a écrit :
> Si je résume les avis exprimés sur la liste

j'ai soumis la question à legal-questi...@osmfoundation.org
histoire d'avoir un avis un peu plus neutre que "c'est covid19
donc c'est légal"

hélas j'imagine que cela prendra un peu de temps.

Cordialement,
Marc

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

[OSM-talk-fr] Fusions pharmacies

2020-04-16 Per discussione Jacques Lavignotte


Bonjour,

Deux pharmacies fusionnent avec une troisième (3 n° de FINESS) Je mets 
des was: sur les amenity=pharmacy des officines fermées et je laisse les 
reste en l'état. J'ai bon ?


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

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

Re: [Talk-it] Import Farmacie

Am Do., 16. Apr. 2020 um 13:45 Uhr schrieb Francesco Ansanelli <
franci...@gmail.com>:

> Spero sia sufficiente come risposta, vedi anche quanto tempo ci è voluto
> per aggiungere i dati... Un import vero e proprio sarebbe stato sicuramente
> distruttivo.
>
> Se ho sbagliato, l'ho fatto in buona fede, e spero che presto venga fatta
> chiarezza da chi di dovere.
>


OSM normalmente funziona così: tu vedi una cosa in giro e la inserisci
nella mappa, oppure vedi una cosa nella mappa che nella realtà non c'è
(più), la rimuovi. Con questo procedere abbiamo sempre dati aggiornati dove
è passato un mappatore. Se non ci fossero mappatori a sufficienza in giro,
avremmo dati incompleti, e se non ci fossero mappatori attivi in una zona,
avremmo anche dati parzialmente superati.

Invece un import è un altra cosa. Si prende la lista di qualcun altro,
spesso parliamo di copie di copie di copie di copie di liste, che sono
state compilate anni fa, poi sono state verificate, aggiornate (anche
parzialmente), approvate, e dopo un po' pubblicate. Come tutti, anche chi
fa queste liste e le verifiche commette degli errori, ma anche se non ci
fossero, ci sono comunque i problemi dovuti al lungo processo di
pubblicazione. Quindi anche se la lista delle farmacie fosse stata
pubblicata ieri, sarebbe già un pocchino vecchia e superata.

Per questo, e anche perché chi fa import può avere più leva sui tags in
uso, c'è la procedura che descrive come fare gli import. La DWG non
autorizza mai import, al massimo fa un revert oppure una redaction, secondo
la gravità del caso.

Prendere dati da un sito web (i dati su un esercizio commerciale, dal loro
proprio sito), lo considero legitimo e legale, mentre prendere dati da
facebook probabilmente non lo è.

Con il import in discussione, oltre alla precisione delle coordinate, c'è
sempre il problema dell'attualità: al momento non possiamo andare in giro
per verificare i dati (tranne quelli sotto casa nostra, dove probabilmente
abbiamo già inserite le farmacie in precedenza). Se sono stato controllati
una a una in altra maniera (sito web della farmacia, idealmente chiamata
telefonica alla farmacia, ecc.), per me andrebbe bene e non lo considererei
più un import.

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

Re: [OSM-talk-fr] #caresteouvert Intégration données dokomaps en opendata

2020-04-16 Per discussione Baptiste Jonglez

Bonjour,

Si je résume les avis exprimés sur la liste, concernant uniquement
l'intégration déjà réalisée des commentaires venant de Dokomaps :

- 2 avis "il faut revert les données déjà intégrées"
- 4 avis "il faut conserver les données déjà intégrées"

Les arguments donnés pour revert : le statut juridique n'est pas
acceptable puisqu'il manque l'accord des contributeurs originaux ;
l'intégration s'est faite de manière trop cavalière ; la licence ODbL sans
provision de future changement de licence ne permet pas d'intégrer des
données dans OSM.

Les arguments donnés pour conserver : on a bien l'accord du propriétaire
de la base de données (Dokomaps) ; ces données ont un intérêt général et
sanitaire qui justifie l'intégration malgré l'incertitude juridique ; les
données seront de toute façon effacées d'OSM à la fin de la crise.

Y a-t-il d'autres avis sur la question ?

Pour ce qui est de finir d'intégrer les données restantes, ce n'est
évidemment plus considéré, et ça n'a de toute façon plus vraiment
d'intérêt (les données sont maintenant trop vieilles).

Baptiste

On 11-04-20, Baptiste Jonglez wrote:
> Bonjour,
> 
> Tout d'abord, je n'ai pas l'impression d'avoir fermé la discussion.  Il y
> a eu une première discussion sur
> https://github.com/osmontrouge/caresteouvert/issues/81 avec des retours
> positifs (je tiens à noter que je ne suis pas l'initiateur de cette
> discussion).
> 
> Puis une seconde discussion ici, où tu as très justement pointé du doigt
> certains problèmes avec l'origine des données.  Quelques personnes ont
> participé à la discussion.  Après je suis d'accord que le début de
> l'intégration a été précipité vis-à-vis de l'annonce sur talk-fr (j'ai
> considéré à tord que les principales personnes concernées avaient déjà eu
> vent de la discussion via le ticket github, ouvert depuis plusieurs jours
> et avec de nombreux retours).
> 
> Maintenant sur les données elles-mêmes, il y a deux cas :
> 
> - les données provenant de Google (nom des POI et localisation) :
>   clairement, il n'y a pas lieu de les intégrer, ça semble faire
>   consensus.  Merci d'avoir remonté ce problème.  Aucune intégration n'a
>   été faite sur ces données.
> 
> - les données d'ouverture en temps de confinement, venant des
>   contributeurs de Dokomaps : il y a effectivement un flou sur la relation
>   entre Dokomaps et ses utilisateurs, Dokomaps aurait dû chercher de façon
>   plus explicite la permission de ses utilisateurs.  Ceci dit, il ne me
>   semble pas y avoir de consensus dans la discussion sur l'intégration de
>   ces données, ni dans un sens ni dans l'autre.  Ça ne me semble pas
>   justifié de reverter l'intégration de ces données (surtout qu'elles sont
>   généralement croisées avec des informations apportées par ailleurs par
>   des contributeurs sur çaresteouvert)
> 
> En tout cas, vu ces oppositions, j'ai désactivé les données restantes à
> intégrer sur umap (ce que j'aurais effectivement dû faire avant).
> 
> Si un consensus émerge sur la nécessité de reverter les données déjà
> intégrées, ce sera à contre-coeur mais je m'en chargerais, il n'est pas
> question que ça demande du travail à d'autres contributeurs...
> 
> Baptiste
> 
> On 11-04-20, althio wrote:
> > En l'absence de clarification complète ou d'autres éléments convaincants
> > sur le statut des données Doko Maps, leur propriété et leur licence, je
> > considère que ces données ne sont pas valables pour un ajout dans OSM.
> > 
> > La discussion avec les différents auteurs de cet ajout de données et le
> > reste de la communauté n'a pas eu lieu (en tout, pas aussi détaillée et
> > conclusive qu'on aurait pu espérer), ni ici sur talk-fr, ni sur
> > https://github.com/osmontrouge/caresteouvert/issues/81
> > 
> > J'ai fait une demande aux auteurs de cet ajout de données de reverter leurs
> > contributions, ce qui a été ignoré pour l'instant.
> > cf.
> > https://github.com/osmontrouge/caresteouvert/issues/81#issuecomment-611299417
> > 
> > Je lance donc un dernier appel sur cette liste, si quelqu'un :
> > - veut exprimer son opinion en faveur ou défaveur de la validité de ces
> > données dans OSM, et pour ou contre des reverts
> > - voire un appel à volontaires pour effectuer les reverts si les auteurs
> > initiaux ne s'en chargent pas
> > 
> > On Sat, 4 Apr 2020 at 21:52, althio  wrote:
> > 
> > > Bonjour,
> > >
> > > Merci pour le suivi, les renseignements complémentaires et la mise à jour
> > > des informations.
> > >
> > > > Alors, en regardant plus en détails, sur les deux catégories de données 
> > > > :
> > >> >
> > >> > - données des contributeurs (commentaire) : je n'ai pas trouvé non plus
> > >> de
> > >> >   Terms of Services ou équivalent, donc c'est effectivement une zone
> > >> >   grise.  Je vais demander.
> > >>
> > >> Ils n'en ont effectivement pas.  Du point de vue d'OSM, on peut 
> > >> considérer
> > >> qu'ils nous ont accordé une licence et que la base juridique de cet 
> > >> accord
> > >> vis-à-vis de leurs utilisateurs

Re: [Talk-GB] Q2 2020 Quarterly project GP Surgeries and health sites

2020-04-16 Per discussione Andy Mabbett

On Thu, 16 Apr 2020 at 15:32, Peter Neale  wrote:
>
> "Anyone?"  Huh?  (seems to be lacking the back-story!)

Apologies; that was meant to be a quote of this email:

   https://lists.openstreetmap.org/pipermail/talk-gb/2020-April/024410.html

in which I asked:

How are we showing pharmacy references like those in:

https://www.pharmacyregulation.org/registers/pharmacy/registrationnumber/1124246

https://www.nhs.uk/Services/pharmacies/Overview/DefaultView.aspx?id=9164

Do we have an exemplar for pharmacies (or several, by type:
stand-alone shop; in GP practice/ medical centre; in supermarket; in
Boots-style shop)?

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

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

Re: [Talk-it] Covid-19 - Buoni acquisto alimentari

Am Do., 16. Apr. 2020 um 17:04 Uhr schrieb dam...@damjan.net <
dam...@damjan.net>:

> Salve a tutti!
>
> Se ho ben capito per segnalare che un esercizio accetta i buoni
> alimentari/buoni spesa forniti dal comune dobbiamo usare il tag:
>
> payment:service_vouchers:covid19=yes
>
> Giusto?
> E per segnalare che lo stesso esercizio applica lo sconto p.es. del 10%
> sugli acquisti con il buono?
>


e per segnalare che c'è un bonus del 10% per famiglie con figli che si
registrano, ma solo il giovedì, però durante il covid19 anche il martedì ed
il mercoledì?


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

[Talk-it] Covid-19 - Buoni acquisto alimentari

2020-04-16 Per discussione dam...@damjan.net

Salve a tutti!

Se ho ben capito per segnalare che un esercizio accetta i buoni 
alimentari/buoni spesa forniti dal comune dobbiamo usare il tag:

payment:service_vouchers:covid19=yes

Giusto?
E per segnalare che lo stesso esercizio applica lo sconto p.es. del 10% sugli 
acquisti con il buono?


Grazie
Damjan

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

Re: [Talk-GB] Q2 2020 Quarterly project GP Surgeries and health sites

2020-04-16 Per discussione Peter Neale via Talk-GB

Thanks for pointing out how to import and convert the file.  After a bit of 
trial and error, I discovered how to get Excel to use the "¬" as the delimiter 
and (as you said), the addresses are quite inconsistent, but the data all lines 
up again in the Post Code Column.  There are some further issues in the 
ParentName Column, with the County sometimes duplicated there and sometimes 
there instead of the County Column. 
Thank you for taking me a step forward in my "How to Use Excel" course!
Regards,Peter

On Thursday, 16 April 2020, 13:52:06 BST, Robert Whittaker (OSM lists) 
 wrote:  

 On Thu, 16 Apr 2020 at 12:27, Peter Neale  wrote:
> I tried following the link to your proposed new source of “official” data, 
> but none of the 3 links to the data worked very well for me.
>
> Link 1:  (API format) led to http 404 error.
> Link 2  (CSV(TSV) format – led to http 404 error
> Link 3  (XSV format) downloaded a file with a “.csv” file extension that 
> seemed to be tab-separated, rather than comma-separated.  I took that into a 
> text editor and did a global Find and Replace of Tab with Comma.  The 
> resultant .csv file loaded into Excel just fine, but it has over 11,000 lines 
> and many of them must now have additional commas, because a number of fields 
> are right-shifted (Post Code in the Latitude Column, Latitude in the 
> Longitude Column, etc.)  Also, over 700 have Blank in the Address1 Field, 
> with the whole address in Address 2, Address 3, etc.  Then quite a few (from 
> my sample in the first 30) have County values in the ParentName Field.  So I 
> fear that, unless you can do a better conversion than I did (and you almost 
> certainly could, I know!) you will have a lot of manual cleaning up to do, 
> before you can use this data.

Yes, the first two links at
https://data.gov.uk/dataset/e373eb6a-fffd-48e5-b306-71eb17f97af2/pharmacies
are broken for me as well. For the third link, it looks like they
tried to do CSV, but didn't understand how to escape commas within the
fields, and so opted to use a different character "¬" instead. If you
import this into a spreadsheet, and tell it to use just "¬" as the
column separator, I think it works out fine, with all the entries in
the right place. (You can certainly do this with LibreOffice; I'm not
sure about Excel.) The address lines seem to be used inconsistently,
but everything is back aligned when you get to the postcode field.

Best wishes,

Robert.

-- 
Robert Whittaker

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

Re: [Talk-GB] prow_ref format for Dorset Public Rights of Way

2020-04-16 Per discussione Nick Whitelegg

>Based on this, my preference would be to standardise on the "SE4/22"
>style format for the prow_ref in Dorset, and convert any other
>instances found to this. What does everyone else think? I'll invite
>Nick Whitelegg (who developed the "map the paths" site) and also a few
>mappers who've made significant contributions to Dorset PRoW's in OSM
>to this thread to get their input too.


Hello Robert,

I wasn't familiar with the situation in Dorset but MapThePaths uses the 'SE 
4/22' scheme (actually it appears as 'SE 4 22') so if people want to use MTP as 
a source for prow_refs, then that would be the format to use.

In terms of how I arrive at the references, I sourced the data from the rowmaps 
site and applied a script which looked for a particular field (I forget its 
name) in the rowmaps data. This is done consistently across all counties.

I don't really mind too much what people use to be honest, obviously something 
like 'Studland FP 1' or similar would be more descriptive, but would require an 
extra step to look up the parish name.

Maybe we should develop some sort of (crowd-sourced?) service which looks up 
parishes based on parish codes to allow easy contribution of descriptive 
prow_refs?

On the other hand some counties do not use parish refs at all in hhe number, 
though they do mention them in the full ref (e.g. FERNHURST 1254). The 
Chichester district of West Sussex (not OGL, by the way - unfortunately from my 
POV as it's an area I'm interested in) appears to use a simple number for all 
PROW refs, ranging from about 1-3500. This is not consistent in a given parish, 
e.g. numbers between 1200-1299 appear to be spread between Fernhurst, Lynchmere 
and Milland parishes.

Nick





From: Robert Whittaker (OSM lists) 
Sent: 16 April 2020 14:18
To: talk-gb 
Subject: [Talk-GB] prow_ref format for Dorset Public Rights of Way

I've recently been looking at increasing the coverage of my PRoW
comparison tool https://osm.mathmos.net/prow/progress/ by adding new
counties. In particular, I've been looking at the data from Dorset.
I've hit a small issue though, in that the council uses two different
formats for their Right of Way Numbers. We really need to just select
one for the county in order to be consistent in OSM.

One format has a parish code followed by a slash and then the route
number within the parish (e.g. "SE4/22" for path number 22 in
Affpuddle and Turnerspuddle parish). The other would be to use the
full parish name, right of way type, and number. I asked their
Definitive Map officer about this and got the response:

"Both systems are used in parallel. For mapping (where the status and
parish are obvious) and for internal use, we use the numbering system,
but when reporting to Committee members or members of the public who
will not be familiar with the numbering system, we name the parish and
describe the status. Our sealed statements are listed by named parish,
status and route number. Our working statement spreadsheet uses parish
number, status and route number."

The "SE4/22" style numbers are what are used on Dorset Council's own
online map at 
https://www.dorsetcouncil.gov.uk/countryside-coast-parks/rights-of-way/rights-of-way-map-where-to-walk-ride-or-cycle.aspx
. Currently in OSM we have about 394km of routes in Dorset using this
style in the prow_ref tag, and another 98km using this style with a
space instead of the slash. That a total of around 492km based on the
parish codes and numbers. Conversely, there's only around 125km of
routes in Dorset that have a prow_ref tag that includes a parish name.

Based on this, my preference would be to standardise on the "SE4/22"
style format for the prow_ref in Dorset, and convert any other
instances found to this. What does everyone else think? I'll invite
Nick Whitelegg (who developed the "map the paths" site) and also a few
mappers who've made significant contributions to Dorset PRoW's in OSM
to this thread to get their input too.

Best wishes,
Robert.

--
Robert Whittaker

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

Re: [Talk-GB] Q2 2020 Quarterly project GP Surgeries and health sites

2020-04-16 Per discussione Peter Neale via Talk-GB

"Anyone?"  Huh?  (seems to be lacking the back-story!)
Regards,Peter

On Thursday, 16 April 2020, 15:16:45 BST, Andy Mabbett 
 wrote:  
 
 Anyone?

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

Re: [Talk-GB] prow_ref format for Dorset Public Rights of Way

2020-04-16 Per discussione Tony OSM

Hi Rob

There is a very similar state in Lancashire, I can imagine the
Lancashire officer providing a very similar response to that from Dorset.

Dorset are saying that their definitive statement is listed by named
parish, status and route number.

I believe that as the public definitive reference is named parish,
status and route number then that should be what is in OSM, using number
references looks to me like an internal workaround for earlier computers
and spreadsheets.

Using named parish, status and route number also makes it easier to use
on maps - eg Andy Townsends
https://map.atownsend.org.uk/maps/map/map.html#zoom=13=53.6423=-2.5975

Regards and mapsafe

Tony Shield

TonyS999

On 16/04/2020 14:18, Robert Whittaker (OSM lists) wrote:

I've recently been looking at increasing the coverage of my PRoW
comparison tool https://osm.mathmos.net/prow/progress/ by adding new
counties. In particular, I've been looking at the data from Dorset.
I've hit a small issue though, in that the council uses two different
formats for their Right of Way Numbers. We really need to just select
one for the county in order to be consistent in OSM.

One format has a parish code followed by a slash and then the route
number within the parish (e.g. "SE4/22" for path number 22 in
Affpuddle and Turnerspuddle parish). The other would be to use the
full parish name, right of way type, and number. I asked their
Definitive Map officer about this and got the response:

"Both systems are used in parallel. For mapping (where the status and
parish are obvious) and for internal use, we use the numbering system,
but when reporting to Committee members or members of the public who
will not be familiar with the numbering system, we name the parish and
describe the status. Our sealed statements are listed by named parish,
status and route number. Our working statement spreadsheet uses parish
number, status and route number."

The "SE4/22" style numbers are what are used on Dorset Council's own
online map at
https://www.dorsetcouncil.gov.uk/countryside-coast-parks/rights-of-way/rights-of-way-map-where-to-walk-ride-or-cycle.aspx
. Currently in OSM we have about 394km of routes in Dorset using this
style in the prow_ref tag, and another 98km using this style with a
space instead of the slash. That a total of around 492km based on the
parish codes and numbers. Conversely, there's only around 125km of
routes in Dorset that have a prow_ref tag that includes a parish name.

Based on this, my preference would be to standardise on the "SE4/22"
style format for the prow_ref in Dorset, and convert any other
instances found to this. What does everyone else think? I'll invite
Nick Whitelegg (who developed the "map the paths" site) and also a few
mappers who've made significant contributions to Dorset PRoW's in OSM
to this thread to get their input too.

Best wishes,
Robert.

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

Re: [Talk-GB] Q2 2020 Quarterly project GP Surgeries and health sites

2020-04-16 Per discussione Andy Mabbett

Anyone?

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

Re: [OSM-talk-fr] formatage no de téléphone

2020-04-16 Per discussione Pierre-Olivier GREGOIRE

C'est la bibliothèque que google utilise dans android si j'ai bien compris
donc ca doit couvrir tous les pays je pense ;)

Le jeu. 16 avr. 2020 à 14:38, Yves P.  a écrit :

>
> Pour info Il y a une bibliotheque libre fournie par Google en js et java
> qui permet de passer de la forme locale a l'international et inversement ::
> https://github.com/google/libphonenumber
> La page liste des portages en python et autre
>
> Merci cool :)
>
> Ça évite de réinventer la roue et ça marche pour plein de pays (tous ?)
> Un détail, la bibliothèque indique que mon n° de mobile est chez SFR :
> perdu :D
>
> Comme me l'on fait remarqué 2 personnes assidues, le formatage de n° comme
> "0800 130 000
> " est cassé.
> Dans CRO, on peut par exemple ne pas reformater un n° si il contient des
> espaces (pour la France).
> Ou alors laisser ça aux éditeurs (c'est le cas actuellement dans CRO).
>
> Et pour les données ouvertes, faire ça automatiquement à l'import, en
> prévenant l'opérateur en cas de doute.
> (en France, un groupement de 3 chiffres est probablement voulu).
>
> Pour les développeurs de JOSM, cette bibliothèque est faite pour vous ;)
>
> __
> Yves
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-GB] prow_ref format for Dorset Public Rights of Way

2020-04-16 Per discussione Robert Whittaker (OSM lists)

Best wishes,
Robert.

--
Robert Whittaker

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

[OSM-talk-fr] Ça reste ouvert : saisie des horaires

Bonjour,

En nettoyant OSM, je suis tombé sur des opening_hours un peu bizarre.
De mémoire, https://openingh.openstreetmap.de/evaluation_tool/ n'a pas trop 
apprécié.

Cela ressemblait à une juxtaposition de jours, sans séparateur ";".
C'était factorisable "Mo-Sa:" 

En découvrant et en testant le formulaire de saisie dans CRO, je pense que le 
problème vient de là.
Le contributeur débutant à dû créer les horaires jour par jour.

Difficile décrire… :/ Je vous laisse essayer.
Avez-vous rencontré des problèmes ?

__
Yves

PS: peut-être en lien avec 
https://github.com/osmontrouge/caresteouvert/issues/338 ?


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

Re: [Talk-GB] Q2 2020 Quarterly project GP Surgeries and health sites

2020-04-16 Per discussione Robert Whittaker (OSM lists)

On Thu, 16 Apr 2020 at 12:27, Peter Neale  wrote:
> I tried following the link to your proposed new source of “official” data, 
> but none of the 3 links to the data worked very well for me.
>
> Link 1:  (API format) led to http 404 error.
> Link 2  (CSV(TSV) format – led to http 404 error
> Link 3  (XSV format) downloaded a file with a “.csv” file extension that 
> seemed to be tab-separated, rather than comma-separated.  I took that into a 
> text editor and did a global Find and Replace of Tab with Comma.  The 
> resultant .csv file loaded into Excel just fine, but it has over 11,000 lines 
> and many of them must now have additional commas, because a number of fields 
> are right-shifted (Post Code in the Latitude Column, Latitude in the 
> Longitude Column, etc.)  Also, over 700 have Blank in the Address1 Field, 
> with the whole address in Address 2, Address 3, etc.  Then quite a few (from 
> my sample in the first 30) have County values in the ParentName Field.  So I 
> fear that, unless you can do a better conversion than I did (and you almost 
> certainly could, I know!) you will have a lot of manual cleaning up to do, 
> before you can use this data.

Yes, the first two links at
https://data.gov.uk/dataset/e373eb6a-fffd-48e5-b306-71eb17f97af2/pharmacies
are broken for me as well. For the third link, it looks like they
tried to do CSV, but didn't understand how to escape commas within the
fields, and so opted to use a different character "¬" instead. If you
import this into a spreadsheet, and tell it to use just "¬" as the
column separator, I think it works out fine, with all the entries in
the right place. (You can certainly do this with LibreOffice; I'm not
sure about Excel.) The address lines seem to be used inconsistently,
but everything is back aligned when you get to the postcode field.

Best wishes,

Robert.

-- 
Robert Whittaker

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

Re: [OSM-talk-fr] formatage no de téléphone


> Pour info Il y a une bibliotheque libre fournie par Google en js et java qui 
> permet de passer de la forme locale a l'international et inversement :: 
> https://github.com/google/libphonenumber 
> 
> La page liste des portages en python et autre 
Merci cool :)

Ça évite de réinventer la roue et ça marche pour plein de pays (tous ?)
Un détail, la bibliothèque indique que mon n° de mobile est chez SFR : perdu :D

Comme me l'on fait remarqué 2 personnes assidues, le formatage de n° comme 
"0800 130 000 " 
est cassé.
Dans CRO, on peut par exemple ne pas reformater un n° si il contient des 
espaces (pour la France).
Ou alors laisser ça aux éditeurs (c'est le cas actuellement dans CRO).

Et pour les données ouvertes, faire ça automatiquement à l'import, en prévenant 
l'opérateur en cas de doute.
(en France, un groupement de 3 chiffres est probablement voulu).

Pour les développeurs de JOSM, cette bibliothèque est faite pour vous ;)

__
Yves

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

Re: [OSM-talk-fr] formatage no de téléphone

2020-04-16 Per discussione Pierre-Olivier GREGOIRE

Pour info Il y a une bibliotheque libre fournie par Google en js et java
qui permet de passer de la forme locale a l'international et inversement ::
https://github.com/google/libphonenumber
La page liste des portages en python et autre

Le jeu. 16 avr. 2020 à 10:56, Yves P.  a écrit :

>
> reformatter au passage le n°
>
>
> quelqu'un avait fait un petit programme
> lors d'une édition de masse précédente,
> ce serrait surement utile de le retrouver
> (le = le programe et/ou la personne :p)
>
>
> J'ai fait ça hier soir dans OpenRefine avec quelques regex.
> Au passage ça rempli soit le champ *phone* soit le champ *mobile*.
>
> Pour remplir les n° de :
>
>- fixe:
>replace(replace(join(splitByLengths(replace(value,"/",""),2,2,2,2,2),"
>"),/^0/,"+33 "),/^\+33 [^67].*/,"")
>- mobile : 
> replace(replace(join(splitByLengths(replace(value,"/",""),2,2,2,2,2),"
>"),/^0/,"+33 "),/^\+33 [67].*/,"")
>
>
> *Notes :*
> C'est la syntaxe GREL
> .
> value dans ce contexte est la valeur de la cellule "téléphone" d'un jeu de
> données.
> Je vire les "/" qui trainent dans les n° (j'aurais pu aussi mettre une
> regex pour supprimer aussi les espaces, points…)
>
> __
> Yves
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2020-04-16 Per discussione Allroads

Aanvullend:

In de BAG registratie staan ook OpenbareRuimte, die niet gebruikt worden voor 
een adres.

type kunstwerk, bruggen staan er meermaals in, dit is dan een verplicht item in 
de BGT , OpenbareRuimte_label.

Voorbeeld Leeuwenbrug geen adres aanwezig
type kunstwerk

https://bagviewer.kadaster.nl/lvbag/bag-viewer/index.html#?searchQuery=Leeuwenbrug=0=017130001066=179783.148=524782.59=4=017130001066

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

Re: [OSM-talk-fr] [caresteouvert] tag pour les marchands de marché

2020-04-16 Per discussione Nicolas Bétheuil

c'est bien ça
localisation=outdoor et reservation=required
mais du coup ce serait reservation:covid19=required parce que les jours de
marché on peut y acheter sans réserver

c'est effectivement un contournement plutôt qu'une entourloupe.
localisation officielle ? c'est un producteur normand du coup ça fait loin
non ?

Le jeu. 16 avr. 2020 à 12:55, Marc M.  a écrit :

> Bonjour,
>
> Le 16.04.20 à 09:19, Vincent Bergeot a écrit :
> > Fausse bonne idée, vraie mauvaise idée ? Petite impression de me perdre
> > dans les tags !
>
> si on veux le tager, je l'aurais fais ainsi :
>
> - la place de livraison (un amenity=parking_space est une partie
> d'un amenity=parking sinon c'est amenity=parking capacity=1)
> et access=delivery s'il y a un panneau "interdit sauf livraison".
> mais si ce n'est pas une place de livraison mais le lieux d'un marché,
> c'est pas bon...
>
> - le vendeur s'apparente un peu aux commerçant de marché qu'on tag
> parfois quand la position est fixe, sauf qu'il faut réserver avant
> dont shop=* opening_hours localisation=outdoor et reservation=required
>
> Mais faut-il tager le commerçant ? je n'ai pas vraiment l'impression
> que c'est un "commerce légal sur livraison" mais plutôt une entourloupe
> pour contourner les règles de fermeture des marchés pour confinement...
> du coup à minima, ce serrait sans doute bien tager sa localisation
> officielle (entreprise agricole ou bureau d'un vendeur)
>
> Cordialement,
> Marc
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Import Farmacie

2020-04-16 Per discussione Francesco Ansanelli

Ciao Andrea,

se c'è qualcuno che dubita dell'operato degli altri, quello, non sono di
certo io...
Anzi personalmente ammiro e rispetto tutto quello che hai fatto, ma non
reputo il tuo giudizio insindacabile.

Stranamente se aggiungo un tag ref io è un import, mentre, se gli altri
mettono la chiave univoca di un database esterno (mapillary nella
fattispecie) non lo è...(?)

Deduco dai toni evidentemente zolaiani che devo rendere conto a te delle
mie modifiche.
Le fonti sono state varie e variabili da caso a caso...Mi sono affidato a
pagine Facebook (che mi risulta usi e ridistribuisca dati OSM) per
verificare che fossero aperte o che non avessero cambiato indirizzo e per
la posizione indicativa, meno spesso ho trovato riscontri da siti delle
farmacie (avrebbero un copyright? forse, ma non credo di far loro un torto
a riportare 1 o 2 informazioni), sovente ho usato i dati già in OSM ovvero
gli indirizzi presenti sulla mappa, qualche volta immagini Mapillary (come
dicevi tu sono poche), conoscenza diretta (non sono chiuso in casa da
anni...), il dataset stesso (alcune erano decisamente coordinate
front-of-the-door), ricerche su internet (specialmente per le partite Iva
errate, ho cercato documenti pubblici, graduatorie, siti dei comuni,
ecc..ecc..).
Spero sia sufficiente come risposta, vedi anche quanto tempo ci è voluto
per aggiungere i dati... Un import vero e proprio sarebbe stato sicuramente
distruttivo.

Se ho sbagliato, l'ho fatto in buona fede, e spero che presto venga fatta
chiarezza da chi di dovere.

Saluti,
Francesco

Il giorno gio 16 apr 2020 alle ore 10:08 Andrea Musuruane <
musur...@gmail.com> ha scritto:

> Ciao Francesco,
>  hai fatto benissimo a scrivere al DWG, se hai dei dubbi sul mio
> operato o sul fatto che usare mapillary sia un import.
>
> Visto che siamo di nuovo in argomento, puoi cortesemente rispondere alle
> domande che ho fatto. Perché - e vorrei che fosse chiaro una volta per
> tutte - il problema non è l'import in se, il problema è che si stanno
> importato dei dati posizionati male e che la conflation è fatta male (cose
> che - seguendo le guidelines - sarebbero state evitate).
>
> Grazie,
>
> Andrea
>
>
>
> On Wed, Apr 15, 2020 at 7:52 PM Francesco Ansanelli 
> wrote:
>
>> Ciao Andrea,
>>
>> Grazie per la preziosa lezione.
>>
>> Ho scritto al DWG per chiedere un approfondimento. Mi sembra fosse stato
>> anche spiegato che mettere il tag mapillary=* come tag sugli oggetti è un
>> import, quindi ho chiesto la cancellazione di tutti gli oggetti che lo
>> contengono. Visto che penso tu voglia dare il buon esempio, per il tuo task
>> su pic4review, per favore occupati della redazione della pagina wiki e
>> inizia discussione su ml dedicata.
>>
>> Un abbraccio
>> Francesco
>>
>> Il mar 14 apr 2020, 14:39 Andrea Musuruane  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

Re: [Talk-GB] Q2 2020 Quarterly project GP Surgeries and health sites

2020-04-16 Per discussione Peter Neale via Talk-GB

Hi Robert,
I also don’t want to delete the objects completely; as they do exist, so we 
should be able to map them.  
However, I do take your point that a pharmacy which is not open to the public 
is not an “amenity” in OSM.  So my 2 “wholesale” pharmacies do not meet the 
wiki definition of “amenity=pharmacy: a shop where a pharmacist sells 
medications” > “A shop is a place selling retail products or services.”
I think they may both be better tagged as “office=company” (I know that one of 
them is also the head office of the company and they both function as offices). 
 I could add a Note explaining why they are not tagged as “amenity-pharmacy”, 
which might deter other mappers from using this tagging, in response to the 
flag generated by your excellent tool.
I tried following the link to your proposed new source of “official” data, but 
none of the 3 links to the data worked very well for me.
Link 1:  (API format) led to http 404 error.Link 2  (CSV(TSV) format – led to 
http 404 errorLink 3  (XSV format) downloaded a file with a “.csv” file 
extension that seemed to be tab-separated, rather than comma-separated.  I took 
that into a text editor and did a global Find and Replace of Tab with Comma.  
The resultant .csv file loaded into Excel just fine, but it has over 11,000 
lines and many of them must now have additional commas, because a number of 
fields are right-shifted (Post Code in the Latitude Column, Latitude in the 
Longitude Column, etc.)  Also, over 700 have Blank in the Address1 Field, with 
the whole address in Address 2, Address 3, etc.  Then quite a few (from my 
sample in the first 30) have County values in the ParentName Field.  So I fear 
that, unless you can do a better conversion than I did (and you almost 
certainly could, I know!) you will have a lot of manual cleaning up to do, 
before you can use this data.
The good news is that neither of my “wholesale” pharmacies is in that 
downloaded file, so, if you were able to use it as a source for your comparison 
tool, it would no longer flag them as “missing pharmacies”.
Good luck and thanks for the excellent tools, which keep me busy, trying to 
find missing post boxes, pharmacies and the like.

Regards,Peter 

On Wednesday, 15 April 2020, 16:46:43 BST, Robert Whittaker (OSM lists) 
 wrote:  

 On Sun, 12 Apr 2020 at 20:40, Peter Neale  wrote:
> I looked up my 2 "wholesale" pharmacies on the list.  Unfortunately, they are 
> both classed as "community", so will continue to be included in your checking 
> tool.
>
> So... ...should we:
> a.  Continue as we are: Plot them in OSM, tag them as pharmacies, but give 
> them a name that makes it clear that they are not publicly accessible?
> b.  Delete them from OSM, so that consumers don't think they are publicly 
> accessible.  (But they do exist and who knows what consumers will really want 
> to find?)  Then we could ask you to manually delete them from the checking 
> tool (but you probably won't want to keep doing that).
> c.  Do something else?

I certainly wouldn't advocate any inappropriate tagging just to keep
my tool happy! So if we don't think they should be amenity=pharmacy,
then we shouldn't tag them like that. While they may technically be
pharmacies, I would think that amenity=pharmacy is best reserved for
places that are amenities for the general public to use, which would
rule out option (a). As for (b), I wouldn't necessarily delete the
objects completely from OSM: if there's a business presence on the
ground, that could still be tagged. The question then is whether it's
worth tweaking my tool to remove these false positives. You could just
ignore the "missing pharmacy" markers local to you that you know are
wrong. As you say, I would have a manually maintained "ignore" list,
but that would be more effort for me.

What I'd prefer to to is to switch to a better data source for my
pharmacy list. There is a list of NHS-contracted pharmacies at
https://data.gov.uk/dataset/e373eb6a-fffd-48e5-b306-71eb17f97af2/pharmacies
which I think would closer match what we want for amenity=pharmacy,
but unfortunately that list appears to be England only. So I'd need to
find corresponding lists for Wales and Scotland. (NI isn't in the data
I'm currently using. I've found
https://www.psni.org.uk/registration/premises-registration/changes-to-the-premises-register/
but the data is all locked up in PDFs.) Can anyone help out here?

Robert.

-- 
Robert Whittaker

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

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

2020-04-16 Per discussione Allroads

https://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29

if the name can be spelled without an abbreviation, then don't abbreviate it.

Houden aan wat wereldwijd gebruikelijk is. OSM methodiek.
Het is niet voor niets, dat deze keuze is gemaakt, wereldwijd bruikbaarder
maken, o.a bij het zoeken

m.a.w
We hebben een OSM naam nodig, zonder abbreviation, zonder afkortingen, name=*
We hebben een officiele naam nodig, dat is de BAG naam inclusief afkortingen
official_name=*. Dit zou zonder kunnen als de OSM naam en de BAG naam niet
verschillen, maar toch misschien wenselijk om beide te vermelden.
We hebben een naam nodig, die we op de bordjes in de straat zien staan. OSM
survey/ mapillary. Wanneer deze verschillen van de OSM naam en/of de BAG naam.
We zien wel eens aparte schrijfwijzes, niet conform de naamsbesluit, hiervoor
zou een key loc_name=* of alt_name=* of anders, gebruikt kunnen worden.
(discussie) (Als Nominatim het gebruikt is het nog beter).

Het adres bestaat uit een woonplaats, OpenbareRuimte en nummer.

De OpenbareRuimte heeft een ID nummer.
Dit nummer toevoegen aan de weg, weg is een type Openbare Ruimte. Hiervoor
zouden we een nieuwe key kunnen gebruiken alleen voor Nederland NL_OR_ID of zo.
Dit kunnen we gezamenlijk besluiten, Nederlands ID.

Zo zijn er meerdere type Openbare Ruimte.
weg water spoorweg kunstwerk terrein landelijk gebied administratief gebied.

Voorbeeld type water, Bovenwijde
https://bagviewer.kadaster.nl/lvbag/bag-viewer/index.html#?geometry.x=203308.5428125=526004.15984375=7=170810032943=170801023938

Voorbeeld type landelijk gebied, Vliehors
https://bagviewer.kadaster.nl/lvbag/bag-viewer/index.html#?geometry.x=123755.1025=583248.75875=4=009610382731=009601385021

Bepaalde place=* Tag kunnen dan ook een NL_OR_ID krijgen.
https://wiki.openstreetmap.org/wiki/Key:place

Dan hebben we gelijk de koppeling met andere type OpenbareRuimte gemaakt.

De basis: De Gemeenten zijn bepalend bij, per naamgevingsbesluit om een
OpenbareRuimte te benoemen. Ik meen, dat zij nu, het enige lichaam is die
Openbare Ruimtes mogen benoemen.
Wet BAG bepaald, hoe een adres moet worden geregistreerd, er zijn dus ook
OpenbareRuimte, die wel benoemd zijn door Gemeentes, maar niet in der BAG
komen. OpenbareRuimte is niet een onderdeel van het adres.
Wet BGT: bepaald dat wanneer een OpenbareRuimte is opgenomen in de BAG, dat
deze als OpenbareRuimte_label moet worden opgenomen in de BGT (verplicht), BGT
OpenbareRuimte (vlak) (niet verplicht).

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

Re: [OSM-talk-fr] [caresteouvert] tag pour les marchands de marché

Bonjour,

Le 16.04.20 à 09:19, Vincent Bergeot a écrit :
> Fausse bonne idée, vraie mauvaise idée ? Petite impression de me perdre
> dans les tags !

si on veux le tager, je l'aurais fais ainsi :

- la place de livraison (un amenity=parking_space est une partie
d'un amenity=parking sinon c'est amenity=parking capacity=1)
et access=delivery s'il y a un panneau "interdit sauf livraison".
mais si ce n'est pas une place de livraison mais le lieux d'un marché,
c'est pas bon...

- le vendeur s'apparente un peu aux commerçant de marché qu'on tag
parfois quand la position est fixe, sauf qu'il faut réserver avant
dont shop=* opening_hours localisation=outdoor et reservation=required

Mais faut-il tager le commerçant ? je n'ai pas vraiment l'impression
que c'est un "commerce légal sur livraison" mais plutôt une entourloupe
pour contourner les règles de fermeture des marchés pour confinement...
du coup à minima, ce serrait sans doute bien tager sa localisation
officielle (entreprise agricole ou bureau d'un vendeur)

Cordialement,
Marc

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

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

2020-04-16 Per discussione St Niklaas

Hi,

Kunnen we in dit verlengde dan niet gelijk besluiten om de verwijzingen mbt 
data die een mindere graad van betrouwbaarheid kennen dan OSM  voor gebruik in 
of voor OSM uit te sluiten ? Met de uitzondering van Mapillaria daar dat 
uiteindelijk slechts een weergave van de werkelijkheid betreft.

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

Re: [OSM-talk] Replication errors

2020-04-16 Per discussione Andrzej Kępys

Thanks for all answers - latest version of osmosis fixed problem. I've 
also following operations tweeter from now on :)



Pozdrawiam
Andrzej Kępys
gg: 7918247
skype: jedrus305
tel: 605 997 440

W dniu 16.04.2020 o 10:35, Simon Poole pisze:

Sarah has already given the answer, but a small remark anyway: I would
suggest following the operations twitter account
https://twitter.com/OSM_Tech as that is the place you are most likely to
see short term notices about these kind of things.

Simon

Am 16.04.2020 um 08:10 schrieb Andrzej Kępys:

Hi All!

Since few days I have a replication errors using osmosis... Any ideas
how to fix it? Is there anythink I can do or it's sth about a data?

---START
Thu Apr 16 08:05:01 CEST 2020
No current.osc file found, downloading new one...
Apr 16, 2020 8:05:02 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Osmosis Version 0.46
Apr 16, 2020 8:05:02 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Preparing pipeline.
Apr 16, 2020 8:05:02 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Launching pipeline execution.
Apr 16, 2020 8:05:02 AM org.openstreetmap.osmosis.core.Osmosis run
INFO: Pipeline executing, waiting for completion.
Apr 16, 2020 8:05:03 AM
org.openstreetmap.osmosis.core.pipeline.common.ActiveTaskManager
waitForCompletion
SEVERE: Thread for task 1-read-replication-interval failed
org.openstreetmap.osmosis.core.OsmosisRuntimeException: Unable to
parse xml file /tmp/change8964114732320454958.tmp.  publicId=(null),
systemId=(null), lineNumber=1775, columnNumber=22.
 at
org.openstreetmap.osmosis.xml.v0_6.XmlChangeReader.run(XmlChangeReader.java:100)
 at
org.openstreetmap.osmosis.replication.v0_6.ReplicationDownloader.processChangeset(ReplicationDownloader.java:107)
 at
org.openstreetmap.osmosis.replication.v0_6.BaseReplicationDownloader.processReplicationFile(BaseReplicationDownloader.java:133)
 at
org.openstreetmap.osmosis.replication.v0_6.BaseReplicationDownloader.download(BaseReplicationDownloader.java:235)
 at
org.openstreetmap.osmosis.replication.v0_6.BaseReplicationDownloader.runImpl(BaseReplicationDownloader.java:271)
 at
org.openstreetmap.osmosis.replication.v0_6.BaseReplicationDownloader.run(BaseReplicationDownloader.java:350)
 at java.lang.Thread.run(Thread.java:748)
Caused by: org.xml.sax.SAXParseException; lineNumber: 1775;
columnNumber: 22; Invalid byte 2 of 4-byte UTF-8 sequence.
 at
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
Source)
 at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown
Source)
 at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
Source)
 at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
Source)
 at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
 at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
 at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
 at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
 at
org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
 at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
 at javax.xml.parsers.SAXParser.parse(SAXParser.java:195)
 at
org.openstreetmap.osmosis.xml.v0_6.XmlChangeReader.run(XmlChangeReader.java:90)
 ... 6 more
Caused by: org.apache.xerces.impl.io.MalformedByteSequenceException:
Invalid byte 2 of 4-byte UTF-8 sequence.
 at org.apache.xerces.impl.io.UTF8Reader.invalidByte(Unknown Source)
 at org.apache.xerces.impl.io.UTF8Reader.read(Unknown Source)
 at org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source)
 at org.apache.xerces.impl.XMLEntityScanner.scanLiteral(Unknown
Source)
 at org.apache.xerces.impl.XMLScanner.scanAttributeValue(Unknown
Source)
 at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanAttribute(Unknown
Source)
 at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown
Source)
 ... 16 more

Apr 16, 2020 8:05:03 AM org.openstreetmap.osmosis.core.Osmosis main
SEVERE: Execution aborted.
org.openstreetmap.osmosis.core.OsmosisRuntimeException: One or more
tasks failed.
 at
org.openstreetmap.osmosis.core.pipeline.common.Pipeline.waitForCompletion(Pipeline.java:146)
 at org.openstreetmap.osmosis.core.Osmosis.run(Osmosis.java:92)
 at org.openstreetmap.osmosis.core.Osmosis.main(Osmosis.java:37)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at

Re: [OSM-talk-fr] Application smartphone pour mettre simplement et rapidement une note avec photo(s) ?

Le 16.04.20 à 11:32, Yves P. a écrit :
>> niveau asso osm-fr, il y avait un projet de faire un démonstrateur

> Comme le fork SC que j'ai imaginé hier ?

on avait imaginé (par ordre de volume, histoire de commencer
par l'utilisable avant d'envisagEr l'hypothétique)
- une url pour ceux qui envoye leur photo en ligne de commande
- une interface web genre Lutim  (utilisée entre autre par framapic
qui ferme en janvier 2021, donc c'est d'actualité)

tout est possible ou presque... s'il y a des bras...

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

Re: [OSM-talk-fr] Application smartphone pour mettre simplement et rapidement une note avec photo(s) ?

2020-04-16 Per discussione European Water Project

Bonjour Marc,




*niveau asso osm-fr, il y avait un projet de faire un démonstrateurpour un
"quelque chose" qui à qui l'utilisateur aurait pu envoyerses photos osm et
qui (dans la réflexion de l'époque) aurait puenvoyer cela à mapillary et/ou
openstreetcam et serveur osm-fr  *

Ce n'est pas possible de prendre des photos individuelles et de les mettre
efficacement sur le serveur de Mapillary.   Jusqu'à présent il semblerait
que c'est plutôt Mapillary qui n'en voulait pas sinon ils auraient ajouté
cette fonctionnalité depuis longtemps dans leur application ou auraient
créé un API d'ajout de photos individuelles .  D'après mes connaissances
limitées sur le sujet, Mapillary a priorisé jusqu'à présent les
séquences de photos prises par des voitures et vélos et aussi des photos
360 dégrées pour des raisons techniques et commerciales. Je pense que
Mapillary pourrait reconsidérer et commencer à intégrer des photos
individuelles dans l'avenir proche. (fingers crossed).

Bien cordialement,

Stuart



On Thu, 16 Apr 2020 at 11:14, Marc M.  wrote:

> niveau asso osm-fr, il y avait un projet de faire un démonstrateur
> pour un "quelque chose" qui à qui l'utilisateur aurait pu envoyer
> ses photos osm et qui (dans la réflexion de l'époque) aurait pu
> envoyer cela à mapillary et/ou openstreetcam et serveur osm-fr
>
> les buts à l'époque était :
> - redondance entre les 2 services
> - avoir une base d'image si la communauté souhaite
> faire du "machine learning"
>
> L'idée est restée en l'état par manque de gens (tant pour
> discuter que pour coder)
>
> PS: je trouve tout à fait normal que la photo pour une photo
> soie supprimée X temps après la fermeture de la photo.
> si la photo est utile à plus long terme, elle doit être
> référencée par autre chose qu'une note
>
> Le 16.04.20 à 11:06, European Water Project a écrit :
> > Bonjour Yves,
> >
> > J'avais la même question sur le stockage temporaire des photos. Le
> > Readme  de sc-photo-service
> >  qui est une module
> > utilisée par StreetComplete explique pourquoi ils ont fait le choix de
> > garder les photos que
> > temporairement. https://github.com/exploide/sc-photo-service
> >
> > Je trouverai très intéressant qu'on trouve un streamlined workflow pour
> > prendre et stocker des photos de qualité sur un serveur accessible à
> > tous pour pouvoir les liées aux objets dans OSM (par exemple: /une
> > devanture de café ou un restaurant/).  Par qualité, c'est plutôt le
> > cadrage et la luminosité qui compte, pas la densité des pixels.
> >
> > Lundi j'ai parlé de ce sujet, d'ajout des photos individuels dans
> > Mapillary, avec Chris Beddow de Mapillary qui a écrit ticket #1780
> >  et hier avec
> > Fredrik Glans, le nouveau Directeur de Business Development de
> > Mapillary. Fredrik est également intéressé par cette fonctionnalité car
> > il y a des clients payants de Mapillary qui pourraient en profiter.
> >
> > Bien cordialement,
> >
> > Stuart
> >
> >
> >
> >
> >
> > On Thu, 16 Apr 2020 at 10:23, Yves P.  > > wrote:
> >
> >> J'ai (re)testé hier. Voici les notes générées
> >> <
> https://ent8r.github.io/NotesReview/?closed=true=pyrog=2020-04-11=2020-04-12=18/46.5763/5.75
> >.
> >
> > Et encore un test plus "grand".
> >
> > Mauvaises surprises :
> >
> >   * les photos sont redimensionnées :
> >   o je ne peux pas lire les références sur un poste de
> > transformation électrique.
> >   o la photo perd en résolution, dommage pour Wikimedia Commons
> >   * Il semble que dès que la note est fermée, elle est effacée du
> > site web de StreetComplete qui sert de stockage (temporaire)
> >   * pas d'enregistrement en pleine résolution dans la galerie du
> > smartphone (pour pallier les pb ci-dessus et une perte
> > éventuelle de données cf. issue #1768
> > )
> >
> >
> > Ça serait pratique de pouvoir choisir le site de stockage
> > (westnordost mais aussi Mapillary, Wikimedia Commons…).
> >
> > De plus le processus ne semble pas documenté (d'où mes mauvaises
> > surprises).
> > J'ai déposé un ticket #1781
> > 
> >
> > Autre détail, sans connexion 3/4/5 G, il me semble pas possible
> > d'envoyer la note.
> > Un mode offline serait pratique.
> > __
> > Yves
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
>
>
> ___
>

Re: [OSM-talk-fr] Application smartphone pour mettre simplement et rapidement une note avec photo(s) ?

2020-04-16 Per discussione osm . sanspourriel


Bonjour Yves et Stuart,

je regardais les possibilités au niveau d'OSMAND et je vois à condition
d'avoir activé les greffons d'édition et de prise de notes que si on
sélection une marque (par exemple) on a la possibilité d'"Ajouter des
photos".

Ceci passe par l'application Mapillary donc j'aurais tendance à dire que
ça existe déjà, rien à développer, juste utiliser les bons outils.

Ça ne répond pas exactement à la demande d'Yves. Il fera donc une
seconde étape : "signaler une anomalie OSM" et il mettra un texte style
"traiter la photo ajoutée".

Yves : tu peux aussi sauver ta photo en local depuis OSMAND.

Jean-Yvon

Le 16/04/2020 à 11:06, European Water Project -
europeanwaterproj...@gmail.com a écrit :

Bonjour Yves,

J'avais la même question sur le stockage temporaire des photos. Le
Readme  de sc-photo-service
 qui est une module
utilisée par StreetComplete explique pourquoi ils ont fait le choix de
garder les photos que temporairement.
https://github.com/exploide/sc-photo-service

Je trouverai très intéressant qu'on trouve un streamlined workflow
pour prendre et stocker des photos de qualité sur un serveur
accessible à tous pour pouvoir les liées aux objets dans OSM (par
exemple: /une devanture de café ou un restaurant/).  Par qualité,
c'est plutôt le cadrage et la luminosité qui compte, pas la densité
des pixels.

Lundi j'ai parlé de ce sujet, d'ajout des photos individuels dans
Mapillary, avec Chris Beddow de Mapillary qui a écrit ticket #1780
 et hier
avec Fredrik Glans, le nouveau Directeur de Business Development de
Mapillary. Fredrik est également intéressé par cette fonctionnalité
car il y a des clients payants de Mapillary qui pourraient en profiter.

Bien cordialement,

Stuart





On Thu, 16 Apr 2020 at 10:23, Yves P. mailto:yves.prat...@gmail.com>> wrote:


J'ai (re)testé hier. Voici les notes générées

.


Et encore un test plus "grand".

Mauvaises surprises :

  * les photos sont redimensionnées :
  o je ne peux pas lire les références sur un poste de
transformation électrique.
  o la photo perd en résolution, dommage pour Wikimedia Commons
  * Il semble que dès que la note est fermée, elle est effacée du
site web de StreetComplete qui sert de stockage (temporaire)
  * pas d'enregistrement en pleine résolution dans la galerie du
smartphone (pour pallier les pb ci-dessus et une perte
éventuelle de données cf. issue #1768
)


Ça serait pratique de pouvoir choisir le site de stockage
(westnordost mais aussi Mapillary, Wikimedia Commons…).

De plus le processus ne semble pas documenté (d'où mes mauvaises
surprises).
J'ai déposé un ticket #1781


Autre détail, sans connexion 3/4/5 G, il me semble pas possible
d'envoyer la note.
Un mode offline serait pratique.
__
Yves

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


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

Re: [OSM-talk-fr] Application smartphone pour mettre simplement et rapidement une note avec photo(s) ?

> Le Readme  de sc-photo-service  
> qui est une module utilisée par StreetComplete explique pourquoi ils ont fait 
> le choix de garder les photos que temporairement. 
> https://github.com/exploide/sc-photo-service 
>   
Merci :) Il est effectivement mentionné dans CONTRIBUTING.md 

 et ARCHITECTURE.md 

 que je n'avais pas lu (je cherchais dans la FAQ)

> Je trouverai très intéressant qu'on trouve un streamlined workflow pour 
> prendre et stocker des photos de qualité sur un serveur accessible à tous 
> pour pouvoir les liées aux objets dans OSM (par exemple: une devanture de 
> café ou un restaurant).
+1

> Par qualité, c'est plutôt le cadrage et la luminosité qui compte, pas la 
> densité des pixels.   
Les pixels aussi, car pensant récupérer la photo en pleine résolution, je n'ai 
pas fait de photos de détail.
Et oui aussi pour Mapillary, Wikimedia Commons…

> Lundi j'ai parlé de ce sujet, d'ajout des photos individuels dans Mapillary, 
> avec Chris Beddow de Mapillary qui a écrit ticket #1780 
> Merci :) Hier, 
> j'ai mis un thumb up

Je pensais à un fork de SC pour les newbies sans les quêtes et dédié aux 
"notes".
Mais autant intégrer ça dans SC.

Je réponds aussi à Marc :

> niveau asso osm-fr, il y avait un projet de faire un démonstrateur
> pour un "quelque chose" qui à qui l'utilisateur aurait pu envoyer
> ses photos osm et qui (dans la réflexion de l'époque) aurait pu
> envoyer cela à mapillary et/ou openstreetcam et serveur osm-fr
Comme le fork SC que j'ai imaginé hier ?

J'ai pensé aussi à un autre "stockage" et protocole de transmission : matrix ;)

En jouant avec le client Riot, j'ai remarqué qu'en faisant un drag'n'drop de 
photos, elles sont stockées sur le serveur Matrix.
J'imagine jusqu'à ce que la "room" soit fermée.

En utilisant ce protocole ouvert, d'autres clients peuvent récupérer 
automatiquement en en temps réel le flux de photos.
Sans passer par IRC ou RSS (c'est pour te taquiner Marc)

> les buts à l'époque était :
> - redondance entre les 2 services
> - avoir une base d'image si la communauté souhaite
> faire du "machine learning"
Intéressant.

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

Re: [OSM-talk-fr] Application smartphone pour mettre simplement et rapidement une note avec photo(s) ?

Le 16.04.20 à 11:13, Marc M. a écrit :
> PS: je trouve tout à fait normal que la photo pour une photo
> soie supprimée X temps après la fermeture de la photo.

houla, je voulais dire :
je trouve tout à fait normal que la photo pour une note
soie supprimée X temps après la fermeture de la note.

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

Re: [OSM-talk-fr] Application smartphone pour mettre simplement et rapidement une note avec photo(s) ?

niveau asso osm-fr, il y avait un projet de faire un démonstrateur
pour un "quelque chose" qui à qui l'utilisateur aurait pu envoyer
ses photos osm et qui (dans la réflexion de l'époque) aurait pu
envoyer cela à mapillary et/ou openstreetcam et serveur osm-fr

les buts à l'époque était :
- redondance entre les 2 services
- avoir une base d'image si la communauté souhaite
faire du "machine learning"

L'idée est restée en l'état par manque de gens (tant pour
discuter que pour coder)

PS: je trouve tout à fait normal que la photo pour une photo
soie supprimée X temps après la fermeture de la photo.
si la photo est utile à plus long terme, elle doit être
référencée par autre chose qu'une note

Le 16.04.20 à 11:06, European Water Project a écrit :
> Bonjour Yves,
> 
> J'avais la même question sur le stockage temporaire des photos. Le
> Readme  de sc-photo-service
>  qui est une module
> utilisée par StreetComplete explique pourquoi ils ont fait le choix de
> garder les photos que
> temporairement. https://github.com/exploide/sc-photo-service  
> 
> Je trouverai très intéressant qu'on trouve un streamlined workflow pour
> prendre et stocker des photos de qualité sur un serveur accessible à
> tous pour pouvoir les liées aux objets dans OSM (par exemple: /une
> devanture de café ou un restaurant/).  Par qualité, c'est plutôt le
> cadrage et la luminosité qui compte, pas la densité des pixels.   
> 
> Lundi j'ai parlé de ce sujet, d'ajout des photos individuels dans
> Mapillary, avec Chris Beddow de Mapillary qui a écrit ticket #1780
>  et hier avec
> Fredrik Glans, le nouveau Directeur de Business Development de
> Mapillary. Fredrik est également intéressé par cette fonctionnalité car
> il y a des clients payants de Mapillary qui pourraient en profiter.  
> 
> Bien cordialement,
> 
> Stuart 
> 
> 
> 
> 
> 
> On Thu, 16 Apr 2020 at 10:23, Yves P.  > wrote:
> 
>> J'ai (re)testé hier. Voici les notes générées
>> 
>> .
> 
> Et encore un test plus "grand".
> 
> Mauvaises surprises :
> 
>   * les photos sont redimensionnées :
>   o je ne peux pas lire les références sur un poste de
> transformation électrique.
>   o la photo perd en résolution, dommage pour Wikimedia Commons
>   * Il semble que dès que la note est fermée, elle est effacée du
> site web de StreetComplete qui sert de stockage (temporaire)
>   * pas d'enregistrement en pleine résolution dans la galerie du
> smartphone (pour pallier les pb ci-dessus et une perte
> éventuelle de données cf. issue #1768
> )
> 
> 
> Ça serait pratique de pouvoir choisir le site de stockage
> (westnordost mais aussi Mapillary, Wikimedia Commons…).
> 
> De plus le processus ne semble pas documenté (d'où mes mauvaises
> surprises).
> J'ai déposé un ticket #1781
> 
> 
> Autre détail, sans connexion 3/4/5 G, il me semble pas possible
> d'envoyer la note.
> Un mode offline serait pratique.
> __
> Yves
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 


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

Re: [OSM-talk-fr] Application smartphone pour mettre simplement et rapidement une note avec photo(s) ?

2020-04-16 Per discussione European Water Project

Bonjour Yves,

J'avais la même question sur le stockage temporaire des photos. Le Readme
de sc-photo-service  qui est
une module utilisée par StreetComplete explique pourquoi ils ont fait le
choix de garder les photos que temporairement.
https://github.com/exploide/sc-photo-service

Je trouverai très intéressant qu'on trouve un streamlined workflow pour
prendre et stocker des photos de qualité sur un serveur accessible à tous
pour pouvoir les liées aux objets dans OSM (par exemple: *une devanture de
café ou un restaurant*).  Par qualité, c'est plutôt le cadrage et la
luminosité qui compte, pas la densité des pixels.

Lundi j'ai parlé de ce sujet, d'ajout des photos individuels dans
Mapillary, avec Chris Beddow de Mapillary qui a écrit ticket #1780
 et hier avec
Fredrik Glans, le nouveau Directeur de Business Development de Mapillary.
Fredrik est également intéressé par cette fonctionnalité car il y a des
clients payants de Mapillary qui pourraient en profiter.

Bien cordialement,

Stuart

On Thu, 16 Apr 2020 at 10:23, Yves P.  wrote:

> J'ai (re)testé hier. Voici les notes générées
> 
> .
>
>
> Et encore un test plus "grand".
>
> Mauvaises surprises :
>
>- les photos sont redimensionnées :
>   - je ne peux pas lire les références sur un poste de transformation
>   électrique.
>   - la photo perd en résolution, dommage pour Wikimedia Commons
>- Il semble que dès que la note est fermée, elle est effacée du site
>web de StreetComplete qui sert de stockage (temporaire)
>- pas d'enregistrement en pleine résolution dans la galerie du
>smartphone (pour pallier les pb ci-dessus et une perte éventuelle de
>données cf. issue #1768
>)
>
>
> Ça serait pratique de pouvoir choisir le site de stockage (westnordost
> mais aussi Mapillary, Wikimedia Commons…).
>
> De plus le processus ne semble pas documenté (d'où mes mauvaises
> surprises).
> J'ai déposé un ticket #1781
> 
>
> Autre détail, sans connexion 3/4/5 G, il me semble pas possible d'envoyer
> la note.
> Un mode offline serait pratique.
> __
> Yves
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2020-04-16 Per discussione Richard Duivenvoorde

On 4/14/20 7:48 PM, Colin Smale wrote:
> On 2020-04-14 18:52, g.id...@zonnet.nl wrote:

>> 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.

In dit geval denk ik dat we in Nederland nu hebben besloten om BAG de
officiele basisregistratie te laten zijn?
En als ik naar bijvoorbeeld mijn straat kijk:

https://bag.basisregistraties.overheid.nl/bag/doc/openbare-ruimte/039230011160

Dan zie ik zelfs een verwijzing naar een "brondocument". Ik zou er
eigenlijk voor pleiten om in Nederland de BAG schrijfwijzen te hanteren
voor alle adressen en straten. Dat maakt data-koppelingen (op
straatnaam/adres) zo veel makkelijker.

Ik zag dat er (veel?) discussie is geweest om ook wikidata id's toe te
voegen:

https://lists.openstreetmap.org/pipermail/talk/2020-March/084260.html

Dus in mijn ogen zou het toevoegen van de BAG id's aan de adressen
(==verblijfobjecten toch?) verschillende voordelen hebben:
- koppelbaarheid van de OSM-adressen aan andere overheidsgerelateerde data
- mogelijkheid om BAG-updates te monitoren (hoewel ik begrijp dat hoewel
er staat 'source:BAG' men toch (straatnaam) aanpassingen maakt?)

In deze tijd waarin ook de overheid steeds meer into 'linked'-data is,
wordt het natuurlijk interessant om zelf ook 'linkable' te zijn?

Wordt het WFS-script nog wel eens gerund? En zou het dan mogelijk zijn
om de BAG-id's toe te voegen?
Of alleen voor beperkte delen van NL?

Groet,

Richard Duivenvoorde






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

Re: [OSM-talk-fr] formatage no de téléphone


>> reformatter au passage le n°
> 
> quelqu'un avait fait un petit programme
> lors d'une édition de masse précédente,
> ce serrait surement utile de le retrouver
> (le = le programe et/ou la personne :p)

J'ai fait ça hier soir dans OpenRefine avec quelques regex.
Au passage ça rempli soit le champ phone soit le champ mobile.

Pour remplir les n° de :
fixe: replace(replace(join(splitByLengths(replace(value,"/",""),2,2,2,2,2)," 
"),/^0/,"+33 "),/^\+33 [^67].*/,"")
mobile : replace(replace(join(splitByLengths(replace(value,"/",""),2,2,2,2,2)," 
"),/^0/,"+33 "),/^\+33 [67].*/,"")

Notes :
C'est la syntaxe GREL 
.
value dans ce contexte est la valeur de la cellule "téléphone" d'un jeu de 
données.
Je vire les "/" qui trainent dans les n° (j'aurais pu aussi mettre une regex 
pour supprimer aussi les espaces, points…)

__
Yves

___
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

2020-04-16 Per discussione Janko Mihelić

Čini se da iD to nema.. Onda možemo poklikati te offsete, vidjeti kako radi
u JOSM-u, i isključiti iD iz raspoloživih editora.

sri, 15. tra 2020. u 17:05 Hrvoje Bogner  napisao je:

> Imagery offset database je integriran u josm, ali trebamo za svaki dio
> Knina to složiti jer su različiti offseti, je li integriran u id to neznam
> ali sumnjam
>
> https://wiki.openstreetmap.org/wiki/Imagery_Offset_Database
>
> On 15. 04. 2020. 12:49, Janko Mihelić wrote:
>
> Ja sam za to da ipak sredimo sa pravim offsetom, vratit će nam se to na
> budućim snimkama. Je li moguće napraviti neke offsete i onda ih šerati tako
> da ih svi imaju? Znam da je postojao takav projekt, ali ne znam jel
> integriran u JOSM ili iD.
>
> uto, 14. tra 2020. u 23:09 Hrvoje Bogner  napisao je:
>
>> 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
>>
>
___
Talk-hr mailing list
Talk-hr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-hr

Re: [OSM-talk-fr] formatage no de téléphone

Le 16.04.20 à 10:34, Yves P. a écrit :
> reformatter au passage le n°

quelqu'un avait fait un petit programme
lors d'une édition de masse précédente,
ce serrait surement utile de le retrouver
(le = le programe et/ou la personne :p)

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

Re: [OSM-talk-fr] [caresteouvert] tag pour les marchands de marché

2020-04-16 Per discussione Nicolas Bétheuil

Je comprends le dérivé vers un lieu de livraison.
J'aurais préféré identifier un commerçant récurent de marché non couvert
qui pendant le confinement fait de la livraison.

Il doit manquer une négation dans la phrase
"Places réservées à de la livraison pour NE approvisionner PAS un magasin
mais directement des gens qui ont passé commande."

La place n'est pas, à ma connaissance "réservée", aucune idée s'il y a
autorisation de la mairie au quoi que ce soit. Juste tu appelles, le
marchand te dit "venez à tel heure, au lieu du marché récurrent, je vous
donnerais votre commande". Ça doit dépendre des places de parking dispo en
plus ...
Du coup la localisation est complexe. Peut être pas sa place dans OSM, vu
que c'est un peu tordu que ce soit une donnée géographique.

Le jeu. 16 avr. 2020 à 09:19, Vincent Bergeot  a
écrit :

> Le 15/04/2020 à 13:44, Nicolas Bétheuil a écrit :
>
> C'est un commerce qui n'est que sur le marché. Il n'a pas de réalité au
> quotidien. Ce n'est pas un primeur qui a pignon sur rue.
> Et pendant le confinement, il propose de retirer les commandes au cul du
> camion sur des horaires précis.
>
> Si je reprends le déroulé :
>
> Les gens passent commande par téléphone et récupère à un lieu donné leur
> commande.
>
> Le lieu géographique est donc un point de livraison, qui possède un numéro
> de téléphone associé pour la commande, avec des horaires réguliers, et où
> l'on peut trouver un certains types de produits
>
> cela me fait penser à :
>
> amenity=parking_space
> parking_space=delivery
>
> Places réservées à de la livraison pour approvisionner un magasin mais
> directement des gens qui ont passé commande.
>
> produce ensuite et opening_hours:covid19 ?
>
> Fausse bonne idée, vraie mauvaise idée ? Petite impression de me perdre
> dans les tags !
>
> Cependant cela peut devenir un volume non négligeable de données car les 2
> sites cités par ailleurs (https://www.produits-locaux.bzh/ et
> https://plateforme.produits-locaux-nouvelle-aquitaine.fr) sont justement
> axés sur des points de livraisons de produits locaux.
>
>
> @nicolas ma surprise ci-dessous ne voulait pas dire que ce n'est pas ce
> qu'il faut faire (en me relisant, je me trouve ambigu), je ne sais pas non
> plus comment taguer un lieu de livraison.
>
>
>
> Le mer. 15 avr. 2020 à 12:45, Vincent Bergeot  a
> écrit :
>
>> Le 15/04/2020 à 11:54, Nicolas Bétheuil a écrit :
>> > Bonjour,
>> >
>> > Comment tagguer un commerçant qui "continue" les marchés en commande
>> > par tel au cul du camion ?
>> > https://www.openstreetmap.org/node/7404967885
>> >
>> > J'ai souvenir d'une recommandation récente mais je n'arrive pas à
>> > remettre la main dessus
>>
>>
>> ce qui me surprend sur le POI c'est shop=greengroccer (c'est un magasin
>> de légume, qui peut s'entendre pour un stand de légule sur un marché).
>>
>> Dans le cas d'un lieu de livraison sur commande, je ne suis pas sur que
>> cela soit "correct".
>>
>> Pour les diverses recommandations, peut-être fais tu référence à cela :
>>
>> https://wiki.openstreetmap.org/wiki/FR:Key:opening_hours:covid19#Livraison.2C_vente_.C3.A0_emporter.2C_drive
>> ?
>>
>> à plus
>>
>>
>> --
>> Vincent Bergeot
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
> --
> 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] Replication errors

2020-04-16 Per discussione Simon Poole

Sarah has already given the answer, but a small remark anyway: I would
suggest following the operations twitter account
https://twitter.com/OSM_Tech as that is the place you are most likely to
see short term notices about these kind of things.

Simon

Am 16.04.2020 um 08:10 schrieb Andrzej Kępys:
> Hi All!
>
> Since few days I have a replication errors using osmosis... Any ideas
> how to fix it? Is there anythink I can do or it's sth about a data?
>
> ---START
> Thu Apr 16 08:05:01 CEST 2020
> No current.osc file found, downloading new one...
> Apr 16, 2020 8:05:02 AM org.openstreetmap.osmosis.core.Osmosis run
> INFO: Osmosis Version 0.46
> Apr 16, 2020 8:05:02 AM org.openstreetmap.osmosis.core.Osmosis run
> INFO: Preparing pipeline.
> Apr 16, 2020 8:05:02 AM org.openstreetmap.osmosis.core.Osmosis run
> INFO: Launching pipeline execution.
> Apr 16, 2020 8:05:02 AM org.openstreetmap.osmosis.core.Osmosis run
> INFO: Pipeline executing, waiting for completion.
> Apr 16, 2020 8:05:03 AM
> org.openstreetmap.osmosis.core.pipeline.common.ActiveTaskManager
> waitForCompletion
> SEVERE: Thread for task 1-read-replication-interval failed
> org.openstreetmap.osmosis.core.OsmosisRuntimeException: Unable to
> parse xml file /tmp/change8964114732320454958.tmp.  publicId=(null),
> systemId=(null), lineNumber=1775, columnNumber=22.
> at
> org.openstreetmap.osmosis.xml.v0_6.XmlChangeReader.run(XmlChangeReader.java:100)
> at
> org.openstreetmap.osmosis.replication.v0_6.ReplicationDownloader.processChangeset(ReplicationDownloader.java:107)
> at
> org.openstreetmap.osmosis.replication.v0_6.BaseReplicationDownloader.processReplicationFile(BaseReplicationDownloader.java:133)
> at
> org.openstreetmap.osmosis.replication.v0_6.BaseReplicationDownloader.download(BaseReplicationDownloader.java:235)
> at
> org.openstreetmap.osmosis.replication.v0_6.BaseReplicationDownloader.runImpl(BaseReplicationDownloader.java:271)
> at
> org.openstreetmap.osmosis.replication.v0_6.BaseReplicationDownloader.run(BaseReplicationDownloader.java:350)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.xml.sax.SAXParseException; lineNumber: 1775;
> columnNumber: 22; Invalid byte 2 of 4-byte UTF-8 sequence.
> at
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown
> Source)
> at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown
> Source)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> at
> org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
> at javax.xml.parsers.SAXParser.parse(SAXParser.java:195)
> at
> org.openstreetmap.osmosis.xml.v0_6.XmlChangeReader.run(XmlChangeReader.java:90)
> ... 6 more
> Caused by: org.apache.xerces.impl.io.MalformedByteSequenceException:
> Invalid byte 2 of 4-byte UTF-8 sequence.
> at org.apache.xerces.impl.io.UTF8Reader.invalidByte(Unknown Source)
> at org.apache.xerces.impl.io.UTF8Reader.read(Unknown Source)
> at org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source)
> at org.apache.xerces.impl.XMLEntityScanner.scanLiteral(Unknown
> Source)
> at org.apache.xerces.impl.XMLScanner.scanAttributeValue(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanAttribute(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown
> Source)
> ... 16 more
>
> Apr 16, 2020 8:05:03 AM org.openstreetmap.osmosis.core.Osmosis main
> SEVERE: Execution aborted.
> org.openstreetmap.osmosis.core.OsmosisRuntimeException: One or more
> tasks failed.
> at
> org.openstreetmap.osmosis.core.pipeline.common.Pipeline.waitForCompletion(Pipeline.java:146)
> at org.openstreetmap.osmosis.core.Osmosis.run(Osmosis.java:92)
> at org.openstreetmap.osmosis.core.Osmosis.main(Osmosis.java:37)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:330)
> at
>

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

>> Comme c'était des téléphones mobiles (le perso du gérant ?), j'ai rajouté un 
>> mobile=06 54 32 10 98,  le message dans description:covid19 demandant 
>> d'appeler le mobile.
> You meant +33 6 54 32 10 98. Permet notamment l'appel automatique depuis un 
> portable (le 0 ne marche pas systématiquement : appel depuis un téléphone 
> étranger).

Oui. J'ai songé aussi à ce point :)

Il ne me semble pas que JOSM ou Osmose ne râle pour ça. Pour iD, je n'ai pas 
testé.

CRO pourrait reformatter au passage le n° (en fonction des pays) :
Il y a un peu n'importe quoi dans les données ouvertes, dans OSM… 
01.02.03.04.05
01-23-45-67-89
0123456789
+33 (0)1 23 45 67 89
Des n° de portables dans le tag pour les n° de fixe…
> J'avais l'intention de dire que les phone_1, phone_2, phone_3 (des gens en 
> manque d'idée - iD) ou que les téléphones séparés par des ; ont un manque 
> commun : ils sont interchangeables ce qui n'est pas le cas en fait.
> 
CRO pourrait aussi charger les numéros de ces clés
> Yves utilise la notion physique, j'aurais plus tendance à utiliser le rôle.
> 
??
> Il n'y a pas de clé mobile sur le wiki.
> 
OsmAnd gère indistinctement les clés mobile et contact:mobile ;)

Je n'étais pas chaud pour ces préfixes contact:* car ils sont plus long a 
saisir et qu'ils sont moins nombreux dans OSM.
Ils ont quand même l'avantage de regrouper les tags en lien avec un contact :D
Dans JOSM, quand il y a beaucoup de tag pour un objet OSM, la 
saisie/vérification est plus facile (pas ou moins besoin de faire défiler le 
panneau des tags)
> phone:reservation
> phone:order
> phone:delivery
> 
J'entends déjà Bryan Housel raller pour l'introduction de nouveaux tags (peu) 
utilisés ;D

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

Re: [OSM-talk-fr] Application smartphone pour mettre simplement et rapidement une note avec photo(s) ?