Re: [OSM-talk-fr] Fond OSM dans des guides de rando du CD63 ?

[JB]

Ok, en fait, j'ai à peu près rien compris :-(

Le 02/02/2016 20:46, Landry Breuil a écrit :

2016-02-02 18:21 GMT+01:00 JB :

Bonjour,
Une très bonne nouvelle !
Je me souviens d'une longue discussion que j'avais eue l'été 2014 avec un
gars bien informé de l'office de tourisme à Clermont-Ferrand. Je pensais en
avoir fait un compte-rendu, mais je n'arrive pas à en retrouver de trace.
C'était à l'époque du deuxième topoguide®, on avait notamment parlé de FFRP,
IGN, carte IGN, et un peu OpenStreetMap. J'avais par hasard avec moi la
carte que j'avais sortie pour le tour de la chaine des Puys.
Ceci dit :
  - est-ce qu'il serait possible de connaitre les circuits pressentis pour le
prochain guide, histoire de contribuer au meilleur endroit ?

Bonne question, ne pas hésiter à demander directement à guillaume, je suis
juste le messager...


  - les traces gps fournies sont de qualité… moyenne, à ne pas privilégier
sur d'autres sources, ou à moyenner avec d'autres traces (j'ai contribué
dans la zone, et en comparant certaines dont je pense la précision correcte,
celles fournies restent moyennes). En tous cas, ne pas supprimer la donnée
OSM pour la remplacer par cette donnée qui serait « de référence ».

J'ai l'impression qu'il y'a mésentente ici. les PDIPR ne sont pas
*pas* en opendata,
donc pas importables dans OSM. J'avais pourtant pensé etre clair dans
mon mail initial.
La notion 'donnée de référence' est annexe ici.

J'ai fourni le lien vers le shapefile des PDIPR présents sur notre
catalogue de données
*uniquement* pour la liste/les emprises des zones concernées...


  - si R25 est pressenti pour le rendu, je veux bien y passer un peu de
temps. Quand la donnée est bonne, la génération de carte est rapide (quand
on a l'habitude, en tous cas).

A discuter directement avec guillaume, quand on avait évoqué le sujet
c'était plutôt
"dans arcgis on a accès directement a un fond OSM" donc je ne sais pas a quel
rendo/fond/service ca correspond. A mon avis dans un premier temps il
n'était pas
prévu de rendu particulier, sauf si evidemment quelqu'un se porte
volontaire pour
gérer ca..

Landry


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

Re: [Talk-at] Via Ferrata/Klettersteig - Wie richtig taggen?

[Friedrich Volkmann]

On 02.02.2016 14:01, Robert Kaiser wrote:
> highway=stairs oder highway=primary_link sind auch nur kurze
> Stücke, haben aber durchaus Aussage. Und gerade mit "stairs" wäre dieses
> "climbing" gut vergleichbar.

Ich weiß schon einen Unterschied: Bei steps und primary_link ist klar, wo
sie anfangen und aufhören, nämlich bei der ersten/letzten Stufe bzw. bei der
Einmündung in die andere Straße. Bei Kletterrouten ist es meist
Geschmacksache, wo man einen Übergang zwischen Gehgelände und 1- ansetzt. Es
hängt auch davon ab, wie sehr man ins Micromapping geht. Das Mosaik aus
Kletterstellen und Gehgelände hat fraktalen Charakter, man könnte es bis zu
den einzelnen Tritten zerlegen.

Der Vergleich mit highway=stairs (eigentlich =steps) spricht nicht unbedingt
für ein neues higway-Tag. Denn wenn es noch kein Tag für Stiegen gäbe und
wir jetzt eines erfinden müssten, würden wir uns sicher für steps=yes
entscheiden, analog zu bridge=yes, tunnel=yes usw. Stufen kann es auf einem
footway oder auf einem path geben, vielleicht sogar auf einem bridleway oder
auf leisure=track. Ich kenne auch einen Radweg mit Stufen. Gerade sehe ich,
dass steps=* sogar schon 7883-mal verwendet wird.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

Re: [Talk-it] Incontro con assessore su OpenData

[Francesco Piero Paolicelli]

mi permetto di suggerirti due miei lavori. il primo condiviso durante il
raduno italiano di spaghetti opendata:
http://www.slideshare.net/piersoft/bignami-opendata-per-pa-di-piccole-dimensioni
http://www.slideshare.net/piersoft/sod15-opendata-nella-pa-di-piccole-dimensioni-processo-sartoriale-o

sono aggiuntive all'ottima sintesi che ha fatto Napo e danno un punto di
vista pratico e social.
Le ho applicate su Lecce quest'anno e mi hanno portato fortuna facendo
vincere al Comune il primo premio E-Gov proprio per gli openData
partecipativi.


Il giorno 2 febbraio 2016 18:40, Maurizio Napolitano 
ha scritto:

> Ciao Lorenzo
> sul tema potrei parlare per giornate intere visto che si tratta del mio
> lavoro affrontato a più livelli (es. l'istituzione per cui lavoro è nodo
> dell'Open Data Institute inglese - http://trento.theodi.org )
> Cercando di sintetizzare vado per punti (riportando anche alcune cose che
> ho scritto)
>
> - Reggio Emilia
> il tema mi interessa parecchio anche perchè faccio parte del comitato
> scientifico dell'agenda digitale dell'Emilia Romagna.
> Il primo consiglio è quello di investire molto nel dialogo con
> l'amministrazione regionale
> http://dati.emilia-romagna.it/
> in particolare nel legame con il progetto ADER - Agenda Digitale Emilia
> Romagna
>
> - open data è prima di tutto processi
> aprire dati vuol dire impattare sui processi organizzativi, questo non va
> assolutamente dimenticato.
> L'apertura dei dati deve essere, prima di tutto, guidata dalla opportunità
> di offrire un vantaggio.
> Credo fortemente che le parole chiave siano: crescità, riuso e
> sostenibilità.
> crescita => si tratta di una operazione di miglioramento del processo di
> produzione
> riuso => il tema del riuso (inteso nei formati, nei vocabolari condivisi e
> nella metadatazione) deve essere cruciale
> sostenibilità => i processi che si creano devono essere guidati fortemente
> dalla sostenibilità nel tempo, altrimenti rimangono cattedrali nel deserto.
> Ne parlo qui
>
> http://www.forumpa.it/dati-riuso-sostenibilita-e-crescita-tre-parole-chiave-per-cogliere-lopportunita-degli-open-data
> e consiglio anche di dare una occhiata a questa formula
> http://de.straba.us/2015/02/18/un_calcolo_per_lopendata/
> che aiuta a guidare una strategia di apertura
>
> Rimando infine a questo lavoro di Luca Corsato, Andrea Raimondi e Simone
> Cortesi
> https://medium.com/@lucacorsato/masterplan-aeb009ca8afd#.415zfh5xh
> che parla proprio del tema dei processi
>
> - piattaforma di pubblicazione dei dati
> l'argomento è molto delicato.
> Partiamo dalla piattaforma di pubblicazione dei dati.
> È importante usarne una che si colleghi a standard internazionali per
> quello che riguarda la metadatazione dei cataloghi.
> Il vocabolario di riferimento è DCAT.
> Al momento AgID ha aperto una consultazione su DCAT-AP, ovvero una
> estensione di DCAT
> http://www.dati.gov.it/consultazione/dcat-ap_it
> Avere una metadatazione dei cataloghi condivisa permette un bel salto di
> qualità.
> CKAN si o no? Io sono per CKAN, ,ma non sto qui a dilungare, quello che
> ritengo più
> importante in assoluto è avviare dei processi di sostenibilità nella
> pubblicazione in modo che i metadati del dataset siano allineati con il
> dataset stesso (in ckan si parla di harvesting).
>
> - formati e vocabolari
> siamo pieni di formati senza metadati e vocabolari e di formati in grado
> di unire queste caratteristiche.
> Più il formato è ricco, e meno è ampio il pubblico a cui ci si rivolge ma
> più facilmente è trasformabile in un formato che chiunque può usare.
> AgID nelle linee guida sul patrimonio informativo pubblico (che consiglio
> vivamente di leggere)
>
> http://www.agid.gov.it/sites/default/files/linee_guida/patrimoniopubblicolg2014_v0.7finale.pdf
> fa questa distinzione
> Qui una slide con lo schema
> http://www.slideshare.net/napo/opendata-suggerimenti-per-dati-di-qualit/19
> Concordo sul fatto che sia importante offrire più formati
> Attenzione al kml (o kmz) è tanto bello quanto sfigato
> Sempre nelle linee guida AgID è scritto come dovrebbe essere distribuito
> (c'è una carenza sul fronte descrizione dei campi)
> Kml piace tanto ma o va distribuito bene o meglio accompagnarlo con altri
> formati
> Meglio ancora se questi geodati sono serviti da un webservice secondo
> standard ogc e si pubblicano i link di come ottenerli convertiti
> Se serve giro esempi
> Consiglio anche la lettura delle linee guida del Trentino
> http://www.provincia.tn.it/progetto_open_data/
>
> - open data e impatto sociale
> L'apertura dei dati ottiene maggior effetto se si cerca di arricchirne il
> contesto
> (vd il capitolo 5 delle linee guida AgID)
> Rimando a questa lettura
> http://www.chefuturo.it/2012/12/wasted-datafood/
>
> Se non erro la Regione Emilia Romagna sta partendo con dei progetti per la
> creazione di laboratori
> Potrebbe essere una buona idea proporli all'assessore ruotando poi su
> openstreemap come ottimo esempio
>
> - 

Re: [Talk-at] Via Ferrata/Klettersteig - Wie richtig taggen?

[Thomas Konrad]

> Bei Kletterrouten ist es meist
> Geschmacksache, wo man einen Übergang zwischen Gehgelände und 1- ansetzt.

Ja das stimmt schon, aber wie bei vielen Dingen in OSM ist hier halt ein wenig 
Abstraktionsvermögen gefragt. Bei so unregelmäßigen Untergründen wie im Gebirge 
lässt sich aus meiner Sicht kaum verhindern, dass vom Mapper “verlangt” wird, 
vernünftig zu abstrahieren. Dasselbe hat man ja beim Schwierigkeitsgrad, der 
ändert sich ja auch auf jedem Meter, wenn man das so sehen will.

> Denn wenn es noch kein Tag für Stiegen gäbe und
> wir jetzt eines erfinden müssten, würden wir uns sicher für steps=yes
> entscheiden, analog zu bridge=yes, tunnel=yes usw. 

Da gebe ich dir Recht (ist aber ein anderes Thema).

> On 02 Feb 2016, at 19:58, Friedrich Volkmann  wrote:
> 
> On 02.02.2016 14:01, Robert Kaiser wrote:
>> highway=stairs oder highway=primary_link sind auch nur kurze
>> Stücke, haben aber durchaus Aussage. Und gerade mit "stairs" wäre dieses
>> "climbing" gut vergleichbar.
> 
> Ich weiß schon einen Unterschied: Bei steps und primary_link ist klar, wo
> sie anfangen und aufhören, nämlich bei der ersten/letzten Stufe bzw. bei der
> Einmündung in die andere Straße. Bei Kletterrouten ist es meist
> Geschmacksache, wo man einen Übergang zwischen Gehgelände und 1- ansetzt. Es
> hängt auch davon ab, wie sehr man ins Micromapping geht. Das Mosaik aus
> Kletterstellen und Gehgelände hat fraktalen Charakter, man könnte es bis zu
> den einzelnen Tritten zerlegen.
> 
> Der Vergleich mit highway=stairs (eigentlich =steps) spricht nicht unbedingt
> für ein neues higway-Tag. Denn wenn es noch kein Tag für Stiegen gäbe und
> wir jetzt eines erfinden müssten, würden wir uns sicher für steps=yes
> entscheiden, analog zu bridge=yes, tunnel=yes usw. Stufen kann es auf einem
> footway oder auf einem path geben, vielleicht sogar auf einem bridleway oder
> auf leisure=track. Ich kenne auch einen Radweg mit Stufen. Gerade sehe ich,
> dass steps=* sogar schon 7883-mal verwendet wird.
> 
> -- 
> Friedrich K. Volkmann   http://www.volki.at/
> Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
> 
> ___
> 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-ca] Talk-ca Digest, Vol 96, Issue 1

[Mojgan Jadidi]

Hi again,

Please accept again my apology!

So I want make it in right way, what we should do, some of you see our data
and did some queries too. If you accept to proceed next step (asking pnorman
to revert back the data) will allow me to do visual inspection (once again
as final verification) in whole region as soon as possible for
any conflict on data server. I am ready to answer any questions regarding
to procedure, data quality, and any geospatial related issues in bulk
import.

Please feel free to send me your feedback!

Thanks
Mojgan

*Mojgan Jadidi, Ph.D.*

*Intern, Applied Research and Corporate Monitoring,*

*Metrolinx  |  97 Front Street West, Toronto, ON, M5J 1E6 | T: 416-202-5844
<416-202-5844>*


*Postdoctoral Research Fellow*
*GeoICT Lab | York University | 4700 Keele St, Toronto, ON, **M3J 1P3*

ca.linkedin.com/pub/mojgan-amaneh-jadidi/10/825/969/

On 2 February 2016 at 10:54, Mojgan Jadidi  wrote:

> Thanks Paul,
> That was totally my mistake to not doing in the way that you explained,
> but I am here to fix any problem. I am willing to collaborate as the
> community expect. Indeed my next plan was do an extra visual inspection on
> OSM data server to remove any duplication or conflict. I hope this
> miscommunication issue will be resolved soon, and we can open-up our data
> to the community.
>
> I am struggling to find a solution
> Thanks
>
> Mojgan
>
> *Mojgan Jadidi, Ph.D.*
>
> *Intern, Applied Research and Corporate Monitoring,*
>
> *Metrolinx  |  97 Front Street West, Toronto, ON, M5J 1E6 |
> T: 416-202-5844 <416-202-5844>*
>
>
> *Postdoctoral Research Fellow*
> *GeoICT Lab | York University | 4700 Keele St, Toronto, ON, **M3J 1P3*
>
> ca.linkedin.com/pub/mojgan-amaneh-jadidi/10/825/969/
>
> On 2 February 2016 at 10:48, Paul Ramsey 
> wrote:
>
>> Yeah, from the outside looking in I'm not seeing the huge surprise.
>> I'm not a community member, but I saw the initial emails from Mojgan,
>> and he's also talked to folks face-to-face. I didn't see an email
>> about the wiki page, but that could be because I wasn't paying
>> attention. What would a good process look like?
>>
>> x- email: "hi, I'm a government organization and I'd like to engage
>> this way, we want to do this"
>> x- comment/response/refine
>> x- wiki: "here is exactly what we plan to do and how we are going to do
>> it"
>> - email: "hi, we now have specific plans and have documented them here
>> in the wiki for your comment"
>> - comment/response/refine
>> - email: "hi, we are going to run a small test import in the following
>> area for your review, please comment"
>> - import: "here's a small amount of data, exactly as we'd do it in a
>> larger area"
>> - email: "hi, we have run a small test import in the following area,
>> please review and comment"
>> - comment/response/refine
>> - email: "hi, we are about to run our main import in the following
>> area, please light your hair on fair if you still have a problem with
>> this"
>> - import: "boom, there it is"
>>
>> I did see the first three communications for sure, and maybe missed
>> one on the wiki. Probably for a big import running a test import first
>> would be a generally wise approach for getting feedback (similar to
>> publishing a github branch).
>>
>> Triplinx has definitely been approaching this in very good faith,
>> shame to see them get reverted for failing to follow a process that
>> doesn't seem to be documented. They certainly met the "communicated"
>> threshold, just maybe not enough or in the right ways for some folks?
>>
>> P.
>>
>>
>> On Tue, Feb 2, 2016 at 6:51 AM, Begin Daniel  wrote:
>> > Initial misunderstandings, emails round trips with the community…
>> standard
>> > communication process!
>> >
>> >
>> >
>> > I do not know how others a seeing it, but reading about the process you
>> use,
>> > I do not see anything like a wild bulk import. At least, it is very
>> similar
>> > to the process I used when importing Canvec datasets.
>> >
>> >
>> >
>> > Daniel
>> >
>> >
>> >
>> > From: Mojgan Jadidi [mailto:mojgan.jad...@gmail.com]
>> > Sent: February-02-16 09:33
>> > To: talk-ca@openstreetmap.org
>> > Subject: Re: [Talk-ca] Talk-ca Digest, Vol 96, Issue 1
>> >
>> >
>> >
>> > Hi all,
>> >
>> > Please accept my apology for this misunderstanding, I thought our
>> presence
>> > for last OSM meeting and flowing emails in Talk-ca and with John were
>> part
>> > of communication and discussion, we launched our wikipage two weeks
>> ago, and
>> > we did not receive any feedback, so we thought to start import via JOSM.
>> >
>> >
>> >
>> > as we expalined in our wikipage, we created the algorithm to detect the
>> > missing information, and then we check the quality of this information
>> on
>> > JOSM on the top of OpenStreetMap, Bing Areal imagery, GeoBase Road
>> network
>> > and some local municpal open data. the data is created initially through
>> > StatCan, however, we noticed the 

Re: [Talk-es] secciones censales zgz

[Rafael Avila Coya]

Eso sí es cierto. Igual habría que preguntar.

Rafael.

On 02/02/16 22:03, Miguel Sevilla-Callejo wrote:
> Mmmm, pues llevas razón pero habŕa uqe saber is las secciones censales,
> sus límites, son algo exclusivo del INE y habría de pensar cómo han de
> citarse en OSM.
> ;-)
> 
> *GeoMiguel Sevilla Callejo*
> *Doctor en Geografía | Doctor in Geography*
> /Consultor freelance e investigador | Freelance Consultant & Researcher/ 
> Colaborador del Instituto Pirenaico de Ecología, CSIC, Zaragoza | Fellow
> at the Pyrenean Institute of Ecology - Spanish National Research Council
> Colegiado nº698, Colegio Oficial de Geógrafos | Member #698, Spanish
> Professional Association of Geographers
> Web: http://bit.ly/sevillacallejo 
> 
> **
> 
> 2016-02-02 15:59 GMT+01:00 Rafael Avila Coya  >:
> 
> Hola:
> 
> No veo porqué no es compatible con la ODbL, siempre y cuando uses datos
> de autoría exclusiva del INE.
> 
> Un saludo,
> 
> Rafael.
> 
> On 02/02/16 15:21, Miguel Sevilla-Callejo wrote:
> > Me respondo yo solo con respecto a lo de las secciones censales:
> >
> > De la web del INE  [1] se puede leer:
> >
> > [...]
> >
> > 5. Reutilización de la información contenida en este sitio web
> >
> > La información contenida en este sitio web procede de múltiples fuentes,
> > por lo que el INE solo autoriza la reutilización de aquélla cuya fuente
> > original sea el propio INE y siempre bajo las siguientes condiciones
> > generales:
> >
> >   * Se prohíbe expresamente desnaturalizar el sentido de la
> información.
> >   * Debe citarse la fuente de la información objeto de reutilización.
> > Esta cita podrá realizarse de la siguiente manera: *Fuente: Sitio
> > web del INE: www.ine.es 
>  *si no se realiza ningún
> > tratamiento de los datos o bien: *Elaboración propia con datos
> > extraídos del sitio web del INE: www.ine.es
>  * en
> > caso de que se realice tratamiento de los datos.
> >   * Debe mencionarse la fecha de la última actualización de la
> > información objeto de reutilización, siempre y cuando estuviera
> > incluida en el original.
> >   * No se podrá indicar, insinuar o sugerir que el INE participa,
> > patrocina o apoya la reutilización que se lleve a cabo con la
> > información.
> >   * El INE no será responsable del uso que de su información hagan los
> > agentes reutilizadores. Tampoco será responsable de los daños
> > materiales o sobre datos, ni de posibles perjuicios económicos
> > provocados por el uso de la información reutilizada.
> >
> >
> > --
> >
> > O lo que es lo mismo, NO es compatible con OSM   :-(
> >
> >
> > [1]
> > 
> http://www.ine.es/ss/Satellite?L=0=Page=1254735849170=1254735849170=Ayuda%2FINELayout#
> >
> > *GeoMiguel Sevilla Callejo*
> > *Doctor en Geografía | Doctor in Geography*
> > /Consultor freelance e investigador | Freelance Consultant &
> Researcher/
> > Colaborador del Instituto Pirenaico de Ecología, CSIC, Zaragoza | Fellow
> > at the Pyrenean Institute of Ecology - Spanish National Research Council
> > Colegiado nº698, Colegio Oficial de Geógrafos | Member #698, Spanish
> > Professional Association of Geographers
> > Web: http://bit.ly/sevillacallejo 
> >
> > **
> >
> > 2016-02-02 15:15 GMT+01:00 Miguel Sevilla-Callejo  
> > >>:
> >
> > Hola,
> >
> > Alejandro Suarez y yo andábamos comentando sobre encontrar los
> > límites de los barrios de Zaragoza para incluirlos definitivamente
> > en la base de datos de OSM y hemos encontrado dos fuentes que
> quería
> > contrastar y comentar con alguno de vosotros para saber si alguien
> > ya se ha visto en una problemática similar.
> >
> > 1. Por un lado está la información urbanística del municipio, en
> > concreto la cartografía que emana del Plan General de Ordenación
> > Urbana de Zaragoza, tanto en un visor web [1], como accesible a
> > través de los mapas en PDF [2] en donde se ven los límites de los
> > distritos y barrios y sería relativamente sencillos de pasar (pues
> > coinciden con calles mayormente) a OSM.
> > ¿ALguien ha trabajado antes con información urbanística? ¿Alguien
> > sabe qué tipo de licencias de usos tiene esta información? Yo
> diría
> > que al ser algo público y que afecta a todo el mundo (escomo si se
> > tratara de una ley) habrá de tener una licencia libre, no?
> >

Re: [OSM-talk-fr] rendu Défibrillateur

[Erwan Salomon]

il me semble bien avoir proposé un lien sur le rendu fr en exemple

le miracle doit venir du fait que j’ai actualisé/complété le tag …
les autres cas que je regardaient ont des labels vraiment très rapproché, tous 
ne peut pas être rendu

au passage j’ai cherché des listes de défibrillateurs, quelques villes les 
fournissent en opendata (sous forme d’adresse, parfois de données issues d’OSM)
et 2 app sur mon téléphone (avec une localisation très approximative et 
beaucoup de doublons ou de manquant, pas vraiment exploitable dans l’urgence 
d’un arrêt cardiaque)
je trouve ça dingue que leurs emplacements ne soit pas mieux diffusé (par les 
pompiers qui forment des secouristes, les municipalités qui en placent dans 
leurs bâtiment …)

> Le 2 févr. 2016 à 22:08, osm.sanspourr...@spamgourmet.com a écrit :
> 
> Dans le premier cas tu utilises un rendu OSM France qui fait bien son boulot 
> et dans l'autre un rendu mondial qui le fait moins bien.
> J'ai repris les coordonnées du second et placé dans OSM FR : miracle (*)
>  
> http://tile.openstreetmap.fr/?zoom=18=47.74828=-3.3657=B00
>  
> 
>  
> http://tile.openstreetmap.fr/?zoom=18=47.74836=-3.36504=B00
>  
> 
>  est bien rendu
> Je soupçonne quelqu'un d'avoir fait un /dirty ou d'avoir mis à jour le rendu 
> récemment (ou je ne suis pas passé sur le même serveur mais je viens de 
> tester http://tile 
> -[a-c].openstreetmap.fr/osmfr/18/128621/91398.png).
> 
> (*) non, je ne crois pas aux miracles.
>  
> 
> 
> Le 02/02/2016 14:48, Erwan Salomon - r...@gmx.fr  a écrit 
> :
>> selon le wiki les défibrillateurs sont rendu dans OSM.fr  :  
>> http://wiki.openstreetmap.org/wiki/Tag:emergency%3Ddefibrillator
>>  
>> un exemple le prouve : 
>> http://tile.openstreetmap.fr/?zoom=17=44.12069=4.83901=B00
>>  
>> 
>> pourtant je constate que d’autres (  
>> http://www.tappenbeck.net/osm/maps/deu/index.php?id=1029=18=47.74828=-3.3657=BFTTT=de
>>  
>> 
>>  )ne sont pas rendu : 
>> http://tile.openstreetmap.fr/?zoom=18=47.74836=-3.36504=B000FF
>>  
>> 
>> 
>> il y a une explication ?
>> 
>> 
>> ___
>> 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: [Talk-es] secciones censales zgz

[Miguel Sevilla-Callejo]

Lo que suele suceder con estas cosas es uqe las bases suelen ser del IGN,
aunque desconozco si el INE llega producir cartografía extrictamente
propia. Por ambos lados imagino que habría via libre de importar datos
pero, si, habría que consultarlo si es que nos parece que la información de
las secciones censales es relaevante para OSM.
;-)

*[image: Geo]Miguel Sevilla Callejo*
*Doctor en Geografía | Doctor in Geography*
*Consultor freelance e investigador | Freelance Consultant & Researcher*
Colaborador del Instituto Pirenaico de Ecología, CSIC, Zaragoza | Fellow at
the Pyrenean Institute of Ecology - Spanish National Research Council
Colegiado nº698, Colegio Oficial de Geógrafos | Member #698, Spanish
Professional Association of Geographers
Web: http://bit.ly/sevillacallejo

2016-02-02 22:20 GMT+01:00 Rafael Avila Coya :

> Eso sí es cierto. Igual habría que preguntar.
>
> Rafael.
>
> On 02/02/16 22:03, Miguel Sevilla-Callejo wrote:
> > Mmmm, pues llevas razón pero habŕa uqe saber is las secciones censales,
> > sus límites, son algo exclusivo del INE y habría de pensar cómo han de
> > citarse en OSM.
> > ;-)
> >
> > *GeoMiguel Sevilla Callejo*
> > *Doctor en Geografía | Doctor in Geography*
> > /Consultor freelance e investigador | Freelance Consultant & Researcher/
> > Colaborador del Instituto Pirenaico de Ecología, CSIC, Zaragoza | Fellow
> > at the Pyrenean Institute of Ecology - Spanish National Research Council
> > Colegiado nº698, Colegio Oficial de Geógrafos | Member #698, Spanish
> > Professional Association of Geographers
> > Web: http://bit.ly/sevillacallejo 
> >
> > **
> >
> > 2016-02-02 15:59 GMT+01:00 Rafael Avila Coya  > >:
> >
> > Hola:
> >
> > No veo porqué no es compatible con la ODbL, siempre y cuando uses
> datos
> > de autoría exclusiva del INE.
> >
> > Un saludo,
> >
> > Rafael.
> >
> > On 02/02/16 15:21, Miguel Sevilla-Callejo wrote:
> > > Me respondo yo solo con respecto a lo de las secciones censales:
> > >
> > > De la web del INE  [1] se puede leer:
> > >
> > > [...]
> > >
> > > 5. Reutilización de la información contenida en este sitio web
> > >
> > > La información contenida en este sitio web procede de múltiples
> fuentes,
> > > por lo que el INE solo autoriza la reutilización de aquélla cuya
> fuente
> > > original sea el propio INE y siempre bajo las siguientes
> condiciones
> > > generales:
> > >
> > >   * Se prohíbe expresamente desnaturalizar el sentido de la
> > información.
> > >   * Debe citarse la fuente de la información objeto de
> reutilización.
> > > Esta cita podrá realizarse de la siguiente manera: *Fuente:
> Sitio
> > > web del INE: www.ine.es 
> >  *si no se realiza ningún
> > > tratamiento de los datos o bien: *Elaboración propia con datos
> > > extraídos del sitio web del INE: www.ine.es
> >  * en
> > > caso de que se realice tratamiento de los datos.
> > >   * Debe mencionarse la fecha de la última actualización de la
> > > información objeto de reutilización, siempre y cuando estuviera
> > > incluida en el original.
> > >   * No se podrá indicar, insinuar o sugerir que el INE participa,
> > > patrocina o apoya la reutilización que se lleve a cabo con la
> > > información.
> > >   * El INE no será responsable del uso que de su información hagan
> los
> > > agentes reutilizadores. Tampoco será responsable de los daños
> > > materiales o sobre datos, ni de posibles perjuicios económicos
> > > provocados por el uso de la información reutilizada.
> > >
> > >
> > > --
> > >
> > > O lo que es lo mismo, NO es compatible con OSM   :-(
> > >
> > >
> > > [1]
> > >
> http://www.ine.es/ss/Satellite?L=0=Page=1254735849170=1254735849170=Ayuda%2FINELayout#
> > >
> > > *GeoMiguel Sevilla Callejo*
> > > *Doctor en Geografía | Doctor in Geography*
> > > /Consultor freelance e investigador | Freelance Consultant &
> > Researcher/
> > > Colaborador del Instituto Pirenaico de Ecología, CSIC, Zaragoza |
> Fellow
> > > at the Pyrenean Institute of Ecology - Spanish National Research
> Council
> > > Colegiado nº698, Colegio Oficial de Geógrafos | Member #698,
> Spanish
> > > Professional Association of Geographers
> > > Web: http://bit.ly/sevillacallejo 
> > >
> > > **
> > >
> > > 2016-02-02 15:15 GMT+01:00 Miguel Sevilla-Callejo <
> msevill...@gmail.com 
> > > >>:
> > >
> > > Hola,
> > >
> > > Alejandro Suarez y yo andábamos comentando sobre encontrar los
> > > 

Re: [OSM-talk-fr] openstreetmap et les abeilles

[THEVENON Julien]

En date de : Mar 2.2.16, Adrien Grellier  a écrit :

 Objet: [OSM-talk-fr] openstreetmap et les abeilles
 À: talk-fr@openstreetmap.org
 Date: Mardi 2 février 2016, 18h07
 
> Bonjour,
 
> Je m'étonne qu'il n'y ait que très peu de choses sur le wiki d'OpenStreetMap 
> concernant l'apiculture. En effet, à par un « craft = beekeeper », je n'ai  
> pas trouvé grand chose.
 
> Ais-je mal cherché ? Ou bien il n'y a vraiment rien sur ce
 domaine dans OSM 
 ?
 
> Au départ je suis arrivé sur ce constat en voulant ajouter un magasin qui  
> vend du matériel apicole, mais je n'ai trouvé aucun tag. 
 
Bonjour,

Pour ce qui est des ruches, j en avais parle avec un collegue qui en possede et 
il y etait formellement oppose par crainte de vol de ruche et d interception d 
essaims en periode d essaimage

julien

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

Re: [OSM-talk-fr] openstreetmap et les abeilles

[Christian Quest]

En plus les ruches ça se déplace quand même souvent... c'est pas assez fixe
pour être dans OSM à mon avis.

Le 2 février 2016 à 21:30, THEVENON Julien  a
écrit :

>
> 
> En date de : Mar 2.2.16, Adrien Grellier  a écrit :
>
>  Objet: [OSM-talk-fr] openstreetmap et les abeilles
>  À: talk-fr@openstreetmap.org
>  Date: Mardi 2 février 2016, 18h07
>
> > Bonjour,
>
> > Je m'étonne qu'il n'y ait que très peu de choses sur le wiki
> d'OpenStreetMap concernant l'apiculture. En effet, à par un « craft =
> beekeeper », je n'ai  pas trouvé grand chose.
>
> > Ais-je mal cherché ? Ou bien il n'y a vraiment rien sur ce
>  domaine dans OSM
>  ?
>
> > Au départ je suis arrivé sur ce constat en voulant ajouter un magasin
> qui  vend du matériel apicole, mais je n'ai trouvé aucun tag.
>
> Bonjour,
>
> Pour ce qui est des ruches, j en avais parle avec un collegue qui en
> possede et il y etait formellement oppose par crainte de vol de ruche et d
> interception d essaims en periode d essaimage
>
> julien
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



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

Re: [Talk-it] Incontro con assessore su OpenData

[Lorenzo "Beba" Beltrami]

Ringrazio tutti perché stanno saltando fuori i vari punti di vista e questo
crea una discreta fonte di ispirazione.

Il mio più che un invito ad utilizzare il formato KMZ è di utilizzare
> almeno un paio di formati diversi
>

Avevo capito che il non era "KMZ è il formato perfetto", ma il mio
interessamento era proprio per l'idea di non fossilizzarsi su di un solo
formato.

mi permetto di suggerirti due miei lavori. il primo condiviso durante il
> raduno italiano di spaghetti opendata:

http://www.slideshare.net/piersoft/bignami-opendata-per-pa-di-piccole-dimensioni
>
> http://www.slideshare.net/piersoft/sod15-opendata-nella-pa-di-piccole-dimensioni-processo-sartoriale-o
>

Uno dei partecipanti al tavolo è Cristiano Ferrari, anche lui di Spaghetti
OpenData e anche lui di Reggio provincia.


> Il primo consiglio è quello di investire molto nel dialogo con
> l'amministrazione regionale
>

L'assessorato all'agenda digitale è già connesso con quello regionale,
all'ultimo incontro esteso era presente anche Dimitri Tartari

> AgID nelle linee guida sul patrimonio informativo pubblico (che consiglio
> vivamente di leggere)
>
> http://www.agid.gov.it/sites/default/files/linee_guida/patrimoniopubblicolg2014_v0.7finale.pdf
> fa questa distinzione
> Qui una slide con lo schema
> http://www.slideshare.net/napo/opendata-suggerimenti-per-dati-di-qualit/19
>
Ho anche notato una certa voglia di mettersi in gioco per cui hanno
cominciato a studiarsi, ad esempio, il modello per la definizione dei
metadati.

Inoltre mi leggerò con calma tutti i link che state segnalando.

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

Re: [OSM-talk-fr] rendu Défibrillateur

[osm . sanspourriel]

Dans le premier cas tu utilises un rendu OSM France qui fait bien son 
boulot et dans l'autre un rendu mondial qui le fait moins bien.

J'ai repris les coordonnées du second et placé dans OSM FR : miracle (*)
http://tile.openstreetmap.fr/?zoom=18=47.74828=-3.3657=B00
http://tile.openstreetmap.fr/?zoom=18=47.74836=-3.36504=B00 
est bien rendu
Je soupçonne quelqu'un d'avoir fait un /dirty ou d'avoir mis à jour le 
rendu récemment (ou je ne suis pas passé sur le même serveur mais je 
viens de tester 
http://tile-[a-c].openstreetmap.fr/osmfr/18/128621/91398.png).


(*) non, je ne crois pas aux miracles.


Le 02/02/2016 14:48, Erwan Salomon - r...@gmx.fr a écrit :
selon le wiki les défibrillateurs sont rendu dans OSM.fr 
 : 
http://wiki.openstreetmap.org/wiki/Tag:emergency%3Ddefibrillator 

un exemple le prouve : 
http://tile.openstreetmap.fr/?zoom=17=44.12069=4.83901=B00
pourtant je constate que d’autres ( 
http://www.tappenbeck.net/osm/maps/deu/index.php?id=1029=18=47.74828=-3.3657=BFTTT=de )ne 
sont pas rendu : 
http://tile.openstreetmap.fr/?zoom=18=47.74836=-3.36504=B000FF


il y a une explication ?


___
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] Problème Umap - Tile.openstreetmap rendu BANO sous firefox

[Christian Quest]

Pas de problème avec Firefox 44 pour moi.

La 46 est encore en 46.0a2... donc pas encore stable. Il y avait un autre
bug lié à leaflet il y a peu dans une unstable... tu es un peu trop en
"bleeding edge" ;)

Le 2 février 2016 à 15:36, Simon Miniou  a écrit :

> Bonjour,
>
> depuis quelque temps, j'ai un souci sur les cartes d'umap et sur
> http://tile.openstreetmap.fr/~cquest/leaflet/bano.html sous Mozilla (*version
> 46) ;*
>
> Il m'est impossible de me déplacer dans la carte une fois un zoom/de-zoom
> effectué comme ci les tuiles ne se chargeaient pas.
>
> est ce que ce problème aurait déjà été remonté? problème serveur ou autre?
>
> Merci,
> Simon
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] rendu Défibrillateur

