Re: [Talk-it] Kathmandu, OSM e il Politecnico di Milano
Alessandro wrote Il 30/04/2015 20:03, Aury88 ha scritto: ...la domanda dei miei amici era generica e cioè perchè le organizzazioni umanitarie dovrebbero preferire la nostra alle mappe google visto che la nostra non fa vedere neanche la foto satellitare...in poche parole mi si chiedeva i vantaggi nell'usare la mappa osm e non google per le ong. che poi la mappa osm sia più completa nelle zone comercialmente meno vantaggiose è una cosa che possono vedere benissimo da se...ma è un vantaggio che si ha solo in certe zone e non in molte altre dove la copertura di google è uguale e in alcuni casi superiore alla nostra. poi per carità: la velocità nell'inserimento dei dati è un altro fattore a nostro favore, quindi se una zona è mappata male sia siu osm che su google in osm nell'arco di pochi giorni si ha già tutto caricato sulla mappa mentre per google ci vuole più tempo ma le zone già complete in google? conviene sempre usare osm e perchè? Leggendo queste domande mi viene da sorridere visto che la differenza dovrebbe essere chiarissima dopo 5', provo a dire la mia. Cosa serve a dei soccorritori che arrivano in un paese straniero e a volte, come in questo a caso, con delle infrastrutture arretrate? Quali informazioni cercano su una mappa? La prima cosa è ovviamene il reticolo stradale: quali sono le strade (preferibilmente asfaltate) agibili a una colonna di soccorsi che comprende mezzi pesanti; quali di queste sono ancora transitabili al netto di ponti crollati o edifici collassati. Se non c'è asfalto cosa c'è, fango, terra compatta, ..? Nel caso dei ponti che portata hanno e quale larghezza; magari sono lesionati solo in parte. La mappatura di Google anche se fosse stata completa sino al giorno prima viene stravolta da eventi del genere. Occorre sapere ad occhio e croce che dimensione hanno gli insediamenti per capire quanti aiuti inviare (con le foto satellitari scattate in tempo quasi reale si mappano anche gli edifici). Se le strade sono impraticabili c'è possibilità di atterrare con elicotteri? Quella radura che si vede dalle foto aeree sarà ancora utilizzabile? Dove vengono piazzati i punti di raccolta per i rifugiati, dove gli ospedali da campo, dove si trovano fonti di acqua potabile. Quale percorso fanno i principali elettrodotti/gasdotti/condutture d'acqua? E' importante saperlo per poterle ripristinare. La maggior parte di queste informazioni vanno trasferite sui GPS di chi materialmente si muove sul territorio, quasi sempre senza telefono nè internet nè energia elettrica: sui camion di solito si ha un GPS e una radio che può coprire solo pochi chilometri. Sulle mappe bisogna inserire e/o evidenziare informazioni che normalmente sono marginali o che non esistono proprio. La situazione sul campo dev'essere costantemente aggiornata: la mappa del luogo viene renderizzata più volte al giorno e le mappe nei GPS aggiornate più spesso che si può. Se si può aiutare a mappare essendo dall'altra parte del globo e con mezzi semplici si può contribuire in migliaia lasciando alle persone in loco compiti di coordinamento. Questi sono giusto alcuni punti a vantaggio della soluzione OSM Alessandro Ale_Zena_IT ok, la flessibilità del nostro tagging è un vantaggio...purtroppo non l'ho visto molto sfruttare soprattutto in risposta della crisi dove spesso è richiesta una generica mappatura (livello della strada, mai dati tipo la superficie delle strade figurarsi dati sui limiti di larghezza ). tutte queste informazioni sono comunque presenti anche su una mappa google ed aggiustabili dai volontari (in zona o da remoto) come la mappatura google viene stravolta così viene stravolta la nostra...a quel punto? mi dici che l'unica differenza è la velocità di risposta e mappatura della community? ...ne parli come se non fosse possibile per gli utenti google mappare da locale e da remoto quando invece tramite google maker (che nelle zone di crisi ha tempi minori di approvazione rispetto al solito) + tutte le informazioni ottenibili tramite servizi aggiuntivi, come per esempio waze (già integrato nelle mappe), questi dati vengono raccolti sia dai volontari sia, inconsciamente, dai semplici utilizzatori. le mappe google mi sembra che da qualche anno permettano tra l'altro anche l'uso offline e penso che altri dati possano essere raccolti da offline (salvati nella cache e poi aggiornati sul serer centrale alla pria connessione disponibile). forse l'unico punto a nostro favore per questi argomenti è il fatto che Gmap non venga usata sui navigatori (credo), ma se si ha uno smartphone con connettività GPS? le nostre mappe che vantaggio hanno? condutture elettriche e acquedotti non li ho mai visti richiesti HOT...e sono comunque dati che sicuramente il governo locale ha e fornisce visto che per la loro costruzione da parte delle compagnie ci vuole, salvo stato di assoluta anarchia, delle autorizzazioni e dei progetti...le unità di crisi poi
Re: [Talk-at] OpenStreetMap Infostand auf den Linuxwochen Wien von 7. bis 9. Mai 2015 (fwd)
Auch wenn ich diesmal nicht mit dabei sein kann, möchte ich Stephans Aufruf unterstreichen! Traut euch, es ist viel informeller als man denkt, mehr wie ein Hacker-Event, bei dem hin und wieder ein Besucher nachfrägt, ob OpenStreetMap etwa mit Landkarten zu tun hat, weil ein Map im Namen vorkommt. ;-) lg, Markus Am 2015-05-02 um 07:20 schrieb Stephan Bösch-Plepelits: Hi! Wir haben jetzt die finale Information für die heurigen Linuxwochen bekommen. Leider haben sich noch nicht viele Leute zur Anwesenheit am Stand eingetragen. Wäre toll, wenn sich noch ein paar finden würden. Ist immer nett sich auch untereinander besser kennen zu lernen. - https://wiki.openstreetmap.org/wiki/Wien/Linuxwochen2015 Ich möchte hiermit vor allem jüngere Mitglieder (sowohl jung als in Alter, als auch in noch nicht lange registriert) dazu motivieren sich zu beteiligen. Vor den Gesprächen am Stand muss man keine Angst haben, meistens sind diese eher oberflächlich und niemand erwartet, dass man sich mit allen Aspekten der OSM gut auskennt. Außerdem könnt ihr ein paar von den älteren Hasen kennen lernen. Andreas: Du hast Materialien bereits besorgt, oder? Gibt es noch Dinge die ich mitnehmen kann? Ich freue mich wieder auf interessante Gespräche am Stand! gruesse, Stephan - Forwarded message from Linuxwochen Programm progr...@linuxwochen.at - Date: Fri, 01 May 2015 21:13:02 +0200 From: Linuxwochen Programm progr...@linuxwochen.at To: Stephan Bösch-Plepelits sk...@xover.htu.tuwien.ac.at Subject: OpenStreetMap Infostand auf den Linuxwochen Wien von 7. bis 9. Mai 2015 Hallo Stephan, wir freuen uns sehr den OpenStreetMap-Infostand auf den Linuxwochen Wien 2015 vom 7. bis 9. Mai in der FH Technikum Wien begrüßen zu dürfen. Im Ausstellungsbereich gibt es für unsere Aussteller: - Tische und Sesseln nach Bedarf - Bodensteckdosen (Verteiler bitte mitnehmen) - Internet via Wlan - eine Glaswand dahinter für Poster* bis zu A0 Größe - die Möglichkeit Dinge, die nicht transportabel sind, zu versperren. Die Anlieferung kann am Donnerstag 7. Mai ab 8:30 beginnen, der Aufbau ab 9:00, der Einlass für Besucher ist 10:00 und die Keynote beginnt ab 10:30. Der tägliche Abbau empfiehlt sich kurz nach Beginn des letzten Vortrages. Der Abbau am Samstag 9. Mai beginnt ab 16:00. Bitte die Linuxwochen in Euren Communities noch bewerben: - alle Infos: http://www.linuxwochen.at - das Programm: https://cfp.linuxwochen.at/de/LWW15/public/schedule - Linuxwochen Twitter: @linuxwochen Hashtag ist #lww15 * falls ihr noch einen Poster braucht, können wir euch helfen einen auszudrucken, also bitte diesen per PDF, oder PNG sobald als möglich schicken. Bevorzugt nicht vollflächig. Wir schauen was möglich ist. mit lieben Grüßen Christian Jeitler -- progr...@linuxwochen.at +43-699-81729005 Verein Linuxwochen Museumsplatz 1/49 1070 Wien ZVR: 320875837 - End forwarded message - ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-si] nov maper razsaja po Sloveniji
Mislim, da se je boljše vzdrževati komentarjev tipa correcting changes made by an idiot ipd. (razen če res gre za namerne, katastrofalne spremembe). Fant je začel mapirati pred komaj štirimi dnevi, pač začetniške napake. Po moje je problem predvsem v sistemu, ki omogoča kakršnokoli spreminjanje ne glede na izkušnje. lp Igor 2015-05-02 8:26 GMT+02:00 Stefan Baebler stefan.baeb...@gmail.com: Absolutno, sem mu povsod prijazno napisal razlog revertanja in predlog za izboljšavo (uporaba relacij). Lp, Štefan Najboljse da se mu se napise kaj dela narobe. Ceprav se to malokdaj uposteva. Sam sem poiskusal nekega mariborskega mapperja prepricat da naj uporablja ustaljeno shemo za wifi in ostalo pa vstraja na svoji ki se seveda ne prikazuje nikjer in vstavlja podatke v bistvu brez ucinka. Sent from my BlackBerry® PlayBook™ www.blackberry.com -- *From:* Stefan Baebler stefan.baeb...@gmail.com *To:* Blaž Lorger blaz.lor...@krs.net *CC:* OSM-Talk-Si talk-si@openstreetmap.org *Sent:* May 1, 2015 10:53 PM *Subject:* Re: [Talk-si] nov maper razsaja po Sloveniji Sem pregledal še vse njegove ostale prispevke in je žal v vseh zelo grobo dodajal bodisi pešpoti ali kolesarske steze po obstoječih poteh, zato sem revertal še vse ostale njegove prispevke. lp, Štefan 2015-05-01 21:55 GMT+02:00 Stefan Baebler: Ja, tudi od Ljubljanie do Višnje gore je naredil eno takšno dolgo stezico: https://www.openstreetmap.org/way/341018171 https://www.openstreetmap.org/changeset/30557944 Posnetek: http://imgur.com/DLZpqqg Sem mu vpisal komentar k chagesetu in brez zadržkov naredil revert ( https://www.openstreetmap.org/changeset/30701724 ) Ponavadi bi najprej odprl debato in mu predlagal, da zadevo popravi, ampak se bojim, da bi pri tem nastalo več škode kot koristi, odlašanje pa bi kvečjemu otežilo kasnejši revert. Ostali uporabnikovi prispevki: https://www.openstreetmap.org/user/Tanch/history Po komentarjih changesetov se bojim, da so vsi zelo podobni. lp, Štefan ___ Talk-si mailing list Talk-si@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-si ___ Talk-si mailing list Talk-si@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-si
Re: [Talk-it] Kathmandu, OSM e il Politecnico di Milano
Il 02/05/2015 08:50, Aury88 ha scritto: ok, la flessibilità del nostro tagging è un vantaggio...purtroppo non l'ho visto molto sfruttare soprattutto in risposta della crisi dove spesso è richiesta una generica mappatura (livello della strada, mai dati tipo la superficie delle strade figurarsi dati sui limiti di larghezza ). Se da una foto satellitare riesci a mappare anche altri dettagli benissimo. Si chiede che migliaia di persone si applichino a quello con strumenti che spesso usano già. Il resto lo mappa il personale sul campo. Se, ad esempio, leggi qui http://kathmandulivinglabs.org/blog/ CIT.:We also had a direct request from the humanitarian community to better map four VDCs in Dhading, where roads are not accessible. They have requested us to create maps focusing on open spaces for potential helicopter landings, potential sources of drinking water, and paths, in case they need to use mules for transport. A task related to this request has been created on Hot OSM ... mi dici che l'unica differenza è la velocità di risposta e mappatura della community? Ti consiglierei di leggere un pò di materiale su HOT ampiamente disponibile in rete, il primo link che mi viene in mente è http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Team leggendo alla sezione The Missing Maps Project The Missing Maps Project is an open collaboration founded by HOT, Medecins Sans Frontieres / Doctors Without Borders (MSF), American and British Red Cross ... ecco senti, manda una mail a MSF e la Croce Rossa e chiedi a loro perchè non usano Gmap, forse sono degli sprovveduti e non hanno valutato a pieno le potenzialità del progetto Google ... informazioni ottenibili tramite servizi aggiuntivi, come per esempio waze (già integrato nelle mappe), questi dati vengono raccolti sia dai volontari sia, inconsciamente, dai semplici utilizzatori. Eh sì, basta che ci siano utenti che viaggiano in Nepal e inviino dati attraverso internet coi loro dispositivi mobili. Forse dovresti farti un'idea più chiara di come sia la vita quotidiana in alcun paesi e poi cercare d'immaginare come diventi quando si abbattono certi cataclismi. Ieri sera guardavo un servizio su al Jazeera: guarda i vari eserciti di tutto il mondo quanti smartphone hanno immagino che tu il militare non l'abbia fatto :-) (io sì) :-( e in tempi normali (non durante crisi) ho lavorato nel Sud Est asiatico: non hai proprio idea ;-) le mappe google mi sembra che da qualche anno permettano tra l'altro anche l'uso offline e penso che altri dati possano essere raccolti da offline (salvati nella cache e poi aggiornati sul serer centrale alla pria connessione disponibile). forse l'unico punto a nostro favore per questi argomenti è il fatto che Gmap non venga usata sui navigatori (credo), ma se si ha uno smartphone con connettività GPS? le nostre mappe che vantaggio hanno? Non sapevo che le Gmappe possano mappare virtualmente qualsiasi caratteristica. Vogliamo tralasciare il fatto che se mappassimo su Gmap tutto il lavoro rimarrebbe loro proprietà? condutture elettriche e acquedotti non li ho mai visti richiesti HOT...e sono comunque dati che sicuramente il governo locale ha e fornisce mi iniziano a cascare le braccia le unità di crisi poi queste informazioni non le ho mai viste sfruttare visto che di solito usano gruppi elettrogeni e depuratori d'acqua mobili Dopo gli interventi di estrema urgenza si cerca di ripristinare i servizi di base, elettricità e acqua in primis I maggiori problemi ora sono dati dalla mancanza di acqua potabile. ripeto nulla che non possano comunque ottenere dal governo centrale senza doversi affidare alla mappatura da parte di OSM continuano a cascarmi le braccia quindi in definitiva i vantaggi sembrerebbero essere due: possibilità di mappare alcuni particolari marginali e la possibilità di renderizzare ciò che serve? ci rinuncio. Per carità, nulla di personale eh Alessandro Ale_Zena_IT ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Kathmandu, OSM e il Politecnico di Milano
girarsi_liste wrote Provo a dire la mia, perchè la nostra mappa, ma soprattutto i task aperti su hotosm, sono ambivalenti, hanno la precedenza sugli altri caricamenti normali, non permettono solo la mappatura rilevata da foto satellitari, ma permettono anche da chi è sul campo di poter segnalare e correggere eventuali inesattezze, in tempo praticamente reale, a differenza delle altre mappe che sarebbero utilizzate e gestite solo da poche persone, che per quanto competenti, ci metterebbero una vita a comunicare e modificare. con google maker gli utenti possono caricare direttamente i dati. tramite servizi google (che ormai prevedono una sorta di utilizzo offline delle mappe) anche gmap può essere utilizzata per la navigazione dagli utenti normali. nelle aree di crisi si attiva anche google (non mi ricordo il nome ma c'è) che mi sembra di capire abbassa di molto il livello dei controlli sui commit proprio per rispondere alla crisi più velocemente oltre ad intervenire, se può, generando foto aeree della zona. Quanto alle foto satellitari e aeree, riporterei come minimo l'esempio dell'alluvione in Sardegna, dove tramite accordi con la Regione Sardegna, si è potuto praticamente avere in tempo reale le foto per mappare i tratti interessati. mappe e foto che anche google può utilizzare, almeno limitatamente per rispondere alal crisi, sempre che la concessione non sia esclusiva per il progetto osm. - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/Kathmandu-OSM-e-il-Politecnico-di-Milano-tp5842207p5842840.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk] Chain Store Cleanup
On 02/05/2015 02:18, Andrew MacKinnon wrote: The same is true with an amenity=restaurant called Subway, since it should be amenity=fast_food and any Subway that is not the well known chain would almost certainly be sued by the well known chain and forced to changed its name. I wouldn't be so sure here. As an example, there's a bakery chain in the UK called Greggs. They're mostly tagged shop=bakery (with a few Subway-esque amenity=fast_food / cuisine=sandwich as well). Occasionally shops like this get wrongly tagged, sometimes as amenity=cafe, and there's always a temptation to just fix them. However, guess what? Yesterday I accidentally walked past a genuine Greggs amenity=cafe: http://www.openstreetmap.org/node/3490805096 It seems to share staff with the neighbouring bakery, but is entirely separate inside. A better approach to tidying up shops is the one that Math1985 has been using in the UK - add a note, and get some local feedback to separate the genuine errors from the unexpected ones: http://www.openstreetmap.org/note/303935 A Subway _restaurant_ is clearly a bit of a stretch, but not entirely impossible. I'd definitely add notes rather than remotely fixing these. Alternatively, perhaps contact the previous mapper? Cheers, Andy ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-it] Tag negozio car wrapping
Buongiorno a tutti, come posso taggare un negozio che si occupa di car wrapping? ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-si] nov maper razsaja po Sloveniji
Absolutno, sem mu povsod prijazno napisal razlog revertanja in predlog za izboljšavo (uporaba relacij). Lp, Štefan Najboljse da se mu se napise kaj dela narobe. Ceprav se to malokdaj uposteva. Sam sem poiskusal nekega mariborskega mapperja prepricat da naj uporablja ustaljeno shemo za wifi in ostalo pa vstraja na svoji ki se seveda ne prikazuje nikjer in vstavlja podatke v bistvu brez ucinka. Sent from my BlackBerry® PlayBook™ www.blackberry.com -- *From:* Stefan Baebler stefan.baeb...@gmail.com *To:* Blaž Lorger blaz.lor...@krs.net *CC:* OSM-Talk-Si talk-si@openstreetmap.org *Sent:* May 1, 2015 10:53 PM *Subject:* Re: [Talk-si] nov maper razsaja po Sloveniji Sem pregledal še vse njegove ostale prispevke in je žal v vseh zelo grobo dodajal bodisi pešpoti ali kolesarske steze po obstoječih poteh, zato sem revertal še vse ostale njegove prispevke. lp, Štefan 2015-05-01 21:55 GMT+02:00 Stefan Baebler: Ja, tudi od Ljubljanie do Višnje gore je naredil eno takšno dolgo stezico: https://www.openstreetmap.org/way/341018171 https://www.openstreetmap.org/changeset/30557944 Posnetek: http://imgur.com/DLZpqqg Sem mu vpisal komentar k chagesetu in brez zadržkov naredil revert ( https://www.openstreetmap.org/changeset/30701724 ) Ponavadi bi najprej odprl debato in mu predlagal, da zadevo popravi, ampak se bojim, da bi pri tem nastalo več škode kot koristi, odlašanje pa bi kvečjemu otežilo kasnejši revert. Ostali uporabnikovi prispevki: https://www.openstreetmap.org/user/Tanch/history Po komentarjih changesetov se bojim, da so vsi zelo podobni. lp, Štefan ___ Talk-si mailing list Talk-si@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-si
[OSM-talk] Smrender — State of Development Report
»Designed to produce nautical paper charts.« https://www.cypherpunk.at/2015/04/smrender-state-of-development-report/ Best regards, Bernhard signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-it] Kathmandu, OSM e il Politecnico di Milano
Qualcuno conosce enti (Croce Rossa, ONG o altro) che intervengono in caso di emergenza che usi le mappe OSM? Sarebbe una bella occasione per contattarli e presentare i vantaggi di OSM Dario -- Messaggio originale -- Da: Aury88 spacedrive...@gmail.com A: talk-it@openstreetmap.org Inviato: 02/05/2015 08:50:02 Oggetto: Re: [Talk-it] Kathmandu, OSM e il Politecnico di Milano Alessandro wrote Il 30/04/2015 20:03, Aury88 ha scritto: ...la domanda dei miei amici era generica e cioè perchè le organizzazioni umanitarie dovrebbero preferire la nostra alle mappe google visto che la nostra non fa vedere neanche la foto satellitare...in poche parole mi si chiedeva i vantaggi nell'usare la mappa osm e non google per le ong. che poi la mappa osm sia più completa nelle zone comercialmente meno vantaggiose è una cosa che possono vedere benissimo da se...ma è un vantaggio che si ha solo in certe zone e non in molte altre dove la copertura di google è uguale e in alcuni casi superiore alla nostra. poi per carità: la velocità nell'inserimento dei dati è un altro fattore a nostro favore, quindi se una zona è mappata male sia siu osm che su google in osm nell'arco di pochi giorni si ha già tutto caricato sulla mappa mentre per google ci vuole più tempo ma le zone già complete in google? conviene sempre usare osm e perchè? Leggendo queste domande mi viene da sorridere visto che la differenza dovrebbe essere chiarissima dopo 5', provo a dire la mia. Cosa serve a dei soccorritori che arrivano in un paese straniero e a volte, come in questo a caso, con delle infrastrutture arretrate? Quali informazioni cercano su una mappa? La prima cosa è ovviamene il reticolo stradale: quali sono le strade (preferibilmente asfaltate) agibili a una colonna di soccorsi che comprende mezzi pesanti; quali di queste sono ancora transitabili al netto di ponti crollati o edifici collassati. Se non c'è asfalto cosa c'è, fango, terra compatta, ..? Nel caso dei ponti che portata hanno e quale larghezza; magari sono lesionati solo in parte. La mappatura di Google anche se fosse stata completa sino al giorno prima viene stravolta da eventi del genere. Occorre sapere ad occhio e croce che dimensione hanno gli insediamenti per capire quanti aiuti inviare (con le foto satellitari scattate in tempo quasi reale si mappano anche gli edifici). Se le strade sono impraticabili c'è possibilità di atterrare con elicotteri? Quella radura che si vede dalle foto aeree sarà ancora utilizzabile? Dove vengono piazzati i punti di raccolta per i rifugiati, dove gli ospedali da campo, dove si trovano fonti di acqua potabile. Quale percorso fanno i principali elettrodotti/gasdotti/condutture d'acqua? E' importante saperlo per poterle ripristinare. La maggior parte di queste informazioni vanno trasferite sui GPS di chi materialmente si muove sul territorio, quasi sempre senza telefono nè internet nè energia elettrica: sui camion di solito si ha un GPS e una radio che può coprire solo pochi chilometri. Sulle mappe bisogna inserire e/o evidenziare informazioni che normalmente sono marginali o che non esistono proprio. La situazione sul campo dev'essere costantemente aggiornata: la mappa del luogo viene renderizzata più volte al giorno e le mappe nei GPS aggiornate più spesso che si può. Se si può aiutare a mappare essendo dall'altra parte del globo e con mezzi semplici si può contribuire in migliaia lasciando alle persone in loco compiti di coordinamento. Questi sono giusto alcuni punti a vantaggio della soluzione OSM Alessandro Ale_Zena_IT ok, la flessibilità del nostro tagging è un vantaggio...purtroppo non l'ho visto molto sfruttare soprattutto in risposta della crisi dove spesso è richiesta una generica mappatura (livello della strada, mai dati tipo la superficie delle strade figurarsi dati sui limiti di larghezza ). tutte queste informazioni sono comunque presenti anche su una mappa google ed aggiustabili dai volontari (in zona o da remoto) come la mappatura google viene stravolta così viene stravolta la nostra...a quel punto? mi dici che l'unica differenza è la velocità di risposta e mappatura della community? ...ne parli come se non fosse possibile per gli utenti google mappare da locale e da remoto quando invece tramite google maker (che nelle zone di crisi ha tempi minori di approvazione rispetto al solito) + tutte le informazioni ottenibili tramite servizi aggiuntivi, come per esempio waze (già integrato nelle mappe), questi dati vengono raccolti sia dai volontari sia, inconsciamente, dai semplici utilizzatori. le mappe google mi sembra che da qualche anno permettano tra l'altro anche l'uso offline e penso che altri dati possano essere raccolti da offline (salvati nella cache e poi aggiornati sul serer centrale alla pria connessione disponibile). forse l'unico punto a nostro favore per questi argomenti è il fatto che Gmap non venga usata sui
Re: [OSM-talk-fr] Normalisation du tag antenne
On ne tag pas les bandes, on unifie les émetteurs par opérateur et les opérateurs et les formes par station. Le Samedi 2 mai 2015 14h30, Eric Debeau eric.deb...@gmail.com a écrit : Oups, le mulot avait dérapé... Salut Je suis un peu perdu. J'ai mis des commentaires dans le pad. Concrètement, j'ai compris que l'on veut intégrer dans OSM des infos sur les supports et les antennes. J'ai compris que la proposition de Phlippe Verdy vise à intégrer dans le même tag différentes informations liées à un même support et pas à une antenne au sens ANFR ! Je trouve aussi très bien le modèle de représentation proposé par Philippe. Du coup, je ne comprends pas bien l'intérêt de proposer des tags liés à une antenne (au sens ANFR). Ce serait bien de clarifier le modèle de données de ANFR. 1 support support n station 1 station supporte n antennes 1 antenne supporte n émetteur 1 émetteur supporte n bandes Cas concret. Le support 687819 supporte 3 stations (sur un chateau d'eau) 0220220007 (FH) 022033 (E-Message) 090003 (Telecom) La station 090003 supporte 6 antennes (2 * 3 antennes panneau : une antenne par secteur) 325425 2487083 2487081 2487079 162468 162466 L'antenne 325425 supporte 2 émetteurs 3220894;GSM 1800 3220896;UMTS 2100 L'émetteur 3220896 supporte 3 bandes 1964,9;1979,7 1910,1;1915,1 2154,9;2169,7 Concrètement, on taggue comment ? Eric 2015-05-02 13:53 GMT+02:00 dHuy Pierre dh...@yahoo.fr: @Verdy: Je soutiens ton idée, je dis juste qu'il faudrait la voter ensemble, comme tu l'a dit, c'est l'affaire de la communauté. Le Samedi 2 mai 2015 13h43, Eric Debeau eric.deb...@gmail.com a écrit : Salut J'a Eric 2015-05-02 5:04 GMT+02:00 Philippe Verdy verd...@wanadoo.fr: Le 2 mai 2015 00:21, dHuy Pierre dh...@yahoo.fr a écrit : L'idée de Verdy est pas al en la matière mais non normalisé encore, OSM non plus n'est pas normalisé dans ses données: il crée lui même ses propres standards avec nous tous. J'ai proposé un truc générique proche de JSON mais plus compact et adapté aux usages d'OSM, rien de plus, mais assez générique pour coder des données structurées sans avoir pléthore de tags et de codages spécifiques pour chaque tag particulier (celui des lanes est actuellement une horreur, tout le monde s'y trompe). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Normalisation du tag antenne
Le 2 mai 2015 00:09, dHuy Pierre dh...@yahoo.fr a écrit :
@Jérome: Merci de l'avoir expliqué. Je suis opposé au tag communication:*=
cependant, en effet je trouve que ces tags surchargeraient trop en cas de
données multiples et ne serons jamais assez exhaustif, on risquerait de se
retrouver avec des key user defined...). Pour le type d'antenne, je propose
déjà antenna:shape (antenna:type éventuellement, j'étais partagé en
écrivant). Mais on reste sur le même set d'info a taguer.
@Lacombe, comme précisé plus haut, les commentaires sont souhaités entre
crochet, j'ai donc rajouté pour les tiens mais du coup j'y réponds ici. Ah
et si possible sur le pad les commentaires sont plus intéressants s'ils
constituent un texte à compléter et pas une remarque qui nécessite débat,
plus approprié à la ML (ou au canal de communication si subitement on s'y
connecte en masse), je supprimerai du texte les superflus mais il sera
possible d'en retrouver la trace dans l'interface.
Désolé, c'est nouveau pour moi.
- radio=repeater|relay ou autre: Non il s'agit d'élément immatériel,
difficile à vérifier en pratique et peu utile en carto, mais si quelqu'un
d'autre les souhaite, je suis à l'écoute de vos raisonnements. Je propose
antenna=yes seul sur un node en cas d'absence de support ponctuel (comme
sur un immeuble)
Il s'agit de stations au sens ANFR.
Au sens OSM, ces stations seraient plutôt des relations entre les supports
et les antennes.
Les stations supportent le service, notre principal problème quand on veut
ajouter ces infos sur l'antenne directement.
On évite les chaines de ce genre :
operator={[TDF{FM|FH}][Opérateur privé{PMR}][SNCF{GSM R}][FREE MOBILE{UMTS
900|UMTS 2100|LTE 2600}]}
En indiquant l'opérateur sur les stations plus que sur le support ou
l'antenne.
yes est une valeur par défaut, il faudrait utiliser le tag antenna pour y
ajouter d'autres infos (comme le type directement, au lieu de
antenna:type=*, on s'évite de créer une clé supplémentaire).
- tower:type=communication_tower conduisait jusqu'alors implicitement à
l'existence d'une antenne, ce que je défend c'est un tag unifié pour les
antennes. Mais donc non pas de confusions...
Implicitement, on peut affirmer plein de choses.
Que se passe-t-il si toutes les antennes ont été désinstallées ? On a
toujours un tower:type=communication_tower sans antennes.
Ces valeurs trappes font dire plein de choses et on a finalement pas l'info
qu'on cherche.
Avec les explications de cette nuit, je comprends mieux antenna=*, d'autant
que cette clé-ci est quand même moins sujette aux interprétations comme
pour la plupart des valeurs tower:type.
- Le fichier ANFR ne permettrait pas le placement: Relis ce qu'à écrit
Jérôme.
Non en effet : c'est bien ce que je disais. C'était une affirmation.
- Une antenne radar/ une antenne onde courte... etc sont des antennes
colossales qui se remarque facilement en milieu urbain et qui constituent
toujours un repère, de même à la campagne.
On est d'accord là-dessus, l'objet du commentaire n'était pas sur le côté
représentatif de l'antenne ou non mais dans sa place dans le modèle.
Bref, en relisant c'était un peu HS, autant pour moi.
- La base de données opencellid/mozstumbler est approximative, mais elle
peut etre utile dans des pays qui ne possède pas un équivalent de l'anfr ou
dont la base serait non libre. Cela donne une position approximative d'une
antenne télécom. d'où la précision déjà présente sur la localisation.
Pas forcément : ce genre de base recense des endroits où on capte, mais
l'antenne peut être à des dizaines de km.
Le GSM fixe un rayon de cellule de 35 km pour que la communication puisse
s'effectuer
Cependant on peut capter la cellule bien plus loin si l'opérateur ne prend
pas les dispositions nécessaires.
C'est pour ca qu'il y a toujours un problème avec openCellID et autres :
sans infos plus précises, on ne sais toujours pas où sont les antennes en
question.
On peut aussi être à côté d'une et en capter une bien plus loin.
J'ai laissé un commentaire parce que je ne comprends pas ce que tu veux y
dire. (J'ai intégré certains commentaires au texte aussi)
Les stations au sens ANFR ont pour principale utilité de savoir quel
service est derrière l'antenne.
L'antenne est uniquement faite pour une bande de fréquence. Après tu y fait
transiter ce que tu veux.
La preuve : GSM et GSM-R (communications sol/trains dans le ferroviaire)
sont tout de même deux choses bien différentes, pourtant les mêmes antennes
sont utilisées.
Donc si on ne sais pas ce qu'il y a derrière l'antenne, on ne peut pas dire
réellement quel service elle offre.
D'où l'utilité de mettre les stations ANFR sous forme de relation dans
laquelle on ajouterai les antennes, principaux objets physiques sur le
terrain on est d'accord.
Ce genre de relation permet d'éviter de surcharger en clé des objets
node/way (ici les antennes).
Peut-on commencer à compléter une page de proposition sur le wiki avec
Re: [OSM-talk-fr] Normalisation du tag antenne
Avant la proposition j'attends au moins une unité dans le camp talk-fr
:pOpencellid se base sur des séries de mesures cumulés pour estimé la position
de l'antenne en fonction de la réception. Ces estimations donnent une précision
de 100m (donc contestable mais intéressant).Bon je crois crois qu'on se
comprend pas pour les données du set ANFR, il y a la position GPS.Pour ta
relation je te laisse proposer ton modèle alternatif clairement avec la
relation. Et une fois le consens obtenu je le poste sur le wiki.
Le Samedi 2 mai 2015 15h37, François Lacombe fl.infosrese...@gmail.com a
écrit :
Le 2 mai 2015 00:09, dHuy Pierre dh...@yahoo.fr a écrit :
@Jérome: Merci de l'avoir expliqué. Je suis opposé au tag communication:*=
cependant, en effet je trouve que ces tags surchargeraient trop en cas de
données multiples et ne serons jamais assez exhaustif, on risquerait de se
retrouver avec des key user defined...). Pour le type d'antenne, je propose
déjà antenna:shape (antenna:type éventuellement, j'étais partagé en écrivant).
Mais on reste sur le même set d'info a taguer.
@Lacombe, comme précisé plus haut, les commentaires sont souhaités entre
crochet, j'ai donc rajouté pour les tiens mais du coup j'y réponds ici. Ah et
si possible sur le pad les commentaires sont plus intéressants s'ils
constituent un texte à compléter et pas une remarque qui nécessite débat, plus
approprié à la ML (ou au canal de communication si subitement on s'y connecte
en masse), je supprimerai du texte les superflus mais il sera possible d'en
retrouver la trace dans l'interface.
Désolé, c'est nouveau pour moi.
- radio=repeater|relay ou autre: Non il s'agit d'élément immatériel, difficile
à vérifier en pratique et peu utile en carto, mais si quelqu'un d'autre les
souhaite, je suis à l'écoute de vos raisonnements. Je propose antenna=yes seul
sur un node en cas d'absence de support ponctuel (comme sur un immeuble)
Il s'agit de stations au sens ANFR.
Au sens OSM, ces stations seraient plutôt des relations entre les supports et
les antennes.
Les stations supportent le service, notre principal problème quand on veut
ajouter ces infos sur l'antenne directement.
On évite les chaines de ce genre :
operator={[TDF{FM|FH}][Opérateur privé{PMR}][SNCF{GSM R}][FREE MOBILE{UMTS
900|UMTS 2100|LTE 2600}]}
En indiquant l'opérateur sur les stations plus que sur le support ou l'antenne.
yes est une valeur par défaut, il faudrait utiliser le tag antenna pour y
ajouter d'autres infos (comme le type directement, au lieu de antenna:type=*,
on s'évite de créer une clé supplémentaire).
- tower:type=communication_tower conduisait jusqu'alors implicitement à
l'existence d'une antenne, ce que je défend c'est un tag unifié pour les
antennes. Mais donc non pas de confusions...
Implicitement, on peut affirmer plein de choses.
Que se passe-t-il si toutes les antennes ont été désinstallées ? On a toujours
un tower:type=communication_tower sans antennes.
Ces valeurs trappes font dire plein de choses et on a finalement pas l'info
qu'on cherche.
Avec les explications de cette nuit, je comprends mieux antenna=*, d'autant que
cette clé-ci est quand même moins sujette aux interprétations comme pour la
plupart des valeurs tower:type.
- Le fichier ANFR ne permettrait pas le placement: Relis ce qu'à écrit Jérôme.
Non en effet : c'est bien ce que je disais. C'était une affirmation.
- Une antenne radar/ une antenne onde courte... etc sont des antennes
colossales qui se remarque facilement en milieu urbain et qui constituent
toujours un repère, de même à la campagne.
On est d'accord là-dessus, l'objet du commentaire n'était pas sur le côté
représentatif de l'antenne ou non mais dans sa place dans le modèle.
Bref, en relisant c'était un peu HS, autant pour moi.
- La base de données opencellid/mozstumbler est approximative, mais elle peut
etre utile dans des pays qui ne possède pas un équivalent de l'anfr ou dont la
base serait non libre. Cela donne une position approximative d'une antenne
télécom. d'où la précision déjà présente sur la localisation.
Pas forcément : ce genre de base recense des endroits où on capte, mais
l'antenne peut être à des dizaines de km.
Le GSM fixe un rayon de cellule de 35 km pour que la communication puisse
s'effectuer
Cependant on peut capter la cellule bien plus loin si l'opérateur ne prend pas
les dispositions nécessaires.
C'est pour ca qu'il y a toujours un problème avec openCellID et autres : sans
infos plus précises, on ne sais toujours pas où sont les antennes en question.
On peut aussi être à côté d'une et en capter une bien plus loin.
J'ai laissé un commentaire parce que je ne comprends pas ce que tu veux y dire.
(J'ai intégré certains commentaires au texte aussi)
Les stations au sens ANFR ont pour principale utilité de savoir quel service
est derrière l'antenne.
L'antenne est uniquement faite pour une bande de fréquence. Après tu y fait
transiter ce que tu
Re: [OSM-talk-fr] Normalisation du tag antenne
Oups, le mulot avait dérapé... Salut Je suis un peu perdu. J'ai mis des commentaires dans le pad. Concrètement, j'ai compris que l'on veut intégrer dans OSM des infos sur les supports et les antennes. J'ai compris que la proposition de Phlippe Verdy vise à intégrer dans le même tag différentes informations liées à un même support et pas à une antenne au sens ANFR ! Je trouve aussi très bien le modèle de représentation proposé par Philippe. Du coup, je ne comprends pas bien l'intérêt de proposer des tags liés à une antenne (au sens ANFR). Ce serait bien de clarifier le modèle de données de ANFR. 1 support support n station 1 station supporte n antennes 1 antenne supporte n émetteur 1 émetteur supporte n bandes Cas concret. Le support 687819 supporte 3 stations (sur un chateau d'eau) 0220220007 (FH) 022033 (E-Message) 090003 (Telecom) La station 090003 0220220007 supporte 6 antennes (2 * 3 antennes panneau : une antenne par secteur) 325425 2487083 2487081 2487079 162468 162466 L'antenne 325425 supporte 2 émetteurs 3220894;GSM 1800 3220896;UMTS 2100 L'émetteur 3220896 supporte 3 bandes 1964,9;1979,7 1910,1;1915,1 2154,9;2169,7 Concrètement, on taggue comment ? Eric 2015-05-02 13:53 GMT+02:00 dHuy Pierre dh...@yahoo.fr: @Verdy: Je soutiens ton idée, je dis juste qu'il faudrait la voter ensemble, comme tu l'a dit, c'est l'affaire de la communauté. Le Samedi 2 mai 2015 13h43, Eric Debeau eric.deb...@gmail.com a écrit : Salut J'a Eric 2015-05-02 5:04 GMT+02:00 Philippe Verdy verd...@wanadoo.fr: Le 2 mai 2015 00:21, dHuy Pierre dh...@yahoo.fr a écrit : L'idée de Verdy est pas al en la matière mais non normalisé encore, OSM non plus n'est pas normalisé dans ses données: il crée lui même ses propres standards avec nous tous. J'ai proposé un truc générique proche de JSON mais plus compact et adapté aux usages d'OSM, rien de plus, mais assez générique pour coder des données structurées sans avoir pléthore de tags et de codages spécifiques pour chaque tag particulier (celui des lanes est actuellement une horreur, tout le monde s'y trompe). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] Chain Store Cleanup
I wouldn't be so sure here. As an example, there's a bakery chain in the UK called Greggs. They're mostly tagged shop=bakery (with a few Subway-esque amenity=fast_food / cuisine=sandwich as well). Occasionally shops like this get wrongly tagged, sometimes as amenity=cafe, and there's always a temptation to just fix them. However, guess what? Yesterday I accidentally walked past a genuine Greggs amenity=cafe: There are too many of these errors (things like McDonalds without an apostrophe and amenity=fast_food incorrectly tagged amenity=restaurant) to check them all individually. I am only interested in fixing the big chains here and will leave things I am not familiar with alone. I live in Canada, and we have all the big worldwide chains (McDonald's, Subway, KFC, Walmart) and some big local chains (Tim Hortons, Loblaws, Shoppers Drug Mart, Sobeys, Rexall etc.) With many of the chains most of the stores look pretty similar from an air photo and it is easy to identify them that way. Also the increasing popularity of Mapillary makes it easier to check these in areas where Mapillary is available. If you find a weird situation like this I would strongly recommend putting a note tag on it. If I don't mistakenly correct the POI then someone else might do it. Usually when I find this sort of situation it is in a different country from the country where the chain has its stores, and some independent store has the same name as the chain. Occasionally there might be some store called Subway that doesn't sell sandwiches that is legal because the Subway trademark only covers fast food restaurants, or something like that. Any Subway or McDonald's store that isn't owned by the big chains in one of the countries where those chains operate would almost certainly be sued for trademark infringement and shut down. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] Normalisation du tag antenne
Salut J'a Eric 2015-05-02 5:04 GMT+02:00 Philippe Verdy verd...@wanadoo.fr: Le 2 mai 2015 00:21, dHuy Pierre dh...@yahoo.fr a écrit : L'idée de Verdy est pas al en la matière mais non normalisé encore, OSM non plus n'est pas normalisé dans ses données: il crée lui même ses propres standards avec nous tous. J'ai proposé un truc générique proche de JSON mais plus compact et adapté aux usages d'OSM, rien de plus, mais assez générique pour coder des données structurées sans avoir pléthore de tags et de codages spécifiques pour chaque tag particulier (celui des lanes est actuellement une horreur, tout le monde s'y trompe). ___ 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] Normalisation du tag antenne
@Nicolas: mea culpa, je vis en milieu urbain dense dans ce cas! Je ne parlais
que d'un doublement de vérification des données en cas de cartographie visuelle
pour les pays sans opendata sur cette base.@Debeau: je viens de voir ton
message dans le pad, mais du coup je ne suis pas sûr que ça soit pertinenet
pour la page du tag antenna.@Lacombe, @Verdy @Amagat: du coup j'attends de voir
une propal clairement définie pour les associations. Je la formulerai au mieux
(ou copie/collerai si vous avez vraiment bien expliqué)
Le Samedi 2 mai 2015 17h53, Nicolas CORBEL nicolas.cor...@gmail.com a
écrit :
OCID n'est pas précis à 100m, je t'assure. Ou alors ponctuellement sur des
endroits où énormément de mesures ont été faites, dans des zones très denses.
Et surtout, OCID est plus qu'incomplet. Je ne pense pas qu'il faille continuer
dans cette voie.
Je crois que le propos de François c'est qu'il n'était pas possible de placer
précisement les antennes, et que seul le support dispose de coordonnées GPS
dans le jeu de données dont on parle ici.
2015-05-02 17:48 GMT+02:00 dHuy Pierre dh...@yahoo.fr:
Avant la proposition j'attends au moins une unité dans le camp talk-fr
:pOpencellid se base sur des séries de mesures cumulés pour estimé la position
de l'antenne en fonction de la réception. Ces estimations donnent une précision
de 100m (donc contestable mais intéressant).Bon je crois crois qu'on se
comprend pas pour les données du set ANFR, il y a la position GPS.Pour ta
relation je te laisse proposer ton modèle alternatif clairement avec la
relation. Et une fois le consens obtenu je le poste sur le wiki.
Le Samedi 2 mai 2015 15h37, François Lacombe fl.infosrese...@gmail.com a
écrit :
Le 2 mai 2015 00:09, dHuy Pierre dh...@yahoo.fr a écrit :
@Jérome: Merci de l'avoir expliqué. Je suis opposé au tag communication:*=
cependant, en effet je trouve que ces tags surchargeraient trop en cas de
données multiples et ne serons jamais assez exhaustif, on risquerait de se
retrouver avec des key user defined...). Pour le type d'antenne, je propose
déjà antenna:shape (antenna:type éventuellement, j'étais partagé en écrivant).
Mais on reste sur le même set d'info a taguer.
@Lacombe, comme précisé plus haut, les commentaires sont souhaités entre
crochet, j'ai donc rajouté pour les tiens mais du coup j'y réponds ici. Ah et
si possible sur le pad les commentaires sont plus intéressants s'ils
constituent un texte à compléter et pas une remarque qui nécessite débat, plus
approprié à la ML (ou au canal de communication si subitement on s'y connecte
en masse), je supprimerai du texte les superflus mais il sera possible d'en
retrouver la trace dans l'interface.
Désolé, c'est nouveau pour moi.
- radio=repeater|relay ou autre: Non il s'agit d'élément immatériel, difficile
à vérifier en pratique et peu utile en carto, mais si quelqu'un d'autre les
souhaite, je suis à l'écoute de vos raisonnements. Je propose antenna=yes seul
sur un node en cas d'absence de support ponctuel (comme sur un immeuble)
Il s'agit de stations au sens ANFR.
Au sens OSM, ces stations seraient plutôt des relations entre les supports et
les antennes.
Les stations supportent le service, notre principal problème quand on veut
ajouter ces infos sur l'antenne directement.
On évite les chaines de ce genre :
operator={[TDF{FM|FH}][Opérateur privé{PMR}][SNCF{GSM R}][FREE MOBILE{UMTS
900|UMTS 2100|LTE 2600}]}
En indiquant l'opérateur sur les stations plus que sur le support ou l'antenne.
yes est une valeur par défaut, il faudrait utiliser le tag antenna pour y
ajouter d'autres infos (comme le type directement, au lieu de antenna:type=*,
on s'évite de créer une clé supplémentaire).
- tower:type=communication_tower conduisait jusqu'alors implicitement à
l'existence d'une antenne, ce que je défend c'est un tag unifié pour les
antennes. Mais donc non pas de confusions...
Implicitement, on peut affirmer plein de choses.
Que se passe-t-il si toutes les antennes ont été désinstallées ? On a toujours
un tower:type=communication_tower sans antennes.
Ces valeurs trappes font dire plein de choses et on a finalement pas l'info
qu'on cherche.
Avec les explications de cette nuit, je comprends mieux antenna=*, d'autant que
cette clé-ci est quand même moins sujette aux interprétations comme pour la
plupart des valeurs tower:type.
- Le fichier ANFR ne permettrait pas le placement: Relis ce qu'à écrit Jérôme.
Non en effet : c'est bien ce que je disais. C'était une affirmation.
- Une antenne radar/ une antenne onde courte... etc sont des antennes
colossales qui se remarque facilement en milieu urbain et qui constituent
toujours un repère, de même à la campagne.
On est d'accord là-dessus, l'objet du commentaire n'était pas sur le côté
représentatif de l'antenne ou non mais dans sa place dans le modèle.
Bref, en relisant c'était un peu HS, autant pour moi.
- La base de données opencellid/mozstumbler est
Re: [Talk-at] basemap.at Umstellung
Wie kann ich das bei JOSM umstellen? In TMS hat das umstellen mit Neueingabe und Änderung auf .png nicht funktioniert. Danke, Peter. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-fr] Normalisation du tag antenne
OCID n'est pas précis à 100m, je t'assure. Ou alors ponctuellement sur des
endroits où énormément de mesures ont été faites, dans des zones très
denses. Et surtout, OCID est plus qu'incomplet. Je ne pense pas qu'il
faille continuer dans cette voie.
Je crois que le propos de François c'est qu'il n'était pas possible de
placer précisement les antennes, et que seul le support dispose de
coordonnées GPS dans le jeu de données dont on parle ici.
2015-05-02 17:48 GMT+02:00 dHuy Pierre dh...@yahoo.fr:
Avant la proposition j'attends au moins une unité dans le camp talk-fr :p
Opencellid se base sur des séries de mesures cumulés pour estimé la
position de l'antenne en fonction de la réception. Ces estimations donnent
une précision de 100m (donc contestable mais intéressant).
Bon je crois crois qu'on se comprend pas pour les données du set ANFR, il
y a la position GPS.
Pour ta relation je te laisse proposer ton modèle alternatif clairement
avec la relation. Et une fois le consens obtenu je le poste sur le wiki.
Le Samedi 2 mai 2015 15h37, François Lacombe fl.infosrese...@gmail.com
a écrit :
Le 2 mai 2015 00:09, dHuy Pierre dh...@yahoo.fr a écrit :
@Jérome: Merci de l'avoir expliqué. Je suis opposé au tag communication:*=
cependant, en effet je trouve que ces tags surchargeraient trop en cas de
données multiples et ne serons jamais assez exhaustif, on risquerait de se
retrouver avec des key user defined...). Pour le type d'antenne, je propose
déjà antenna:shape (antenna:type éventuellement, j'étais partagé en
écrivant). Mais on reste sur le même set d'info a taguer.
@Lacombe, comme précisé plus haut, les commentaires sont souhaités entre
crochet, j'ai donc rajouté pour les tiens mais du coup j'y réponds ici. Ah
et si possible sur le pad les commentaires sont plus intéressants s'ils
constituent un texte à compléter et pas une remarque qui nécessite débat,
plus approprié à la ML (ou au canal de communication si subitement on s'y
connecte en masse), je supprimerai du texte les superflus mais il sera
possible d'en retrouver la trace dans l'interface.
Désolé, c'est nouveau pour moi.
- radio=repeater|relay ou autre: Non il s'agit d'élément immatériel,
difficile à vérifier en pratique et peu utile en carto, mais si quelqu'un
d'autre les souhaite, je suis à l'écoute de vos raisonnements. Je propose
antenna=yes seul sur un node en cas d'absence de support ponctuel (comme
sur un immeuble)
Il s'agit de stations au sens ANFR.
Au sens OSM, ces stations seraient plutôt des relations entre les supports
et les antennes.
Les stations supportent le service, notre principal problème quand on veut
ajouter ces infos sur l'antenne directement.
On évite les chaines de ce genre :
operator={[TDF{FM|FH}][Opérateur privé{PMR}][SNCF{GSM R}][FREE
MOBILE{UMTS 900|UMTS 2100|LTE 2600}]}
En indiquant l'opérateur sur les stations plus que sur le support ou
l'antenne.
yes est une valeur par défaut, il faudrait utiliser le tag antenna pour y
ajouter d'autres infos (comme le type directement, au lieu de
antenna:type=*, on s'évite de créer une clé supplémentaire).
- tower:type=communication_tower conduisait jusqu'alors implicitement à
l'existence d'une antenne, ce que je défend c'est un tag unifié pour les
antennes. Mais donc non pas de confusions...
Implicitement, on peut affirmer plein de choses.
Que se passe-t-il si toutes les antennes ont été désinstallées ? On a
toujours un tower:type=communication_tower sans antennes.
Ces valeurs trappes font dire plein de choses et on a finalement pas
l'info qu'on cherche.
Avec les explications de cette nuit, je comprends mieux antenna=*,
d'autant que cette clé-ci est quand même moins sujette aux interprétations
comme pour la plupart des valeurs tower:type.
- Le fichier ANFR ne permettrait pas le placement: Relis ce qu'à écrit
Jérôme.
Non en effet : c'est bien ce que je disais. C'était une affirmation.
- Une antenne radar/ une antenne onde courte... etc sont des antennes
colossales qui se remarque facilement en milieu urbain et qui constituent
toujours un repère, de même à la campagne.
On est d'accord là-dessus, l'objet du commentaire n'était pas sur le côté
représentatif de l'antenne ou non mais dans sa place dans le modèle.
Bref, en relisant c'était un peu HS, autant pour moi.
- La base de données opencellid/mozstumbler est approximative, mais elle
peut etre utile dans des pays qui ne possède pas un équivalent de l'anfr ou
dont la base serait non libre. Cela donne une position approximative d'une
antenne télécom. d'où la précision déjà présente sur la localisation.
Pas forcément : ce genre de base recense des endroits où on capte, mais
l'antenne peut être à des dizaines de km.
Le GSM fixe un rayon de cellule de 35 km pour que la communication puisse
s'effectuer
Cependant on peut capter la cellule bien plus loin si l'opérateur ne prend
pas les dispositions nécessaires.
C'est pour ca qu'il y a
Re: [Talk-it] Kathmandu, OSM e il Politecnico di Milano
Il giorno 02/mag/2015, alle ore 08:50, Aury88 spacedrive...@gmail.com ha scritto: Alessandro wrote Il 30/04/2015 20:03, Aury88 ha scritto: ...la domanda dei miei amici era generica e cioè perchè le organizzazioni umanitarie dovrebbero preferire la nostra alle mappe google visto che la nostra non fa vedere neanche la foto satellitare...in poche parole mi si chiedeva i vantaggi nell'usare la mappa osm e non google per le ong. che poi la mappa osm sia più completa nelle zone comercialmente meno vantaggiose è una cosa che possono vedere benissimo da se...ma è un vantaggio che si ha solo in certe zone e non in molte altre dove la copertura di google è uguale e in alcuni casi superiore alla nostra. poi per carità: la velocità nell'inserimento dei dati è un altro fattore a nostro favore, quindi se una zona è mappata male sia siu osm che su google in osm nell'arco di pochi giorni si ha già tutto caricato sulla mappa mentre per google ci vuole più tempo ma le zone già complete in google? conviene sempre usare osm e perchè? Leggendo queste domande mi viene da sorridere visto che la differenza dovrebbe essere chiarissima dopo 5', provo a dire la mia. Cosa serve a dei soccorritori che arrivano in un paese straniero e a volte, come in questo a caso, con delle infrastrutture arretrate? Quali informazioni cercano su una mappa? La prima cosa è ovviamene il reticolo stradale: quali sono le strade (preferibilmente asfaltate) agibili a una colonna di soccorsi che comprende mezzi pesanti; quali di queste sono ancora transitabili al netto di ponti crollati o edifici collassati. Se non c'è asfalto cosa c'è, fango, terra compatta, ..? Nel caso dei ponti che portata hanno e quale larghezza; magari sono lesionati solo in parte. La mappatura di Google anche se fosse stata completa sino al giorno prima viene stravolta da eventi del genere. Occorre sapere ad occhio e croce che dimensione hanno gli insediamenti per capire quanti aiuti inviare (con le foto satellitari scattate in tempo quasi reale si mappano anche gli edifici). Se le strade sono impraticabili c'è possibilità di atterrare con elicotteri? Quella radura che si vede dalle foto aeree sarà ancora utilizzabile? Dove vengono piazzati i punti di raccolta per i rifugiati, dove gli ospedali da campo, dove si trovano fonti di acqua potabile. Quale percorso fanno i principali elettrodotti/gasdotti/condutture d'acqua? E' importante saperlo per poterle ripristinare. La maggior parte di queste informazioni vanno trasferite sui GPS di chi materialmente si muove sul territorio, quasi sempre senza telefono nè internet nè energia elettrica: sui camion di solito si ha un GPS e una radio che può coprire solo pochi chilometri. Sulle mappe bisogna inserire e/o evidenziare informazioni che normalmente sono marginali o che non esistono proprio. La situazione sul campo dev'essere costantemente aggiornata: la mappa del luogo viene renderizzata più volte al giorno e le mappe nei GPS aggiornate più spesso che si può. Se si può aiutare a mappare essendo dall'altra parte del globo e con mezzi semplici si può contribuire in migliaia lasciando alle persone in loco compiti di coordinamento. Questi sono giusto alcuni punti a vantaggio della soluzione OSM Alessandro Ale_Zena_IT ok, la flessibilità del nostro tagging è un vantaggio...purtroppo non l'ho visto molto sfruttare soprattutto in risposta della crisi dove spesso è richiesta una generica mappatura (livello della strada, mai dati tipo la superficie delle strade figurarsi dati sui limiti di larghezza ). tutte queste informazioni sono comunque presenti anche su una mappa google ed aggiustabili dai volontari (in zona o da remoto) come la mappatura google viene stravolta così viene stravolta la nostra...a quel punto? mi dici che l'unica differenza è la velocità di risposta e mappatura della community? ...ne parli come se non fosse possibile per gli utenti google mappare da locale e da remoto quando invece tramite google maker (che nelle zone di crisi ha tempi minori di approvazione rispetto al solito) + tutte le informazioni ottenibili tramite servizi aggiuntivi, come per esempio waze (già integrato nelle mappe), questi dati vengono raccolti sia dai volontari sia, inconsciamente, dai semplici utilizzatori. le mappe google mi sembra che da qualche anno permettano tra l'altro anche l'uso offline e penso che altri dati possano essere raccolti da offline (salvati nella cache e poi aggiornati sul serer centrale alla pria connessione disponibile). forse l'unico punto a nostro favore per questi argomenti è il fatto che Gmap non venga usata sui navigatori (credo), ma se si ha uno smartphone con connettività GPS? le nostre mappe che vantaggio hanno? Ciao Aury, ti rispondo brevemente per quella che è la mia esperienza. OSM permette un potente uso offline quindi anche in assenza di connessione utilizzando software come QGIS e formato
[Talk-br] Áreas de risco
Sem querer polemizar , mas aproveitando algumas respostas . Primeiro eu deixo perguntas : quem participa do OSM e mapeia o seu bairro e/ou partes da sua cidade , o faz para si ou para os outros ? Se a volatilidade na informação , quando a CET-SP faz alterações nas velocidades de via ( me parece que fará agora na marginal Tiete , naquilo que é considerada uma auto-estrada , reduzindo de 90 para 70 Km ) , ou quando cria o setor 40 ( onde a velocidade máxima passar a ser 40 Km ) , ou quando introduz uma ciclofaixa numa via que não existia eu devo manter o que existia antigamente ou corrigir e atualizar ? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk] Chain Store Cleanup
A bit of a meta-discussion I wonder why this topic is not going the same way as the debate on talk-gb last November-December in which it was proposed to tidy up and normalise various spelling variants? There was a lot of vehement opposition to any automated corrections as many chains are inconsistent with their own orthography and only on-the-ground mappers would be able to tell whether or not there is an apostrophe present in the signage at this particular branch (etc. etc., you get this idea). Discussion starts here: https://lists.openstreetmap.org/pipermail/talk-gb/2014-November/016718.html //colin On 2015-05-02 18:14, Andrew MacKinnon wrote: I wouldn't be so sure here. As an example, there's a bakery chain in the UK called Greggs. They're mostly tagged shop=bakery (with a few Subway-esque amenity=fast_food / cuisine=sandwich as well). Occasionally shops like this get wrongly tagged, sometimes as amenity=cafe, and there's always a temptation to just fix them. However, guess what? Yesterday I accidentally walked past a genuine Greggs amenity=cafe: There are too many of these errors (things like McDonalds without an apostrophe and amenity=fast_food incorrectly tagged amenity=restaurant) to check them all individually. I am only interested in fixing the big chains here and will leave things I am not familiar with alone. I live in Canada, and we have all the big worldwide chains (McDonald's, Subway, KFC, Walmart) and some big local chains (Tim Hortons, Loblaws, Shoppers Drug Mart, Sobeys, Rexall etc.) With many of the chains most of the stores look pretty similar from an air photo and it is easy to identify them that way. Also the increasing popularity of Mapillary makes it easier to check these in areas where Mapillary is available. If you find a weird situation like this I would strongly recommend putting a note tag on it. If I don't mistakenly correct the POI then someone else might do it. Usually when I find this sort of situation it is in a different country from the country where the chain has its stores, and some independent store has the same name as the chain. Occasionally there might be some store called Subway that doesn't sell sandwiches that is legal because the Subway trademark only covers fast food restaurants, or something like that. Any Subway or McDonald's store that isn't owned by the big chains in one of the countries where those chains operate would almost certainly be sued for trademark infringement and shut down. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-gb-westmidlands] May Meeting (Disabilty Kurb Project)
Sounds like an interesting project. Hopefully we'll see you in Bromsgrove on Thursday to discuss this in more detail. Speaking of which does anyone know what the plan is for Bromsgrove. Is there any priority areas that we should focus on or shall I just pick something and meet you in the pub afterwards? Rob On 1 May 2015 at 18:01, Mark Croft mark.croft@gmail.com wrote: Hi The group has been out to bewdley and did a test run of finding curbs. I was not able to join in cos of health problems felling worn out with weather n hayfever. I should really have a go on my own here around my town in redditch. got a stack of photos and a spreadsheet of gps points where there good curbs and so reasonable ones that either steep and hard work to push a manual wheelchair up and others with a reasonable size drop down to the path/road etc etc I need to get some clarification on all the different issues with curbs and come up with some form of coding and label system. first beta version of the map attached (not sure its openstreetmap) i want to know to make a seperate layer of points on top of openstreetmap? does this need to done on custom webpage and having a host etc? I not done any internet programming yet would like the challange but also very time limited too get some sort of beat/demo copy of at least a paper copy of the map of bewdley. Maybe we have a go around bromsgrove on thursday? Is taking photos with embedded gps position enough? I have a friend that can offer me some free website space? ( i am involved in another project called Disability Action Redditch and need to redo there website and i am hoping to put this Curb/Kurb project on there for now - so that should be up soon or at least a frontpage saying that DAR website going live in june/july 2015) mark croft redditch On 15 April 2015 at 19:42, Brian Prangle bpran...@gmail.com wrote: A quick reminder that we're due to meet on Thurs 7 May (Election Night!). Thise of us who were at the April meeting decided from our list on Bromsgrove ( mainly to support mark a new mapper). Pub is the Golden Cross ( A Wetherspoons ) which might be a challenge as it wasn't on the map when we decided Regards Brian ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
Re: [Talk-br] Áreas de perigo
Quando a nomear, acho válido. Se o nome é específico daquele lugar (não algo para referenciar o tipo de lugar), pode ser um loc_name, um alt_name ou mesmo um name. Quanto a mapear áreas de risco, continuo achando temerário. Acho válido que haja aplicativos e sites específicos para esse fim que se utilizem do OSM, mas não parece coerente incluir essas informações diretamente no mapa pela simples subjetividade do tema. Não é nem pela negatividade que a classificação traz. De forma análoga, poderíamos discutir se vale a pena marcar áreas relaxantes... Algo igualmente muito subjetivo (muito embora também da mesma forma haja estatísticas a respeito). - - - · Atenciosamente, Márcio Vinícius Pinheiro http://about.me/Doideira http://pt.gravatar.com/marciovinicius Em 1 de maio de 2015 11:48, Arlindo Pereira openstreet...@arlindopereira.com escreveu: Já teve, vindo das contribuições de usuário que as vezes eles põem no mapa, mas já foi removido. http://m.oglobo.globo.com/sociedade/tecnologia/google-maps-identifica-regiao-de-sao-paulo-como-cracolandia-14391239 Em sex, 1 de mai de 2015 11:13, Gerald Weber gwebe...@gmail.com escreveu: Acompanhando esta discussão, eu me lembrei que nos mapas impressos do Guida 4Rodas em algumas rodovias há alertas sobre perigo de assaltos durante a noite. Ainda que eu concorde com a subjetividade da questão, o exemplo mostra que não é inteiramente fora de propósito inserir este tipo de informação num mapa. O outro ponto bem mais objetivo que me chama atenção na pergunta é o seguinte: se existe um *lugar* conhecido pelo nome de Cracolândia, porque não inserir esta informação no mapa? algo assim: place=locality name=Cracolândia Tirando o nome infame, que diferença isto tem para qualquer outra denominação popular de lugar? É um lugar e tem nome, porque não mapeá-lo? Não será o primeiro e nem o último topónimo com conotação triste. Obs.: O Google Maps não achou Cracolândia. abraço e bom feriado a todos Gerald 2015-04-30 11:24 GMT-03:00 belnu...@pop.com.br: Sei que o termo Área de perigo seria algo muito subjetivo , mas o OSM não poderia criar uma tag para que possamos alertar as pessoas sobre regiões perigosas pra trânsito seja com veículo ou a pé , como por exemplo a Cracolândia ( que existe há muito tempo e parece que não vai acabar ) na cidade de SP ? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Evento de mapeamento na USP São Carlos
Olá Julio, Infelizmente não gravamos o webinar dessa vez. A propósito, o nossos eventos de mapeamento colaborativo foram divulgados na mídia, e assim também o OSM: http://g1.globo.com/sp/sao-carlos-regiao/noticia/2015/05/alunos-da-usp-sao-carlos-ajudam-mapear-areas-destruidas-no-nepal.html Abraços, João Porto Em 29 de abril de 2015 11:22, Julio Refosco ju...@3geo.com.br escreveu: Olá João, como podemos ter acesso a este webinar? Obrigado, Julio *-* *Julio Cesar Refosco* *Engenheiro Florestal, Dr., Especialista em GIS e Gestão Ambiental* *www.3geo.com.br http://www.3geo.com.br* *ju...@3geo.com.br ju...@3geo.com.br* *04796170560 04796170560* Em 27 de abril de 2015 21:25, Joao Porto jpo...@gmail.com escreveu: Pessoal, Hoje fizemos um evento de mapeamento humanitário com os estudantes da USP São Carlos para o Nepal e Xanxerê (aparentemente os estudantes se concentraram mais no Nepal): http://www.agora.icmc.usp.br/site/?p=922 Agradeço muito ao Wille que fez um webinar introdutório aos estudantes, mesmo com o aviso em cima da hora, muito obrigado! Espero que tenhamos ajudado os esforços humanitários e ganhado alguns novos mapeadores para a comunidade OSM Brasil. Abraços, João Porto ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-GB] Road-name oddity in Bath
Around: http://www.openstreetmap.org/?mlat=51.38137mlon=-2.37016#map=19/51.38137/-2.37016 Stanier Road seems to become Ivo Peters Road, then Stanier Road again Meanwhile, slightly to the NE, there is another Ivo Peters Road. Is something mis-tagged? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [OSM-talk] Chain Store Cleanup
On 2 May 2015 at 02:18, Andrew MacKinnon andrew...@gmail.com wrote: If a store changes name a mechanical edit does not make sense because usually new signs get put up gradually. For instance Domino's Pizza changed its name to Domino's and is running TV ads promoting this, but there are still old signs that say Domino's Pizza I suppose it depends whether we want to map what (sometimes incorrect) store signs say, or what the stores actually are. I favour the latter, but if you want the former, I have a list defunct shops whose signs are still visible, which you can add Another issue to consider is that either method will incude some errors. Which will include fewest, and which will inconvenience our users less? How long will it take for all our entries for Domino's to be manually updated, even after the signs are changed? -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-at] basemap.at Umstellung
Hallo, leider ist nur dir normale Auflösung in PNG verfügbar. JOSM verwendet die high dpi Version, welche nur in JPEG verfügbar ist. Wenn diese auch in PNG verfügbar ist, werd ich die TMS links aktualisieren, so dass automatisch für jeden User die PNG Variante verwendet wird Mit freundlichen Grüßen Paul Wölfel Email p...@woelfel.at Tel. +43 664 88 533 801 Lindengasse 31/1/11 1070 Wien Austria Am 02.05.2015 5:24 nachm. schrieb Peter Kössler pkoess...@gmx.net: Wie kann ich das bei JOSM umstellen? In TMS hat das umstellen mit Neueingabe und Änderung auf .png nicht funktioniert. Danke, Peter. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-br] Áreas de risco
1) Para mim e pensando nos outros também (compartilhar). 2) Corrigir e atualizar. Se possível, deixando uma maneira de rastrear as dificuldades. Em 2 de maio de 2015 15:59, belnu...@pop.com.br escreveu: eu deixo perguntas : *[1]* quem participa do OSM e mapeia o seu bairro e/ou partes da sua cidade , o faz para si ou para os outros ? *[2]* Se a volatilidade na informação , quando a CET-SP faz alterações nas velocidades de via ( me parece que fará agora na marginal Tiete , naquilo que é considerada uma auto-estrada , reduzindo de 90 para 70 Km ) , ou quando cria o setor 40 ( onde a velocidade máxima passar a ser 40 Km ) , ou quando introduz uma ciclofaixa numa via que não existia eu devo manter o que existia antigamente ou corrigir e atualizar ? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] unpraktisches Nominatim-Ergebnis
Verständlich, hier Auszug aus dem FAQ https://wiki.openstreetmap.org/wiki/Nominatim/FAQ#Why_is_the_place_I.27m_looking_for_not_at_the_top_of_the_list.3F Why is the place I'm looking for not at the top of the list? Nominatim uses various heuristics to calculate the order to show search results, these include the area of the map you were looking at when you did the search, the 'importance' or a place and how accurately your search string matches the result. Exact matches win over anything else but after that the most significant factor is importance of the returned feature which is calculated either from the tagging (i.e. town, city, country) or preferably from the linked wikipedia article. If you find a place is not where you expect it to be the simplest way to resolve the problem is usually to add a wikipedia tag to the data in osm. Am 02.05.2015 um 21:43 schrieb Christian H. Bruhn: Hallo! Ich habe gestern auf openstreetmap.org nach Wildpark Eekholt gesucht. Da gab es mehrere Suchergebnisse. Das erste war http://www.openstreetmap.org/node/2414231380 , welches ein Straßenschild ist. So eine braune Tafel, welche an Autobahnen auf touristische Ziele hinweist. Gerade in Verbindung mit der neuen Routingfunktion auf der der Hauptseite ist das unpraktisch, da dort wohl stets das erste Ergebnis genommen wird und einen nun zu dieser Hinweistafel an der Autobahn, statt zum eigentlichen Wildpark https://www.openstreetmap.org/relation/1918204 leitet. Ich habe keine Ahnung wie man das verbessern kann. Vielleicht sollte Nominatim irgendwie die Relevanz von den Ergebnissen besser sortieren, so daß eine große Toristenattraktion Vorrang vor einem Straßenschild haben sollte. Christian ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Tagging di chiese
Am 30.04.2015 um 22:33 schrieb Leonardo Frassetto kinetocor...@gmail.com: L'edificio in se building=church o building:part=yes con relazione multipoligono. se usi building:part ci sarà comunque anche un building=* (church, chapel, cathedral, etc) Amenity=place_of_worship sul poligono della chiesa (quindi building e amenity sullo stesso poligono) o in caso di strutture complesse (vedi convento+chiesa annessa) un poligono separato per ciascuna delle due. per il convento metterei amenity=monastery e subtag monastery:type=convent http://wiki.openstreetmap.org/wiki/Proposed_features/monastery ciao Martin___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[OSM-talk] Case study: Lloyds TSB (Was: Chain Store Cleanup)
Andy Mabbett wrote: I suppose it depends whether we want to map what (sometimes incorrect) store signs say, or what the stores actually are. I favour the latter, but if you want the former, I have a list defunct shops whose signs are still visible, which you can add Another issue to consider is that either method will incude some errors. Which will include fewest, and which will inconvenience our users less? How long will it take for all our entries for Domino's to be manually updated, even after the signs are changed? I also favour the latter too. I feel this is an area where the on the ground rule is too strong. For an idea of how long it takes to *manually update* shop names take a look at Lloyds TSB in the UK. In September 2013 the bank split into two separate banks and they were quickly rebranded as Lloyds and TSB. As it was impossible to say which branch became a Lloyds and which branch became a Lloyds so a mechanical edit wasn't possible. Almost 2 years later we still have 400 Lloyds TSB in OpenStreetMap [1] and this is despite the fact that a tool was developed for the UK mappers to help them find the remaining incorrect instances of Lloyds TSB. Without this tool I expect there would be many hundreds more. I don't want to say the UK mapping community is dead, but it is not big enough to manage the volume of data we already have in OSM. Any tools that can help this situation (tools to compare to external data sources, QA tools, Maproulette type tools, apps for Android, Windows phone and iOS, and yes, mechnaincal edits) would be welcome in my eyes. We need to grow our community and our toolset. Best, Rob [1] http://taginfo.openstreetmap.org.uk/search?q=name%3Dlloyds+tsb ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] Normalisation du tag antenne
Pour ta norme pour cartographier les données associées aux antennes si tu veux.
Le Samedi 2 mai 2015 23h08, Philippe Verdy verd...@wanadoo.fr a écrit :
Ou ai-je parlé d'association, je n'ai même pas vu ce terme utilisé dans
cette discussion...
Le 2 mai 2015 18:00, dHuy Pierre dh...@yahoo.fr a écrit :
@Nicolas: mea culpa, je vis en milieu urbain dense dans ce cas! Je ne parlais
que d'un doublement de vérification des données en cas de cartographie visuelle
pour les pays sans opendata sur cette base.@Debeau: je viens de voir ton
message dans le pad, mais du coup je ne suis pas sûr que ça soit pertinenet
pour la page du tag antenna.@Lacombe, @Verdy @Amagat: du coup j'attends de voir
une propal clairement définie pour les associations. Je la formulerai au mieux
(ou copie/collerai si vous avez vraiment bien expliqué)
Le Samedi 2 mai 2015 17h53, Nicolas CORBEL nicolas.cor...@gmail.com a
écrit :
OCID n'est pas précis à 100m, je t'assure. Ou alors ponctuellement sur des
endroits où énormément de mesures ont été faites, dans des zones très denses.
Et surtout, OCID est plus qu'incomplet. Je ne pense pas qu'il faille continuer
dans cette voie.
Je crois que le propos de François c'est qu'il n'était pas possible de placer
précisement les antennes, et que seul le support dispose de coordonnées GPS
dans le jeu de données dont on parle ici.
2015-05-02 17:48 GMT+02:00 dHuy Pierre dh...@yahoo.fr:
Avant la proposition j'attends au moins une unité dans le camp talk-fr
:pOpencellid se base sur des séries de mesures cumulés pour estimé la position
de l'antenne en fonction de la réception. Ces estimations donnent une précision
de 100m (donc contestable mais intéressant).Bon je crois crois qu'on se
comprend pas pour les données du set ANFR, il y a la position GPS.Pour ta
relation je te laisse proposer ton modèle alternatif clairement avec la
relation. Et une fois le consens obtenu je le poste sur le wiki.
Le Samedi 2 mai 2015 15h37, François Lacombe fl.infosrese...@gmail.com a
écrit :
Le 2 mai 2015 00:09, dHuy Pierre dh...@yahoo.fr a écrit :
@Jérome: Merci de l'avoir expliqué. Je suis opposé au tag communication:*=
cependant, en effet je trouve que ces tags surchargeraient trop en cas de
données multiples et ne serons jamais assez exhaustif, on risquerait de se
retrouver avec des key user defined...). Pour le type d'antenne, je propose
déjà antenna:shape (antenna:type éventuellement, j'étais partagé en écrivant).
Mais on reste sur le même set d'info a taguer.
@Lacombe, comme précisé plus haut, les commentaires sont souhaités entre
crochet, j'ai donc rajouté pour les tiens mais du coup j'y réponds ici. Ah et
si possible sur le pad les commentaires sont plus intéressants s'ils
constituent un texte à compléter et pas une remarque qui nécessite débat, plus
approprié à la ML (ou au canal de communication si subitement on s'y connecte
en masse), je supprimerai du texte les superflus mais il sera possible d'en
retrouver la trace dans l'interface.
Désolé, c'est nouveau pour moi.
- radio=repeater|relay ou autre: Non il s'agit d'élément immatériel, difficile
à vérifier en pratique et peu utile en carto, mais si quelqu'un d'autre les
souhaite, je suis à l'écoute de vos raisonnements. Je propose antenna=yes seul
sur un node en cas d'absence de support ponctuel (comme sur un immeuble)
Il s'agit de stations au sens ANFR.
Au sens OSM, ces stations seraient plutôt des relations entre les supports et
les antennes.
Les stations supportent le service, notre principal problème quand on veut
ajouter ces infos sur l'antenne directement.
On évite les chaines de ce genre :
operator={[TDF{FM|FH}][Opérateur privé{PMR}][SNCF{GSM R}][FREE MOBILE{UMTS
900|UMTS 2100|LTE 2600}]}
En indiquant l'opérateur sur les stations plus que sur le support ou l'antenne.
yes est une valeur par défaut, il faudrait utiliser le tag antenna pour y
ajouter d'autres infos (comme le type directement, au lieu de antenna:type=*,
on s'évite de créer une clé supplémentaire).
- tower:type=communication_tower conduisait jusqu'alors implicitement à
l'existence d'une antenne, ce que je défend c'est un tag unifié pour les
antennes. Mais donc non pas de confusions...
Implicitement, on peut affirmer plein de choses.
Que se passe-t-il si toutes les antennes ont été désinstallées ? On a toujours
un tower:type=communication_tower sans antennes.
Ces valeurs trappes font dire plein de choses et on a finalement pas l'info
qu'on cherche.
Avec les explications de cette nuit, je comprends mieux antenna=*, d'autant que
cette clé-ci est quand même moins sujette aux interprétations comme pour la
plupart des valeurs tower:type.
- Le fichier ANFR ne permettrait pas le placement: Relis ce qu'à écrit Jérôme.
Non en effet : c'est bien ce que je disais. C'était une affirmation.
- Une antenne radar/ une antenne onde courte... etc sont des antennes
colossales qui se remarque facilement en milieu
Re: [OSM-talk] Chain Store Cleanup
On Sat, May 2, 2015 at 1:01 PM, Colin Smale colin.sm...@xs4all.nl wrote: A bit of a meta-discussion I wonder why this topic is not going the same way as the debate on talk-gb last November-December in which it was proposed to tidy up and normalise various spelling variants? There was a lot of vehement opposition to any automated corrections as many chains are inconsistent with their own orthography and only on-the-ground mappers would be able to tell whether or not there is an apostrophe present in the signage at this particular branch (etc. etc., you get this idea). There are some chains that are very consistent and there are others that are inconsistent and haven't bothered to change old signage. At least in Canada I am aware of which ones these are. I am 99% confident that Tim Hortons never has an apostrophe and McDonald's always has an apostrophe, the dozens/hundreds of stores in the Greater Toronto Area are all consistent. Also amenity=restaurant with Subway, McDonald's, KFC, etc. is wrong because amenity=restaurant means a sit down restaurant where you pay after eating. The pages on the wiki I am working on creating are useful for telling which chain stores are always consistent and which have several different variations. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Chain Store Cleanup
Hi, On 05/02/2015 10:40 PM, Andrew MacKinnon wrote: This is due to weirdness in trademark laws where sometimes companies in different categories are allowed to use the same trademark - e.g. Apple Inc. and Apple Records. Also, by far not every chain will have a global trademark (or the clout to actually police it). If there's a Starbuck's cafe in Burma, maybe it is indeed a blatant rip-off run by a cousin of the prime minister, and maybe it is really called Starbuck's. I'm still convinced that fixing these low hangig fruit is an excellent task for a beginning mapper in an area (you may not dare to draw a landuse but you will be able to summon the courage of fixing an obvious spelling mistake), and in turn it will say something about how well kept an area is in OSM. You will never be able to make the map good in an area from your desk thousands of miles away. Doing a chain store cleanup from that distance is just window dressing - the quality of the map will not be different, at best you'll make it appear different. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-de] unpraktisches Nominatim-Ergebnis
Hallo! Ich habe gestern auf openstreetmap.org nach Wildpark Eekholt gesucht. Da gab es mehrere Suchergebnisse. Das erste war http://www.openstreetmap.org/node/2414231380 , welches ein Straßenschild ist. So eine braune Tafel, welche an Autobahnen auf touristische Ziele hinweist. Gerade in Verbindung mit der neuen Routingfunktion auf der der Hauptseite ist das unpraktisch, da dort wohl stets das erste Ergebnis genommen wird und einen nun zu dieser Hinweistafel an der Autobahn, statt zum eigentlichen Wildpark https://www.openstreetmap.org/relation/1918204 leitet. Ich habe keine Ahnung wie man das verbessern kann. Vielleicht sollte Nominatim irgendwie die Relevanz von den Ergebnissen besser sortieren, so daß eine große Toristenattraktion Vorrang vor einem Straßenschild haben sollte. Christian ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-fr] Normalisation du tag antenne
Ou ai-je parlé d'association, je n'ai même pas vu ce terme utilisé dans
cette discussion...
Le 2 mai 2015 18:00, dHuy Pierre dh...@yahoo.fr a écrit :
@Nicolas: mea culpa, je vis en milieu urbain dense dans ce cas! Je ne
parlais que d'un doublement de vérification des données en cas de
cartographie visuelle pour les pays sans opendata sur cette base.
@Debeau: je viens de voir ton message dans le pad, mais du coup je ne suis
pas sûr que ça soit pertinenet pour la page du tag antenna.
@Lacombe, @Verdy @Amagat: du coup j'attends de voir une propal clairement
définie pour les associations. Je la formulerai au mieux (ou copie/collerai
si vous avez vraiment bien expliqué)
Le Samedi 2 mai 2015 17h53, Nicolas CORBEL nicolas.cor...@gmail.com a
écrit :
OCID n'est pas précis à 100m, je t'assure. Ou alors ponctuellement sur des
endroits où énormément de mesures ont été faites, dans des zones très
denses. Et surtout, OCID est plus qu'incomplet. Je ne pense pas qu'il
faille continuer dans cette voie.
Je crois que le propos de François c'est qu'il n'était pas possible de
placer précisement les antennes, et que seul le support dispose de
coordonnées GPS dans le jeu de données dont on parle ici.
2015-05-02 17:48 GMT+02:00 dHuy Pierre dh...@yahoo.fr:
Avant la proposition j'attends au moins une unité dans le camp talk-fr :p
Opencellid se base sur des séries de mesures cumulés pour estimé la
position de l'antenne en fonction de la réception. Ces estimations donnent
une précision de 100m (donc contestable mais intéressant).
Bon je crois crois qu'on se comprend pas pour les données du set ANFR, il
y a la position GPS.
Pour ta relation je te laisse proposer ton modèle alternatif clairement
avec la relation. Et une fois le consens obtenu je le poste sur le wiki.
Le Samedi 2 mai 2015 15h37, François Lacombe fl.infosrese...@gmail.com
a écrit :
Le 2 mai 2015 00:09, dHuy Pierre dh...@yahoo.fr a écrit :
@Jérome: Merci de l'avoir expliqué. Je suis opposé au tag communication:*=
cependant, en effet je trouve que ces tags surchargeraient trop en cas de
données multiples et ne serons jamais assez exhaustif, on risquerait de se
retrouver avec des key user defined...). Pour le type d'antenne, je propose
déjà antenna:shape (antenna:type éventuellement, j'étais partagé en
écrivant). Mais on reste sur le même set d'info a taguer.
@Lacombe, comme précisé plus haut, les commentaires sont souhaités entre
crochet, j'ai donc rajouté pour les tiens mais du coup j'y réponds ici. Ah
et si possible sur le pad les commentaires sont plus intéressants s'ils
constituent un texte à compléter et pas une remarque qui nécessite débat,
plus approprié à la ML (ou au canal de communication si subitement on s'y
connecte en masse), je supprimerai du texte les superflus mais il sera
possible d'en retrouver la trace dans l'interface.
Désolé, c'est nouveau pour moi.
- radio=repeater|relay ou autre: Non il s'agit d'élément immatériel,
difficile à vérifier en pratique et peu utile en carto, mais si quelqu'un
d'autre les souhaite, je suis à l'écoute de vos raisonnements. Je propose
antenna=yes seul sur un node en cas d'absence de support ponctuel (comme
sur un immeuble)
Il s'agit de stations au sens ANFR.
Au sens OSM, ces stations seraient plutôt des relations entre les supports
et les antennes.
Les stations supportent le service, notre principal problème quand on veut
ajouter ces infos sur l'antenne directement.
On évite les chaines de ce genre :
operator={[TDF{FM|FH}][Opérateur privé{PMR}][SNCF{GSM R}][FREE
MOBILE{UMTS 900|UMTS 2100|LTE 2600}]}
En indiquant l'opérateur sur les stations plus que sur le support ou
l'antenne.
yes est une valeur par défaut, il faudrait utiliser le tag antenna pour y
ajouter d'autres infos (comme le type directement, au lieu de
antenna:type=*, on s'évite de créer une clé supplémentaire).
- tower:type=communication_tower conduisait jusqu'alors implicitement à
l'existence d'une antenne, ce que je défend c'est un tag unifié pour les
antennes. Mais donc non pas de confusions...
Implicitement, on peut affirmer plein de choses.
Que se passe-t-il si toutes les antennes ont été désinstallées ? On a
toujours un tower:type=communication_tower sans antennes.
Ces valeurs trappes font dire plein de choses et on a finalement pas
l'info qu'on cherche.
Avec les explications de cette nuit, je comprends mieux antenna=*,
d'autant que cette clé-ci est quand même moins sujette aux interprétations
comme pour la plupart des valeurs tower:type.
- Le fichier ANFR ne permettrait pas le placement: Relis ce qu'à écrit
Jérôme.
Non en effet : c'est bien ce que je disais. C'était une affirmation.
- Une antenne radar/ une antenne onde courte... etc sont des antennes
colossales qui se remarque facilement en milieu urbain et qui constituent
toujours un repère, de même à la campagne.
On est d'accord là-dessus, l'objet du commentaire n'était pas sur le
[Talk-it] Open Location Code: Addresses for everything, everywhere
Ciao a tutti, mi ci sono imbattuto questa sera: per ora ho solo letto e non ho provato ma mi sembra interessante e quindi lo segnalo . sembra essere open http://google-opensource.blogspot.be/2015/04/open-location-code-addresses-for.html Cesare Gerbino http://cesaregerbino.wordpress.com/ http://www.facebook.com/cesare.gerbino http://www.facebook.com/pages/Cesare-Gerbino-GIS-Blog/246234455498174?ref=hl https://twitter.com/CesareGerbino http://www.linkedin.com/pub/cesare-gerbino/56/494/77b Questo è un account di posta personale di Cesare Gerbino: tutte le opinioni espresse sono personali e non riflettono necessariamente quelle del mio datore di lavoro This is Cesare Gerbino mail account. Text is written by Cesare Gerbino: the views expressed are mine and not necessarily those of my employer. . ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk] Chain Store Cleanup
Hi, On 05/02/2015 07:58 PM, Andy Mabbett wrote: I suppose it depends whether we want to map what (sometimes incorrect) store signs say, or what the stores actually are. Definitely we want to map what's on the ground. We map mis-spellings in road signs, too. I favour the latter, but if you want the former, I have a list defunct shops whose signs are still visible, which you can add I don't know about the general rules about tagging defunct shops but if there is a tag for a defunct shop then the name tag should certainly bear the name on the still visible sign; if only as a landmark. Another issue to consider is that either method will incude some errors. Which will include fewest, and which will inconvenience our users less? How long will it take for all our entries for Domino's to be manually updated, even after the signs are changed? We collect observations. The fact that there is a relationship between all pizza places with a red-and-blue Domino's sign and what kind of relationship there is - are they all owned by the same company, are they a franchise, and if they are a franchise, what contractual freedoms in naming/signage are given to the franchisee in the contract - is not easily observable and therefore should not inform OSM mapping. There is no way for the mapper on the ground to know that the name on the building should be something else. I know you have a Wikidata background and things may be different in Wikidata; in Wikidata, you might be interested to research and record the details of the contractual relationship between a Domino's store and whatever the Domino HQ is, but in OSM this is very low on our list, if it is on our list at all. We see a place that sells pizzas and the place has a sign with their name on it, and that's what we map. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] unpraktisches Nominatim-Ergebnis
Gute Chance auf besser findbare Zoos. Zumindest dieser Konstellation: https://github.com/twain47/Nominatim/issues/273 Grüße Johannes Am 02.05.2015 um 21:57 schrieb Johannes: Verständlich, hier Auszug aus dem FAQ https://wiki.openstreetmap.org/wiki/Nominatim/FAQ#Why_is_the_place_I.27m_looking_for_not_at_the_top_of_the_list.3F Why is the place I'm looking for not at the top of the list? Nominatim uses various heuristics to calculate the order to show search results, these include the area of the map you were looking at when you did the search, the 'importance' or a place and how accurately your search string matches the result. Exact matches win over anything else but after that the most significant factor is importance of the returned feature which is calculated either from the tagging (i.e. town, city, country) or preferably from the linked wikipedia article. If you find a place is not where you expect it to be the simplest way to resolve the problem is usually to add a wikipedia tag to the data in osm. Am 02.05.2015 um 21:43 schrieb Christian H. Bruhn: Hallo! Ich habe gestern auf openstreetmap.org nach Wildpark Eekholt gesucht. Da gab es mehrere Suchergebnisse. Das erste war http://www.openstreetmap.org/node/2414231380 , welches ein Straßenschild ist. So eine braune Tafel, welche an Autobahnen auf touristische Ziele hinweist. Gerade in Verbindung mit der neuen Routingfunktion auf der der Hauptseite ist das unpraktisch, da dort wohl stets das erste Ergebnis genommen wird und einen nun zu dieser Hinweistafel an der Autobahn, statt zum eigentlichen Wildpark https://www.openstreetmap.org/relation/1918204 leitet. Ich habe keine Ahnung wie man das verbessern kann. Vielleicht sollte Nominatim irgendwie die Relevanz von den Ergebnissen besser sortieren, so daß eine große Toristenattraktion Vorrang vor einem Straßenschild haben sollte. Christian ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-fr] Normalisation du tag antenne
Le 2 mai 2015 23:14, dHuy Pierre dh...@yahoo.fr a écrit : Pour ta norme pour cartographier les données associées aux antennes si tu veux. Je n'ai pas parlé de ma norme... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk] Data Quality - was Re: Chain Store Cleanup
On 2015-05-02 23:28, Frederik Ramm wrote: We collect observations. ... There is no way for the mapper on the ground to know that the name on the building should be something else. I think that sounds rather disingenuous. We humans are perfectly capable of correctly interpreting data which contains errors, and recognising what the error is. And there are plenty of types of information in OSM which are not (easily) verifiable on the ground - admin boundaries spring to mind. The important thing in my mind is that the information should be independently verifiable from publicly accessible (and appropriately licensed) sources, thus making the information objective. Of course the signs on the ground come into that category, but they are not necessarily superior to other valid sources. There are plenty of spelling and grammatical mistakes on public signs, and although we are not the world's signage police, we should not be in the business of propagating obvious errors either. You mentioned quality in another post; that implies the extent of adherence to agreed criteria it's a problem that we cannot yet measure the quality of our data because there is no consensus on what is good and what is not. That's why these discussions go round and round and round for a couple of weeks and then die off. There seems to be little motivation or drive to reach a clear conclusion. We don't even manage to work out *how* to determine what is good. It's time we grew the balls we need to have the very painful talk about good data vs. bad data, followed by finding the right balance between quality and quantity. Quality itself can be subjective. What's fit for my purpose may break the data's usability for yours. And yet there is only one OSM data set. What are we going to agree to put in there, to keep the majority of people happy? What is our shared definition of quality? //colin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Case study: Lloyds TSB (Was: Chain Store Cleanup)
On 2 May 2015 at 22:10, Rob Nickerson rob.j.nicker...@gmail.com wrote: Andy Mabbett wrote: I suppose it depends whether we want to map what (sometimes incorrect) store signs say, or what the stores actually are. I favour the latter, but if you want the former, I have a list defunct shops whose signs are still visible, which you can add Another issue to consider is that either method will incude some errors. Which will include fewest, and which will inconvenience our users less? How long will it take for all our entries for Domino's to be manually updated, even after the signs are changed? I also favour the latter too. I feel this is an area where the on the ground rule is too strong. For an idea of how long it takes to *manually update* shop names take a look at Lloyds TSB in the UK. In September 2013 the bank split into two separate banks and they were quickly rebranded as Lloyds and TSB. As it was impossible to say which branch became a Lloyds and which branch became a Lloyds so a mechanical edit wasn't possible. Almost 2 years later we still have 400 Lloyds TSB in OpenStreetMap [1] and this is despite the fact that a tool was developed for the UK mappers to help them find the remaining incorrect instances of Lloyds TSB. Without this tool I expect there would be many hundreds more. I don't want to say the UK mapping community is dead, but it is not big enough to manage the volume of data we already have in OSM. Any tools that can help this situation (tools to compare to external data sources, QA tools, Maproulette type tools, apps for Android, Windows phone and iOS, and yes, mechnaincal edits) would be welcome in my eyes. We need to grow our community and our toolset. Best, Rob +1 in all respects. If we map incorrect stuff on the ground it's only going to support incorrect names. Where mechanical edits (or better) is possible, it's a case of letting the world catch up to OSM rather than the other way around. At least we can change name to old_name as an edit and then create a new new name based on the name change - so the db reflects old and new - and hopefully a search for LloydsTSB branch at ** should still find it even as an old name. -- Mike. @millomweb https://sites.google.com/site/millomweb/index/introduction - For all your info on Millom and South Copeland via *the area's premier website - * *currently unavailable due to ongoing harassment of me, my family, property pets* TCs https://sites.google.com/site/pmailkeey/e-mail ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Chain Store Cleanup
On 2 May 2015 at 22:28, Frederik Ramm frede...@remote.org wrote: I know you have a Wikidata background and things may be different in Wikidata I've been editing OSM longer than Wikidata has existed. Even had I not, I don't think your attempt to analyse my background has any place on this list. -- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Data Quality - was Re: Chain Store Cleanup
On 2 May 2015 at 23:05, Colin Smale colin.sm...@xs4all.nl wrote: On 2015-05-02 23:28, Frederik Ramm wrote: We collect observations. ... There is no way for the mapper on the ground to know that the name on the building should be something else. I think that sounds rather disingenuous. We humans are perfectly capable of correctly interpreting data which contains errors, and recognising what the error is. And there are plenty of types of information in OSM which are not (easily) verifiable on the ground - admin boundaries spring to mind. The important thing in my mind is that the information should be independently verifiable from publicly accessible (and appropriately licensed) sources, thus making the information objective. Of course the signs on the ground come into that category, but they are not necessarily superior to other valid sources. There are plenty of spelling and grammatical mistakes on public signs, and although we are not the world's signage police, we should not be in the business of propagating obvious errors either. You mentioned quality in another post; that implies the extent of adherence to agreed criteria it's a problem that we cannot yet measure the quality of our data because there is no consensus on what is good and what is not. That's why these discussions go round and round and round for a couple of weeks and then die off. There seems to be little motivation or drive to reach a clear conclusion. We don't even manage to work out *how* to determine what is good. It's time we grew the balls we need to have the very painful talk about good data vs. bad data, followed by finding the right balance between quality and quantity. Quality itself can be subjective. What's fit for my purpose may break the data's usability for yours. And yet there is only one OSM data set. What are we going to agree to put in there, to keep the majority of people happy? What is our shared definition of quality? //colin HERE HERE. Having said that, I fear the grey area is almost as large as a popular blue-green planet. I think whatever is decided as being the correct way can only end up being a guide. There's always the possibility the correct way will change in time as we learn. The correct way needs to be easily accessible too - to all - especially newbies to OSM. It seems iD is the preferred newbie editor so that needs to be designed to guide all in using correct ways. When we come across incorrect signs, how big a deal is it to point them out and at least start the ball rolling to get them corrected ? As a keen data observer, I'm doing it - even correcting Ordnance Survey. -- Mike. @millomweb https://sites.google.com/site/millomweb/index/introduction - For all your info on Millom and South Copeland via *the area's premier website - * *currently unavailable due to ongoing harassment of me, my family, property pets* TCs https://sites.google.com/site/pmailkeey/e-mail ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Chain Store Cleanup
On 2 May 2015 at 23:18, Andy Mabbett a...@pigsonthewing.org.uk wrote: On 2 May 2015 at 22:28, Frederik Ramm frede...@remote.org wrote: I know you have a Wikidata background and things may be different in Wikidata I've been editing OSM longer than Wikidata has existed. Even had I not, I don't think your attempt to analyse my background has any place on this list. Frederik, Andy started out as a valve in ENIAC. -- Mike. @millomweb https://sites.google.com/site/millomweb/index/introduction - For all your info on Millom and South Copeland via *the area's premier website - * *currently unavailable due to ongoing harassment of me, my family, property pets* TCs https://sites.google.com/site/pmailkeey/e-mail ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [talk-au] camp sites
I have an ideological objection to introducing key values that represent composite keys (e.g. serviced === standard + shower + power). Over time, the definition of such values becomes more and more convoluted (e.g. how do I tag a campsite that is standard + shower? Introduce another bloody campsite=* value, of course!). This also introduces unnecessary complexity that makes the data harder to use (e.g. an app that allows search for showers suddenly needs to know about the definition of campsite=serviced). I've made this point several times over the last several years, but either I haven't made it effectively, or I'm wrong. On Sat, May 2, 2015 at 3:39 PM, David Bannon dban...@internode.on.net wrote: On Sat, 2015-05-02 at 14:36 +1000, Ian Sergeant wrote: Hi, My only observation would be that in Australia toilets and no water seems a very common combination at camp grounds. You know the kind of campground I'm talking about, with either drop toilets or unpotable water. Thanks Ian. The 'standard' level has water, not necessarily potable or drinking water. So much of your use case is covered. Some effort was put in to minimise the number of steps. Too many and the idea would be unwieldy. So that call had to be made. I reckon at least 95% of camps with a toilet also had water, probably better. So we are playing the odds ! Please consider voting ! david ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [OSM-talk] Chain Store Cleanup
While you're at it, please consider adding brand:wikidata=Q38076 for McDonald's you verify. Polyglot 2015-05-03 0:28 GMT+02:00 pmailkeey . pmailk...@googlemail.com: On 2 May 2015 at 23:18, Andy Mabbett a...@pigsonthewing.org.uk wrote: On 2 May 2015 at 22:28, Frederik Ramm frede...@remote.org wrote: I know you have a Wikidata background and things may be different in Wikidata I've been editing OSM longer than Wikidata has existed. Even had I not, I don't think your attempt to analyse my background has any place on this list. Frederik, Andy started out as a valve in ENIAC. -- Mike. @millomweb https://sites.google.com/site/millomweb/index/introduction - For all your info on Millom and South Copeland via *the area's premier website - * *currently unavailable due to ongoing harassment of me, my family, property pets* TCs https://sites.google.com/site/pmailkeey/e-mail ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [talk-au] camp sites
On 3 May 2015 at 10:22, David Bannon dban...@internode.on.net wrote: No possible, in any readable way, to render something like this. Either all the icons appear on top of each other or, most are discarded. And imagine just how many columns need be added to the render database. The proposed categories are almost a mapping of the amenity to broad categories. So the mapper would have to identify the amenities, decide on a corresponding category, and tag that. I can't see any reason why this responsibility should be given to the mapper. The corresponding categories may be better held in a software ruleset, and the mapper just enumerate the amenities on the campsite that they are aware of. Ian. ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] camp sites
On 3/05/2015 2:50 PM, Ian Sergeant wrote: I can't see any reason why this responsibility should be given to the mapper. The corresponding categories may be better held in a software ruleset, and the mapper just enumerate the amenities on the campsite that they are aware of. Mappers take on many responsibilities. If a mapper chooses to enumerate all the facilities that too is a responsibility. And then the responsibility of rendering the 'level of amenity' falls to the render. Whatever way it is cut there is a 'responsiblity', and I'd rather see the 'rules' and have the mapper make the choice from local knowledge rather than pass it to some remote person who can only judge it from a yes/no answer. ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-br] Áreas de perigo
Existem pessoas mais assombradas e existem pessoas menos assombradas. Em 2 de maio de 2015 16:23, Márcio Vinícius Pinheiro marcioviniciu...@gmail.com escreveu: Quanto a mapear áreas de risco, continuo achando temerário. Acho válido que haja aplicativos e sites específicos para esse fim que se utilizem do OSM, mas não parece coerente incluir essas informações diretamente no mapa pela simples subjetividade do tema. Não é nem pela negatividade que a classificação traz. De forma análoga, poderíamos discutir se vale a pena marcar áreas relaxantes... Algo igualmente muito subjetivo (muito embora também da mesma forma haja estatísticas a respeito).exemplo mostra que não é inteiramente fora de propósito inserir este tipo de informação num mapa. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk] Chain Store Cleanup
I found a few McDonald's that are not what you think they are. In OSM there is a McDonald's confectionery shop in Mexico, a McDonald's supermarket in Missouri, and a McDonald's kitchen store in New Hampshire that are not fast food restaurants. Looks like you need to be careful when fixing these. This is due to weirdness in trademark laws where sometimes companies in different categories are allowed to use the same trademark - e.g. Apple Inc. and Apple Records. I am pretty confident that any fast food/restaurant that is called McDonald's is what you think it is though. Most of the time (at least with suburban locations) you can tell that it is a McDonald's from the aerial imagery. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [talk-au] camp sites
On 3/05/2015 10:22 AM, David Bannon wrote: On Sun, 2015-05-03 at 08:41 +1000, waldo000...@gmail.com wrote: I have an ideological objection to introducing key values that represent composite keys (e.g. serviced === standard + shower + Yes Waldo, I do understand this point. But conversely, its useful to look closely at the problem from a map user's point of view. We identified, in a few emails, twenty plus characteristics of camp sites that would interest people. There are undoubtedly a lot more ! Not possible, in any readable way, to render something like this. The object it to show on the map (without interrogation) the level of amenity at camp sites. If say 5 camp sites are shown on the map in close proximity to each other, at the moment there is no way to visually distinguish (from the rendering) between them for level of amenity. Most of the camp sites I have been too where a toilet is available have had water too, even 'dry' toilets (long drop or other). I'd think 'they' do this for sanitary reasons! The introduction of this tag does not mean that camp site features cannot be added in other ways, additional to or despite this tag. ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] camp sites
On Sun, 2015-05-03 at 08:41 +1000, waldo000...@gmail.com wrote: I have an ideological objection to introducing key values that represent composite keys (e.g. serviced === standard + shower + Yes Waldo, I do understand this point. But conversely, its useful to look closely at the problem from a map user's point of view. We identified, in a few emails, twenty plus characteristics of camp sites that would interest people. There are undoubtedly a lot more ! No possible, in any readable way, to render something like this. Either all the icons appear on top of each other or, most are discarded. And imagine just how many columns need be added to the render database. Not going to happen. But, speaking to campers around the world, it emerged that the scheme on the proposal adequately described a large percentage of camp sites AND a large percentage of end users needs. Its how campers describe sites amongst themselves. The assumption being the 'other' things probably come along at the appropriate level. So this proposal is about providing information to the end user (of typically a map). Its not mapping for the renderer but is about mapping in such a way that the data is usable. And no reason to assume using this tag will discourage tagging of the individual features. Indeed, in typical usage, once a user identifies a likely camp site, they will drill down in some way and look at the details. Your concern seems to be about feature creep, I really cannot guarantee that won't happen but assure you the designers don't plan any such behaviour at this stage. Quite the converse. https://wiki.openstreetmap.org/wiki/Proposed_features/Camp_Site David power). Over time, the definition of such values becomes more and more convoluted (e.g. how do I tag a campsite that is standard + shower? Introduce another bloody campsite=* value, of course!). This also introduces unnecessary complexity that makes the data harder to use (e.g. an app that allows search for showers suddenly needs to know about the definition of campsite=serviced). I've made this point several times over the last several years, but either I haven't made it effectively, or I'm wrong. On Sat, May 2, 2015 at 3:39 PM, David Bannon dban...@internode.on.net wrote: On Sat, 2015-05-02 at 14:36 +1000, Ian Sergeant wrote: Hi, My only observation would be that in Australia toilets and no water seems a very common combination at camp grounds. You know the kind of campground I'm talking about, with either drop toilets or unpotable water. Thanks Ian. The 'standard' level has water, not necessarily potable or drinking water. So much of your use case is covered. Some effort was put in to minimise the number of steps. Too many and the idea would be unwieldy. So that call had to be made. I reckon at least 95% of camps with a toilet also had water, probably better. So we are playing the odds ! Please consider voting ! david ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-br] Evento de mapeamento na USP São Carlos
Ótimo, João!! É muito bom ver o OpenStreetMap na mídia. Adicionei no wiki: https://wiki.openstreetmap.org/wiki/OpenStreetMap_in_the_media#2015 abraços, wille On 02-05-2015 14:37, Joao Porto wrote: Olá Julio, Infelizmente não gravamos o webinar dessa vez. A propósito, o nossos eventos de mapeamento colaborativo foram divulgados na mídia, e assim também o OSM: http://g1.globo.com/sp/sao-carlos-regiao/noticia/2015/05/alunos-da-usp-sao-carlos-ajudam-mapear-areas-destruidas-no-nepal.html Abraços, João Porto Em 29 de abril de 2015 11:22, Julio Refosco ju...@3geo.com.br mailto:ju...@3geo.com.br escreveu: Olá João, como podemos ter acesso a este webinar? Obrigado, Julio /- / /Julio Cesar Refosco/ /Engenheiro Florestal, Dr., Especialista em GIS e Gestão Ambiental/ /www.3geo.com.br http://www.3geo.com.br/ /ju...@3geo.com.br mailto:ju...@3geo.com.br/ /04796170560 tel:04796170560/ Em 27 de abril de 2015 21:25, Joao Porto jpo...@gmail.com mailto:jpo...@gmail.com escreveu: Pessoal, Hoje fizemos um evento de mapeamento humanitário com os estudantes da USP São Carlos para o Nepal e Xanxerê (aparentemente os estudantes se concentraram mais no Nepal): http://www.agora.icmc.usp.br/site/?p=922 Agradeço muito ao Wille que fez um webinar introdutório aos estudantes, mesmo com o aviso em cima da hora, muito obrigado! Espero que tenhamos ajudado os esforços humanitários e ganhado alguns novos mapeadores para a comunidade OSM Brasil. Abraços, João Porto ___ Talk-br mailing list Talk-br@openstreetmap.org mailto:Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org mailto:Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