[Christian Quest]

En principe ermergency=aed et emergency=defibrillator sont bien rendus
pareil dans le rendu FR.

C'est ici:
https://github.com/cquest/osmfr-cartocss/blob/master/amenity-points.mss#L335

ça doit effectivement être un problème de placement... plus de place pour
l'ajouter après le texte.


Le 2 février 2016 à 15:24, Erwan Salomon  a écrit :

> ce défibrillateur est bien au goût du jour :
> emergency=defibrillator
> source=survey
>
> il a été ajouté le 03/02/2015, donc pas un problème de rendu à attendre
> non plus
> d’autres sont dans le même cas :
> http://tile.openstreetmap.fr/?zoom=20=47.70477=-3.16498=B000FF
>  (dans
> l’angle du Kayak club)
> peut-être trop proche des autres labels ?
>
> Le 2 févr. 2016 à 15:07, Nicolas Dumoulin <
> nicolas_openstreetmap@dumoulin63.net> a écrit :
>
> Je pense que c'est dû à l'utilisation de l'ancien attribut "aed". Il faut
> maintenant utiliser emergency=defibrillator
>
>
> --
> Nicolas Dumoulin
> http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin
>
>
> ___
> 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
>
>


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

[OSM-talk-fr] rendu micro bibliothèque

[osm . sanspourriel]

Bonjour,
on ne tague pas pour le rendu mais si on ne voit pas et si Nominatim ne 
trouve pas, ça devient plus difficile à trouver pour monsieur tout le monde.

http://www.openstreetmap.org/node/3949032937#map=19/47.78961/-3.48841
En passant par le wiki :
http://wiki.openstreetmap.org/wiki/FR:Tag:amenity=public%20bookcase?uselang=fr
on va sur Overpass et voilà :
http://overpass-turbo.eu/s/e9i

Pas exactement idéal pour inciter les gens à utiliser ce service.
On peut taguer "name=boîte à livres" car c'est écrit dessus, mais là au 
contraire on risque de donner trop d'importance.
Un  petit icône style Maki library icon 
 
(qui n'est pas celui utilisé en France comme bibliothèque) pourrait être 
sympa (icône en CC0 ).


N. B. : même avec public bookcase, Nominatim ne trouve rien.

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

Re: [OSM-talk-fr] Fond OSM dans des guides de rando du CD63 ?

[Christian Quest]

Le 2 février 2016 à 20:46, Landry Breuil  a écrit :

> 2016-02-02 18:21 GMT+01:00 JB :
> > Bonjour,
> > Une très bonne nouvelle !
> > Je me souviens d'une longue discussion que j'avais eue l'été 2014 avec un
> > gars bien informé de l'office de tourisme à Clermont-Ferrand. Je pensais
> en
> > avoir fait un compte-rendu, mais je n'arrive pas à en retrouver de trace.
> > C'était à l'époque du deuxième topoguide®, on avait notamment parlé de
> FFRP,
> > IGN, carte IGN, et un peu OpenStreetMap. J'avais par hasard avec moi la
> > carte que j'avais sortie pour le tour de la chaine des Puys.
> > Ceci dit :
> >  - est-ce qu'il serait possible de connaitre les circuits pressentis
> pour le
> > prochain guide, histoire de contribuer au meilleur endroit ?
>
> Bonne question, ne pas hésiter à demander directement à guillaume, je suis
> juste le messager...
>
> >  - les traces gps fournies sont de qualité… moyenne, à ne pas privilégier
> > sur d'autres sources, ou à moyenner avec d'autres traces (j'ai contribué
> > dans la zone, et en comparant certaines dont je pense la précision
> correcte,
> > celles fournies restent moyennes). En tous cas, ne pas supprimer la
> donnée
> > OSM pour la remplacer par cette donnée qui serait « de référence ».
>
> J'ai l'impression qu'il y'a mésentente ici. les PDIPR ne sont pas
> *pas* en opendata,
>

Et pourquoi donc ?

C'est un document public, le département a l'obligation de les établir pour
"favoriser la découverte de sites naturels et de paysages ruraux en
développant la pratique de la randonnée" (circulaire ministérielle de
1988)... mais ne les diffuserait pas librement ?

De nombreux départements les diffusent en opendata.

Je ne veux pas faire le râleur (si quand même, j'assume), mais bon si on
résume ça donne:
- OSM c'est bien (entendre gratuit parce que SCAN25 c'était très bien parce
que gratuit), mais y'a pas assez de données
- je ne veux pas mettre mes données dedans...

Vous faites comme vous le sentez, mais je préfère me mobiliser sur d'autres
projets plus équibilibrés.


donc pas importables dans OSM. J'avais pourtant pensé etre clair dans
> mon mail initial.
> La notion 'donnée de référence' est annexe ici.
>
> J'ai fourni le lien vers le shapefile des PDIPR présents sur notre
> catalogue de données
> *uniquement* pour la liste/les emprises des zones concernées...
>
> >  - si R25 est pressenti pour le rendu, je veux bien y passer un peu de
> > temps. Quand la donnée est bonne, la génération de carte est rapide
> (quand
> > on a l'habitude, en tous cas).
>
> A discuter directement avec guillaume, quand on avait évoqué le sujet
> c'était plutôt
> "dans arcgis on a accès directement a un fond OSM" donc je ne sais pas a
> quel
> rendo/fond/service ca correspond. A mon avis dans un premier temps il
> n'était pas
> prévu de rendu particulier, sauf si evidemment quelqu'un se porte
> volontaire pour
> gérer ca..
>
>
Il y a là une occasion de faire quelque chose de vraiment bien, propre (le
rendu R25 de JB est top pour ça) et en mobilisant la communauté pour
améliorer les données, mais pour ça il faut aussi faire un minimum
d'effort... à minima nous autoriser à utiliser librement les tracés des
PDIPR.


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

Re: [OSM-talk-fr] rendu Défibrillateur

[Christian Quest]

Le 2 février 2016 à 22:50, Erwan Salomon  a écrit :

> il me semble bien avoir proposé un lien sur le rendu fr en exemple
>
> le miracle doit venir du fait que j’ai actualisé/complété le tag …
> les autres cas que je regardaient ont des labels vraiment très rapproché,
> tous ne peut pas être rendu
>
>
Possible aussi que le cache désormais présent sur les tuiles FR ait
rallongé le délais pour leur mise à jour qui peut aller jusqu'à 24h.



> au passage j’ai cherché des listes de défibrillateurs, quelques villes les
> fournissent en opendata (sous forme d’adresse, parfois de données issues
> d’OSM)
> et 2 app sur mon téléphone (avec une localisation très approximative et
> beaucoup de doublons ou de manquant, pas vraiment exploitable dans
> l’urgence d’un arrêt cardiaque)
> je trouve ça dingue que leurs emplacements ne soit pas mieux diffusé (par
> les pompiers qui forment des secouristes, les municipalités qui en placent
> dans leurs bâtiment …)
>


Comme beaucoup de données très utiles, elles ne sont malheureusement pas
agrégées systématiquement du coup tout le monde bricole plus ou moins...

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

Re: [OSM-ja] Google Map 利用規約更新

[下り専門]

変更前の「Google マップ/Earth 利用の追加規約」です。

https://web.archive.org/web/20150531053930/http://www.google.co.jp/intl/ja/help/terms_maps.html
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [Talk-it] Incontro con assessore su OpenData

[Maurizio Napolitano]

2016-02-02 23:07 GMT+01:00 Lorenzo "Beba" Beltrami :
> Ringrazio tutti perché stanno saltando fuori i vari punti di vista e questo
> crea una discreta fonte di ispirazione.
>
>> Il mio più che un invito ad utilizzare il formato KMZ è di utilizzare
>> almeno un paio di formati diversi
>
>
> Avevo capito che il non era "KMZ è il formato perfetto", ma il mio
> interessamento era proprio per l'idea di non fossilizzarsi su di un solo
> formato.

Guarda io preferisco dire "abbasso il kmz" perchè poi finisce che ti
distribuiscono
solo quello.
Tutti felici di vedere i dati su google earth ma se poi vuoi filtrarli
rispetto ad un
valore ... ti tocca smazzarti il campo description

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

[OSM-co] mapeo remoto

[Nohora Castellanos]

Hola maper@s

Estamos mapeando Nazareth de manera remota.

Vamos en un 65% de https://tasks.hotosm.org/project/1418


La mesa de ayuda esta a disposición hasta las 21 horas.

Los esperamos para mapear juntos.

¡Bienvenidos!
___
Talk-co mailing list
Talk-co@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-co

Re: [Talk-it] Incontro con assessore su OpenData

[Piergiorgio Cipriano]

Oltre ai preziosi link di Napo e di Francesco, vorrei ricordare che:
- il Comune di Reggio-Emilia è una Pubblica Amministrazione europea ...
- ... e come tutte le PA europee è soggetta a rendere disponibili dati in
conformità a INSPIRE (deadline 2020) ...
- ... che oltre ad essere Direttiva e norma, prevede una "semantica di
base" comune per i vari temi ...
- ... con vocabolari descritti in http://inspire.ec.europa.eu/codelist/

Il Comune di Reggio, inoltre, è partner di diversi progetti europei, e
oltre a lavorare per rendere aperti i suoi dati sta lavorando (molto) per
avere dati open e coerenti con INSPIRE:
http://www.municipio.re.it/retecivica/urp/retecivi.nsf/PESDocumentID/734B7F4308B4824EC1257D4600398E9F?opendocument=PrgttNWST

Per quanto riguarda metadati e standard:
https://joinup.ec.europa.eu/node/139283/ ... ovvero GeoDCAT-AP, che
rappresenta l'allineamento tra quanto previsto da INSPIRE (per i metadati)
e DCAT, citato da Napo.
12 giorni fa è stato rilasciato questo plugin CKAN (
https://github.com/CCSS-CZ/ckan-ext-inspire) che permette di esporre
metadati di dati e servizi geografici secondo GeoDCAT-AP.

Per il formato: riprendendo quanto ha scritto Napo, meglio avere GeoJSON o
GML (senza troppe complessità), possibilmente esposti tramite servizi WFS
(ma non necessariamente).


pg

__
Piergiorgio Cipriano
https://twitter.com/PgCipriano


Il giorno 2 febbraio 2016 23:07, Lorenzo "Beba" Beltrami <
lorenzo.b...@gmail.com> ha scritto:

> Ringrazio tutti perché stanno saltando fuori i vari punti di vista e
> questo crea una discreta fonte di ispirazione.
>
> Il mio più che un invito ad utilizzare il formato KMZ è di utilizzare
>> almeno un paio di formati diversi
>>
>
> Avevo capito che il non era "KMZ è il formato perfetto", ma il mio
> interessamento era proprio per l'idea di non fossilizzarsi su di un solo
> formato.
>
> mi permetto di suggerirti due miei lavori. il primo condiviso durante il
>> raduno italiano di spaghetti opendata:
>
>
>> http://www.slideshare.net/piersoft/bignami-opendata-per-pa-di-piccole-dimensioni
>>
>> http://www.slideshare.net/piersoft/sod15-opendata-nella-pa-di-piccole-dimensioni-processo-sartoriale-o
>>
>
> Uno dei partecipanti al tavolo è Cristiano Ferrari, anche lui di Spaghetti
> OpenData e anche lui di Reggio provincia.
>
>
>> Il primo consiglio è quello di investire molto nel dialogo con
>> l'amministrazione regionale
>>
>
> L'assessorato all'agenda digitale è già connesso con quello regionale,
> all'ultimo incontro esteso era presente anche Dimitri Tartari
>
>> AgID nelle linee guida sul patrimonio informativo pubblico (che consiglio
>> vivamente di leggere)
>>
>> http://www.agid.gov.it/sites/default/files/linee_guida/patrimoniopubblicolg2014_v0.7finale.pdf
>> fa questa distinzione
>> Qui una slide con lo schema
>> http://www.slideshare.net/napo/opendata-suggerimenti-per-dati-di-qualit/19
>>
> Ho anche notato una certa voglia di mettersi in gioco per cui hanno
> cominciato a studiarsi, ad esempio, il modello per la definizione dei
> metadati.
>
> Inoltre mi leggerò con calma tutti i link che state segnalando.
>
> Lorenzo
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Rapprochement BANO dans L'île de Saint-Martin

[Vincent de Château-Thierry]

Bonsoir,

Le 02/02/2016 17:04, Philippe Verdy a écrit :

Il n'y a pas de commune car les compétences d'une commune sont dévolues
à la collectivité entière. C'était une commune. Néanmoins il devrait
rester un noeud place=town dedans. La capitale Gustavia est en fait un
des quartier de la collectivité, et pourrait se coder aussi en suburb,
en plus du place=town avec capital=4 en tant que capitale "régionale".
Pas 3 car le niveau 3 c'est l'ensemble des com.

Le 2 févr. 2016 14:41, "Cactusbone" > a écrit :

L'île de Saint-Martin est un territoire français ne contenant pas de
commune
(
https://fr.wikipedia.org/wiki/Saint-Martin_%28Antilles_fran%C3%A7aises%29
)
taggé admin_level 3 dans osm

dans bano on a des adresses dans le CSV, mais aucune n'est rapprochée
http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#14/18.0743/-63.0576

par exemple ,
15 rue du Général De Gaule, 97150 Saint-Martin est bien dans le CSV,
la rue existe aussi dans OSM (
https://www.openstreetmap.org/way/27614897 )
mais aucun rapprochement n'est fait.

Je pense que c'est lié a l'absence de ville/commune coté osm


Les adresses du CSV proviennent du Cadastre, en effet sans 
rapprochement. Plusieurs facteurs se cumulent :
- côté Cadastre, Saint-Martin a son cadastre comme les autres communes, 
mais son code est "ZS127", ce qui correspond au code INSEE 97127, qui 
n'est plus en vigueur depuis 2007 d'après l'INSEE :

http://www.insee.fr/fr/methodes/default.asp?page=nomenclatures/cog/outremer.htm#saintmartin

BANO cherche donc à rapprocher les adresses de ce Cadastre avec les 
voies adresses d'OSM incluses dans un polygone administatif ayant le tag 
ref:INSEE=97127, polygone qui n'existe pas. Cependant OSM ne propose pas 
non plus de limite administrative avec ref:INSEE=97801 qui est le code à 
5 chiffres donné par l'INSEE pour "les applications nécessitant une 
codification sur 5 positions".


En résumé pour OSM : ça aurait du sens de rajouter un ref:INSEE=97801 
sur la relation http://www.openstreetmap.org/relation/1891583 ou sur 
http://www.openstreetmap.org/relation/299354 ceci afin de se rendre 
compatible avec certains usages comme suggéré par l'INSEE. Le problème : 
ces 2 relations ont déjà un tag ref:INSEE=97-8.


En résumé pour BANO : il faut adapter la mécanique de rapprochement pour 
faire correspondre le Cadastre "ZS127" avec le code INSEE 97-8 ou 97801. 
Le code 97801 a moins d'impact sur le code de BANO car on reste sur un 
code à 5 positions, mais comme vu plus haut, il n'est pas évident de lui 
faire une place dans le schéma de tags actuel.


Suggestions bienvenues,

vincent

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

Re: [OSM-talk-fr] openstreetmap et les abeilles

[osm . sanspourriel]

> En plus les ruches ça se déplace quand même souvent... c'est pas 
assez fixe pour être dans OSM à mon avis.

Pas faux mais la question initiale était plus générale :

> Au départ je suis arrivé sur ce constat en voulant ajouter un magasin 
qui  vend du matériel apicole, mais je n'ai trouvé aucun tag.

Mais n'est pas parce que rares sont les magasins spécialisés à ce point ?
Je pense que les jardineries 
 et les 
vendeurs de matériel agricoles sont des approximations.

Je me trompe peut-être.
Rien ne t'empêche de proposer un nouveau tag.

À propose d'abeilles, il s'agit d'une association d'idées, j'ai déjà vu 
l'Abeille Bourbon :

http://tile.openstreetmap.fr/?q=abeille%20bourbon
Comme les autres abeilles, et là même en présence de Gaucho, ça se déplace.
Certes par vent de force inférieure à 5, marée de moins de 92 et en 
absence d'appel, ce bateau se trouve là et ce n'est pas taggué hulk 
.
building=boat n'est pas renseigné sur le wiki et a plus de 500 
occurrences en France.

Il ne serait pas temps d'ajouter ça dans le wiki ?

Jean-Yvon



Le 02/02/2016 22:27, Christian Quest - cqu...@openstreetmap.fr a écrit :
En plus les ruches ça se déplace quand même souvent... c'est pas assez 
fixe pour être dans OSM à mon avis.


Le 2 février 2016 à 21:30, THEVENON Julien > a écrit :




En date de : Mar 2.2.16, Adrien Grellier > a écrit :

 Objet: [OSM-talk-fr] openstreetmap et les abeilles
 À: talk-fr@openstreetmap.org 
 Date: Mardi 2 février 2016, 18h07

> Bonjour,

> Je m'étonne qu'il n'y ait que très peu de choses sur le wiki
d'OpenStreetMap concernant l'apiculture. En effet, à par un «
craft = beekeeper », je n'ai  pas trouvé grand chose.

> Ais-je mal cherché ? Ou bien il n'y a vraiment rien sur ce
 domaine dans OSM
 ?

> Au départ je suis arrivé sur ce constat en voulant ajouter un
magasin qui  vend du matériel apicole, mais je n'ai trouvé aucun tag.

Bonjour,

Pour ce qui est des ruches, j en avais parle avec un collegue qui
en possede et il y etait formellement oppose par crainte de vol de
ruche et d interception d essaims en periode d essaimage

julien

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




--
Christian Quest - OpenStreetMap France


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


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

Re: [Talk-dk] Feriehuse på OSM

[sfromis]

> tvivlsomt om ferienhaus.de faktisk er operatør for husene

"Sjovt nok" markedsføres nævnte hus også via
http://www.sommerhusedanmark.dk/sommerhus-29676132.html
Her ser det ud til at "Sol og Strand" er operatør. Det er ganske
plausibelt at de samarbejder med et tysk bureau - tyskere er jo en
stor del af markedet.

> Hvis de bare bruge et ferienhaus_de_number tag, ville det være OK med mig.

Men så taber de den store synlighed i kraft af OSM default-rendering.
De håber jo fx på at nogen ser navnet, og spørger Google (incl.
løbenr). Så er de yderst velplaceret i søgeresultatet, i modsætning
til den reelle operatør. Så de har næppe den store lyst til et tag som
ikke giver en dyt eksponering på et normalt renderet OSM kort. Et
marketing-stunt, altså spam.


2016-02-03 0:32 GMT+01:00 Niels Elgaard Larsen :
> Jeg har sådan set ikke ondt over, at de tagger husene, så kunderne kan
> finde dem.
>
> Men jeg har noget imod at de misbruger tags, der bruges i forvejen.
>
> Det er især:
>
> * name. Fx http://www.openstreetmap.org/node/3514350303 . Det hus hedder
> jo ikke "Bøgfinkehus (L321)". For det første er det meget usandsynligt
> at løbenummeret indgår i navnet. Men det er næsten endnu værre at de
> bare navngiver husene efter vejnavnene (i dette tilfælde er der vist
> sket en fejl). For der er nogle huse der er opkaldt efter vejen, eller
> typisk snare omvent, hvilket kan skabe forvirring.
> Hvis de bare bruge et ferienhaus_de_number tag, ville det være OK med mig.
>
> Operator: Wikien siger
>
> ==
> When choosing the appropriate value for the operator=* tag, it is
> beneficial to use exactly the same text including capitalization across
> all entities managed by the same structure
> ==
>
>
> For det første er det tvivlsomt om ferienhaus.de faktisk er operatør for
> husene. For det andet hører en unik URL ikke hjemme i feltet.
>
> I øvrigt synes jeg, at det er lidt uheldigt at man bare kan skrive en
> URL i operator-tagget, der overlevet på openstreetmap.org. Det frister
> åbenbart svage sjæle. Jeg ville hellere have at de fik websiden til at
> generere en URL for et særligt ferienhause_de tag.
>
>
> sfro...@gmail.com:
>> Jeg har også bemærket dem under mine beskedne justeringer i OSM, og
>> tænker "spam". Det er jo netop blot et enkelt sommerhusudlejnings-bureau
>> som vil markere sig på kortet, og sprede sine links. Det kan da have en
>> vis værdi at kunne sige til kunderne "huset er på kortet" (ud over OSM
>> kan jeg se at de tilsvarende muntrer sig i Google Map Maker.
>>
>> Men sådan et "navn", incl. deres id på huset, er jo ikke nogen egenskab
>> ved huset, men blot ved kundeforholdet mellem bureauet, og ejer samt
>> lejere af huset. Derfor forekommer det ret skævt at disse data
>> (udlejningsnavn og URL) sættes på huset, selv om den fysiske virkelighed
>> næppe kan rumme mere end højst et beskedent skilt fra bureauet ved det
>> enkelte hus. Så jeg er helt enig i betragtningen om at det var noget
>> andet for et kontor med personale og åbningstider.
>
>
> Et kontor skal heller ikke komme løbenumre i name-tagget.
>
>
>> Det forekommer mig rimeligt at orientere dem om at deres aktiviteter
>> falder udenfor formålet med OSM, og at rydde op i deres spam (vil jeg
>> kalde det). Jeg må dog tilstå at jeg ikke melder mig til det job.
>>
>>
>> ___
>> Talk-dk mailing list
>> Talk-dk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-dk
>>
>
> --
> Niels Elgaard Larsen
>
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk

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

Re: [OSM-talk-fr] Fond OSM dans des guides de rando du CD63 ?

[Landry Breuil]

2016-02-02 18:21 GMT+01:00 JB :
> Bonjour,
> Une très bonne nouvelle !
> Je me souviens d'une longue discussion que j'avais eue l'été 2014 avec un
> gars bien informé de l'office de tourisme à Clermont-Ferrand. Je pensais en
> avoir fait un compte-rendu, mais je n'arrive pas à en retrouver de trace.
> C'était à l'époque du deuxième topoguide®, on avait notamment parlé de FFRP,
> IGN, carte IGN, et un peu OpenStreetMap. J'avais par hasard avec moi la
> carte que j'avais sortie pour le tour de la chaine des Puys.
> Ceci dit :
>  - est-ce qu'il serait possible de connaitre les circuits pressentis pour le
> prochain guide, histoire de contribuer au meilleur endroit ?

Bonne question, ne pas hésiter à demander directement à guillaume, je suis
juste le messager...

>  - les traces gps fournies sont de qualité… moyenne, à ne pas privilégier
> sur d'autres sources, ou à moyenner avec d'autres traces (j'ai contribué
> dans la zone, et en comparant certaines dont je pense la précision correcte,
> celles fournies restent moyennes). En tous cas, ne pas supprimer la donnée
> OSM pour la remplacer par cette donnée qui serait « de référence ».

J'ai l'impression qu'il y'a mésentente ici. les PDIPR ne sont pas
*pas* en opendata,
donc pas importables dans OSM. J'avais pourtant pensé etre clair dans
mon mail initial.
La notion 'donnée de référence' est annexe ici.

J'ai fourni le lien vers le shapefile des PDIPR présents sur notre
catalogue de données
*uniquement* pour la liste/les emprises des zones concernées...

>  - si R25 est pressenti pour le rendu, je veux bien y passer un peu de
> temps. Quand la donnée est bonne, la génération de carte est rapide (quand
> on a l'habitude, en tous cas).

A discuter directement avec guillaume, quand on avait évoqué le sujet
c'était plutôt
"dans arcgis on a accès directement a un fond OSM" donc je ne sais pas a quel
rendo/fond/service ca correspond. A mon avis dans un premier temps il
n'était pas
prévu de rendu particulier, sauf si evidemment quelqu'un se porte
volontaire pour
gérer ca..

Landry

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

Re: [Talk-es] Nominatim debería ser más flexible

[Alejandro Moreno Calvo]

Hola Xavier.

Hay que tener en cuenta que ese PR soluciona un caso muy concreto pero que
habría que hacer un análisis más profundo de los artículos que se pueden
dar. Así a bote pronto se me ocurre también habría que añadir "el", "la",
"las", "los".

El 2 de febrero de 2016, 8:40, Xavier Barnada  escribió:

> Hola,
>
> Acabo de hacer una pull request que deberia solucionar este problema, he
> seguido el ejemplo de las otras stopwords  y este comentario
> https://trac.openstreetmap.org/ticket/4895#comment:4
>
> https://github.com/twain47/Nominatim/pull/358
>
> Saludos
>
> El dom., 31 ene. 2016 a las 11:57, Emilio Gómez Fernández (<
> emilio.gomez.f...@gmail.com>) escribió:
>
>> Hola a todos.
>>
>> Fui yo quien abrí ese ticket hace tiempo, tanto ahí como en GitHub [1], y
>> también lo comenté  en la reunión en Aguilar de Campoo en la que estuvimos
>> algunos de nosotros.
>> La respuesta viene a ser, en resumidas cuentas, que añadir nuevas
>> palabras vacías en español a las escasas que ya existen en Nominatim [2]
>> podría perjudicar las búsquedas en otros idiomas. La consecuencia es que en
>> nuestro caso usar la API de Nominatim para realizar, por ejemplo,
>> geocodificación inversa es de escasa utilidad aun a pesar de que los datos
>> existan en la base de datos.
>>
>> Lo único que se me ocurre es que esta discusión salte a la lista General
>> y tener un feedback de otros usuarios para que la cosa se mueva y tenga más
>> repercusión, porque este importante problema también afecta a otros idiomas
>> [3][4].
>>
>> Saludos.
>>
>> [1] https://github.com/twain47/Nominatim/issues/85
>> [2] https://github.com/twain47/Nominatim/blob/master/module/nominatim.c
>> [3] https://github.com/twain47/Nominatim/issues/333
>> [4] https://trac.openstreetmap.org/ticket/4961
>>
>>
>> El 30 de enero de 2016, 14:17, Alejandro Moreno Calvo 
>> escribió:
>>
>>> Este problema ya lleva reportado tiempo.
>>> https://trac.openstreetmap.org/ticket/4895
>>> El 30 ene. 2016 2:04 p. m., "Xavier Barnada" 
>>> escribió:
>>>
 Hola,

 A parte de la ayuda que podamos prestar al buscador mediante mejor
 etiquetado no veo mucho mas que se pueda hacer.
 Si quereix podeis reportar los problemas que veais al repositorio de
 Nominatim en github
 https://github.com/twain47/Nominatim

 Saludos

 El sáb., 30 ene. 2016 a las 13:54, Jorge Sanz Sanfructuoso (<
 sanc...@gmail.com>) escribió:

> Hola.
>
> Son un desastre las búsquedas. Hace no mucho salio el tema, no se si
> por aqui o por el telegram y alguien comentó que está adaptado para el
> habla inglesa y que según Nominatim si se adapta para otros idiomas podría
> hacer que fallara en el inglés.
>
> Ya no es escribir bien o mal, hay casos como los artículos que a veces
> los llevan las calles y a veces no. Es adivina adivinanza. jajaja
>
> Un saludo.
>
> El sáb., 30 ene. 2016 a las 13:12, Manuel Lladosa (<
> manolo...@gmail.com>) escribió:
>
>> Hace un rato he hecho estas búsquedas:
>>
>> - Calle san roNque, paiporta (con falta de ortografía por descuido):
>> no
>> me encuentra nada por la falta, vale, de acuerdo.
>> - Calle san roque, paiporta: no me encuentra nada. ¡Pues vaya!
>> - Calle de san roque, paiporta: ¡premio!
>>
>> ¡Que tiquismiquis! jeje. Tienes que poner la calle con precisión
>> milimétrica. Cuando alguien busca una calle no suele conocer el nombre
>> con tanta exactitud y esto irrita un pelín :-), ya me ha pasado varias
>> veces que no he encontrado calles, siendo que estaban en OSM.
>>
>> ¿Como podemos pedir que Nominatim sea más flexible, que no requiera
>> búsquedas tan precisas? Y tampoco estaría mal que corrigiera faltas de
>> ortografía, vale, debemos escribir bien, pero es que a veces se hacen
>> por descuido.
>>
>> Muchas gracias.
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
> --
> Jorge Sanz Sanfructuoso - Sanchi
> Blog http://blog.jorgesanzs.com/
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>

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


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

Re: [OSM-talk-fr] OSM : contribuer avec quel smartphone?

[Nicolas Dumoulin]

Salut,

Le Monday 01 February 2016, 14:06:26 image93 a écrit :
> JE suis intéressé par toute info me permettant de selectionner un samrtphone
> adapté. Merci bien.

Comme les autres, je n'utilise mon smartphone que pour prendre des photos et 
enregistrer ma trace, pas d'édition directe. J'utilise OsmAnd qui me permet de 
superposer tout ça avec une vue de la carte et des itinéraires préparés à la 
maison (couche GPX) ou un itinéraire calculé à la volée.
De retour sur mon PC, je peux consolider mon relevé avec l'imagerie aérienne 
et les données présentes.
Niveau matériel, il faut un truc pratique à tenir. Le mien est un acer z200 
payé 50€, du trés bas de gamme donc, et ça me suffit. Les photos sont à peu 
près correcte pour peu qu'il fasse jour et je m'arrête de courir.
Niveau autonomie, j'arrive à tenir tranquile une rando à la journée après 1 an 
d'utilisation.
Voilà, c'est un vrai plus pour OSM cet outil moderne qui pollue (enfin de mien 
en tout cas).

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin


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

Re: [OSM-talk-fr] Import de données dans OSM - Zonage Unesco Causses & Cévennes de 6 000 km² (!)

[Stéphane Ritzenthaler]

Merci pour vos réponses.
Ok, j'ai bien compris qu'il fallait reprendre des limites déjà 
existantes dans la mesure du possible et découper mon polygone pour 
limiter le nombre de nœuds. Et oui merci, j'ai oublié le tag 
"boundary=protected_area". Mais, le problème principal est que ces 
chemins doivent être assez précis (je ne peux donc pas trop simplifier 
la géométrie) et qu'il font plus de 600 km pour chaque zonage. Donc 
beaucoup de découpages en perspective et un gros travail de fourmis à 
faire. Ce n'est pas que je rechigne à faire cela mais, avant de me 
lancer là dedans, je voulais savoir s'il existait un processus 
d'automatisation pour détecter les endroits où ma limite coïnciderait 
avec un objet déjà présent dans OSM. Et vu que c'est évoqué dans la 
méthode du paragraphe "Phase 4" de cette page 
(https://wiki.openstreetmap.org/wiki/WikiProject_France/Parcs_nationaux_et_r%C3%A9gionaux,_r%C3%A9serves_naturelles/Import_des_donn%C3%A9es_INPN), 
je me suis dit que quelqu'un avait peut être une idée à ce sujet.

A+
Stéphane


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

Re: [Talk-at] Via Ferrata/Klettersteig - Wie richtig taggen?

[Thomas Konrad]

Hallo,

aus meiner Sicht wäre folgendes am saubersten:

- Einen eigenen “highway”-Tag für Wege einführen, für die man “alle viere” 
braucht, also für Wege in den Bergen, die nicht nur auf den zwei Beinen 
begehbar sind (sowas wie highway=steep_path oder highway=mountain_path, 
besseres Wording anyone?). Das ist aus meiner Sicht 1.) ein *halbwegs* 
eindeutiges Kriterium und im Sinne der Datennutzung “Renderer” würde das 
bedeuten, man muss nicht “SELECT * FROM planet_osm_ways WHERE highway=‘path’ 
and ‘sac_scale’ = null and ‘via_ferrata_scale’ = null and ‘was_weiss_ich_scale’ 
= null” machen, sondern einfach SELECT * FROM planet_osm_ways WHERE 
highway=’steep_path’”. Solche “paths” könnte man dann z.B. etwas transparenter 
rendern, dann ist eher sichtbar dass er nicht für jeden begehbar ist. Für den 
Import-Stil (Stichwort defaul.style) müsste man dann auch nicht all diese 
Skala-Spalten importieren, was ja sonst die Datenbank schon ziemlich aufblasen 
würde.

- Via Ferratas bzw. Klettersteige gehören aus meiner Sicht als Route (Relation) 
erfasst und nicht direkt auf den “way” getaggt, denn auch Klettersteige können 
gewöhnliche Trampelpfade und andere Wegarten beinhalten (muss man nicht z.B. 
auf dem HTL-Steig auf der hohen Wand zwischendrin einmal kurz auf einen 
Wanderweg?). Ist ja auch bei MTB-Routen so - da fährt man ja auch mal ein paar 
Meter auf einer Bundesstraße um in den nächsten Wald zu kommen. MTB-Routen sind 
richtigerweise als Relation erfasst. Eine Karte, die Klettersteige rendern 
möchte, kann dann einfach die Relationen auswerten.

So sieht meine Sicht als Datennutzer aus.

Schönen Tag
Thomas

> On 01 Feb 2016, at 23:25, Richard  wrote:
> 
> On Mon, Feb 01, 2016 at 05:39:25PM +0100, Friedrich Volkmann wrote:
>> On 01.02.2016 16:57, Borut Maricic wrote:
>>> Mir scheint besser keinen sac_scale-Wert anzunehmen, sondern eine 
>>> Darstellung
>>> für "sac_scale undefiniert" zu haben. Auch als Mapper gehe ich mit sac_scale
>>> vorsichtig um (auch wenn nicht sparsam). Aus Mappers Perspektive: Man will
>>> ja nicht die Bergpfade, die kein sac_scale haben, mit einem sac_scale=hiking
>>> verpassen, ohne dort gewesen zu sein. Ich will keinen in die 
>>> Abendnachrichten
>>> schicken (oder schlimmeres).
>> 
>> Wenn es für sac_scale=undefiniert einen eigenen Linienstil gibt, gewöhnen
>> sich die Kartennutzer schnell daran, dass die so dargestellten Wege fast
>> immer geringe Schwierigkeiten aufweisen. Der Effekt ist also der selbe, wie
>> wenn sie gleich mit geringer Schwierigkeit dargestellt werden. Es ist sogar
>> denkbar, dass Nutzer in Gegenden, wo wenig sac_scale gemappt ist, die mit
>> sac_scale=hiking meiden, weil ihnen deren Stil fremd ist.
> 
> einen eigenen Linienstil für Wege ohne sac_scale Angabe gibt es zumindest 
> in OpenAndroMaps. Geht auch gar nicht anders wenn man sac_scale rendern will.
> 
> Richard
> 
> ___
> 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: [OSM-talk-fr] Histoire de déchets / code SINOE

[Vincent Bergeot]

Bonjour et merci pour vos retours,

Le 01/02/2016 12:09, Jérôme Seigneuret a écrit :
La base de données est sous copyright et protéger au titre du Code de 
la Propriété Intellectuelle. Donc pour l'utilisation du code il va 
falloir avoir l'accord de l'ADEME il me semble.


cela signifie que simplement l'ajout du code SINOE, avec des personnes 
du syndicat de gestion, est soumis à restriction ?

Ok (et encore !!!) pour la base de données de l'ensemble des codes !






Il ne risque pas de libérer cette base vu qu'il vendent des 
prestations (cartes de synthèse et indicateurs statistiques) comme le 
font les CCI et les Chambres d'Agricultures. Il y a 3 niveaux de 
licences mais je ne suis pas allé plus loin.

La licence fait rire quand on lit la partie responsabilité...


oui effectivement cela concerne les volumes de déchets et autres recyclages.
Je ne sais pas si la correspondance entre un équipement lié au déchet et 
son code SINOE soit si sensible que cela !






Les références SINOE sont accessibles sur le site mais en recherche 
par commune.


Attention à l'actualisation des données car pour les marchés 
renouvelés dans l'année 2015/2016 c'est pas vraiment à jour. La 
dernière mise à jour de la base date 02/2015 et sur Montpellier le 
marché a été renouvelé au 01/2016.



merci pour toutes ces informations,

Merci Christian pour la demande au MEDDE.
Que signifie sur le site de data.gouv.fr un document sans licence (?) 
qui fait référence à SINOE justement 
(https://www.data.gouv.fr/fr/datasets/tableau-de-bord-dechets/) ? 
L'ADEME a eu envie puis n'a pas voulu mettre de licence ?


Bonne journée




Cordialement,
Jérôme



Le 1 février 2016 à 11:27, Vincent Bergeot > a écrit :


Bonjour,
commençant à travailler avec des syndicats mixtes de gestion des
déchets, en particulier sur la cartographie de leurs équipements,
je pense qu'il faudrait ajouter ref:FR:SINOE, qui pour les
professionnels du secteur est la base de données de référence pour
les équipements liés aux déchets.

Est ce qu'il "suffit" de le dire et ensuite de le faire (comme
cela existe pour d'autres données : je pense aux écoles et
ref:fr:UAI, boite aux lettres, pharmacies, ...)

  o je parle bien de l'ajout avec les professionnels de ce
code et pas de l'utilisation de la base de données SINOE,
qui ne semble pas disponible
(https://www.data.gouv.fr/fr/search/?q=sinoe),
  o peut-être d'ailleurs que l'ADEME pourrait vouloir libérer
cette base (je vais me renseigner) ?

Est ce la bonne direction ?

Bonne journée

-- 
Vincent Bergeot



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




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



--
Vincent Bergeot

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

Re: [Talk-es] secciones censales zgz

[Miguel Sevilla-Callejo]

Me respondo yo solo con respecto a lo de las secciones censales:

De la web del INE  [1] se puede leer:

[...]

5. Reutilización de la información contenida en este sitio web

La información contenida en este sitio web procede de múltiples fuentes,
por lo que el INE solo autoriza la reutilización de aquélla cuya fuente
original sea el propio INE y siempre bajo las siguientes condiciones
generales:

   - Se prohíbe expresamente desnaturalizar el sentido de la información.
   - Debe citarse la fuente de la información objeto de reutilización. Esta
   cita podrá realizarse de la siguiente manera: *Fuente: Sitio web del
   INE: www.ine.es  *si no se realiza ningún tratamiento
   de los datos o bien: *Elaboración propia con datos extraídos del sitio
   web del INE: www.ine.es * en caso de que se realice
   tratamiento de los datos.
   - Debe mencionarse la fecha de la última actualización de la información
   objeto de reutilización, siempre y cuando estuviera incluida en el original.
   - No se podrá indicar, insinuar o sugerir que el INE participa,
   patrocina o apoya la reutilización que se lleve a cabo con la información.
   - El INE no será responsable del uso que de su información hagan los
   agentes reutilizadores. Tampoco será responsable de los daños materiales o
   sobre datos, ni de posibles perjuicios económicos provocados por el uso de
   la información reutilizada.


--

O lo que es lo mismo, NO es compatible con OSM   :-(


[1]
http://www.ine.es/ss/Satellite?L=0=Page=1254735849170=1254735849170=Ayuda%2FINELayout#

*[image: Geo]Miguel Sevilla Callejo*
*Doctor en Geografía | Doctor in Geography*
*Consultor freelance e investigador | Freelance Consultant & Researcher*
Colaborador del Instituto Pirenaico de Ecología, CSIC, Zaragoza | Fellow at
the Pyrenean Institute of Ecology - Spanish National Research Council
Colegiado nº698, Colegio Oficial de Geógrafos | Member #698, Spanish
Professional Association of Geographers
Web: http://bit.ly/sevillacallejo

2016-02-02 15:15 GMT+01:00 Miguel Sevilla-Callejo :

> Hola,
>
> Alejandro Suarez y yo andábamos comentando sobre encontrar los límites de
> los barrios de Zaragoza para incluirlos definitivamente en la base de datos
> de OSM y hemos encontrado dos fuentes que quería contrastar y comentar con
> alguno de vosotros para saber si alguien ya se ha visto en una problemática
> similar.
>
> 1. Por un lado está la información urbanística del municipio, en concreto
> la cartografía que emana del Plan General de Ordenación Urbana de Zaragoza,
> tanto en un visor web [1], como accesible a través de los mapas en PDF [2]
> en donde se ven los límites de los distritos y barrios y sería
> relativamente sencillos de pasar (pues coinciden con calles mayormente) a
> OSM.
> ¿ALguien ha trabajado antes con información urbanística? ¿Alguien sabe qué
> tipo de licencias de usos tiene esta información? Yo diría que al ser algo
> público y que afecta a todo el mundo (escomo si se tratara de una ley)
> habrá de tener una licencia libre, no?
>
> 2. Por otro lado estuve mirando a ver de dónde podría sacar esa misma
> información y llegué a la cartografía de las secciones censales del INE [3]
> de dónde, igualmente se pueden identificar límites que son comunies a los
> de los barrios, a pesar que en su base de datos no exista este tipo de
> agriupación (se pasa de distrito, que coincide con los de Zaragoza, a las
> secciones censales).
>
> ¿Alguien ha echado un vistazo a esta información y/o a usado la misma?
> También desconozco el tipo de licencia que tiene. Se podría investigar.
>
> A ver si alguien nos puede orientar.
>
> Un saludo
>
> M
>
> [1] - http://www.zaragoza.es/ciudad/urbanismo/oficina/siggurz.htm
> [2] -
> http://www.zaragoza.es/ciudad/urbanismo/planeamiento/pgouz/planos.htm
> [3] - http://www.ine.es/censos2011_datos/cen11_datos_resultados_seccen.htm
>
>
> *[image: Geo]Miguel Sevilla Callejo*
> *Doctor en Geografía | Doctor in Geography*
> *Consultor freelance e investigador | Freelance Consultant & Researcher*
> Colaborador del Instituto Pirenaico de Ecología, CSIC, Zaragoza | Fellow at
> the Pyrenean Institute of Ecology - Spanish National Research Council
> Colegiado nº698, Colegio Oficial de Geógrafos | Member #698, Spanish
> Professional Association of Geographers
> Web: http://bit.ly/sevillacallejo
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] Import de données dans OSM - Zonage Unesco Causses & Cévennes de 6 000 km² (!)

[Jérôme Amagat]

Le mardi 2 février 2016, Jérôme Amagat  a écrit :

> Pour ta zone tampon si les frontières c'est des limites de commune, tu
> peux utiliser ça :
> http://comcommaker.openstreetmap.fr/
>

Et pour la frontière de tes zones, pour les chemins déjà existant,
n'utilise que des chemins frontières de commune et de parcs pas de route ni
de landuse.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-ca] Talk-ca Digest, Vol 96, Issue 1

[Mojgan Jadidi]

Hi all,
Please accept my apology for this misunderstanding, I thought our presence
for last OSM meeting and flowing emails in Talk-ca and with John were part
of communication and discussion, we launched our wikipage two weeks ago,
and we did not receive any feedback, so we thought to start import via
JOSM.

as we expalined in our wikipage, we created the algorithm to detect the
missing information, and then we check the quality of this information on
JOSM on the top of OpenStreetMap, Bing Areal imagery, GeoBase Road network
and some local municpal open data. the data is created initially through
StatCan, however, we noticed the low quality of StatCan road segment
geometry, so we deal with this issue by using complement dataset such as
OpenStreetMap, Bing Areal imagery, GeoBase Road network and some local
municpal open data. all created nodes and ways are carefully inspected
visually using above dataset for more that 6 weeks.

Our final verification will be on the OSM server (on-line) to avoid or
detect any issues. Our aim is having high quality address information in
OSM for sake of community. we were very prudent from the first step to have
a high quality source of information.

I hope that the community will accept our contribution and enjoy to use the
data.

Best regards,

Mojgan


Mojgan (Amaneh) Jadidi, Ph.D.
Postdoctoral Research Fellow
GeoICT Lab
York University
Toronto

ca.linkedin.com/pub/mojgan-amaneh-jadidi/10/825/969/

On 2 February 2016 at 07:00,  wrote:

> Send Talk-ca mailing list submissions to
> talk-ca@openstreetmap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.openstreetmap.org/listinfo/talk-ca
> or, via email, send a message with subject or body 'help' to
> talk-ca-requ...@openstreetmap.org
>
> You can reach the person managing the list at
> talk-ca-ow...@openstreetmap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Talk-ca digest..."
>
>
> Today's Topics:
>
>1. Triplinx import (Stewart Russell)
>2. Re: Triplinx import (john whelan)
>3. Re: Triplinx import (Stewart Russell)
>
>
> --
>
> Message: 1
> Date: Mon, 1 Feb 2016 18:36:01 -0500
> From: Stewart Russell 
> To: talk-ca 
> Subject: [Talk-ca] Triplinx import
> Message-ID:
> 

Re: [OSM-talk-fr] rendu Défibrillateur

[Erwan Salomon]

ce défibrillateur est bien au goût du jour :
emergency=defibrillator
source=survey

il a été ajouté le 03/02/2015, donc pas un problème de rendu à attendre non plus
d’autres sont dans le même cas : 
http://tile.openstreetmap.fr/?zoom=20=47.70477=-3.16498=B000FF
 

 (dans l’angle du Kayak club)
peut-être trop proche des autres labels ?

> Le 2 févr. 2016 à 15:07, Nicolas Dumoulin 
>  a écrit :
> 
> Je pense que c'est dû à l'utilisation de l'ancien attribut "aed". Il faut 
> maintenant utiliser emergency=defibrillator
> 
> 
> -- 
> Nicolas Dumoulin
> http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Import de données dans OSM - Zonage Unesco Causses & Cévennes de 6 000 km² (!)

[Jérôme Amagat]

Pour ta zone tampon si les frontières c'est des limites de commune, tu peux
utiliser ça :
http://comcommaker.openstreetmap.fr/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Problème Umap - Tile.openstreetmap rendu BANO sous firefox

[Simon Miniou]

Bonjour,

depuis quelque temps, j'ai un souci sur les cartes d'umap et sur
http://tile.openstreetmap.fr/~cquest/leaflet/bano.html sous Mozilla (*version
46) ;*

Il m'est impossible de me déplacer dans la carte une fois un zoom/de-zoom
effectué comme ci les tuiles ne se chargeaient pas.

est ce que ce problème aurait déjà été remonté? problème serveur ou autre?

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

Re: [Talk-ca] Talk-ca Digest, Vol 96, Issue 1

[Begin Daniel]

Initial misunderstandings, emails round trips with the community… standard 
communication process!

I do not know how others a seeing it, but reading about the process you use, I 
do not see anything like a wild bulk import. At least, it is very similar to 
the process I used when importing Canvec datasets.

Daniel

From: Mojgan Jadidi [mailto:mojgan.jad...@gmail.com]
Sent: February-02-16 09:33
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Talk-ca Digest, Vol 96, Issue 1

Hi all,
Please accept my apology for this misunderstanding, I thought our presence for 
last OSM meeting and flowing emails in Talk-ca and with John were part of 
communication and discussion, we launched our wikipage two weeks ago, and we 
did not receive any feedback, so we thought to start import via JOSM.

as we expalined in our wikipage, we created the algorithm to detect the missing 
information, and then we check the quality of this information on JOSM on the 
top of OpenStreetMap, Bing Areal imagery, GeoBase Road network and some local 
municpal open data. the data is created initially through StatCan, however, we 
noticed the low quality of StatCan road segment geometry, so we deal with this 
issue by using complement dataset such as OpenStreetMap, Bing Areal imagery, 
GeoBase Road network and some local municpal open data. all created nodes and 
ways are carefully inspected visually using above dataset for more that 6 weeks.

Our final verification will be on the OSM server (on-line) to avoid or detect 
any issues. Our aim is having high quality address information in OSM for sake 
of community. we were very prudent from the first step to have a high quality 
source of information.

I hope that the community will accept our contribution and enjoy to use the 
data.

Best regards,

Mojgan


Mojgan (Amaneh) Jadidi, Ph.D.
Postdoctoral Research Fellow
GeoICT Lab
York University
Toronto

ca.linkedin.com/pub/mojgan-amaneh-jadidi/10/825/969/

On 2 February 2016 at 07:00, 
> 
wrote:
Send Talk-ca mailing list submissions to
talk-ca@openstreetmap.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.openstreetmap.org/listinfo/talk-ca
or, via email, send a message with subject or body 'help' to

talk-ca-requ...@openstreetmap.org

You can reach the person managing the list at
talk-ca-ow...@openstreetmap.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Talk-ca digest..."


Today's Topics:

   1. Triplinx import (Stewart Russell)
   2. Re: Triplinx import (john whelan)
   3. Re: Triplinx import (Stewart Russell)


--

Message: 1
Date: Mon, 1 Feb 2016 18:36:01 -0500
From: Stewart Russell >
To: talk-ca >
Subject: [Talk-ca] Triplinx import
Message-ID:

Re: [OSM-ja] Google Map 利用規約更新

[Satoshi IIDA]

いいだです。

えっと、僕も専門家ではないのと、変更前後の文章を比較検討したわけではないので、
あくまで個人的な意見ではありますが。

> 浅野さん
著作権者のなかにはゼンリンさんも含まれますが、
Google Mapsの利用規約によって、そのコンテンツの利用が規定されている（はず）です。
なので、ゼンリンさんの規約まで確認する必要はないのではないかな、と思います。

著作権は人格権が残存するので行使が可能ではないか？という意見があるかもしれませんが、
普通は、こういう場合、Googleさん⇔ゼンリンさんの間で、
ある程度の権利非行使の契約を結ぶはずです。（結んでいるかはわかりません）

> フェアユース
日本にはフェアユースがありませんので、無視するのが正しいです。

> 印刷して配布して良いかどうか
以下「Google の地図を印刷物で使いたいのですが、何を調べればよいでしょうか？ 」にあるとおり、
「Google マップと Google Earth のコンテンツは、個人使用の目的で印刷し、拡大することができます。」
再配布については、許諾なき配布・再配布は引き続き許されていません。
https://www.google.co.jp/intl/ja/permissions/geoguidelines.html#maps-print

> 1.ライセンス には
> c. 適切な所有権を持つコンテンツのオンライン、動画形式、印刷形式における公開表示がライセンスされる
たぶん、山下さんが読み方を間違えている気がします。
「印刷形式における公開表示」が「ライセンス、に含まれる対象である」と書いているように見えます。
なので、この文言によって許諾が行われているわけではないです。

> プレゼン／文書に使うのは二次著作物になるのでダメ
状況によっては引用として扱われる可能性がありますが、
本来の目的である「地図」として使うのはよくないかな、と僕も思います。

「社内での利用については」許諾された、とのことなので、
社外での公開については引き続き変わらず、というかんじでしょうか。



とりあえず比較用に、変更前の文言がほしいなぁ。。。



2016年2月2日 22:45 浅野和仁 :

> 山下様
>
> 富田林市の浅野です。専門家ではありませんが・・・。
>
> ゼンリンの「複製等利用のご案内～利用手続きと基本条件、利用対象地図製品～」
> http://www.zenrin.co.jp/fukusei/index.html
> というページも確認する必要があると思います。
>
> その中で社内での複製利用が可能な製品が列挙されており、その下に
> 「無償で閲覧できる当社の地図製品は、複製等利用ができません。」と記されています。
>
> つまり、無償公開されているGoogleマップに関してはゼンリンが複製利用を認めていません。
> よって日本国内ではフェアユース（国内法に規定がないようです・・・）であろうとなかろうと、複製利用はできないとみるべきかと思います。
>
> --
> **
> 浅野 和仁 090-2067-9293
> helicobacter_y...@hera.eonet.ne.jp（メインメール）
> 586-0077 河内長野市南花台四丁目7-5
> **
>
>
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>
>


-- 
Satoshi IIDA
mail: nyamp...@gmail.com
twitter: @nyampire
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-fr] Fond OSM dans des guides de rando du CD63 ?

[Nicolas Dumoulin]

Le Tuesday 02 February 2016, 15:23:09 bernard a écrit :
> Bonjour,
> La page *craig.fr* a du mal à s'afficher.
> Tu peux fournir les fichiers GPX des itinéraires; cela permettra de
> mettre sur la carte les ways non existants en se servant des données
> cadastre et Biing.

Depuis la fiche du craig on peut télécharger le zip en allant dans le menu 
Actions->Export (ZIP) en haut à gauche.
Tu peux ensuite importer le shp dans josm.
Plutôt que Bing, utilises l'imagerie du Craig, ou encore mieux les deux ;-)


-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin


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

Re: [Talk-es] secciones censales zgz

[Rafael Avila Coya]

Hola:

No veo porqué no es compatible con la ODbL, siempre y cuando uses datos
de autoría exclusiva del INE.

Un saludo,

Rafael.

On 02/02/16 15:21, Miguel Sevilla-Callejo wrote:
> Me respondo yo solo con respecto a lo de las secciones censales:
> 
> De la web del INE  [1] se puede leer:
> 
> [...]
> 
> 5. Reutilización de la información contenida en este sitio web
> 
> La información contenida en este sitio web procede de múltiples fuentes,
> por lo que el INE solo autoriza la reutilización de aquélla cuya fuente
> original sea el propio INE y siempre bajo las siguientes condiciones
> generales:
> 
>   * Se prohíbe expresamente desnaturalizar el sentido de la información.
>   * Debe citarse la fuente de la información objeto de reutilización.
> Esta cita podrá realizarse de la siguiente manera: *Fuente: Sitio
> web del INE: www.ine.es  *si no se realiza ningún
> tratamiento de los datos o bien: *Elaboración propia con datos
> extraídos del sitio web del INE: www.ine.es * en
> caso de que se realice tratamiento de los datos.
>   * Debe mencionarse la fecha de la última actualización de la
> información objeto de reutilización, siempre y cuando estuviera
> incluida en el original.
>   * No se podrá indicar, insinuar o sugerir que el INE participa,
> patrocina o apoya la reutilización que se lleve a cabo con la
> información.
>   * El INE no será responsable del uso que de su información hagan los
> agentes reutilizadores. Tampoco será responsable de los daños
> materiales o sobre datos, ni de posibles perjuicios económicos
> provocados por el uso de la información reutilizada.
> 
> 
> --
> 
> O lo que es lo mismo, NO es compatible con OSM   :-(
> 
> 
> [1]
> http://www.ine.es/ss/Satellite?L=0=Page=1254735849170=1254735849170=Ayuda%2FINELayout#
> 
> *GeoMiguel Sevilla Callejo*
> *Doctor en Geografía | Doctor in Geography*
> /Consultor freelance e investigador | Freelance Consultant & Researcher/ 
> Colaborador del Instituto Pirenaico de Ecología, CSIC, Zaragoza | Fellow
> at the Pyrenean Institute of Ecology - Spanish National Research Council
> Colegiado nº698, Colegio Oficial de Geógrafos | Member #698, Spanish
> Professional Association of Geographers
> Web: http://bit.ly/sevillacallejo 
> 
> **
> 
> 2016-02-02 15:15 GMT+01:00 Miguel Sevilla-Callejo  >:
> 
> Hola,
> 
> Alejandro Suarez y yo andábamos comentando sobre encontrar los
> límites de los barrios de Zaragoza para incluirlos definitivamente
> en la base de datos de OSM y hemos encontrado dos fuentes que quería
> contrastar y comentar con alguno de vosotros para saber si alguien
> ya se ha visto en una problemática similar.
> 
> 1. Por un lado está la información urbanística del municipio, en
> concreto la cartografía que emana del Plan General de Ordenación
> Urbana de Zaragoza, tanto en un visor web [1], como accesible a
> través de los mapas en PDF [2] en donde se ven los límites de los
> distritos y barrios y sería relativamente sencillos de pasar (pues
> coinciden con calles mayormente) a OSM.
> ¿ALguien ha trabajado antes con información urbanística? ¿Alguien
> sabe qué tipo de licencias de usos tiene esta información? Yo diría
> que al ser algo público y que afecta a todo el mundo (escomo si se
> tratara de una ley) habrá de tener una licencia libre, no?
> 
> 2. Por otro lado estuve mirando a ver de dónde podría sacar esa
> misma información y llegué a la cartografía de las secciones
> censales del INE [3] de dónde, igualmente se pueden identificar
> límites que son comunies a los de los barrios, a pesar que en su
> base de datos no exista este tipo de agriupación (se pasa de
> distrito, que coincide con los de Zaragoza, a las secciones censales).
> 
> ¿Alguien ha echado un vistazo a esta información y/o a usado la
> misma? También desconozco el tipo de licencia que tiene. Se podría
> investigar.
> 
> A ver si alguien nos puede orientar.
> 
> Un saludo
> 
> M
> 
> [1] - http://www.zaragoza.es/ciudad/urbanismo/oficina/siggurz.htm
> [2] -
> http://www.zaragoza.es/ciudad/urbanismo/planeamiento/pgouz/planos.htm
> [3] -
> http://www.ine.es/censos2011_datos/cen11_datos_resultados_seccen.htm
> 
> 
> *GeoMiguel Sevilla Callejo*
> *Doctor en Geografía | Doctor in Geography*
> /Consultor freelance e investigador | Freelance Consultant &
> Researcher/ 
> Colaborador del Instituto Pirenaico de Ecología, CSIC, Zaragoza |
> Fellow at the Pyrenean Institute of Ecology - Spanish National
> Research Council
> Colegiado nº698, Colegio Oficial de Geógrafos | Member #698, Spanish
> Professional Association of Geographers
> Web: http://bit.ly/sevillacallejo 
> 
> **
> 
> 
> 
> 
> 

Re: [OSM-talk-fr] Fond OSM dans des guides de rando du CD63 ?

[bernard]

Bonjour,
La page *craig.fr* a du mal à s'afficher.
Tu peux fournir les fichiers GPX des itinéraires; cela permettra de 
mettre sur la carte les ways non existants en se servant des données 
cadastre et Biing.

Les randonneurs pourront corriger si necessaire.
Cordialement
Bernard

Le 02/02/2016 15:00, Nicolas Dumoulin a écrit :

Bonjour,

Le Tuesday 02 February 2016, 11:52:10 Landry Breuil a écrit :

Après en avoir discuté avec Guillaume Tournadre (du service SIG) qui
trouvait que les données OSM étaient un peu pauvres sur les zones
concernées (les PDIPR), je lui ai proposé de faire appel à la
communauté pour enclencher le cercle vertueux de -> les itinéraires
sont la -> on améliore les données -> le fond devient plus riche ->
tout le monde en bénéficie!

Dans tout les cas, les itinéraires des PDIPR sont disponibles en ligne
chez nous:
http://ids.craig.fr/geocat/apps/search/?uuid=3bd16d2d-5fc7-4816-b824-c27460
3cfd16

Super nouvelle !
Le mieux serait de nous communiquer les itinéraires identifiés où le fond OSM
révèle des manques, pour aller plus vite. Mais avec cette base d'itinéraires,
on peut passer en revue systématiquement tous les itinéraires.
À noter que nous avons dans la communauté pas mal de randonneurs. Si on se
répartit le travail, ça pourrait aller assez vite.
Et puis si on a un petit groupe qui s'ennue le soir au SotM fin mai … ;-)

Bon, et bien je sais quoi faire pendant les prochaines vacances :-)

Merci à Guillaume, et Landry



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

Re: [Talk-it] OpenStreetMap Italia

[Andrea Lattmann]

>Simone non ci sarà
>più" (nella comunità OSM, non in >generale ovviamente).

Meno male che hai specificato tra parentesi :-)
Comunque Simone una toccatina non guasta. :-D

Andrea Lattmann

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

Re: [Talk-es] Ordenanza de transparencia de Madrid

[Alejandro Moreno Calvo]

Haced un escrito oficial y mandadlo a transparen...@madrid.es

El 1 de febrero de 2016, 21:37, Miguel Sevilla-Callejo  escribió:

> Hola,
> Gracias por la información Alejandro y Manuel.
> ¿Habría alguna fórmula para que desde OSM subscribiéramos/apoyáramos el
> escrito de Wikimedia España?
> Creo que su escrito es totalmente vinculante y reivindicable desde nuestra
> posición.
>
> --
> Miguel Sevilla-Callejo
> desde el móvil
> El 31/01/2016 20:28, "Manu El"  escribió:
>
>> Hola Alejandro.
>>
>> Desde Wikimedia España hemos comentado el borrador de ordenanza. Uno de
>> nuestros socios sacó el tema a principios de año y hemos redactado un
>> pequeño texto. La ordenanza hace referencia a información de naturaleza muy
>> interesante, que en el caso de OSM podría ser de mucha utilidad, como la
>> información espacial. Sin embargo creemos que la ordenanza descuida por
>> completo lo que debe ser el espíritu libre en la publicación de datos y
>> transparencia (abierto ≠ libre). De hecho el artículo 29 sobre condiciones
>> de reutilización incluye aspectos que harían incompatible el contenido
>> publicado con las licencias que utilizamos en Wikipedia, por ejemplo, y
>> también en OSM.
>>
>> El texto que hemos añadido es el siguiente:
>>
>> Tal como señala el preámbulo del borrador de ordenanza, se pretenden
>> asumir los principios generales de la Carta Internacional de Datos Abiertos
>> a la cual el Ayuntamiento de Madrid está adherido. En dicha carta,[1]
>> 
>> en su principio 5 sobre liberación de datos para la innovación, se asume el
>> compromiso de realizar la liberación de datos utilizando licencias libres.
>> Entendemos que el borrador de la ordenanza de Transparencia de la Ciudad de
>> Madrid no hace suyo este principio en ninguno de sus apartados, lo cual
>> limita significativamente la utilidad de la publicación de los datos tal y
>> como establece el borrador de la ordenanza. En particular, el artículo 29
>> sobre las condiciones generales para la reutilización del borrador incluye
>> además elementos totalmente opuestos a lo que se entiende por licencia
>> libre, por ejemplo la imposibilidad de alterar el contenido de la
>> información.
>>
>> Desde Wikimedia España, proponemos que todo este artículo sea reformulado
>> adaptándose a una licencia libre, como por ejemplo algunas de las licencias
>> Creative Commons. En concreto, licencias como Creative Commons Atribución,
>> [2]
>> 
>> o Atribución-CompartirIgual,[3]
>> 
>> las cuales se usan por parte de un gran número de gobiernos y
>> administraciones en todo el mundo.[4]
>> 
>> De esta forma se asegura la posibilidad de reutilizar los datos en
>> cualquier circunstancia (aunque no sea necesario, recordamos que
>> independientemente de lo libre o cerrada que sea la licencia, se mantienen
>> los derechos morales y, por tanto, es obligatorio siempre consignar la
>> autoría y procedencia de la información). Licencias del tipo NC o ND no son
>> auténticamente libres, puesto que limitan gravemente la reutilización. Los
>> contenidos de Wikipedia, por ejemplo, se licencian bajo CC-BY-SA.
>>
>> Adicionalmente, ofrecemos la ayuda de Wikimedia España para, por ejemplo,
>> ayudar a subir información gráfica a Wikimedia Commons,[5]
>> 
>> el mayor repositorio de material gráfico de toda Internet, al que numerosos
>> archivos de todo el mundo han subido imágenes y material audiovisual.
>>
>> [1]
>> https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/207772/Open_Data_Charter.pdf
>> [2] https://creativecommons.org/licenses/by/4.0/deed.es_ES
>> [3] https://creativecommons.org/licenses/by-sa/4.0/deed.es_ES
>> [4]
>> https://wiki.creativecommons.org/wiki/Government_use_of_Creative_Commons
>> [5] https://commons.wikimedia.org/
>>
>> Un saludo.
>> Manuel.
>>
>> El 19 de enero de 2016, 14:37, Alejandro Moreno Calvo 
>> escribió:
>>
>>> No es un tema que tenga que ver directamente con la lista pero si creo
>>> que puede interesar. Hasta el 31 de enero se pueden presentar comentarios
>>> al borrador de la nueva Ordenanza de transparencia de Madrid en
>>> https://decide.madrid.es/processes_ordinance
>>> Creo que sería interesante revisarla para ver si desde OSM se puede
>>> aportar algo que ayude al proyecto.
>>>
>>> 

Re: [Talk-es] Nominatim debería ser más flexible

[Xavier Barnada]

Hola,

Acabo de hacer una pull request que deberia solucionar este problema, he
seguido el ejemplo de las otras stopwords  y este comentario
https://trac.openstreetmap.org/ticket/4895#comment:4

https://github.com/twain47/Nominatim/pull/358

Saludos

El dom., 31 ene. 2016 a las 11:57, Emilio Gómez Fernández (<
emilio.gomez.f...@gmail.com>) escribió:

> Hola a todos.
>
> Fui yo quien abrí ese ticket hace tiempo, tanto ahí como en GitHub [1], y
> también lo comenté  en la reunión en Aguilar de Campoo en la que estuvimos
> algunos de nosotros.
> La respuesta viene a ser, en resumidas cuentas, que añadir nuevas palabras
> vacías en español a las escasas que ya existen en Nominatim [2] podría
> perjudicar las búsquedas en otros idiomas. La consecuencia es que en
> nuestro caso usar la API de Nominatim para realizar, por ejemplo,
> geocodificación inversa es de escasa utilidad aun a pesar de que los datos
> existan en la base de datos.
>
> Lo único que se me ocurre es que esta discusión salte a la lista General y
> tener un feedback de otros usuarios para que la cosa se mueva y tenga más
> repercusión, porque este importante problema también afecta a otros idiomas
> [3][4].
>
> Saludos.
>
> [1] https://github.com/twain47/Nominatim/issues/85
> [2] https://github.com/twain47/Nominatim/blob/master/module/nominatim.c
> [3] https://github.com/twain47/Nominatim/issues/333
> [4] https://trac.openstreetmap.org/ticket/4961
>
>
> El 30 de enero de 2016, 14:17, Alejandro Moreno Calvo 
> escribió:
>
>> Este problema ya lleva reportado tiempo.
>> https://trac.openstreetmap.org/ticket/4895
>> El 30 ene. 2016 2:04 p. m., "Xavier Barnada" 
>> escribió:
>>
>>> Hola,
>>>
>>> A parte de la ayuda que podamos prestar al buscador mediante mejor
>>> etiquetado no veo mucho mas que se pueda hacer.
>>> Si quereix podeis reportar los problemas que veais al repositorio de
>>> Nominatim en github
>>> https://github.com/twain47/Nominatim
>>>
>>> Saludos
>>>
>>> El sáb., 30 ene. 2016 a las 13:54, Jorge Sanz Sanfructuoso (<
>>> sanc...@gmail.com>) escribió:
>>>
 Hola.

 Son un desastre las búsquedas. Hace no mucho salio el tema, no se si
 por aqui o por el telegram y alguien comentó que está adaptado para el
 habla inglesa y que según Nominatim si se adapta para otros idiomas podría
 hacer que fallara en el inglés.

 Ya no es escribir bien o mal, hay casos como los artículos que a veces
 los llevan las calles y a veces no. Es adivina adivinanza. jajaja

 Un saludo.

 El sáb., 30 ene. 2016 a las 13:12, Manuel Lladosa ()
 escribió:

> Hace un rato he hecho estas búsquedas:
>
> - Calle san roNque, paiporta (con falta de ortografía por descuido): no
> me encuentra nada por la falta, vale, de acuerdo.
> - Calle san roque, paiporta: no me encuentra nada. ¡Pues vaya!
> - Calle de san roque, paiporta: ¡premio!
>
> ¡Que tiquismiquis! jeje. Tienes que poner la calle con precisión
> milimétrica. Cuando alguien busca una calle no suele conocer el nombre
> con tanta exactitud y esto irrita un pelín :-), ya me ha pasado varias
> veces que no he encontrado calles, siendo que estaban en OSM.
>
> ¿Como podemos pedir que Nominatim sea más flexible, que no requiera
> búsquedas tan precisas? Y tampoco estaría mal que corrigiera faltas de
> ortografía, vale, debemos escribir bien, pero es que a veces se hacen
> por descuido.
>
> Muchas gracias.
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
 --
 Jorge Sanz Sanfructuoso - Sanchi
 Blog http://blog.jorgesanzs.com/
 ___
 Talk-es mailing list
 Talk-es@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-es

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

Re: [OSM-talk-fr] OSM : contribuer avec quel smartphone? (Nicolas Dumoulin)

[image93]

Bonjour et merci pour l'info. 

1/ En quoi est il moins conseillé pour la ville s'il vous plait? 

2/ Ce genre de smartphone pourrait etre intéressant. En avez vous testé
d'autres? Si vous d'autres modèles à me proposer ce serait avec plaisir.
Merci. 



--
View this message in context: 
http://gis.19327.n5.nabble.com/Re-OSM-contribuer-avec-quel-smartphone-Nicolas-Dumoulin-tp5866502p5866506.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Histoire de déchets / code SINOE

[Christian Quest]

L'ADEME est un EPIC (établissement public à caractère industriel et
commercial).

Les données produites par l'ADEME sont donc des informations publiques (loi
de 78), qui peuvent être soumises à redevances. Encore faut-il qu'elles
figure sur une liste officielle de 2013...

Ces redevances sont listées ici: https://www.data.gouv.fr/fr/Redevances

Pour le MEDDE, l'ADEME ne figure pas dans la liste, on serait donc dans le
cadre d'informations publiques, non soumises à redevances, donc librement
réutilisables... ce que je vais demander à vérifier ce soir.



Le 2 février 2016 à 09:59, Vincent Bergeot  a écrit :

> Bonjour et merci pour vos retours,
>
> Le 01/02/2016 12:09, Jérôme Seigneuret a écrit :
>
> La base de données est sous copyright et protéger au titre du Code de la
> Propriété Intellectuelle. Donc pour l'utilisation du code il va falloir
> avoir l'accord de l'ADEME il me semble.
>
>
> cela signifie que simplement l'ajout du code SINOE, avec des personnes du
> syndicat de gestion, est soumis à restriction ?
> Ok (et encore !!!) pour la base de données de l'ensemble des codes !
>
>
>
>
>
> Il ne risque pas de libérer cette base vu qu'il vendent des prestations
> (cartes de synthèse et indicateurs statistiques) comme le font les CCI et
> les Chambres d'Agricultures. Il y a 3 niveaux de licences mais je ne suis
> pas allé plus loin.
> La licence fait rire quand on lit la partie responsabilité...
>
>
> oui effectivement cela concerne les volumes de déchets et autres
> recyclages.
> Je ne sais pas si la correspondance entre un équipement lié au déchet et
> son code SINOE soit si sensible que cela !
>
>
>
>
> Les références SINOE sont accessibles sur le site mais en recherche par
> commune.
>
> Attention à l'actualisation des données car pour les marchés renouvelés
> dans l'année 2015/2016 c'est pas vraiment à jour. La dernière mise à jour
> de la base date 02/2015 et sur Montpellier le marché a été renouvelé au
> 01/2016.
>
>
>
> merci pour toutes ces informations,
>
> Merci Christian pour la demande au MEDDE.
> Que signifie sur le site de data.gouv.fr un document sans licence (?) qui
> fait référence à SINOE justement (
> https://www.data.gouv.fr/fr/datasets/tableau-de-bord-dechets/) ? L'ADEME
> a eu envie puis n'a pas voulu mettre de licence ?
>
> Bonne journée
>
>
>
> Cordialement,
> Jérôme
>
>
>
> Le 1 février 2016 à 11:27, Vincent Bergeot  a écrit :
>
>> Bonjour,
>> commençant à travailler avec des syndicats mixtes de gestion des déchets,
>> en particulier sur la cartographie de leurs équipements, je pense qu'il
>> faudrait ajouter ref:FR:SINOE, qui pour les professionnels du secteur est
>> la base de données de référence pour les équipements liés aux déchets.
>>
>> Est ce qu'il "suffit" de le dire et ensuite de le faire (comme cela
>> existe pour d'autres données : je pense aux écoles et ref:fr:UAI, boite aux
>> lettres, pharmacies, ...)
>>
>>- je parle bien de l'ajout avec les professionnels de ce code et pas
>>   de l'utilisation de la base de données SINOE, qui ne semble pas 
>> disponible (
>>   
>>   https://www.data.gouv.fr/fr/search/?q=sinoe),
>>   - peut-être d'ailleurs que l'ADEME pourrait vouloir libérer cette
>>   base (je vais me renseigner) ?
>>
>> Est ce la bonne direction ?
>>
>> Bonne journée
>>
>> --
>> Vincent Bergeot
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> --
> Vincent Bergeot
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [Talk-de] Deutscehr tileserver (was: HTTPS für openstreetmap.DE)

[Christoph Hormann]

On Monday 01 February 2016, Sven Geggus wrote:
>
> Was wir dringend brauchen ist ein Neustart des deutschen kartenstils
> als patchset des offiziellen carto style.
>
> Würde mich freuen wenn wir da 2-3 Leute finden würden, die sich darum
> kümmern.  Aus meiner Sicht hat das jedenfalls Priorität und ganz
> ehrlich https ist mir in diesem Fall völlig egal.

Yup, das wäre sehr schön.

Ich glaube ich hatte schon mal angeregt, die Unterschiede im deutschen 
Stil so weit zurückzufahren, dass diese sich mit dem begrenzten 
verfügbaren Engagement managen lassen.  Das würde sicherlich den 
Verlust einiger Aspekte dieses Stils bedeuten, aber gleichzeitig ergäbe 
dies die Chance auch die Leute anzusprechen, die sich im 
internationalen Stil engagieren.

Es gibt ja im internationalen Stil auch eine Menge jüngere Änderungen, 
die in Kombination mit so manchen Unterschieden des deutschen Stils bei 
Zoomlevel-Grenzen etc. vermutlich nicht sonderlich gut funktionieren.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Talk-cz] Národní katalog otevřených dat

[Petr Schönmann]

To je presne to cemu se chci vyhnout. Byrokracie. Proto zkuseny klikač,
který trasy dokreslí, udělá relace na již exitujících ( +opraví geometrii )
Není toho moc http://s17.postimg.org/cw6izj8tb/bezky.jpg

út 2. 2. 2016 v 11:08 odesílatel Marián Kyral  napsal:

> Kdepak. Nejprve potřebuješ zkušeného borce schopného zprocesovat
> byrokracii okolo importu ;-)
>
> Marián
>
> -- Původní zpráva --
> Od: Petr Schönmann 
> Komu: OpenStreetMap Czech Republic 
> Datum: 2. 2. 2016 10:53:03
> Předmět: [Talk-cz] Národní katalog otevřených dat
>
> Náhodou jsem narazil na Národní katalog otevřených dat, kde zaplesalo oko
> mé na některé datasety. Něco by se mohlo hodit třeba Lyžařské běžecké trasy
> Moravskoslezs­kého kraje -
> http://portal.gov.cz/app/RejData/rec.jsp?id=2665641_rej=97898=2016=01=idx
>
> Případně další zdroje http://www.otevrenadata.cz/otevrena-data/zdroje-dat/
>
> Publikují to v SHP, do JOSM na to je plugin opendata. Teď jen nějaké
> zkušené klikače s místní znalostí :)
> --
> S pozdravem
> Petr Schönmann
> https://www.facebook.com/klikklakcz
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
-- 
S pozdravem
Petr Schönmann
https://www.facebook.com/klikklakcz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

[Talk-it] Incontro con assessore su OpenData

[Lorenzo "Beba" Beltrami]

Ciao a tutti,
un po' come spinoff della superdiscussione "OpenStreetMap Italia" vorrei
chiedere a chi ha avuto più esperienza con le PA qualche consiglio.

Nel mio comune (Reggio nell'Emilia) l'interesse e la sensibilità sugli
OpenData c'è. L'assessore ha già convocato qualche tavolo sul tema a cui ho
partecipato in quanto semplice interessato del tema.

Già il fatto che stiano passando da un sito wordpress (
http://opendata.comune.re.it/) ad un portale CKAN lo trovo un passaggio
interessante, ma non mi accontenterei di questo: avete qualche suggerimento
da darmi a riguardo?
Anche solo qualche link da leggere su standard/direttive (sì, sì, lo so che
gli "standard" sono in realtà milioni...) per indirizzarli nel verso giusto.

Scrivetemi pure anche in privato.

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

Re: [OSM-talk-fr] OSM : contribuer avec quel smartphone? (Nicolas Dumoulin)

[Martin Noblecourt]

Dans le genre smartphone de terrain, on a aussi essayé et pas mal 
apprécié le Crosscall Odyssey+: étanche, antichoc, énorme batterie 
http://www.cdiscount.com/telephonie/telephone-mobile/crosscall-odyssey/f-1440402-crosscallodyssey.html
Moins adapté en ville par contre bien sûr, et plus cher qu'une entrée de 
gamme (autour de 200/250€ selon les vendeurs)


A bientôt,

--
Martin Noblecourt

*m_nobleco...@cartong.org | Bureau/Office: +33 (0)4 79 26 28 82 | Skype: 
martin.noblecourt*
CartONG - Mapping and information management for humanitarian 
organizations | Cartographie et gestion de l'information pour les 
organisations humanitaires


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

Re: [Talk-cz] Národní katalog otevřených dat

[Marián Kyral]

Kdepak. Nejprve potřebuješ zkušeného borce schopného zprocesovat byrokracii 
okolo importu ;-)

Marián


-- Původní zpráva --
Od: Petr Schönmann 
Komu: OpenStreetMap Czech Republic 
Datum: 2. 2. 2016 10:53:03
Předmět: [Talk-cz] Národní katalog otevřených dat

"


Náhodou jsem narazil na Národní katalog otevřených dat, kde zaplesalo oko mé
na některé datasety. Něco by se mohlo hodit třeba Lyžařské běžecké trasy 
Moravskoslezs­kého kraje - http://portal.gov.cz/app/RejData/rec.jsp?id=
2665641_rej=97898=2016=01=idx
(http://portal.gov.cz/app/RejData/rec.jsp?id=2665641_rej=97898=2016=01=idx)



Případně další zdroje http://www.otevrenadata.cz/otevrena-data/zdroje-dat/
(http://www.otevrenadata.cz/otevrena-data/zdroje-dat/)




Publikují to v SHP, do JOSM na to je plugin opendata. Teď jen nějaké zkušené
klikače s místní znalostí :)


-- 


S pozdravem
Petr Schönmann
https://www.facebook.com/klikklakcz(https://www.facebook.com/klikklakcz)


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

Re: [Talk-it] Incontro con assessore su OpenData

[Michele Mondelli]

Sono d'accordo con Alessandro, il problema non è fare o meno open data, ma
farlo bene.

Ho visto portali in cui venivano rilasciati dataset cartografici con il
solo file .shp (quindi inutilizzabile).
Inoltre la metadatazione è importante per capire il dato, e poterlo
utilizzare.

Inoltre utilizzare soluzioni "una tantum", creando un portale con un CMS e
CKAN, non garantisce un flusso
di controllo del ciclo di produzione degli open data ed il progressivo
aggiornamento degli stessi.

Per la mia azienda ho lavorato alla costruzione di un software che permette
di creare, gestire e pubblicare
dataset opendata rispettando la normativa vigente e garantendo la qualità
del dato.
È possibile anche esportare linked open data tramite server SPARQL.

Riporto alcuni esempi dei portali ai quali abbiamo lavorato:
- http://www.sitmontevarchi.it/?q=opendata
- http://opendata.comune.siena.it/
- http://maps1.ldpgis.it/montemurlo/?q=metarepo

Sono esempi di portali sia grandi che piccoli, in relazione a quanto
l'amministrazione volesse investire sul progetto.
Ovviamente c'è tutta la parte di gestionale nel "back-office" che se
qualcuno è interessato posso mostrarla su
un ambiente di staging.

ciao,

Il giorno 2 febbraio 2016 10:43, Alessandro Palmas <
alessandro.pal...@wikimedia.it> ha scritto:

> Il 02/02/2016 10:03, Lorenzo "Beba" Beltrami ha scritto:
>
>> Ciao a tutti,
>> un po' come spinoff della superdiscussione "OpenStreetMap Italia" vorrei
>> chiedere a chi ha avuto più esperienza con le PA qualche consiglio.
>>
>> Nel mio comune (Reggio nell'Emilia) l'interesse e la sensibilità sugli
>> OpenData c'è. L'assessore ha già convocato qualche tavolo sul tema a cui ho
>> partecipato in quanto semplice interessato del tema.
>>
>> Già il fatto che stiano passando da un sito wordpress (
>> http://opendata.comune.re.it/) ad un portale CKAN lo trovo un passaggio
>> interessante, ma non mi accontenterei di questo: avete qualche suggerimento
>> da darmi a riguardo?
>> Anche solo qualche link da leggere su standard/direttive (sì, sì, lo so
>> che gli "standard" sono in realtà milioni...) per indirizzarli nel verso
>> giusto.
>>
>> Scrivetemi pure anche in privato.
>>
>
> L'argomento è interessante, direi di parlarne pubblicamente.
> Pronto ad attirarmi le critiche di molti, personalmente che sia un
> wordpress piuttosto che un portale CKAN non mi interessa più di tanto,
> questo estratto viene da un portale CKAN
> guidcomunege:b018e8dc-9661-4299-ab59-7cfb78659292
> harvest_object_id   09e36314-0e07-48a8-bc5a-5a3b19081530
> harvest_source_id   f69c12e3-c997-4d3d-861f-e6846089b72e
> harvest_source_titleProduzione
> licence ["Condizioni sconosciute"]
> metadata-date   2015-02-02
> metadata-language   ita
> progress
> resource-type   dataset
>
>
> e di questi metadati non so che farmene.
> Preferirei avere dati aggiornati (a campione ho visto che nella zona del
> cimitero mancano delle strade) e magari un paio di formati diversi in
> uscita (le ciclabili sono anche in KMZ oltre che in shape) perchè non tutti
> sanno come maneggiare gli shapefile.
> Poi, se le risorse permettono sia di mettere sù il portale che continuare
> ad alimentarlo con nuovi dataset e tenerli aggiornati allora siamo tutti
> contenti.
>
> Alessandro Ale_Zena_IT
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>



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

Re: [OSM-talk-fr] Import de données dans OSM - Zonage Unesco Causses & Cévennes de 6 000 km² (!)

[Christian Quest]

Le 2 février 2016 à 09:16, Stéphane Ritzenthaler <
sritzentha...@causses-et-cevennes.fr> a écrit :

> beaucoup de découpages en perspective et un gros travail de fourmis à faire


L'appariement automatique est possible entre ton gros polygone et les
chemins OSM mais c'est pas simple et il n'y a pas d'outil directement
utilisable pour faire ça.

Le principe pour ce type d'appariement consiste à tronçonner les chemins de
part et d'autre pour faire ensuite l'appariement... pas super simple. Ça
vaut le coup de coder ça si on a un volume important à traiter, sinon, le
faire à la main peut aller plus vite si il y en a peu.

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

[Talk-cz] Národní katalog otevřených dat

[Petr Schönmann]

Náhodou jsem narazil na Národní katalog otevřených dat, kde zaplesalo oko
mé na některé datasety. Něco by se mohlo hodit třeba Lyžařské běžecké trasy
Moravskoslezs­kého kraje -
http://portal.gov.cz/app/RejData/rec.jsp?id=2665641_rej=97898=2016=01=idx

Případně další zdroje http://www.otevrenadata.cz/otevrena-data/zdroje-dat/

Publikují to v SHP, do JOSM na to je plugin opendata. Teď jen nějaké
zkušené klikače s místní znalostí :)
-- 
S pozdravem
Petr Schönmann
https://www.facebook.com/klikklakcz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-it] Incontro con assessore su OpenData

[Alessandro Palmas]

Il 02/02/2016 10:03, Lorenzo "Beba" Beltrami ha scritto:

Ciao a tutti,
un po' come spinoff della superdiscussione "OpenStreetMap Italia" 
vorrei chiedere a chi ha avuto più esperienza con le PA qualche consiglio.


Nel mio comune (Reggio nell'Emilia) l'interesse e la sensibilità sugli 
OpenData c'è. L'assessore ha già convocato qualche tavolo sul tema a 
cui ho partecipato in quanto semplice interessato del tema.


Già il fatto che stiano passando da un sito wordpress 
(http://opendata.comune.re.it/) ad un portale CKAN lo trovo un 
passaggio interessante, ma non mi accontenterei di questo: avete 
qualche suggerimento da darmi a riguardo?
Anche solo qualche link da leggere su standard/direttive (sì, sì, lo 
so che gli "standard" sono in realtà milioni...) per indirizzarli nel 
verso giusto.


Scrivetemi pure anche in privato.


L'argomento è interessante, direi di parlarne pubblicamente.
Pronto ad attirarmi le critiche di molti, personalmente che sia un 
wordpress piuttosto che un portale CKAN non mi interessa più di tanto, 
questo estratto viene da un portale CKAN

guidcomunege:b018e8dc-9661-4299-ab59-7cfb78659292
harvest_object_id   09e36314-0e07-48a8-bc5a-5a3b19081530
harvest_source_id   f69c12e3-c997-4d3d-861f-e6846089b72e
harvest_source_titleProduzione
licence ["Condizioni sconosciute"]
metadata-date   2015-02-02
metadata-language   ita
progress
resource-type   dataset


e di questi metadati non so che farmene.
Preferirei avere dati aggiornati (a campione ho visto che nella zona del 
cimitero mancano delle strade) e magari un paio di formati diversi in 
uscita (le ciclabili sono anche in KMZ oltre che in shape) perchè non 
tutti sanno come maneggiare gli shapefile.
Poi, se le risorse permettono sia di mettere sù il portale che 
continuare ad alimentarlo con nuovi dataset e tenerli aggiornati allora 
siamo tutti contenti.


Alessandro Ale_Zena_IT

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

[talk-au] AGRI Imagery

[Grant Slater]

Hi Talk-AU,

I'm still working to fully restore the Australian Geographic Reference
Image (AGRI) site I run after the hardware failure...
AGRI? https://wiki.openstreetmap.org/wiki/Australian_Geographic_Reference_Image

I now have the tiles up and running again and they can be used in the
editors JOSM / iD or similar.

Issues still to resolve:
 * Currently no web interface to access the tiles.
 * Large black stripes over the overlapping sections of the imagery.
 * Poor performance, currently no caching.

I hope to fix the remaining issues over the next few weeks.

Technical:
The code used for serving the imagery is managed using opscode chef:
https://github.com/openstreetmap/chef/blob/master/cookbooks/imagery/recipes/au_agri.rb

Kind regards,

Grant

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

Re: [OSM-talk-fr] OSM : contribuer avec quel smartphone? (Nicolas Dumoulin)

[Christian Quest]

La qualité et surtout la réactivité de l'appareil photo est pour moi un
critère prioritaire, avec celle du GPS.


J'ai pris des milliers de photos avec un iphone 4 puis 5S et maintenant 6S.
Couplé quand c'est nécessaire à une batterie externe, c'est mon outil de
base pour mapper... et il est toujours dans ma poche donc je mappe, je
mappe, je mappe ;)



Le 2 février 2016 à 11:09, image93  a écrit :

> Bonjour et merci pour l'info.
>
> 1/ En quoi est il moins conseillé pour la ville s'il vous plait?
>
> 2/ Ce genre de smartphone pourrait etre intéressant. En avez vous testé
> d'autres? Si vous d'autres modèles à me proposer ce serait avec plaisir.
> Merci.
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Re-OSM-contribuer-avec-quel-smartphone-Nicolas-Dumoulin-tp5866502p5866506.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



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

[OSM-talk-fr] Fond OSM dans des guides de rando du CD63 ?

[Landry Breuil]

Hello,

le conseil départemental du Puy-de-Dôme envisage d'utiliser des fonds
OSM pour l'édition de son prochain guide papier/pdf de randonnées
suivant les PDIPR - ces guides utilisaient jusqu'ici le fond scan 25
de l'IGN (que le CRAIG fournit au CD63), mais a priori (?) les
conditions de licence ne le permettent plus de la même manière, donc
pour des questions de coût le service SIG s'oriente potentiellement
vers un fond OSM.

Cf 
http://www.planetepuydedome.com/destination-volcans/tout-le-puy-de-dome/le-puy-de-dome-terre-de-randonnee-au-coeur-des-volcans/randonnez-vous-661-1.html,
http://www.planetepuydedome.com/destination-volcans/tout-le-puy-de-dome/le-puy-de-dome-terre-de-randonnee-au-coeur-des-volcans/randos-a-croquer-662-1.html
et http://www.planetepuydedome.com/brochures-688-1.html pour les
précedentes éditions. Oui, y'a du google maps sur les versions web des
itinéraires, mais du scan 25 dans la version pdf/papier.

Après en avoir discuté avec Guillaume Tournadre (du service SIG) qui
trouvait que les données OSM étaient un peu pauvres sur les zones
concernées (les PDIPR), je lui ai proposé de faire appel à la
communauté pour enclencher le cercle vertueux de -> les itinéraires
sont la -> on améliore les données -> le fond devient plus riche ->
tout le monde en bénéficie!

Dans tout les cas, les itinéraires des PDIPR sont disponibles en ligne
chez nous: 
http://ids.craig.fr/geocat/apps/search/?uuid=3bd16d2d-5fc7-4816-b824-c274603cfd16

Les données ne sont pas en opendata (pas encore, mais guillaume y
travaille!) mais rien n'empèche (ou plutôt, on a l'accord) de les
utiliser pour connaitre les zones à améliorer/cartographier

Ca ne sera peut-être pas pour cette édition because timing serré...
mais ca ne sera jamais perdu!

Guillaume est en copie de ce mail, vous pouvez le contacter pour plus
d'informations.

Landry

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

Re: [Talk-at] Via Ferrata/Klettersteig - Wie richtig taggen?

[Richard]

On Tue, Feb 02, 2016 at 11:38:24AM +0100, Friedrich Volkmann wrote:
> On 02.02.2016 07:43, Thomas Konrad wrote:
> > - Einen eigenen “highway”-Tag für Wege einführen, für die man “alle viere” 
> > braucht, also für Wege in den Bergen, die nicht nur auf den zwei Beinen 
> > begehbar sind (sowas wie highway=steep_path oder highway=mountain_path, 
> > besseres Wording anyone?).

...
...

> Aber das größte Problem mit highway=climbing sehe ich darin, dass es auf
> manchen Steigen nur eine einzelne Kletterstelle gibt (das ist dann die
> Schlüsselstelle). Wenn man den Way aus irgendeinem Grund in mehrere
> Abschnitte zerlegt, stimmt highway=climbing nur noch für das kurze Stückerl
> mit der Schlüsselstelle. Alle anderen Teile muss man auf highway=path
> ändern. Dann fällt das andere Rendering des kurzen Stückerls in der Karte
> überhaupt nicht auf. Damit wird der ganze Zweck des eigenen highway-Tags
> verfehlt.

das sehe ich nicht so als das große Problem. Wenn herausgezoomt wird kann
die Stelle mit einem auffälligen Icon verdeutlicht werden.

Richard

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

Re: [Talk-ca] Talk-ca Digest, Vol 96, Issue 1

[Paul Ramsey]

Yeah, from the outside looking in I'm not seeing the huge surprise.
I'm not a community member, but I saw the initial emails from Mojgan,
and he's also talked to folks face-to-face. I didn't see an email
about the wiki page, but that could be because I wasn't paying
attention. What would a good process look like?

x- email: "hi, I'm a government organization and I'd like to engage
this way, we want to do this"
x- comment/response/refine
x- wiki: "here is exactly what we plan to do and how we are going to do it"
- email: "hi, we now have specific plans and have documented them here
in the wiki for your comment"
- comment/response/refine
- email: "hi, we are going to run a small test import in the following
area for your review, please comment"
- import: "here's a small amount of data, exactly as we'd do it in a
larger area"
- email: "hi, we have run a small test import in the following area,
please review and comment"
- comment/response/refine
- email: "hi, we are about to run our main import in the following
area, please light your hair on fair if you still have a problem with
this"
- import: "boom, there it is"

I did see the first three communications for sure, and maybe missed
one on the wiki. Probably for a big import running a test import first
would be a generally wise approach for getting feedback (similar to
publishing a github branch).

Triplinx has definitely been approaching this in very good faith,
shame to see them get reverted for failing to follow a process that
doesn't seem to be documented. They certainly met the "communicated"
threshold, just maybe not enough or in the right ways for some folks?

P.


On Tue, Feb 2, 2016 at 6:51 AM, Begin Daniel  wrote:
> Initial misunderstandings, emails round trips with the community… standard
> communication process!
>
>
>
> I do not know how others a seeing it, but reading about the process you use,
> I do not see anything like a wild bulk import. At least, it is very similar
> to the process I used when importing Canvec datasets.
>
>
>
> Daniel
>
>
>
> From: Mojgan Jadidi [mailto:mojgan.jad...@gmail.com]
> Sent: February-02-16 09:33
> To: talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] Talk-ca Digest, Vol 96, Issue 1
>
>
>
> Hi all,
>
> Please accept my apology for this misunderstanding, I thought our presence
> for last OSM meeting and flowing emails in Talk-ca and with John were part
> of communication and discussion, we launched our wikipage two weeks ago, and
> we did not receive any feedback, so we thought to start import via JOSM.
>
>
>
> as we expalined in our wikipage, we created the algorithm to detect the
> missing information, and then we check the quality of this information on
> JOSM on the top of OpenStreetMap, Bing Areal imagery, GeoBase Road network
> and some local municpal open data. the data is created initially through
> StatCan, however, we noticed the low quality of StatCan road segment
> geometry, so we deal with this issue by using complement dataset such as
> OpenStreetMap, Bing Areal imagery, GeoBase Road network and some local
> municpal open data. all created nodes and ways are carefully inspected
> visually using above dataset for more that 6 weeks.
>
>
>
> Our final verification will be on the OSM server (on-line) to avoid or
> detect any issues. Our aim is having high quality address information in OSM
> for sake of community. we were very prudent from the first step to have a
> high quality source of information.
>
>
>
> I hope that the community will accept our contribution and enjoy to use the
> data.
>
>
>
> Best regards,
>
>
>
> Mojgan
>
>
>
>
> Mojgan (Amaneh) Jadidi, Ph.D.
>
> Postdoctoral Research Fellow
>
> GeoICT Lab
>
> York University
>
> Toronto
>
>
>
> ca.linkedin.com/pub/mojgan-amaneh-jadidi/10/825/969/
>
>
>
> On 2 February 2016 at 07:00,  wrote:
>
> Send Talk-ca mailing list submissions to
> talk-ca@openstreetmap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.openstreetmap.org/listinfo/talk-ca
> or, via email, send a message with subject or body 'help' to
> talk-ca-requ...@openstreetmap.org
>
> You can reach the person managing the list at
> talk-ca-ow...@openstreetmap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Talk-ca digest..."
>
>
> Today's Topics:
>
>1. Triplinx import (Stewart Russell)
>2. Re: Triplinx import (john whelan)
>3. Re: Triplinx import (Stewart Russell)
>
>
> --
>
> Message: 1
> Date: Mon, 1 Feb 2016 18:36:01 -0500
> From: Stewart Russell 
> To: talk-ca 
> Subject: [Talk-ca] Triplinx import
> Message-ID:
> 

Re: [OSM-talk-fr] Rapprochement BANO dans L'île de Saint-Martin

[Philippe Verdy]

Il n'y a pas de commune car les compétences d'une commune sont dévolues à
la collectivité entière. C'était une commune. Néanmoins il devrait rester
un noeud place=town dedans. La capitale Gustavia est en fait un des
quartier de la collectivité, et pourrait se coder aussi en suburb, en plus
du place=town avec capital=4 en tant que capitale "régionale". Pas 3 car le
niveau 3 c'est l'ensemble des com.
Le 2 févr. 2016 14:41, "Cactusbone"  a écrit :

> L'île de Saint-Martin est un territoire français ne contenant pas de
> commune
> (
> https://fr.wikipedia.org/wiki/Saint-Martin_%28Antilles_fran%C3%A7aises%29
> )
> taggé admin_level 3 dans osm
>
> dans bano on a des adresses dans le CSV, mais aucune n'est rapprochée
> http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#14/18.0743/-63.0576
>
> par exemple ,
> 15 rue du Général De Gaule, 97150 Saint-Martin est bien dans le CSV,
> la rue existe aussi dans OSM ( https://www.openstreetmap.org/way/27614897
> )
> mais aucun rapprochement n'est fait.
>
> Je pense que c'est lié a l'absence de ville/commune coté osm
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Rapprochement-BANO-dans-L-ile-de-Saint-Martin-tp5866521.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Incontro con assessore su OpenData

[Alessandro]

Il 02/02/2016 12:08, Lorenzo "Beba" Beltrami ha scritto:



Ad esempio trovo interessante il parere di Alessandro sui dati in
formati più o meno accessibili (per accontentare gli smanettoni, ma
anche chi semplicemente sa usare Google Earth come unica risorsa
geografica).



Il mio più che un invito ad utilizzare il formato KMZ è di utilizzare 
almeno un paio di formati diversi




Sull'aggiornamento dei dati il problema sta più che altro nel
coordinamento e nella mancanza di uniformità tra i vari fornitori dei
dati (uffici tecnici, municipalizzate, partecipate, ...).


La mancanza di coordinamento è quasi una costante, l'importante è che i 
dati siano aggiornati. Spesso visito portali open data comunali che 
hanno dati non aggiornati, magari hanno tirato su il portale nel 2012 e 
i dati continuano ad essere quelli.


Alessandro Ale_Zena_IT


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

Re: [Talk-es] Nominatim debería ser más flexible

[Benjamín Valero Espinosa]

El problema con las "stop words" es que puedes sin querer capar una palabra
que sí tiene sentido en otro idioma. El ejemplo típico es "die", que es un
artículo definido en alemán pero es un verbo en inglés. ¿Esto se está
controlando? Lo ideal sería listas de "stop words" por idioma, pero claro,
para eso también habría que saber en qué idioma está la calle :-O

El 2 de febrero de 2016, 9:16, Alejandro Moreno Calvo 
escribió:

> Hola Xavier.
>
> Hay que tener en cuenta que ese PR soluciona un caso muy concreto pero que
> habría que hacer un análisis más profundo de los artículos que se pueden
> dar. Así a bote pronto se me ocurre también habría que añadir "el", "la",
> "las", "los".
>
> El 2 de febrero de 2016, 8:40, Xavier Barnada 
> escribió:
>
>> Hola,
>>
>> Acabo de hacer una pull request que deberia solucionar este problema, he
>> seguido el ejemplo de las otras stopwords  y este comentario
>> https://trac.openstreetmap.org/ticket/4895#comment:4
>>
>> https://github.com/twain47/Nominatim/pull/358
>>
>> Saludos
>>
>> El dom., 31 ene. 2016 a las 11:57, Emilio Gómez Fernández (<
>> emilio.gomez.f...@gmail.com>) escribió:
>>
>>> Hola a todos.
>>>
>>> Fui yo quien abrí ese ticket hace tiempo, tanto ahí como en GitHub [1],
>>> y también lo comenté  en la reunión en Aguilar de Campoo en la que
>>> estuvimos algunos de nosotros.
>>> La respuesta viene a ser, en resumidas cuentas, que añadir nuevas
>>> palabras vacías en español a las escasas que ya existen en Nominatim [2]
>>> podría perjudicar las búsquedas en otros idiomas. La consecuencia es que en
>>> nuestro caso usar la API de Nominatim para realizar, por ejemplo,
>>> geocodificación inversa es de escasa utilidad aun a pesar de que los datos
>>> existan en la base de datos.
>>>
>>> Lo único que se me ocurre es que esta discusión salte a la lista General
>>> y tener un feedback de otros usuarios para que la cosa se mueva y tenga más
>>> repercusión, porque este importante problema también afecta a otros idiomas
>>> [3][4].
>>>
>>> Saludos.
>>>
>>> [1] https://github.com/twain47/Nominatim/issues/85
>>> [2] https://github.com/twain47/Nominatim/blob/master/module/nominatim.c
>>> [3] https://github.com/twain47/Nominatim/issues/333
>>> [4] https://trac.openstreetmap.org/ticket/4961
>>>
>>>
>>> El 30 de enero de 2016, 14:17, Alejandro Moreno Calvo >> > escribió:
>>>
 Este problema ya lleva reportado tiempo.
 https://trac.openstreetmap.org/ticket/4895
 El 30 ene. 2016 2:04 p. m., "Xavier Barnada" 
 escribió:

> Hola,
>
> A parte de la ayuda que podamos prestar al buscador mediante mejor
> etiquetado no veo mucho mas que se pueda hacer.
> Si quereix podeis reportar los problemas que veais al repositorio de
> Nominatim en github
> https://github.com/twain47/Nominatim
>
> Saludos
>
> El sáb., 30 ene. 2016 a las 13:54, Jorge Sanz Sanfructuoso (<
> sanc...@gmail.com>) escribió:
>
>> Hola.
>>
>> Son un desastre las búsquedas. Hace no mucho salio el tema, no se si
>> por aqui o por el telegram y alguien comentó que está adaptado para el
>> habla inglesa y que según Nominatim si se adapta para otros idiomas 
>> podría
>> hacer que fallara en el inglés.
>>
>> Ya no es escribir bien o mal, hay casos como los artículos que a
>> veces los llevan las calles y a veces no. Es adivina adivinanza. jajaja
>>
>> Un saludo.
>>
>> El sáb., 30 ene. 2016 a las 13:12, Manuel Lladosa (<
>> manolo...@gmail.com>) escribió:
>>
>>> Hace un rato he hecho estas búsquedas:
>>>
>>> - Calle san roNque, paiporta (con falta de ortografía por descuido):
>>> no
>>> me encuentra nada por la falta, vale, de acuerdo.
>>> - Calle san roque, paiporta: no me encuentra nada. ¡Pues vaya!
>>> - Calle de san roque, paiporta: ¡premio!
>>>
>>> ¡Que tiquismiquis! jeje. Tienes que poner la calle con precisión
>>> milimétrica. Cuando alguien busca una calle no suele conocer el
>>> nombre
>>> con tanta exactitud y esto irrita un pelín :-), ya me ha pasado
>>> varias
>>> veces que no he encontrado calles, siendo que estaban en OSM.
>>>
>>> ¿Como podemos pedir que Nominatim sea más flexible, que no requiera
>>> búsquedas tan precisas? Y tampoco estaría mal que corrigiera faltas
>>> de
>>> ortografía, vale, debemos escribir bien, pero es que a veces se hacen
>>> por descuido.
>>>
>>> Muchas gracias.
>>>
>>> ___
>>> Talk-es mailing list
>>> Talk-es@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-es
>>>
>> --
>> Jorge Sanz Sanfructuoso - Sanchi
>> Blog http://blog.jorgesanzs.com/
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> 

Re: [Talk-at] Via Ferrata/Klettersteig - Wie richtig taggen?

[Stefan Kopetzky]

On 2016-02-02 11:38, Friedrich Volkmann wrote:
> Relationen (z.B. route=ferrata) sind verträglicher als ein eigenes
> highway-Tag und sicher eine gute Idee, damit man Tags wie operator=* und
> start_date=* nicht auf jedes einzelne Wegstück setzen muss. 

+1


LG,
Stefan

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

Re: [Talk-de] Deutscehr tileserver

[gmbo]

Am 01.02.2016 um 10:55 schrieb Sven Geggus:
Der deutsche Tileserver und auch unsere Webseiten haben aber 
eigentlich ein ganz anderes Problem. Alle wollen nur und niemand 
arbeitet mit :( Was wir dringend brauchen ist ein Neustart des 
deutschen kartenstils als patchset des offiziellen carto style. Würde 
mich freuen wenn wir da 2-3 Leute finden würden, die sich darum kümmern. 
Welche Voraussetzungen müsste ich außer Zeit dafür haben, um dich dabei 
zu unterstützen.


Gruß Gisbert



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

Re: [Talk-es] Nominatim debería ser más flexible

[Alejandro Moreno Calvo]

Curiosamente hay un pueblo llamado De en Indonesia
http://nominatim.openstreetmap.org/details.php?place_id=14215103 que con
ese parche no se encontraría nunca.

No tengo el detalle de cómo está implementado Nominatim pero para mí la
solución pasa por usar funciones estadísticas de comparación de cadenas, de
manera que en vez de buscar una similitud exacta se busque aquello que
supere un cierto porcentaje de similitud. En Oracle estás funciones están
dentro del paquete UTL_MATCH [
https://docs.oracle.com/cd/E18283_01/appdev.112/e16760/u_match.htm ]. En
PostgreSQL existe el módulo *fuzzystrmatch* [
http://www.postgresql.org/docs/current/static/fuzzystrmatch.html ] que
parece más limitado y existe un proyecto [
http://pgsimilarity.projects.pgfoundry.org/ ] que implementa más funciones
pero no sé si es muy común su uso ni si está actualizado.

Yo tengo pendiente echarle un vistazo a Nominatim e intentar implementar
esto pero seguramente me lleve varios meses por falta de tiempo por lo que
si alguien se quiere animar a recoger el testigo bienvenido es.

El 2 de febrero de 2016, 12:02, Benjamín Valero Espinosa <
benjaval...@gmail.com> escribió:

> El problema con las "stop words" es que puedes sin querer capar una
> palabra que sí tiene sentido en otro idioma. El ejemplo típico es "die",
> que es un artículo definido en alemán pero es un verbo en inglés. ¿Esto se
> está controlando? Lo ideal sería listas de "stop words" por idioma, pero
> claro, para eso también habría que saber en qué idioma está la calle :-O
>
> El 2 de febrero de 2016, 9:16, Alejandro Moreno Calvo 
> escribió:
>
>> Hola Xavier.
>>
>> Hay que tener en cuenta que ese PR soluciona un caso muy concreto pero
>> que habría que hacer un análisis más profundo de los artículos que se
>> pueden dar. Así a bote pronto se me ocurre también habría que añadir "el",
>> "la", "las", "los".
>>
>> El 2 de febrero de 2016, 8:40, Xavier Barnada 
>> escribió:
>>
>>> Hola,
>>>
>>> Acabo de hacer una pull request que deberia solucionar este problema, he
>>> seguido el ejemplo de las otras stopwords  y este comentario
>>> https://trac.openstreetmap.org/ticket/4895#comment:4
>>>
>>> https://github.com/twain47/Nominatim/pull/358
>>>
>>> Saludos
>>>
>>> El dom., 31 ene. 2016 a las 11:57, Emilio Gómez Fernández (<
>>> emilio.gomez.f...@gmail.com>) escribió:
>>>
 Hola a todos.

 Fui yo quien abrí ese ticket hace tiempo, tanto ahí como en GitHub [1],
 y también lo comenté  en la reunión en Aguilar de Campoo en la que
 estuvimos algunos de nosotros.
 La respuesta viene a ser, en resumidas cuentas, que añadir nuevas
 palabras vacías en español a las escasas que ya existen en Nominatim [2]
 podría perjudicar las búsquedas en otros idiomas. La consecuencia es que en
 nuestro caso usar la API de Nominatim para realizar, por ejemplo,
 geocodificación inversa es de escasa utilidad aun a pesar de que los datos
 existan en la base de datos.

 Lo único que se me ocurre es que esta discusión salte a la lista
 General y tener un feedback de otros usuarios para que la cosa se mueva y
 tenga más repercusión, porque este importante problema también afecta a
 otros idiomas [3][4].

 Saludos.

 [1] https://github.com/twain47/Nominatim/issues/85
 [2] https://github.com/twain47/Nominatim/blob/master/module/nominatim.c
 [3] https://github.com/twain47/Nominatim/issues/333
 [4] https://trac.openstreetmap.org/ticket/4961


 El 30 de enero de 2016, 14:17, Alejandro Moreno Calvo <
 almo...@gmail.com> escribió:

> Este problema ya lleva reportado tiempo.
> https://trac.openstreetmap.org/ticket/4895
> El 30 ene. 2016 2:04 p. m., "Xavier Barnada" 
> escribió:
>
>> Hola,
>>
>> A parte de la ayuda que podamos prestar al buscador mediante mejor
>> etiquetado no veo mucho mas que se pueda hacer.
>> Si quereix podeis reportar los problemas que veais al repositorio de
>> Nominatim en github
>> https://github.com/twain47/Nominatim
>>
>> Saludos
>>
>> El sáb., 30 ene. 2016 a las 13:54, Jorge Sanz Sanfructuoso (<
>> sanc...@gmail.com>) escribió:
>>
>>> Hola.
>>>
>>> Son un desastre las búsquedas. Hace no mucho salio el tema, no se si
>>> por aqui o por el telegram y alguien comentó que está adaptado para el
>>> habla inglesa y que según Nominatim si se adapta para otros idiomas 
>>> podría
>>> hacer que fallara en el inglés.
>>>
>>> Ya no es escribir bien o mal, hay casos como los artículos que a
>>> veces los llevan las calles y a veces no. Es adivina adivinanza. jajaja
>>>
>>> Un saludo.
>>>
>>> El sáb., 30 ene. 2016 a las 13:12, Manuel Lladosa (<
>>> manolo...@gmail.com>) escribió:
>>>
 Hace un rato he hecho estas búsquedas:

 - Calle san roNque, paiporta (con falta de ortografía 

Re: [OSM-talk-fr] Histoire de déchets / code SINOE

[Philippe Verdy]

Les données soumises à redevance et protégées par un copyright (même si
elles sont "publiques") ne devraient pas être sur l'opendata public.

On se demande alors pourquoi ces données ont été acceptées et publiées sans
licence sur le site opendata gouvernemental.

Ce serait bien d'en aviser le site pour qu'éventuellement il retire la
référence litigieuse. alors que les données ne sont pas vraiment "open". Il
s'agit peut-être d'un oubli de l'ADEME quand il a posté son fichier: il n'a
pas bien complété ses infos de profil, les réferences sont incomplètes. En
avertissant le site, au moins il passera en revue les données et demandera
des précisions à son auteur pour que soit il retire le fichier, soit il
complète sa licence et la fiche de métadonnées, dans un délai raisonnable.

On voit donc que les publications récentes sur l'opendata public sont à
utiliser avec précaution et demandent à être vérifiées, ne pas se
précipiter dessus. Ce n'est pas parce qu'on peut les visualiser (pour un
usage privé) qu'on peut les utiliser dans une oeuvre collective destinée à
être republiée comme OSM, qui lui ne pourra payer aucune redevance à divers
tiers, ou ne le fera qu'avec un financement décidé et approuvé par la
Fondation pour acquérir une licence ouverte utilisable :

Un auteur devra alors renoncer à ses redevances car nous ne pouvons pas
limiter les réutilisateurs des données republiées par OSM, même pour les
usages commerciaux ; en revanche il peut ouvrir ses données à une date
donnée et conserver la main mises sur les mises à jour dans sa propre base
protégée, et décider ensuite quand les republier en usage "open", et il
peut décider de limiter la précision des données ouvertes, quitte pour lui
à devoir gérer deux bases de travail séparées (pour gérer en interne ses
imports de l'une vers l'autre destinée à la republication "open", par
exemple une fois par an ou lorsque la loi ou le contrat/mandat qui le lit à
la collectivité lui demande de fournir des données à jour dans un délai
raisonnable et avec la précision suffisante demandée par la collectivité,
tout en respectant d'autres clauses de droit, comme la protection de la vie
privée, le secret statistique, et d'autre clauses contractuelles du droit
des affaires qui peuvent demander de garder des infos secrètes pendant un
certain temps nécessaire à l'exploitation, la rentabilité des contrats en
cours et rester dans les cadres des budgets alloués qui prévoient des
recettes pour financer les projets d'où seront issues les données
exploitées).


Le 2 février 2016 à 11:47, Christian Quest  a
écrit :

> L'ADEME est un EPIC (établissement public à caractère industriel et
> commercial).
>
> Les données produites par l'ADEME sont donc des informations publiques
> (loi de 78), qui peuvent être soumises à redevances. Encore faut-il
> qu'elles figure sur une liste officielle de 2013...
>
> Ces redevances sont listées ici: https://www.data.gouv.fr/fr/Redevances
>
> Pour le MEDDE, l'ADEME ne figure pas dans la liste, on serait donc dans le
> cadre d'informations publiques, non soumises à redevances, donc librement
> réutilisables... ce que je vais demander à vérifier ce soir.
>
>
>
> Le 2 février 2016 à 09:59, Vincent Bergeot  a écrit :
>
>> Bonjour et merci pour vos retours,
>>
>> Le 01/02/2016 12:09, Jérôme Seigneuret a écrit :
>>
>> La base de données est sous copyright et protéger au titre du Code de la
>> Propriété Intellectuelle. Donc pour l'utilisation du code il va falloir
>> avoir l'accord de l'ADEME il me semble.
>>
>>
>> cela signifie que simplement l'ajout du code SINOE, avec des personnes du
>> syndicat de gestion, est soumis à restriction ?
>> Ok (et encore !!!) pour la base de données de l'ensemble des codes !
>>
>>
>>
>>
>>
>> Il ne risque pas de libérer cette base vu qu'il vendent des prestations
>> (cartes de synthèse et indicateurs statistiques) comme le font les CCI et
>> les Chambres d'Agricultures. Il y a 3 niveaux de licences mais je ne suis
>> pas allé plus loin.
>> La licence fait rire quand on lit la partie responsabilité...
>>
>>
>> oui effectivement cela concerne les volumes de déchets et autres
>> recyclages.
>> Je ne sais pas si la correspondance entre un équipement lié au déchet et
>> son code SINOE soit si sensible que cela !
>>
>>
>>
>>
>> Les références SINOE sont accessibles sur le site mais en recherche par
>> commune.
>>
>> Attention à l'actualisation des données car pour les marchés renouvelés
>> dans l'année 2015/2016 c'est pas vraiment à jour. La dernière mise à jour
>> de la base date 02/2015 et sur Montpellier le marché a été renouvelé au
>> 01/2016.
>>
>>
>>
>> merci pour toutes ces informations,
>>
>> Merci Christian pour la demande au MEDDE.
>> Que signifie sur le site de data.gouv.fr un document sans licence (?)
>> qui fait référence à SINOE justement (
>> https://www.data.gouv.fr/fr/datasets/tableau-de-bord-dechets/) ? L'ADEME
>> a eu envie puis n'a pas voulu mettre de licence ?
>>
>> 

Re: [Talk-it] Incontro con assessore su OpenData

[Lorenzo "Beba" Beltrami]

Mi piace molto la piega che sta prendendo questa discussione.
Siccome ci hanno avvisato (anche se vedrò direttamente lo stato dei lavori
solo il 4) che il portale è già pronto non mi soffermerei tanto sul
software da utilizzare o meno (discussione comunque interessante), ma
appunto su metodologie e qualità.

Quello del cambio di portale è solo un indice di come la voglia politica da
parte dell'amministrazione ci sia.
Quello dell'invito dei cittadini interessati è indice invece di come ci sia
la volontà anche di aprirsi a suggerimenti di appassionati del tema.

Ad esempio trovo interessante il parere di Alessandro sui dati in formati
più o meno accessibili (per accontentare gli smanettoni, ma anche chi
semplicemente sa usare Google Earth come unica risorsa geografica).

Sull'aggiornamento dei dati il problema sta più che altro nel coordinamento
e nella mancanza di uniformità tra i vari fornitori dei dati (uffici
tecnici, municipalizzate, partecipate, ...).

Lorenzo

Il giorno 2 febbraio 2016 11:19, Michele Mondelli 
ha scritto:

> Sono d'accordo con Alessandro, il problema non è fare o meno open data, ma
> farlo bene.
>
> Ho visto portali in cui venivano rilasciati dataset cartografici con il
> solo file .shp (quindi inutilizzabile).
> Inoltre la metadatazione è importante per capire il dato, e poterlo
> utilizzare.
>
> Inoltre utilizzare soluzioni "una tantum", creando un portale con un CMS e
> CKAN, non garantisce un flusso
> di controllo del ciclo di produzione degli open data ed il progressivo
> aggiornamento degli stessi.
>
> Per la mia azienda ho lavorato alla costruzione di un software che
> permette di creare, gestire e pubblicare
> dataset opendata rispettando la normativa vigente e garantendo la qualità
> del dato.
> È possibile anche esportare linked open data tramite server SPARQL.
>
> Riporto alcuni esempi dei portali ai quali abbiamo lavorato:
> - http://www.sitmontevarchi.it/?q=opendata
> - http://opendata.comune.siena.it/
> - http://maps1.ldpgis.it/montemurlo/?q=metarepo
>
> Sono esempi di portali sia grandi che piccoli, in relazione a quanto
> l'amministrazione volesse investire sul progetto.
> Ovviamente c'è tutta la parte di gestionale nel "back-office" che se
> qualcuno è interessato posso mostrarla su
> un ambiente di staging.
>
> ciao,
>
> Il giorno 2 febbraio 2016 10:43, Alessandro Palmas <
> alessandro.pal...@wikimedia.it> ha scritto:
>
>> Il 02/02/2016 10:03, Lorenzo "Beba" Beltrami ha scritto:
>>
>>> Ciao a tutti,
>>> un po' come spinoff della superdiscussione "OpenStreetMap Italia" vorrei
>>> chiedere a chi ha avuto più esperienza con le PA qualche consiglio.
>>>
>>> Nel mio comune (Reggio nell'Emilia) l'interesse e la sensibilità sugli
>>> OpenData c'è. L'assessore ha già convocato qualche tavolo sul tema a cui ho
>>> partecipato in quanto semplice interessato del tema.
>>>
>>> Già il fatto che stiano passando da un sito wordpress (
>>> http://opendata.comune.re.it/) ad un portale CKAN lo trovo un passaggio
>>> interessante, ma non mi accontenterei di questo: avete qualche suggerimento
>>> da darmi a riguardo?
>>> Anche solo qualche link da leggere su standard/direttive (sì, sì, lo so
>>> che gli "standard" sono in realtà milioni...) per indirizzarli nel verso
>>> giusto.
>>>
>>> Scrivetemi pure anche in privato.
>>>
>>
>> L'argomento è interessante, direi di parlarne pubblicamente.
>> Pronto ad attirarmi le critiche di molti, personalmente che sia un
>> wordpress piuttosto che un portale CKAN non mi interessa più di tanto,
>> questo estratto viene da un portale CKAN
>> guidcomunege:b018e8dc-9661-4299-ab59-7cfb78659292
>> harvest_object_id   09e36314-0e07-48a8-bc5a-5a3b19081530
>> harvest_source_id   f69c12e3-c997-4d3d-861f-e6846089b72e
>> harvest_source_titleProduzione
>> licence ["Condizioni sconosciute"]
>> metadata-date   2015-02-02
>> metadata-language   ita
>> progress
>> resource-type   dataset
>>
>>
>> e di questi metadati non so che farmene.
>> Preferirei avere dati aggiornati (a campione ho visto che nella zona del
>> cimitero mancano delle strade) e magari un paio di formati diversi in
>> uscita (le ciclabili sono anche in KMZ oltre che in shape) perchè non tutti
>> sanno come maneggiare gli shapefile.
>> Poi, se le risorse permettono sia di mettere sù il portale che continuare
>> ad alimentarlo con nuovi dataset e tenerli aggiornati allora siamo tutti
>> contenti.
>>
>> Alessandro Ale_Zena_IT
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>
>
>
> --
> *Michele Mondelli*
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-at] Via Ferrata/Klettersteig - Wie richtig taggen?

[Marcus MERIGHI]

b...@volki.at (Friedrich Volkmann), 2016.02.02 (Tue) 11:38 (CET):
> On 02.02.2016 07:43, Thomas Konrad wrote:
> > - Einen eigenen ???highway???-Tag f??r Wege einf??hren, f??r die man
> > ???alle viere??? braucht, also f??r Wege in den Bergen, die nicht
> > nur auf den zwei Beinen begehbar sind (sowas wie highway=steep_path
> > oder highway=mountain_path, besseres Wording anyone?).
> 
> Wenn das so definiert ist, dann scheint mir highway=climbing am sprechendsten.
> 
> Die Grenze l??ge also zwischen uiaa_scale=0 und 1, wobei diese halt
> auch wieder flie??end ist. 

Nein, weil's 0 nicht gibt. 

Wie auch, wird in roemischen Zahlen bezeichnet und da gibt's keine NULL.

Untenstehendes habe ich von der UIAA-webseite (theuiaa.org), allerdings
vor Jahren und jetzt find' ich's dort nicht mehr.


I
Geringe Schwierigkeiten. Einfachste Form der Felskletterei (kein
leichtes Gehgel??nde!). Die H??nde sind zur Unterst??tzung des
Gleichgewichtes erforderlich. Anf??nger m??ssen am Seil gesichert
werden. Schwindelfreiheit bereits erforderlich.

II
M??ssige Schwierigkeiten. Fortbewegung mit einfachen Tritt- und
Griffkombinationen (Drei-Haltepunkte-Technik).

III
Mittlere Schwierigkeiten. Zwischensicherungen an exponierten Stellen
empfehlenswert.  Senkrechte Stellen oder gutgriffige ?berh??nge
verlangen bereits Kraftaufwand.

IV
Grosse Schwierigkeiten. Erhebliche Klettererfahrung notwendig. L??ngere
Kletterstellen erfordern meist mehrere Zwischensicherungen.

V
Sehr grosse Schwierigkeiten. Zunehmende Anzahl der Zwischensicherungen
ist die Regel. Erh??hte Anforderungen an k??rperliche Voraussetzungen,
Klettertechnik und Erfahrung. Lange hochalpine Routen im
Schwierigkeitsgrad V z??hlen bereits zu den ganz grossen Unternehmungen
in den Alpen.

VI
?beraus grosse Schwierigkeiten. Die Kletterei erfordert
??berdurchschnittliches K??nnen und guten Trainingsstand. Grosse
Ausgesetztheit, oft verbunden mit kleinen Standpl??tzen. Passagen dieser
Schwierigkeit k??nnen in der Regel nur bei guten Bedingungen bezwungen
werden. (Manchmal kombiniert mit k??nstlicher Kletterei: A1 bis A4).

VII
Aussergew??hnliche Schwierigkeiten. Ein durch gesteigertes Training und
verbesserte Ausr??stung erreichter Schwierigkeitsgrad. Auch sehr gute
Kletterer ben??tigen ein an die Gesteinsart angepasstes Training, um
Passagen dieser Schwierigkeit sturzfrei zu meistern. Neben akrobatischem
Kletterverm??gen ist das Beherrschen ausgefeilter Sicherungstechnik
unerl??sslich.

VIII, IX, X, XI
Eine verbale Definition ist hier nicht m??glich. Es handelt sich um eine
weitere Steigerung der zu bew??ltigenden Schwierigkeiten, die an das
Kletterk??nnen und die physische wie auch psychische Leistungsf??higkeit
immer h??here Anforderungen stellen.

Die Gradabstufung kann durch die Bezeichnung wie "ausgesetzt", "heikel",
"athletisch" usw. erg??nzt werden. Der erforderliche Kraftaufwand (Grad
der Anstrengung) wird wie folgt umschrieben: wenig anstrengend, ziemlich
anstrengend, anstrengend, sehr anstrengend.


> Wisleitner gibt in seinem Hohe-Wand-F??hrer manchen
> Steigen die Schwierigkeit 0+, denn "es gibt etliche Wege, die kein

Jetzt sagt sicher gleich einer 'aber die ground truth' jaja aber
legitimieren was einzelne Fuehrer-Autoren erfinden?

Pfirt'Eich, Marcus

> Promenieren mehr zulassen, bei denen man aber, wenn man es darauf anlegt,
> mit einigem Geschick noch ohne Gebrauch der H??nde auskommt." In manchen
> F??hrern werden diese Steige mit 1- bewertet.
> 
> Aber das grte Problem mit highway=climbing sehe ich darin, dass es auf
> manchen Steigen nur eine einzelne Kletterstelle gibt (das ist dann die
> Schl??sselstelle). Wenn man den Way aus irgendeinem Grund in mehrere
> Abschnitte zerlegt, stimmt highway=climbing nur noch f??r das kurze St??ckerl
> mit der Schl??sselstelle. Alle anderen Teile muss man auf highway=path
> ??ndern. Dann f??llt das andere Rendering des kurzen St??ckerls in der Karte
> ??berhaupt nicht auf. Damit wird der ganze Zweck des eigenen highway-Tags
> verfehlt.
> 
> > - Via Ferratas bzw. Klettersteige geh??ren aus meiner Sicht als
> > Route (Relation) erfasst und nicht direkt auf den ???way??? getaggt,
> > denn auch Klettersteige k??nnen gew??hnliche Trampelpfade und andere
> > Wegarten beinhalten (muss man nicht z.B. auf dem HTL-Steig auf der
> > hohen Wand zwischendrin einmal kurz auf einen Wanderweg?).
> 
> Der HTL-Steig ist ein schlechtes Beispiel, weil er fast durchgehend mit
> Drahtseil versichert ist. Es ist aber klar, was du meinst.
> 
> Relationen (z.B. route=ferrata) sind vertr??glicher als ein eigenes
> highway-Tag und sicher eine gute Idee, damit man Tags wie operator=* und
> start_date=* nicht auf jedes einzelne Wegst??ck setzen muss. Die meisten
> Klettersteige bis B sind Teil von markierten Wanderrouten (mit dem selben
> Steigerhalter), aber das trifft eben nicht auf alle zu. Und 

[Talk-cz] Dalsi preklady wiki

[Dalibor Jelínek]

Ahoj,

opet s Lukasem prinasime dalsi zajimave preklady wiki. 

Prijemne cteni.

 

Dalibor 

 

http://wiki.openstreetmap.org/wiki/Cs:Key:turn:lanes 

http://wiki.openstreetmap.org/wiki/Cs:Key:destination

http://wiki.openstreetmap.org/wiki/Cs:Key:lit

http://wiki.openstreetmap.org/wiki/Cs:Key:motorroad

http://wiki.openstreetmap.org/wiki/Cs:Key:mtb:description

http://wiki.openstreetmap.org/wiki/Cs:Key:overtaking

http://wiki.openstreetmap.org/wiki/Cs:Key:passing_places 

http://wiki.openstreetmap.org/wiki/Cs:Key:winter_road

http://wiki.openstreetmap.org/wiki/Cs:Tag:highway%3Dbus_stop

http://wiki.openstreetmap.org/wiki/Cs:Tag:highway%3Delevator

http://wiki.openstreetmap.org/wiki/Cs:Tag:highway%3Demergency_access_point

http://wiki.openstreetmap.org/wiki/Cs:Tag:highway%3Dgive_way

http://wiki.openstreetmap.org/wiki/Cs:Tag:emergency%3Dphone

http://wiki.openstreetmap.org/wiki/Cs:Tag:highway%3Dmini_roundabout

http://wiki.openstreetmap.org/wiki/Cs:Tag:highway%3Dpassing_place

http://wiki.openstreetmap.org/wiki/Cs:Tag:highway%3Dturning_circle

http://wiki.openstreetmap.org/wiki/Cs:Tag:highway%3Drest_area

http://wiki.openstreetmap.org/wiki/Cs:Tag:highway%3Dservices

http://wiki.openstreetmap.org/wiki/Cs:Tag:highway%3Dspeed_camera

http://wiki.openstreetmap.org/wiki/Cs:Tag:highway%3Dstreet_lamp

http://wiki.openstreetmap.org/wiki/Cs:Tag:highway%3Dstop

http://wiki.openstreetmap.org/wiki/Cs:Tag:highway%3Dtraffic_signals

http://wiki.openstreetmap.org/wiki/Cs:Key:parking:lane

 

 

 

 

 

 

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

Re: [Talk-it] Incontro con assessore su OpenData

[Michele Mondelli]

Secondo me il punto è proprio il software, per un motivo molto semplice.

Gli opendata non sono un compito specifico di una persona, e nemmeno di un
ufficio in particolare.
L'apertura ed il rilascio dei dati è un processo che coinvolge tutta
l'amministrazione.
Non è pensabile di formare tutto il personale di un ente a capire che cos'è
un dato geografico,
quali sono i formati aperti, come convertire i dati che si hanno, e così
via.
Allo stesso modo non è pensabile che tutti sappiano qualli sono i metadati
obbligatori,
come devono essere compilati, come devono essere distribuiti, e via dicendo.

Ogni ufficio o sezione dell'amministrazione ha la "conoscenza" del dato;
deve
essere il software a guidare l'utente lungo il percorso di produzione del
dato aperto,
senza che lo stesso debba preoccuparsi di sapere come si converte uno
shapefile
in un KML, o se la metadatazione del databaset per l'RNDT sia stata
prodotta
correttamente o meno.

È impensabile aspettarsi che le amministrazioni rilascino dati fatti bene
se non gli
si fornisce degli strumenti che gli permettano di svolgere questo lavoro
senza dover
diventare esperti del settore.



Il giorno 2 febbraio 2016 12:08, Lorenzo "Beba" Beltrami <
lorenzo.b...@gmail.com> ha scritto:

> Mi piace molto la piega che sta prendendo questa discussione.
> Siccome ci hanno avvisato (anche se vedrò direttamente lo stato dei lavori
> solo il 4) che il portale è già pronto non mi soffermerei tanto sul
> software da utilizzare o meno (discussione comunque interessante), ma
> appunto su metodologie e qualità.
>
> Quello del cambio di portale è solo un indice di come la voglia politica
> da parte dell'amministrazione ci sia.
> Quello dell'invito dei cittadini interessati è indice invece di come ci
> sia la volontà anche di aprirsi a suggerimenti di appassionati del tema.
>
> Ad esempio trovo interessante il parere di Alessandro sui dati in formati
> più o meno accessibili (per accontentare gli smanettoni, ma anche chi
> semplicemente sa usare Google Earth come unica risorsa geografica).
>
> Sull'aggiornamento dei dati il problema sta più che altro nel
> coordinamento e nella mancanza di uniformità tra i vari fornitori dei dati
> (uffici tecnici, municipalizzate, partecipate, ...).
>
> Lorenzo
>
> Il giorno 2 febbraio 2016 11:19, Michele Mondelli 
> ha scritto:
>
>> Sono d'accordo con Alessandro, il problema non è fare o meno open data,
>> ma farlo bene.
>>
>> Ho visto portali in cui venivano rilasciati dataset cartografici con il
>> solo file .shp (quindi inutilizzabile).
>> Inoltre la metadatazione è importante per capire il dato, e poterlo
>> utilizzare.
>>
>> Inoltre utilizzare soluzioni "una tantum", creando un portale con un CMS
>> e CKAN, non garantisce un flusso
>> di controllo del ciclo di produzione degli open data ed il progressivo
>> aggiornamento degli stessi.
>>
>> Per la mia azienda ho lavorato alla costruzione di un software che
>> permette di creare, gestire e pubblicare
>> dataset opendata rispettando la normativa vigente e garantendo la qualità
>> del dato.
>> È possibile anche esportare linked open data tramite server SPARQL.
>>
>> Riporto alcuni esempi dei portali ai quali abbiamo lavorato:
>> - http://www.sitmontevarchi.it/?q=opendata
>> - http://opendata.comune.siena.it/
>> - http://maps1.ldpgis.it/montemurlo/?q=metarepo
>>
>> Sono esempi di portali sia grandi che piccoli, in relazione a quanto
>> l'amministrazione volesse investire sul progetto.
>> Ovviamente c'è tutta la parte di gestionale nel "back-office" che se
>> qualcuno è interessato posso mostrarla su
>> un ambiente di staging.
>>
>> ciao,
>>
>> Il giorno 2 febbraio 2016 10:43, Alessandro Palmas <
>> alessandro.pal...@wikimedia.it> ha scritto:
>>
>>> Il 02/02/2016 10:03, Lorenzo "Beba" Beltrami ha scritto:
>>>
 Ciao a tutti,
 un po' come spinoff della superdiscussione "OpenStreetMap Italia"
 vorrei chiedere a chi ha avuto più esperienza con le PA qualche consiglio.

 Nel mio comune (Reggio nell'Emilia) l'interesse e la sensibilità sugli
 OpenData c'è. L'assessore ha già convocato qualche tavolo sul tema a cui ho
 partecipato in quanto semplice interessato del tema.

 Già il fatto che stiano passando da un sito wordpress (
 http://opendata.comune.re.it/) ad un portale CKAN lo trovo un
 passaggio interessante, ma non mi accontenterei di questo: avete qualche
 suggerimento da darmi a riguardo?
 Anche solo qualche link da leggere su standard/direttive (sì, sì, lo so
 che gli "standard" sono in realtà milioni...) per indirizzarli nel verso
 giusto.

 Scrivetemi pure anche in privato.

>>>
>>> L'argomento è interessante, direi di parlarne pubblicamente.
>>> Pronto ad attirarmi le critiche di molti, personalmente che sia un
>>> wordpress piuttosto che un portale CKAN non mi interessa più di tanto,
>>> questo estratto viene da un portale CKAN
>>> guidcomunege:b018e8dc-9661-4299-ab59-7cfb78659292
>>> 

[OSM-ja] Google Map 利用規約更新

[yasunari]

京都の山下です。
みなさんこんにちわ。
もうどこかで話題になったかもしれませんが。。。

Google Map の利用規約が 2015 年 12 月 17 日 に更新されています。
http://www.google.co.jp/intl/ja/help/terms_maps.html

もし可能なら、専門家の方に
・二次著作物の作成の可否
・再配布の可否
等、コメントいただけるとありがたく思います。


さて、
以前、確か 15/12/12 に確認したときは、うろ覚えながら
2. が「使用の制限」で
（a）派生物作成禁止
（b）再配布禁止
が規定されていました。

今日見ると
2. が「禁止行為」に変わっていて
a. には再配布禁止の旨はあるものの
以前のような派生物作成禁止の記述が見当たりません。

1.ライセンス には
c. 適切な所有権を持つコンテンツのオンライン、動画形式、印刷形式における公開表示
がライセンスされるとの記述もあります。つまり印刷して公開してよいと。

d.Google マップ、Google Earth、ストリートビューの使用許諾ページに記述されている行為。
が記述されている
Google 使用許諾　Google マップ、Google Earth、ストリートビュー
https://www.google.co.jp/intl/ja/permissions/geoguidelines.html
を見ると

これまで特別な許諾なしに印刷して配布はダメだと思っていたのですが、
「Google の地図を印刷物で使いたいのですが、何を調べればよいでしょうか？」
のところには、
フェアユース（これがまたややこしい）であれば配布可能とか


プレゼン／文書に使うのは二次著作物になるのでダメだと思っていたのですが、
「Google の地図をプレゼンテーションに使いたいのですが、可能ですか？」
のところには
「Google の地図は、社内用のレポート、プレゼンテーション、提案書、
その他の業務用文書にお使いいただけます」との記述も。


もう少し読み込んでみますが、
これまでの認識と、マッピングパーティでいつも使っている説明資料とを
改めないといけないように思います。
そして OSM のアドバンテージが少し減ったようにも

以上、首記の通り、専門家の方のコメントをいただけますと幸いです。
よろしくお願いします。
--
山下康成＠京都府向日市

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

[OSM-talk-fr] Rapprochement BANO dans L'île de Saint-Martin

[Cactusbone]

L'île de Saint-Martin est un territoire français ne contenant pas de commune 
( https://fr.wikipedia.org/wiki/Saint-Martin_%28Antilles_fran%C3%A7aises%29
) 
taggé admin_level 3 dans osm

dans bano on a des adresses dans le CSV, mais aucune n'est rapprochée 
http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#14/18.0743/-63.0576

par exemple , 
15 rue du Général De Gaule, 97150 Saint-Martin est bien dans le CSV, 
la rue existe aussi dans OSM ( https://www.openstreetmap.org/way/27614897 )
mais aucun rapprochement n'est fait.

Je pense que c'est lié a l'absence de ville/commune coté osm



--
View this message in context: 
http://gis.19327.n5.nabble.com/Rapprochement-BANO-dans-L-ile-de-Saint-Martin-tp5866521.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Rapprochement BANO dans L'île de Saint-Martin

[Ludovic Hirlimann]

So tu ajoute me tag ref:FR:FANTOIR. Ca change quelque chose ?
Le 2 févr. 2016 14:41, "Cactusbone"  a écrit :

> L'île de Saint-Martin est un territoire français ne contenant pas de
> commune
> (
> https://fr.wikipedia.org/wiki/Saint-Martin_%28Antilles_fran%C3%A7aises%29
> )
> taggé admin_level 3 dans osm
>
> dans bano on a des adresses dans le CSV, mais aucune n'est rapprochée
> http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#14/18.0743/-63.0576
>
> par exemple ,
> 15 rue du Général De Gaule, 97150 Saint-Martin est bien dans le CSV,
> la rue existe aussi dans OSM ( https://www.openstreetmap.org/way/27614897
> )
> mais aucun rapprochement n'est fait.
>
> Je pense que c'est lié a l'absence de ville/commune coté osm
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Rapprochement-BANO-dans-L-ile-de-Saint-Martin-tp5866521.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] openstreetmap et les abeilles

[Adrien Grellier]

Bonjour,

Je m'étonne qu'il n'y ait que très peu de choses sur le wiki d'OpenStreetMap 
concernant l'apiculture. En effet, à par un « craft = beekeeper », je n'ai 
pas trouvé grand chose.

Ais-je mal cherché ? Ou bien il n'y a vraiment rien sur ce domaine dans OSM 
?

Au départ je suis arrivé sur ce constat en voulant ajouter un magasin qui 
vend du matériel apicole, mais je n'ai trouvé aucun tag. 

Bonne soirée

Adrien


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

[talk-ph] Forest landcover

[David Groom]

Hi

Firstly let me introduce myself, I'm based in the UK.  I've been involed 
with OSM pretty much from the start, (I attended the first ever mapping 
party), was responsible for a large part of the original worldwide 
coastline import,  spent a lot of time fixing coastline errors, did most 
of the original mapping of Baghdad from Bing & Yahoo imagery, and have 
done of lot of other mappng from imagery worldwide, as well as mapping 
from my own GPX tracks here in th UK and wherever I vacation.


I have recently started mapping parts of Leyte. Initially focusing on 
some of the smaller scale mapping ( tracing builings etc) .


I then noticed that some areas of coastline on the west of the island 
needed updating from imagery since it had the typical "saw-tooth" effect 
resulting from imports of coastline data. so have been working on that.  
I'm not finished yet!


Anyway, the purpose of my post to the list is to ask about landuse = 
forest areas.  If you look at the central part of Leyte some large areas 
have been mapped and tagged for the forest, but :


(1) these seem to have arbitary boundaries (long strainght lines where 
the areas simply have not been accuarely mapped to any natural feature)


(2) The areas so far mapped with tree cover (either "natural = wood", or 
"landuse = forest" represent a smnall proportion of the actual forest 
cover on the island.


My question is, is it OK if as I map other things I extend the tree 
cover areas .  This may result in a large part of Leyte "turning green" 
on the map.


Regards

David Groom

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

Re: [OSM-talk-fr] Fond OSM dans des guides de rando du CD63 ?

[JB]

Bonjour,
Une très bonne nouvelle !
Je me souviens d'une longue discussion que j'avais eue l'été 2014 avec 
un gars bien informé de l'office de tourisme à Clermont-Ferrand. Je 
pensais en avoir fait un compte-rendu, mais je n'arrive pas à en 
retrouver de trace. C'était à l'époque du deuxième topoguide®, on avait 
notamment parlé de FFRP, IGN, carte IGN, et un peu OpenStreetMap. 
J'avais par hasard avec moi la carte que j'avais sortie pour le tour de 
la chaine des Puys.

Ceci dit :
 - est-ce qu'il serait possible de connaitre les circuits pressentis 
pour le prochain guide, histoire de contribuer au meilleur endroit ?
 - s'il y en a un du coté du col du Béal, je veux bien aller faire une 
sortie par là-bas (je suis de l'autre coté du col, chez les Rhône-Alpiens…)
 - les traces gps fournies sont de qualité… moyenne, à ne pas 
privilégier sur d'autres sources, ou à moyenner avec d'autres traces 
(j'ai contribué dans la zone, et en comparant certaines dont je pense la 
précision correcte, celles fournies restent moyennes). En tous cas, ne 
pas supprimer la donnée OSM pour la remplacer par cette donnée qui 
serait « de référence ».
 - si R25 est pressenti pour le rendu, je veux bien y passer un peu de 
temps. Quand la donnée est bonne, la génération de carte est rapide 
(quand on a l'habitude, en tous cas). On est dans la zone là, tiens : 
http://jb.isonoe.net/CR/demo/Volcans_A5_d%C3%A9mo.pdf
(et puis enfin surimprimer la trace gps de manière semi-transparente, et 
arrêter de cacher ce qu'il y a dessous !)
Voilà voilà, ce serait vraiment chouette que ça aboutisse… probablement 
plus de chances que dans ma zone, ou le topoguide® est en réfection…

JB.

Le 02/02/2016 11:52, Landry Breuil a écrit :

Hello,

le conseil départemental du Puy-de-Dôme envisage d'utiliser des fonds
OSM pour l'édition de son prochain guide papier/pdf de randonnées
suivant les PDIPR - ces guides utilisaient jusqu'ici le fond scan 25
de l'IGN (que le CRAIG fournit au CD63), mais a priori (?) les
conditions de licence ne le permettent plus de la même manière, donc
pour des questions de coût le service SIG s'oriente potentiellement
vers un fond OSM.

Cf 
http://www.planetepuydedome.com/destination-volcans/tout-le-puy-de-dome/le-puy-de-dome-terre-de-randonnee-au-coeur-des-volcans/randonnez-vous-661-1.html,
http://www.planetepuydedome.com/destination-volcans/tout-le-puy-de-dome/le-puy-de-dome-terre-de-randonnee-au-coeur-des-volcans/randos-a-croquer-662-1.html
et http://www.planetepuydedome.com/brochures-688-1.html pour les
précedentes éditions. Oui, y'a du google maps sur les versions web des
itinéraires, mais du scan 25 dans la version pdf/papier.

Après en avoir discuté avec Guillaume Tournadre (du service SIG) qui
trouvait que les données OSM étaient un peu pauvres sur les zones
concernées (les PDIPR), je lui ai proposé de faire appel à la
communauté pour enclencher le cercle vertueux de -> les itinéraires
sont la -> on améliore les données -> le fond devient plus riche ->
tout le monde en bénéficie!

Dans tout les cas, les itinéraires des PDIPR sont disponibles en ligne
chez nous: 
http://ids.craig.fr/geocat/apps/search/?uuid=3bd16d2d-5fc7-4816-b824-c274603cfd16

Les données ne sont pas en opendata (pas encore, mais guillaume y
travaille!) mais rien n'empèche (ou plutôt, on a l'accord) de les
utiliser pour connaitre les zones à améliorer/cartographier

Ca ne sera peut-être pas pour cette édition because timing serré...
mais ca ne sera jamais perdu!

Guillaume est en copie de ce mail, vous pouvez le contacter pour plus
d'informations.

Landry

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


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

Re: [Talk-at] Via Ferrata/Klettersteig - Wie richtig taggen?

[Richard]

On Tue, Feb 02, 2016 at 07:43:20AM +0100, Thomas Konrad wrote:
> Hallo,
> 
> aus meiner Sicht wäre folgendes am saubersten:
> 
> - Einen eigenen “highway”-Tag für Wege einführen, für die man “alle viere” 
> braucht, also für Wege in den Bergen, die nicht nur auf den zwei Beinen 
> begehbar sind (sowas wie highway=steep_path oder highway=mountain_path, 
> besseres Wording anyone?). Das ist aus meiner Sicht 1.) ein *halbwegs* 
> eindeutiges Kriterium und im Sinne der Datennutzung “Renderer” würde das 
> bedeuten, man muss nicht “SELECT * FROM planet_osm_ways WHERE highway=‘path’ 
> and ‘sac_scale’ = null and ‘via_ferrata_scale’ = null and 
> ‘was_weiss_ich_scale’ = null” machen, sondern einfach SELECT * FROM 
> planet_osm_ways WHERE highway=’steep_path’”. Solche “paths” könnte man dann 
> z.B. etwas transparenter rendern, dann ist eher sichtbar dass er nicht für 
> jeden begehbar ist. Für den Import-Stil (Stichwort defaul.style) müsste man 
> dann auch nicht all diese Skala-Spalten importieren, was ja sonst die 
> Datenbank schon ziemlich aufblasen würde.
> 
> - Via Ferratas bzw. Klettersteige gehören aus meiner Sicht als Route 
> (Relation) erfasst und nicht direkt auf den “way” getaggt, denn auch 
> Klettersteige können gewöhnliche Trampelpfade und andere Wegarten beinhalten 
> (muss man nicht z.B. auf dem HTL-Steig auf der hohen Wand zwischendrin einmal 
> kurz auf einen Wanderweg?). Ist ja auch bei MTB-Routen so - da fährt man ja 
> auch mal ein paar Meter auf einer Bundesstraße um in den nächsten Wald zu 
> kommen. MTB-Routen sind richtigerweise als Relation erfasst. Eine Karte, die 
> Klettersteige rendern möchte, kann dann einfach die Relationen auswerten.

hat bestimmt Voreile, nur die Einführung von highway=steep_path sehe ich nicht 
so einfach, da hat man die ganzen Probleme mit der Abgrenzung evtl noch 
schlimmer.

Es gibt schon mal einen Versuch in ähnliche Richtung
  http://wiki.openstreetmap.org/wiki/Proposed_features/Trail_%28new_proposal%29



Richard

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

[Talk-gb-westmidlands] OSM & Wikidata, down under in Australia & Indonesia

[Andy Mabbett]

[cross-posted]

I'll be waving the Mappa Mercia flag and giving another talk about OSM
& Wikidata soon - in Jakarta, Indonesia!

It's part of a speaking tour of Australia and Indonesia:

   https://wikimedia.org.au/wiki/Wikidata_Tour_Down_Under

   http://wikimedia.or.id/wiki/Wikidata_and_Pywikibot_Training

mostly talking about Wikidata (I'll mention OSM in all my talks, but
the Jakarta talk is specifically on that topic).

Most of the talks are open to the public, and there are also social
meetups, so please notify any OSM, Wikimedian, GLAM or Open Data
contacts you have in those countries.

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

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

Re: [OSM-talk-ie] New GitHub Repository for OpenStreetMap Ireland code

[Brian O'Hare]

Hi Rory,

I'd like to be added to the osmie org on github.

https://github.com/bjohare

many thanks,

Brian.

On 2 February 2016 at 15:19, Rory McCann  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi all,
>
> OSM is a mapping project, but sometimes people write software to do
> stuff with OSM. www.townlands.ie is one example of this. And that code
> (like much in OSM) is open source, and I use Github, since it's so
> popular for open source.
>
> So I set up a Github organization for us! Here:
> https://github.com/osmie If you're a Github user, feel free to join
> (on-line, or contact me and I can add you). I've already transferred
> the townlands.ie source code there. Feel free to transfer any other
> projects on github there.
>
>
> Happy mapping and hacking,K
>
> Rory
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQEcBAEBAgAGBQJWsMkJAAoJEOrWdmeZivv28acH/RjV6Ax2Gz6gzO6SQqAM8/vI
> vN6bHFe1O7ampH4N5ZW7eEfggge77SWzD9u90VP38gBXD7W2lqyfipAdrCm6V0Vz
> g7AlOZb0AkJNH8vKVzPNOqWmiKlHjWZi08abkoIG7vuq84D2q+jJP699Fo1+pYAG
> faGanq+7BnhMKRfcmMYv+rqiByjdiz6z5BwqC9NCpwwW6gpic2AH6I8g3pUyw4an
> NQ2eNWG+b8t1KVUWf+LvjIFi9uvTo4x3VEe644GG/ygDxkIQTPlBjhA3P5r2N5hL
> zbJ8CVJ0I3rdCrsFV/Gb2RpAYLmTV7AuPbT0fbL2A3wgMinqMIXtfZmSm+YguwI=
> =oIXW
> -END PGP SIGNATURE-
>
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie
>
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-it] Incontro con assessore su OpenData

[Maurizio Napolitano]

Ciao Lorenzo
sul tema potrei parlare per giornate intere visto che si tratta del mio
lavoro affrontato a più livelli (es. l'istituzione per cui lavoro è nodo
dell'Open Data Institute inglese - http://trento.theodi.org )
Cercando di sintetizzare vado per punti (riportando anche alcune cose che
ho scritto)

- Reggio Emilia
il tema mi interessa parecchio anche perchè faccio parte del comitato
scientifico dell'agenda digitale dell'Emilia Romagna.
Il primo consiglio è quello di investire molto nel dialogo con
l'amministrazione regionale
http://dati.emilia-romagna.it/
in particolare nel legame con il progetto ADER - Agenda Digitale Emilia
Romagna

- open data è prima di tutto processi
aprire dati vuol dire impattare sui processi organizzativi, questo non va
assolutamente dimenticato.
L'apertura dei dati deve essere, prima di tutto, guidata dalla opportunità
di offrire un vantaggio.
Credo fortemente che le parole chiave siano: crescità, riuso e
sostenibilità.
crescita => si tratta di una operazione di miglioramento del processo di
produzione
riuso => il tema del riuso (inteso nei formati, nei vocabolari condivisi e
nella metadatazione) deve essere cruciale
sostenibilità => i processi che si creano devono essere guidati fortemente
dalla sostenibilità nel tempo, altrimenti rimangono cattedrali nel deserto.
Ne parlo qui
http://www.forumpa.it/dati-riuso-sostenibilita-e-crescita-tre-parole-chiave-per-cogliere-lopportunita-degli-open-data
e consiglio anche di dare una occhiata a questa formula
http://de.straba.us/2015/02/18/un_calcolo_per_lopendata/
che aiuta a guidare una strategia di apertura

Rimando infine a questo lavoro di Luca Corsato, Andrea Raimondi e Simone
Cortesi
https://medium.com/@lucacorsato/masterplan-aeb009ca8afd#.415zfh5xh
che parla proprio del tema dei processi

- piattaforma di pubblicazione dei dati
l'argomento è molto delicato.
Partiamo dalla piattaforma di pubblicazione dei dati.
È importante usarne una che si colleghi a standard internazionali per
quello che riguarda la metadatazione dei cataloghi.
Il vocabolario di riferimento è DCAT.
Al momento AgID ha aperto una consultazione su DCAT-AP, ovvero una
estensione di DCAT
http://www.dati.gov.it/consultazione/dcat-ap_it
Avere una metadatazione dei cataloghi condivisa permette un bel salto di
qualità.
CKAN si o no? Io sono per CKAN, ,ma non sto qui a dilungare, quello che
ritengo più
importante in assoluto è avviare dei processi di sostenibilità nella
pubblicazione in modo che i metadati del dataset siano allineati con il
dataset stesso (in ckan si parla di harvesting).

- formati e vocabolari
siamo pieni di formati senza metadati e vocabolari e di formati in grado di
unire queste caratteristiche.
Più il formato è ricco, e meno è ampio il pubblico a cui ci si rivolge ma
più facilmente è trasformabile in un formato che chiunque può usare.
AgID nelle linee guida sul patrimonio informativo pubblico (che consiglio
vivamente di leggere)
http://www.agid.gov.it/sites/default/files/linee_guida/patrimoniopubblicolg2014_v0.7finale.pdf
fa questa distinzione
Qui una slide con lo schema
http://www.slideshare.net/napo/opendata-suggerimenti-per-dati-di-qualit/19
Concordo sul fatto che sia importante offrire più formati
Attenzione al kml (o kmz) è tanto bello quanto sfigato
Sempre nelle linee guida AgID è scritto come dovrebbe essere distribuito
(c'è una carenza sul fronte descrizione dei campi)
Kml piace tanto ma o va distribuito bene o meglio accompagnarlo con altri
formati
Meglio ancora se questi geodati sono serviti da un webservice secondo
standard ogc e si pubblicano i link di come ottenerli convertiti
Se serve giro esempi
Consiglio anche la lettura delle linee guida del Trentino
http://www.provincia.tn.it/progetto_open_data/

- open data e impatto sociale
L'apertura dei dati ottiene maggior effetto se si cerca di arricchirne il
contesto
(vd il capitolo 5 delle linee guida AgID)
Rimando a questa lettura
http://www.chefuturo.it/2012/12/wasted-datafood/

Se non erro la Regione Emilia Romagna sta partendo con dei progetti per la
creazione di laboratori
Potrebbe essere una buona idea proporli all'assessore ruotando poi su
openstreemap come ottimo esempio

- qualità
la qualità dei dati dipende dai processi di creazione e dalla loro
documentazione
Consiglio di provare i certificati open data dell'ODI
http://certificates.theodi.org

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

Re: [Talk-at] Via Ferrata/Klettersteig - Wie richtig taggen?

[Thomas Konrad]

> * Einen ausreichenden Grund für highway=via_ferrata erkenne
> ich nicht

Ich auch nicht.

> * Erkenne gleichzeitig keinen Bedarf für ferrata=yes.

Ich auch nicht. Aber ich wiederhole mich: Klettersteige gehören aus meiner 
Sicht als Relation gemappt, weil nicht von einem einzelnen Wegstück aus gesehen 
gesagt werden kann, ob das ein Klettersteig ist. Ein Klettersteig kann aus 
Klettersteigstücken mit Seil, Felsstücken mit Tritten, steilen Pfaden und 
(zwischendurch auch) einfachen Wanderwegen bestehen. Auch kann er mal aus einem 
Teilstück bestehen das bereits einen Namen hat - was machst du dann? 
Überschreibst du den Namen des bestehenden Wanderweges? Wie findest du die 
einzelnen Teilstücke des Klettersteigs? Genau, über eine Relation.

> * (via_)ferrata_scale gefällt mir, da komplett analog zu
> sac_scale und mit sac_scale gleichzeitig einsetzbar.

Genau.

> * Warum neulich ein highway=climbing überlegt wird
> bleibt für mich rätselhaft, sorry.

Weil es schon Sinn macht. Damit ist für den Datennutzer einfach und ohne 
komplizierte Statements herausfindbar, ob ein Weg begehbar ist oder ob ich 
dafür spezielle Ausrüstung benötige (Klettersteigset, Kletterausrüstung). Mit 
highway=climbing könnte man ganz einfach alle Kletter- und Klettersteigrouten 
z.B. etwas transparenter rendern, damit klar ist, das ist eher nicht ohne 
weiteres begehbar.

> * Die Tatsache, dass Carto/Mapnik zurzeit kein sac_scale
> (und wer weiß was noch) interpretieren kann lässt mich kalt.

Mapnik könnte das schon, Carto wird es wahrscheinlich bewusst nicht tun, weil 
das zu detailliert ist. Außerdem müssten dann für den Renderer alle 
*_scale-Spalten importiert werden. “highway” war immer schon im Import-Style 
(Stichwort default.style in osm2pgsql).

> * Wenn ich eine Garmin-Karte bastle, interpretiere ich z.B.
> die sac_scale und tracktype ohne Probleme

Siehe oben.

LG

> On 03 Feb 2016, at 00:18, Borut Maricic  wrote:
> 
> Ich habe die Urfrage gestellt. Nach diesem langen Thread
> sehe ich das Thema wie folgt (ist bitte kein Fazit,
> sondern meine sehr persönliche Meinung!)...
> 
> * Einen ausreichenden Grund für highway=via_ferrata erkenne
> ich nicht (genauso schwierig kann man ab etwa T4/T5 im
> Gelände einen Pfad erkennen, und trotzdem wird das als
> highway=path+sac_scale=* gemappt).
> 
> * Erkenne gleichzeitig keinen Bedarf für ferrata=yes.
> 
> * (via_)ferrata_scale gefällt mir, da komplett analog zu
> sac_scale und mit sac_scale gleichzeitig einsetzbar. Die
> Möglichkeit des gleichzeitigen Einsatzes mehrerer *_scale
> (wie schall_scale, uiaa_scale, ...) finde ich gut.
> 
> * Warum neulich ein highway=climbing überlegt wird
> bleibt für mich rätselhaft, sorry.
> 
> * Die Tatsache, dass Carto/Mapnik zurzeit kein sac_scale
> (und wer weiß was noch) interpretieren kann lässt mich kalt.
> Wie ich bei der Fragestellung geschrieben habe, es stimmt,
> dass mit highway=path+(via_)ferrata_scale=* die
> Carto/Mapnik-Karten irreführend sind. (Das stimmt aber
> eigentlich auch bei höheren sac_scales.) Lässt mich
> mittlerweile auch kalt.
> 
> * Wenn ich eine Garmin-Karte bastle, interpretiere ich z.B.
> die sac_scale und tracktype ohne Probleme (abgesehen von
> Garmin-Einschränkungen selbst). Ich denke, dass das beim
> Einsatz zusätzlicher *_scale genauso erweiterbar ist. Ein
> Datenverbraucher kann im Prinzip nach belieben priorisieren,
> wie die Scale-Kombinationen darzustellen sind.
> 
> * Ich würde eine Initiative zum Auflisten und Formalisieren
> aller *_scale Tags, die zur Verfügung stehen und
> gleichzeitig eingesetzt werden können, begrüßen
> (http://www.sac-cas.ch/unterwegs/schwierigkeits-skalen.html).
> 
> 
> ___
> 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

[OSM-talk-fr] openstreetmap et les abeilles

[Adrien]

Bonjour,

Merci pour vos réponses.

Je comprend tout à fait les arguments pour ne pas cartographier les 
ruches. Mais voici trois autres choses que j'aimerais cartograhphier sur 
l'apiculture, qui me semble plus consensuelles :


- Les magasins apicoles. Il y a bien les tags shop=apiary ou 
shop=beekeeper, mais il n'ont pas l'air officiel. Dois-je les utiliser, 
ou vaut-il mieux attendre qu'il soit officialisé avant ?


Voici un exemple de magasin apicole : http://www.mat-apiculture.fr/ On 
en trouve quelques uns par département.


- Les ruchers écoles. Il s'agit de rucher spécialement dédiés à 
l'enseignement de l'apiculture, souvent opéré par le syndicat 
d'apiculture local. Pareil, on en compte quelques uns par département, 
et souvent les addresses sont déjà sur internet, pour les stagiaires : 
http://unapla.org/index.php/rucher-ecole/2013-03-22-13-46-23


- enfin les mielleries. Il s'agit de lieu ou on peut extraire le miel de 
ses propres cadres. Exemple de miellerie, toujours en Loire Atlantique : 
http://unapla.org/index.php/miellerie-et-recolte/miellerie


Pour les ruches je suis mitigé. d'un côté il y a effectivement les 
risques de prédation d'essaim et de vols de ruches. Je peux peut-etre me 
renseigner auprès de mon syndicat apicole sur ce sujet.


Dans OpenStreetMap pour l'instant je n'ai fait qu'utiliser des tag déjà 
définis, je ne maîtrise donc pas du tout le process pour la création ou 
la validation de tag. Mais je suis prêt à investir un peu de temps pour 
mieux définir les tag pour l'apiculture, si vous pensez que c'est une 
bonne idée.


Bonne journée

Adrien

PS : Désolé pour le deuxième fil, mon PC a crashé, donc exit l'accès par 
Gmane, je ne suis abonné à la liste.


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

Re: [OSM-talk-fr] openstreetmap et les abeilles

[Jean-Claude Repetto]

Le 02/02/2016 18:07, Adrien Grellier a écrit :

Bonjour,

Je m'étonne qu'il n'y ait que très peu de choses sur le wiki d'OpenStreetMap
concernant l'apiculture. En effet, à par un « craft = beekeeper », je n'ai
pas trouvé grand chose.



Bonjour,

Voir : http://wiki.openstreetmap.org/wiki/Proposed_features/apiary


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

Re: [Talk-it] Incontro con assessore su OpenData

[Luca Delucchi]

2016-02-03 0:37 GMT+01:00 Maurizio Napolitano :

>>
>> Avevo capito che il non era "KMZ è il formato perfetto", ma il mio
>> interessamento era proprio per l'idea di non fossilizzarsi su di un solo
>> formato.
>
> Guarda io preferisco dire "abbasso il kmz" perchè poi finisce che ti
> distribuiscono
> solo quello.
> Tutti felici di vedere i dati su google earth ma se poi vuoi filtrarli
> rispetto ad un
> valore ... ti tocca smazzarti il campo description
>

e supporta una sola proiezione :-o


-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

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

Re: [OSM-ja] Google Map 利用規約更新

[Kazuyoshi KOMINE]

明星大学のこみねです。

On 2016/02/02 22:20, yasun...@yamasita.jp wrote:


さて、
以前、確か 15/12/12 に確認したときは、うろ覚えながら
2. が「使用の制限」で
（a）派生物作成禁止
（b）再配布禁止
が規定されていました。

今日見ると
2. が「禁止行為」に変わっていて
a. には再配布禁止の旨はあるものの
以前のような派生物作成禁止の記述が見当たりません。


a. の２文目「Google マップ / Google Earth に基づいて新しい商品やサービス 
を作成すること（利用規約に従う Google マップ / Google Earth の API 使用 
を除く）」が派生物作成禁止を示しているように思います。


ただ、変更前の「2. 使用の制限: ユーザーは、事前に Google（または場合に 
よっては特定のコンテンツのプロバイダ）から書面による許可を得ることなく、 
次のことを行ってはなりません: （a）コンテンツまたはその一部を複製、翻 
訳、変更、または派生物を作成すること」では『例外なく派生物作成禁止』だっ 
たのが『利用規約に従ってAPIを使用する場合は例外として許可』となったよう 
にみえます。改めて許可したと言うよりは提供実態に規約の文言を合わせたとい 
うことかもしれません。


--
Windows Vistaのメーカサポートは2017年4月で終了します
===
小峰 一純 Kazuyoshi KOMINE
  明星大学 情報システム課
  

教育の明星大学
2014年、大学創立50周年
===

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

Re: [Talk-ca] Talk-ca Digest, Vol 96, Issue 1

[Steve Singer]

On Tue, 2 Feb 2016, Mojgan Jadidi wrote:

Mojgan,

We did say at MappyHour last month that OSM was filled with well intentioned 
imports gone bad. Don't feel bad you seem to be well intentioned and many 
others before you have made mistakes in the import process.


I don't think the advice you got at the meeting was to go rush ahead and 
start importing. I think the advice you received was more along the lines of 
"imports are really hard, getting community consensus is even harder", 
"spend some time understanding how the OSM community works first", "use 
dedicated import accounts attached to individuals not an organization"


Some specific feedback I have on the import

1) I think it is critical that you do the data validation and checking 
*before* uploading to OSM.  This is what I thought you had described but I 
must have misunderstood.  The reason why it is better to do the cleanup 
before uploading the data to OSM is because this way no bad data is sitting 
in OSM until someone gets around to cleaning it up.  The community also 
likes this better because we don't have to worry about if you will ever get 
around to cleaning it up


The flow I would recommend is along the lines
1) Person takes a small area of generated address points
2) They download the current OSM data and check for problems
3) They fix any issues and upload the small area they just checked

The changesets on Monday appeared to be uploading everything first.


2) You should publish your generated files for review(or at least a sample). 
In some areas I spot checked last night I saw nodes with no tags and not 
connected to an interpolation way.  This might have been an artifact of a 
in-progress revert, I'm not sure.


I also saw some places where the existing OSM roads and address 
interpolations were a bit offset from the stuff you uploaded and this 
resulted in duplicate address ways (the existing geometry in OSM might not 
be from a rough survey). Manual cleanup would be required.



3) I am not sure if we need the :source tag on each node or if putting it on 
the changeset would be enough.  Earlier imports tended to put metadata on 
each node but I think we have been trying to move away from this.



Steve



Hi all,Please accept my apology for this misunderstanding, I thought our 
presence for last OSM meeting and
flowing emails in Talk-ca and with John were part of communication and 
discussion, we launched our wikipage
two weeks ago, and we did not receive any feedback, so we thought to start 
import via JOSM. 

as we expalined in our wikipage, we created the algorithm to detect the missing 
information, and then we
check the quality of this information on JOSM on the top of OpenStreetMap, Bing 
Areal imagery, GeoBase Road
network and some local municpal open data. the data is created initially 
through StatCan, however, we noticed
the low quality of StatCan road segment geometry, so we deal with this issue by 
using complement dataset such
as OpenStreetMap, Bing Areal imagery, GeoBase Road network and some local 
municpal open data. all created
nodes and ways are carefully inspected visually using above dataset for more 
that 6 weeks. 

Our final verification will be on the OSM server (on-line) to avoid or detect 
any issues. Our aim is having
high quality address information in OSM for sake of community. we were very 
prudent from the first step to
have a high quality source of information. 

I hope that the community will accept our contribution and enjoy to use the 
data.

Best regards,

Mojgan  
  

Mojgan (Amaneh) Jadidi, Ph.D.
Postdoctoral Research Fellow
GeoICT Lab
York University
Toronto

ca.linkedin.com/pub/mojgan-amaneh-jadidi/10/825/969/

On 2 February 2016 at 07:00,  wrote:
  Send Talk-ca mailing list submissions to
          talk-ca@openstreetmap.org

  To subscribe or unsubscribe via the World Wide Web, visit
          https://lists.openstreetmap.org/listinfo/talk-ca
  or, via email, send a message with subject or body 'help' to
          talk-ca-requ...@openstreetmap.org

  You can reach the person managing the list at
          talk-ca-ow...@openstreetmap.org

  When replying, please edit your Subject line so it is more specific
  than "Re: Contents of Talk-ca digest..."


  Today's Topics:

     1. Triplinx import (Stewart Russell)
     2. Re: Triplinx import (john whelan)
     3. Re: Triplinx import (Stewart Russell)


  --

  Message: 1
  Date: Mon, 1 Feb 2016 18:36:01 -0500
  From: Stewart Russell 
  To: talk-ca 
  Subject: [Talk-ca] Triplinx import
  Message-ID:
          

Re: [OSM-ja] 日本地域の課題一覧 on Github Issue

[Satoshi IIDA]

いいだです。

おかげさまで多くのかたに参加をいただいていて、
いくつかのIssueで議論が進んでいます。
（例えば、Nominatimの検索結果の話やWeeklyOSMの翻訳の話など）

https://github.com/osmfj/osm_japan_issues/issues

新しいツールだから良い、というわけではもちろんなくて、
ふだん考えていることが表に出てきて、議論ができることがよいことだと思っています。

ちいさなことで構いませんので、
みんなで気づいたことを分けあって、OSMをよりよくできたらよいな、と思います。

歩きましょう！ :)




2016年1月29日 11:43 Satoshi IIDA :

>
> いいだです。
>
> 「日本地域でのデータ品質とか、課題の一覧ってあるの？」という質問が以前ありましたが、
> 試験的に、思いつく課題をGithubにあげてみています。
>
> https://github.com/osmfj/osm_japan_issues/issues
>
> OSM本体に限らず、OSM wikiや日本独自のタグ定義の不足、
> 森林などの大規模データ欠損の対応、
> 不明なインポートの状況調査なども、
> 課題としてあげておけば対応がしやすいかな、と思っています。
> （GithubのIssueにはラベル付けの機能があるので、ある程度数が揃ってきたらラベルをつけてゆきたいと思います）
>
> Issueの追加は誰でも可能ですので、
> 気がついたことなどあれば是非追加ください。
>
> この機能、本来はバグ報告などで使われるものなので
> 事象の再現方法とかをちゃんと書く必要があるの？とか気になるかたもいると思うのですが、
> Githubのgitの機能はまったく使っていませんし、
> 単なる日本語の掲示板としてみるのがよいかなー、と思っています。
>
>
> よろしければご参加くださいませませ (/･ω･)/
>
>
> --
> Satoshi IIDA
> mail: nyamp...@gmail.com
> twitter: @nyampire
>



-- 
Satoshi IIDA
mail: nyamp...@gmail.com
twitter: @nyampire
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [Talk-de] Deutscehr tileserver

[Sven Geggus]

gmbo  wrote:

> Welche Voraussetzungen müsste ich außer Zeit dafür haben, um dich dabei 
> zu unterstützen.

Anfangen sollte man damit am besten bei einem Treffen IRL. Hack Weekend
wäre eine güntige Gelgenheit. Beim nächsten mal in der Geofabrik habe ich
leider keine Zeit.

Nice to have wäre eine Installation von Mapnik und Postgis auf Deinem
eigenen Rechner.

Ich stelle mir das so vor, dass man bestimmte Aspekte des deutschen
Kartenstils als Patchset für den internationalen Stil pflegt.

Gruss

Sven

-- 
"Those who do not understand Unix are condemned to reinvent it, poorly"
(Henry Spencer)

/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Talk-ca] Triplinx import

[Stewart C. Russell]

Okay, so it looks like Paul Norman has started a revert through the DWG.
Thanks!

The thing is, the data did greatly improve addressing in Toronto. In the
areas I looked at, there was careful in-fill with no overlap in address
nodes/ranges.

My only real annoyance about this import was that it was done without
any consultation. For many places in the GTHA, it contributed to making
the map better, but we weren't given the chance to ask questions.

John wrote:
> I think a better solution would be to take a copy of the OSM
> database, strip out the existing address data and drop in the stats
> data and use the copy for their purposes.

I don't think they can do that. They'd then be serving a mix of OSM and
their data to the public without providing it to OSM.

cheers,
 Stewart

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

Re: [Talk-at] Via Ferrata/Klettersteig - Wie richtig taggen?

[Robert Kaiser]

Friedrich Volkmann schrieb:

Wenn das so definiert ist, dann scheint mir highway=climbing am sprechendsten.


+1


Aber das größte Problem mit highway=climbing sehe ich darin, dass es auf
manchen Steigen nur eine einzelne Kletterstelle gibt (das ist dann die
Schlüsselstelle). Wenn man den Way aus irgendeinem Grund in mehrere
Abschnitte zerlegt, stimmt highway=climbing nur noch für das kurze Stückerl
mit der Schlüsselstelle. Alle anderen Teile muss man auf highway=path
ändern. Dann fällt das andere Rendering des kurzen Stückerls in der Karte
überhaupt nicht auf. Damit wird der ganze Zweck des eigenen highway-Tags
verfehlt.


Im Gegenteil. highway=stairs oder highway=primary_link sind auch nur 
kurze Stücke, haben aber durchaus Aussage. Und gerade mit "stairs" wäre 
dieses "climbing" gut vergleichbar. Wir sollten mappen, was wirklich da 
ist - ein Wegstück, das in allen Sichtweisen ein normal gehbarerer Pfad 
ist, sollte ein highway=path sein, auch wenn es nur über andere 
Wegstücke erreichbar ist, die highway=climbing sind - denn das ist, was 
auch wirklich beschreibt, was dort vorhanden ist.


Und auf einer spezifischen Wanderkarte kann man die Relations für z.B. 
route-ferrata ja zusätzlich farbig unterlegen oder sowas.


KaiRo


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

Re: [OSM-talk-be] [Talk-sn] Lancement Site Officiel OSM Du Mali

[Nathalie SIDIBE]

Merci beaucoup, Lamine ! OSM_ML a besoin et compte sur l'accompagnement de
vous tous pour réussir ses entreprises.

Excellente journée à tout le monde !

Nathalie,
Le 2 févr. 2016 12:08 PM, "mohamet lamine Ndiaye"  a
écrit :

> Bonjour,
> Félicitation à la communauté malienne qui monte en puissance au sein de
> OSM avec la mise en plan d'une série d'actions visant à vulgariser et
> dynamiser le Groupe. Courage et bonne continuation pour la réussite de vos
> entreprises.
>
>
> Le 1 février 2016 à 18:10, Nathalie SIDIBE  a
> écrit :
>
>>
>> Bonjour à tous et à toutes !
>>
>> La communauté Openstreetmap du Mali est heureuse de vous faire part  du
>> lancement de son sit officiel, ce lundi matin et vous demande de la suivre
>> dorénavant sur :
>> www.openstreetmapmali.org  #Map4ML
>> #ProjetEOF
>> 
>>  #Bamako  #OpenData
>> #OIF
>>  #DFN
>> 
>>
>>
>> Cordialement,
>>
>> Nathalie,
>>
>>
>>
>>
>>
>>
>> ___
>> Talk-sn mailing list
>> talk...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-sn
>>
>>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

[Talk-it-trentino] R: malghe

[Giorgio Zampedri]

Segnalo questo link dove si possono trovare delle info utili sulle malghe del 
Trentino.
L'aggiornamento dei dati del sito è da verificare !!!

http://www.trentinointavola.it/it/malghe/index.php

Ciao, Giorgio



Messaggio originale

Da: dario.zont...@gmail.com

Data: 2-feb-2016 13.00

A: 

Ogg: [Talk-it-trentino] malghe



BLOCKQUOTE.cite {
PADDING-LEFT: 10px; MARGIN-LEFT: 5px; BORDER-LEFT: #cc 1px solid; 
PADDING-RIGHT: 0px; MARGIN-RIGHT: 0px
}
BLOCKQUOTE.cite2 {
PADDING-TOP: 0px; PADDING-LEFT: 10px; MARGIN-LEFT: 5px; BORDER-LEFT: 
#cc 1px solid; MARGIN-TOP: 3px; PADDING-RIGHT: 0px; MARGIN-RIGHT: 0px
}
.plain PRE {
FONT-SIZE: 100%; FONT-FAMILY: monospace; FONT-WEIGHT: normal; 
FONT-STYLE: normal
}
.plain TT {
FONT-SIZE: 100%; FONT-FAMILY: monospace; FONT-WEIGHT: normal; 
FONT-STYLE: normal
}
A IMG {
BORDER-TOP: 0px; BORDER-RIGHT: 0px; BORDER-BOTTOM: 0px; BORDER-LEFT: 0px
}
#xc1f92177d7d14951a8664fe73d45eec5 {
FONT-SIZE: 12pt; FONT-FAMILY: Tahoma
}
.plain PRE {
FONT-SIZE: 12pt; FONT-FAMILY: Tahoma
}
.plain TT {
FONT-SIZE: 12pt; FONT-FAMILY: Tahoma
}
BODY {
FONT-SIZE: 12pt; FONT-FAMILY: Tahoma
}
#x97352590f821439bb3f957ba96f9e929 .tipsy {
CURSOR: default; POSITION: absolute; PADDING-BOTTOM: 5px; PADDING-TOP: 
5px; PADDING-LEFT: 5px; Z-INDEX: 10; PADDING-RIGHT: 5px
}
#x97352590f821439bb3f957ba96f9e929 .tipsy-inner {
MAX-WIDTH: 15em; BORDER-TOP: #a7d7f9 1px solid; BORDER-RIGHT: #a7d7f9 
1px solid; BORDER-BOTTOM: #a7d7f9 1px solid; COLOR: black; PADDING-BOTTOM: 4px; 
PADDING-TOP: 5px; PADDING-LEFT: 8px; BORDER-LEFT: #a7d7f9 1px solid; 
PADDING-RIGHT: 8px; BACKGROUND-COLOR: #ff; border-radius: 4px
}
#x97352590f821439bb3f957ba96f9e929 .tipsy-arrow {
HEIGHT: 6px; WIDTH: 11px; BACKGROUND: 
url(//wiki.openstreetmap.org/w/resources/src/jquery.tipsy/images/tipsy.png?6c317)
 no-repeat left top; POSITION: absolute
}
#x97352590f821439bb3f957ba96f9e929 .tipsy-n .tipsy-arrow {
MARGIN-LEFT: -5px; LEFT: 50%; TOP: 0px
}
#x97352590f821439bb3f957ba96f9e929 .tipsy-nw .tipsy-arrow {
LEFT: 10px; TOP: 1px
}
#x97352590f821439bb3f957ba96f9e929 .tipsy-ne .tipsy-arrow {
RIGHT: 10px; TOP: 1px
}
#x97352590f821439bb3f957ba96f9e929 .tipsy-s .tipsy-arrow {
BACKGROUND-POSITION: left bottom; MARGIN-LEFT: -5px; LEFT: 50%; BOTTOM: 
0px
}
#x97352590f821439bb3f957ba96f9e929 .tipsy-sw .tipsy-arrow {
BACKGROUND-POSITION: left bottom; LEFT: 10px; BOTTOM: 0px
}
#x97352590f821439bb3f957ba96f9e929 .tipsy-se .tipsy-arrow {
RIGHT: 10px; BACKGROUND-POSITION: left bottom; BOTTOM: 0px
}
#x97352590f821439bb3f957ba96f9e929 .tipsy-e .tipsy-arrow {
HEIGHT: 11px; WIDTH: 5px; RIGHT: 1px; BACKGROUND-POSITION: right top; 
MARGIN-TOP: -5px; TOP: 50%
}
#x97352590f821439bb3f957ba96f9e929 .tipsy-w .tipsy-arrow {
HEIGHT: 11px; WIDTH: 6px; LEFT: 0px; MARGIN-TOP: -5px; TOP: 50%
}
#x97352590f821439bb3f957ba96f9e929 .tipsy {
FONT-SIZE: 0.8em
}
#x97352590f821439bb3f957ba96f9e929 .mw-customtoggle {
CURSOR: pointer
}
#x97352590f821439bb3f957ba96f9e929 .postedit-container:hover {
CURSOR: pointer
}
#x97352590f821439bb3f957ba96f9e929 .uls-menu A {
CURSOR: pointer
}
.mw-collapsible-toggle {
CURSOR: pointer
}
#x97352590f821439bb3f957ba96f9e929 .callout .caret-before {
BORDER-TOP: transparent 20px solid; BORDER-RIGHT: #c9c9c9 20px solid; 
BORDER-BOTTOM: transparent 20px solid; POSITION: absolute; LEFT: -21px; 
DISPLAY: inline-block; TOP: 30px
}
#x97352590f821439bb3f957ba96f9e929 .callout .caret-after {
BORDER-TOP: transparent 20px solid; BORDER-RIGHT: #fcfcfc 20px solid; 
BORDER-BOTTOM: transparent 20px solid; POSITION: absolute; LEFT: -20px; 
DISPLAY: inline-block; TOP: 30px
}
#x97352590f821439bb3f957ba96f9e929 .uls-ui-languages BUTTON {
WIDTH: 23%; TEXT-OVERFLOW: ellipsis; MARGIN-RIGHT: 4%
}
#x97352590f821439bb3f957ba96f9e929 BUTTON.uls-more-languages {
WIDTH: auto
}
#x97352590f821439bb3f957ba96f9e929 .settings-title {
FONT-SIZE: 11pt
}
#x97352590f821439bb3f957ba96f9e929 .settings-text {
FONT-SIZE: 9pt; COLOR: #55
}
#x97352590f821439bb3f957ba96f9e929 DIV.display-settings-block:hover 
.settings-text {
COLOR: #252525
}
#x97352590f821439bb3f957ba96f9e929 
.ve-init-mw-desktopArticleTarget-loading-overlay {
RIGHT: 0px; POSITION: absolute; LEFT: 0px; Z-INDEX: 1; MARGIN-TOP: 
-0.5em
}
#x97352590f821439bb3f957ba96f9e929 .ve-init-mw-desktopArticleTarget-progress {
OVERFLOW: hidden; BORDER-TOP: #347bff 1px solid; HEIGHT: 0.75em; 
BORDER-RIGHT: #347bff 1px solid; BACKGROUND: #fff; BORDER-BOTTOM: #347bff 1px 
solid; MARGIN: 0px 25%; BORDER-LEFT: #347bff 1px solid; border-radius: 2px
}
#x97352590f821439bb3f957ba96f9e929 
.ve-init-mw-desktopArticleTarget-progress-bar {
HEIGHT: 0.75em; WIDTH: 0px; BACKGROUND: #347bff
}
#x97352590f821439bb3f957ba96f9e929 

Re: [Talk-es] Nominatim debería ser más flexible

[Xavier Barnada]

Una pregunta , todo esto que estais comentando esta en la issue?
Porque seguro que les puede ser util a los programadores de Nominatim les
puede ayudar y estoy seguro que si a parte de explicarles el problema les
enviais una solucion os lo agradeceran

Saludos


El mar., 2 feb. 2016 a las 12:43, Alejandro Moreno Calvo ()
escribió:

> Curiosamente hay un pueblo llamado De en Indonesia
> http://nominatim.openstreetmap.org/details.php?place_id=14215103 que con
> ese parche no se encontraría nunca.
>
> No tengo el detalle de cómo está implementado Nominatim pero para mí la
> solución pasa por usar funciones estadísticas de comparación de cadenas, de
> manera que en vez de buscar una similitud exacta se busque aquello que
> supere un cierto porcentaje de similitud. En Oracle estás funciones están
> dentro del paquete UTL_MATCH [
> https://docs.oracle.com/cd/E18283_01/appdev.112/e16760/u_match.htm ]. En
> PostgreSQL existe el módulo *fuzzystrmatch* [
> http://www.postgresql.org/docs/current/static/fuzzystrmatch.html ] que
> parece más limitado y existe un proyecto [
> http://pgsimilarity.projects.pgfoundry.org/ ] que implementa más
> funciones pero no sé si es muy común su uso ni si está actualizado.
>
> Yo tengo pendiente echarle un vistazo a Nominatim e intentar implementar
> esto pero seguramente me lleve varios meses por falta de tiempo por lo que
> si alguien se quiere animar a recoger el testigo bienvenido es.
>
> El 2 de febrero de 2016, 12:02, Benjamín Valero Espinosa <
> benjaval...@gmail.com> escribió:
>
>> El problema con las "stop words" es que puedes sin querer capar una
>> palabra que sí tiene sentido en otro idioma. El ejemplo típico es "die",
>> que es un artículo definido en alemán pero es un verbo en inglés. ¿Esto se
>> está controlando? Lo ideal sería listas de "stop words" por idioma, pero
>> claro, para eso también habría que saber en qué idioma está la calle :-O
>>
>> El 2 de febrero de 2016, 9:16, Alejandro Moreno Calvo 
>> escribió:
>>
>>> Hola Xavier.
>>>
>>> Hay que tener en cuenta que ese PR soluciona un caso muy concreto pero
>>> que habría que hacer un análisis más profundo de los artículos que se
>>> pueden dar. Así a bote pronto se me ocurre también habría que añadir "el",
>>> "la", "las", "los".
>>>
>>> El 2 de febrero de 2016, 8:40, Xavier Barnada 
>>> escribió:
>>>
 Hola,

 Acabo de hacer una pull request que deberia solucionar este problema,
 he seguido el ejemplo de las otras stopwords  y este comentario
 https://trac.openstreetmap.org/ticket/4895#comment:4

 https://github.com/twain47/Nominatim/pull/358

 Saludos

 El dom., 31 ene. 2016 a las 11:57, Emilio Gómez Fernández (<
 emilio.gomez.f...@gmail.com>) escribió:

> Hola a todos.
>
> Fui yo quien abrí ese ticket hace tiempo, tanto ahí como en GitHub
> [1], y también lo comenté  en la reunión en Aguilar de Campoo en la que
> estuvimos algunos de nosotros.
> La respuesta viene a ser, en resumidas cuentas, que añadir nuevas
> palabras vacías en español a las escasas que ya existen en Nominatim [2]
> podría perjudicar las búsquedas en otros idiomas. La consecuencia es que 
> en
> nuestro caso usar la API de Nominatim para realizar, por ejemplo,
> geocodificación inversa es de escasa utilidad aun a pesar de que los datos
> existan en la base de datos.
>
> Lo único que se me ocurre es que esta discusión salte a la lista
> General y tener un feedback de otros usuarios para que la cosa se mueva y
> tenga más repercusión, porque este importante problema también afecta a
> otros idiomas [3][4].
>
> Saludos.
>
> [1] https://github.com/twain47/Nominatim/issues/85
> [2]
> https://github.com/twain47/Nominatim/blob/master/module/nominatim.c
> [3] https://github.com/twain47/Nominatim/issues/333
> [4] https://trac.openstreetmap.org/ticket/4961
>
>
> El 30 de enero de 2016, 14:17, Alejandro Moreno Calvo <
> almo...@gmail.com> escribió:
>
>> Este problema ya lleva reportado tiempo.
>> https://trac.openstreetmap.org/ticket/4895
>> El 30 ene. 2016 2:04 p. m., "Xavier Barnada" 
>> escribió:
>>
>>> Hola,
>>>
>>> A parte de la ayuda que podamos prestar al buscador mediante mejor
>>> etiquetado no veo mucho mas que se pueda hacer.
>>> Si quereix podeis reportar los problemas que veais al repositorio de
>>> Nominatim en github
>>> https://github.com/twain47/Nominatim
>>>
>>> Saludos
>>>
>>> El sáb., 30 ene. 2016 a las 13:54, Jorge Sanz Sanfructuoso (<
>>> sanc...@gmail.com>) escribió:
>>>
 Hola.

 Son un desastre las búsquedas. Hace no mucho salio el tema, no se
 si por aqui o por el telegram y alguien comentó que está adaptado para 
 el
 habla inglesa y que según Nominatim si se 

Re: [OSM-ja] Google Map 利用規約更新

[浅野和仁]

山下様

富田林市の浅野です。専門家ではありませんが・・・。

ゼンリンの「複製等利用のご案内～利用手続きと基本条件、利用対象地図製品～」
http://www.zenrin.co.jp/fukusei/index.html
というページも確認する必要があると思います。

その中で社内での複製利用が可能な製品が列挙されており、その下に
「無償で閲覧できる当社の地図製品は、複製等利用ができません。」と記されています。

つまり、無償公開されているGoogleマップに関してはゼンリンが複製利用を認めていません。
よって日本国内ではフェアユース（国内法に規定がないようです・・・）であろうとなかろうと、複製利用はできないとみるべきかと思います。

-- 
**
浅野 和仁 090-2067-9293
helicobacter_y...@hera.eonet.ne.jp（メインメール）
586-0077 河内長野市南花台四丁目7-5
**
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

[OSM-talk-fr] rendu Défibrillateur

[Erwan Salomon]

selon le wiki les défibrillateurs sont rendu dans OSM.fr  : 
http://wiki.openstreetmap.org/wiki/Tag:emergency%3Ddefibrillator 

un exemple le prouve : 
http://tile.openstreetmap.fr/?zoom=17=44.12069=4.83901=B00
 

pourtant je constate que d’autres ( 
http://www.tappenbeck.net/osm/maps/deu/index.php?id=1029=18=47.74828=-3.3657=BFTTT=de
 

 )ne sont pas rendu : 
http://tile.openstreetmap.fr/?zoom=18=47.74836=-3.36504=B000FF
 


il y a une explication ?___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] UK war office maps of Africa digitised

[Jez Nicholson]

The export tab http://warper.wmflabs.org/maps/629#Export_tab includes a WMS
link "for JOSM OpenStreetMap Editor"

I haven't tried it yet as my company have firewalled the office with an
https whitelist.

On Mon, 1 Feb 2016 at 17:34 Andy Mabbett  wrote:

> On 1 February 2016 at 13:02, Tim Waters  wrote:
>
> > Great stuff. I think a few hundred maps (if not all) from this collection
> > are already in the wikimaps warper.
> > However there was an issue with making a mosaic (stitched layer) for the
> > category, so this will be fixed soon.
>
> Once that's done, how can people see the layer in JOSM?
>
> > I think the British Library also has control points for the maps which
> could
> > be added to the warper when ready (I'd have to double check on this point
> > though).
>
> My contact tells me they (BL & Indigo Trust) want to see the maps
> reused; if there's a speciific request, I can forward it to them.
>
> --
> 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-fr] Fond OSM dans des guides de rando du CD63 ?

[Nicolas Dumoulin]

Bonjour,

Le Tuesday 02 February 2016, 11:52:10 Landry Breuil a écrit :
> Après en avoir discuté avec Guillaume Tournadre (du service SIG) qui
> trouvait que les données OSM étaient un peu pauvres sur les zones
> concernées (les PDIPR), je lui ai proposé de faire appel à la
> communauté pour enclencher le cercle vertueux de -> les itinéraires
> sont la -> on améliore les données -> le fond devient plus riche ->
> tout le monde en bénéficie!
> 
> Dans tout les cas, les itinéraires des PDIPR sont disponibles en ligne
> chez nous:
> http://ids.craig.fr/geocat/apps/search/?uuid=3bd16d2d-5fc7-4816-b824-c27460
> 3cfd16

Super nouvelle !
Le mieux serait de nous communiquer les itinéraires identifiés où le fond OSM 
révèle des manques, pour aller plus vite. Mais avec cette base d'itinéraires, 
on peut passer en revue systématiquement tous les itinéraires.
À noter que nous avons dans la communauté pas mal de randonneurs. Si on se 
répartit le travail, ça pourrait aller assez vite.
Et puis si on a un petit groupe qui s'ennue le soir au SotM fin mai … ;-)

Bon, et bien je sais quoi faire pendant les prochaines vacances :-)

Merci à Guillaume, et Landry
-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin


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

Re: [OSM-talk-fr] Rapprochement BANO dans L'île de Saint-Martin

[Cactusbone]

je teste. j'ai mis FANTOIR 971270095M sur la rue du Général de Gaulle.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Rapprochement-BANO-dans-L-ile-de-Saint-Martin-tp5866521p5866528.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Fond OSM dans des guides de rando du CD63 ?

[Nicolas Dumoulin]

Le Tuesday 02 February 2016, 11:52:10 Landry Breuil a écrit :
> Dans tout les cas, les itinéraires des PDIPR sont disponibles en ligne
> chez nous:
> http://ids.craig.fr/geocat/apps/search/?uuid=3bd16d2d-5fc7-4816-b824-c27460
> 3cfd16
> 
> Les données ne sont pas en opendata (pas encore, mais guillaume y
> travaille!) mais rien n'empèche (ou plutôt, on a l'accord) de les
> utiliser pour connaitre les zones à améliorer/cartographier

Par exemple, est-ce qu'on a le droit de publier une liste des itinéraires (nom 
et éventuellement tracé) pour faciliter la coordination ?

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin


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