[Talk-us] Mappers in Idaho!

2016-08-07 Per discussione Martijn van Exel
Hey all, and mappers in Idaho in particular!

I spoke with the GIS person of Teton County in Idaho. This is a popular
area with tourists (Grand Teton NP, Jackson Hole, ECLIPSE 2017!!) and he
received an increasing number of complaints from folks getting lost using
apps / sites based on OSM data. He offered locally produced, surveyed
(craft!) data so we may improve OSM. I uploaded it here[1], who wants to
take a stab at thinking about ways to incorporate improvements into OSM?

I did confirm with him that this data resides in the PD but I can get a
written note to that effect if you want.

I am also happy to put you in touch with him if you want.

Martijn

[1] https://www.dropbox.com/s/3au2uwulx14rzqu/TetonCounty_OSM_Data.zip?dl=0
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [OSM-talk] Building a free/open reviews community w/ OSM support

2016-08-07 Per discussione Erik Moeller
On Fri, Aug 5, 2016 at 7:48 PM, Pine W  wrote:

Hi Pine,

Nice to run into you here!

> Hod do you plan to develop readership for this site? Yelp seems to have a
> commanding lead.

To begin with, I think the most important question is whether this is
something of importance to the free culture movement -- people like us
who care about works being free to share and build upon, without
control by any single organization, and with the technology being
re-usable by others along with the content.

I personally obviously think it's an important problem to work on --
user-created reviews are pervasive, important and typically
proprietary, along with the sites that host them. Moreover, there are
obvious conflicts of interest at play that can be mitigated through a
more open approach without a commercial motive by the site operator.
Finally, I hope that we can ultimately add useful metadata beyond just
"is this a good product", e.g., about  a company's environmental or
labor record.

If enough other people agree, then the answer to your question is not
what _I_ plan to do :). If we don't care about this problem as a
movement (which might legitimately be because other things are more
important), then it won't get solved.

With that preamble, I personally have a few thoughts on that, of
course. For now I'm building out core functionality; once that's done,
I want to look into meeting the needs of specialized communities that
aren't currently being well-served by commercial players. lib.reviews
already has the notion of teams:

https://lib.reviews/teams

If anyone reading this would like to start a team to review things
that already have a matching OSM community, for example, let me know
and we'll get that started. I also want to make reviews easily
embeddable, Disqus style, so that folks who run small web shops and
such can use our software with minimal effort.

There's more, but I don't want to take up too much space on the OSM
list with not obviously OSM-related aspects of the project, and invite
folks who want to brainstorm further about it in general to subscribe
to the lib.reviews list, here:

http://www.freelists.org/list/lib.reviews

Cheers,

Erik

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


Re: [Talk-it] [english 100%] Re: Edit war Sardegna

2016-08-07 Per discussione fayor
Standard unico per situazioni analoghe: si parla della L. 482/99 che tutela
le minoranze linguistiche, ed esattamente la lingua e la cultura delle
popolazioni albanesi, catalane, germaniche, greche, slovene e croate e di
quelle parlanti il francese, il franco-provenzale, il friulano, il ladino,
l'occitano e il sardo, quindi perché trattarle in modo diverso? 

L'Istat non è l'autorità amministrativa vigente, non ha poteri decisionali:
è un ente statistico e non fa politica. 



--
View this message in context: 
http://gis.19327.n5.nabble.com/Edit-war-Sardegna-tp5879638p5880066.html
Sent from the Italy General mailing list archive at Nabble.com.

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


Re: [Talk-it] [english 100%] Re: Edit war Sardegna

2016-08-07 Per discussione Francesca Valentina
+tutto
Grande Paolo!
Questa "edit war" non é piú sulla Sardegna ma davvero, come sospettavo
dall'inizio, su cosa si intende per OpenStreetMap.
Francesca
On 7 Aug 2016 23:31, "Paolo Monegato"  wrote:

> Il 05/08/2016 20:04, Fayor Uno ha scritto:
>
>>
>> Intendiamoci, con rilevanza nazionale voglio dire che, come anche
>> evidenziato aury88, sarebbe bene avere uno standard unico per situazioni
>> analoghe, quindi non va che in Friuli decidano una cosa e in Sardegna
>> un'altra se hanno la stessa situazione.
>>
>>
> Lo standard unico allora, essendo il progetto mondiale, dovrebbe essere
> mondiale. Se altrove nel mondo fanno ognuno come gli pare è giusto che sia
> così anche qui.
>
>
> Quando dico che non devono decidere i locali non voglio assolutamente dire
>> che deve essere il governo italiano a decidere su tali questioni, e non mi
>> sembra di averlo mai detto.
>>
>>
> Sostieni però che dovrebbe deciderlo l'intera comunità italica. Ma a quel
> punto perché non aprire una discussione sulla lista talk e definire uno
> standard che valga per tutto il database?
>
> (che poi, comunque, il dire usiamo l'Istat equivale a dire che decide
> l'autorità amministrativa vigente...)
>
> ciao
> Paolo M
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] [english 100%] Re: Edit war Sardegna

2016-08-07 Per discussione Paolo Monegato

Il 05/08/2016 20:04, Fayor Uno ha scritto:


Intendiamoci, con rilevanza nazionale voglio dire che, come anche 
evidenziato aury88, sarebbe bene avere uno standard unico per 
situazioni analoghe, quindi non va che in Friuli decidano una cosa e 
in Sardegna un'altra se hanno la stessa situazione.




Lo standard unico allora, essendo il progetto mondiale, dovrebbe essere 
mondiale. Se altrove nel mondo fanno ognuno come gli pare è giusto che 
sia così anche qui.



Quando dico che non devono decidere i locali non voglio assolutamente 
dire che deve essere il governo italiano a decidere su tali questioni, 
e non mi sembra di averlo mai detto.




Sostieni però che dovrebbe deciderlo l'intera comunità italica. Ma a 
quel punto perché non aprire una discussione sulla lista talk e definire 
uno standard che valga per tutto il database?


(che poi, comunque, il dire usiamo l'Istat equivale a dire che decide 
l'autorità amministrativa vigente...)


ciao
Paolo M



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


Re: [OSM-talk] Maritime boundary missing. How to fix?

2016-08-07 Per discussione Martin Koppenhoefer


sent from a phone

> Il giorno 07 ago 2016, alle ore 21:17, Evan Siroky  ha 
> scritto:
> 
> Are these 12nm boundaries automatically created or do they require manual 
> editing?


these boundaries are not 12NM offsets of the actual coastline, but of the base 
line, a legally defined simplification / theoretical and more inclusive 
coastline. Also, 12NM (nautical miles, not nanometers ;-) ) is only the typical 
claim, some countries claim more (but generally these claims have to be 
acknowledged by other countries to become meaningful). 

To add them into osm you can either look for supposedly reasonable data to 
import or research the base line definition and claim of the country in 
question.

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


Re: [OSM-talk-fr] Changement de nom réseau / opérateurs suite changement de type de regroupement de communes

2016-08-07 Per discussione osm . sanspourriel

Le 07/08/2016 à 20:55, Philippe Verdy - verd...@wanadoo.fr a écrit :

Les ref:Q ne servent à rien: on a une clé standard pour ça: 
wikidata=Qnnn

Non, c'est la référence du référentiel, pas le référentiel.
C'est pour lever l'ambiguïté que j'ai utilisé ref:wikidata:Qnnn.
La clé est le référentiel d'Enedis, ce transformateur (par exemple) 
n'est pas Enedis (ce que supposerait un wikidata=Qnnn).


Mais cela revient à supposer que Wikidata est une référence alors que 
Wikidata a lui-même besoin de référence (et n'est pas forcément plus à 
jour qu'OSM et demande une mise à jour séparée, par des outils 
séparés, un compte utilisateur séparé, une adminsitration de site séparée.

C'est à dire qu'il faut plutôt voir Wikidata comme une source pour OSM.
Je veux bien qu'on utilise Wikidata pour collecter d'autres données 
sur les réseaux de transport mais dans OSM ces réseaux ont une 
vocation géographique certaine et une logique en terme de 
routage/calcule d'itinériaires. On est dans le coeur d'OSM plus que 
dans Wikidata qui s'intéresse à des tas d'autres choses non 
géographiques (élections, politiques, liste des élus, histoire, 
économie, personnalités, divers éléments économiques et culturels plsu 
ou moins locaux, jumelages/partenariats, évènements d'actualité, 
entreprises et marques...).
Et notamment des concepts intéressants (s'ils sont correctement 
utilisés) comme disons les entreprises de transport d'électricité comme 
support potentiel d'un ref sur un pylône.


Pour OSM on a besoin de repreésenter le monde dans son état actuel et 
le plus à jour possible. Je pense qu'OSM devrait plutôt être la 
référence externe dans Wikidata de tout ce qui est géographique (mais 
OSM n'est pas la seule source possible non plus évidemment) en tant 
"qu'agrégateur" de sources géographiques.
Justement ici on parle de ce qui *n*'est *pas* forcément géographique 
(une référence dans un référentiel).
Et puis ce n'est pas très grave si une clé ref=* mentionne une valeur 
abrégée qui ne correspond plus au nom actuel de l'entitité: on ne 
représente pas réellement dans OSM cette entité elle-même, c'est une 
valeur *codée*.
Si tu dis que ref:FR:PTT est le référentiel du Groupe La Poste, au bout 
d'un certain temps ça va coincer (et c'est à peine moins abscons qu'un 
ref:wikidata:Qnnn). Aujourd'hui tout le monde connaît ERDF (quoique) 
mais demain ?


Dans ce but il faut juste que les valeurs de clés soient réellement 
uniques, ne génèrent pas de conflits inattendus, facilement 
orthographiés pour pouvoir les rendre homogènes.

Wikidata règle cela.
Personnellement le moyen d'y parvenir (avec le moins d'efforts pour la 
maintenance et les recherches nécessaires), c'est d'utiliser les 
relations d'OSM (sachant que certains lignes ou tronçons de lignes 
peuvent faire partie de plusieurs réseaux simultanément, comme par 
exemple la ligne RER A du Francilien/SNCF et de la RATP, ou nombre de 
lignes de bus "départementales" dont les sections urbaines font aussi 
très souvent partie des réseaux de transports communautaires, les bus 
ayant alors une double numérotation, voire trois numéros si on ajoute 
le numéro de ligne de l'exploitant comme à la SNCF qui donne des 
numéros uniques non pas ligne par ligne mais horaire par horaire quand 
les parcours et arrêts peuvent changer selon l'heure).

Je ne comprends pas (ou plutôt j'espère ne pas comprendre).
Tu veux créer une relation Enedis ? avec pour rôle la référence dans le 
référentiel Enedis 
Ou plutôt ici une relation TBM où tu vas mettre des lignes et des 
stations ???
Par rapport à ta remarque sur les numéros SNCF, la plupart des 
opérateurs ont pour un numéro de ligne donné un nom unique, mettons 12 
et 12a pour la version ne desservant pas un bout de ligne.

Reste que la question est à quel référentiel rattache-t-on ce 12 ou 12a ?
J'ai l'impression qu'à l'étranger on a un ref=12 ou 12a et que c'est via 
le network qu'on sait le référentiel utilisé.

Ça suppose que l'on n'utilise qu'un ref par objet. Pas forcément stupide.

Et network n'étant pas géolocalisé, qu'il soit porté par un wikidata 
plutôt qu'un objet OSM ne me choque pas. Rien n'empêche de l'intégrer 
comme objet dans OSM. C'est le problème de toutes les métadonnées 
actuellement définies au niveau du wiki et non des outils rendant la 
contribution des nouveaux dans OSM plus difficile. Le décrire comme 
relation... - sans membre ! - ne me choque pas. Si c'est avec membre 
alors les membres sont les objets OSM du référentiel, mais à mon avis 
c'est plus par requête overpass qu'on doit les trouver.


Donc network=Groupe La Poste pour les boîtes aux lettres ??? Et non, là 
c'est via brand...


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


[OSM-talk] Maritime boundary missing. How to fix?

2016-08-07 Per discussione Evan Siroky
The Island of Mauke appears to be missing a 12nm boundary around it making it 
part of the Cook Islands. See the map:  
https://www.openstreetmap.org/#map=11/-20.1527/-157.2356  Are these 12nm 
boundaries automatically created or do they require manual editing?___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk-fr] Changement de nom réseau / opérateurs suite changement de type de regroupement de communes

2016-08-07 Per discussione Philippe Verdy
Les ref:Q ne servent à rien: on a une clé standard pour ça:
wikidata=Qnnn
Mais cela revient à supposer que Wikidata est une référence alors que
Wikidata a lui-même besoin de référence (et n'est pas forcément plus à jour
qu'OSM et demande une mise à jour séparée, par des outils séparés, un
compte utilisateur séparé, une adminsitration de site séparée.

Notez que Wikdiata n'est pas non plus exempt d'erreurs. Bref au lie ude
faire du contrôle qualité sur une base de données, on se retrouve à la
faire sur une autre base de données (où la persistence des Q n'est pas
non plus garantie du tout: à tout moment un Qnnn peut aussi être supprimé
par la création d'un objte homonyme puis une fusion qui préservera une des
deux références mais pas toujours celle qu'on croyait (ceci dit, Wikidata
préfère ne pas supprimer un Q pour créer plutôt une redirection, mais
rediriger un élément Wikidata sur un autre n'est franchement pas facile à
faire et demande des droits très pariticuliers, et c'est encore
passablement compliqué par le nombre d'opérations et de pages spéciales à
utiliser).

Je veux bien qu'on utilise Wikidata pour collecter d'autres données sur les
réseaux de transport mais dans OSM ces réseaux ont une vocation
géographique certaine et une logique en terme de routage/calcule
d'itinériaires. On est dans le coeur d'OSM plus que dans Wikidata qui
s'intéresse à des tas d'autres choses non géographiques (élections,
politiques, liste des élus, histoire, économie, personnalités, divers
éléments économiques et culturels plsu ou moins locaux,
jumelages/partenariats, évènements d'actualité, entreprises et marques...).

Pour OSM on a besoin de repreésenter le monde dans son état actuel et le
plus à jour possible. Je pense qu'OSM devrait plutôt être la référence
externe dans Wikidata de tout ce qui est géographique (mais OSM n'est pas
la seule source possible non plus évidemment) en tant "qu'agrégateur" de
sources géographiques.

Et puis ce n'est pas très grave si une clé ref=* mentionne une valeur
abrégée qui ne correspond plus au nom actuel de l'entitité: on ne
représente pas réellement dans OSM cette entité elle-même, c'est une valeur
*codée*. Le but est seulement d'avoir un identifiant unique raisonnable et
identifiable de ce réseau quand il a une structure homogène ou intégrée (et
peu importe alors les spécificités locales de ce réseau qui comprend
presque toujours des éléments partagés avec d'autres réseaux de transports
publics ou privés sur certaines lignes coexploitées ou partiellement
subventionnées sur une partie de leur parcours ou pour certains horaires
seulement). Ces réseaux sont pourtant existant en martière de
planification, ils peuvent changer un peu chaque année, selon les budgets
des collectivités et selon les appels d'offre et fins de marchés publics en
cas de nouvel appel à la concurrence, en utilisant divers moeysn
disponibles, privés ou publics, commerciaux ou associatifs sous contrat.

Dans ce but il faut juste que les valeurs de clés soient réellement
uniques, ne génèrent pas de conflits inattendus, facilement orthographiés
pour pouvoir les rendre homogènes.

Personnellement le moyen d'y parvenir (avec le moins d'efforts pour la
maintenance et les recherches nécessaires), c'est d'utiliser les relations
d'OSM (sachant que certains lignes ou tronçons de lignes peuvent faire
partie de plusieurs réseaux simultanément, comme par exemple la ligne RER A
du Francilien/SNCF et de la RATP, ou nombre de lignes de bus
"départementales" dont les sections urbaines font aussi très souvent partie
des réseaux de transports communautaires, les bus ayant alors une double
numérotation, voire trois numéros si on ajoute le numéro de ligne de
l'exploitant comme à la SNCF qui donne des numéros uniques non pas ligne
par ligne mais horaire par horaire quand les parcours et arrêts peuvent
changer selon l'heure).

Le 7 août 2016 à 13:31,  a écrit :

>
>
> Le 07/08/2016 à 10:42, lenny.libre - lenny.li...@orange.fr a écrit :
>
> Le 06/08/2016 à 14:33, osm.sanspourr...@spamgourmet.com a écrit :
>
> Sur https://www.wikidata.org/wiki/Q1117116 les noms hormis en français et
> occitan sont toujours basés sur la CUB.
>
> si on avait les ref:Q1117116 on n'aurait pas à les changer mais il faut
> adapter les outils. Car un tel code est sujet à typo et côté ergonomie
> homme-machine on a vu mieux.
>
> Je n'avais pas compris grand-chose dans la précédente discussion ...
> est-ce un tag a ajouter (lequel) ou une modification de josm, ID, ... ou
> doit-il encore faire l'objet de discutions au niveau des listes
> internationales ?
>
> L'idée c'est de remplacer les ref:FR:CUB par exemple par des ref:Q1117116
> L'avantage c'est qu'à périmètre constant (ce qui est le cas de la CUB
> devenue BM ou de ERDF devenu Enedis), on n'a rien à changer.
> L'inconvénient c'est que c'est inutilisable en brut comme présenté ici :
> - pas de contrôle (un ref:FR:CUN au lieu de ref:FR:CUB, ça se voit plus
> 

Re: [Talk-es] Reunion con el Ayntamiento de Girona

2016-08-07 Per discussione Xavier Barnada
Hola Carlos,

Por el momento lo que voy a hacer es provar el programa que paso Santiago y
ver si funciona y sirve. Si quieres cuando haga alguna prueba te aviso y
asi lo verificamos los dos.

Muchas gracias
Xavier Barnada

El dom., 7 ago. 2016 a las 12:56, Carlos m ()
escribió:

> Hola Xavier,
>
>
> Sí que es buena idea, y más aún si llegara a exportarse a otros municipios
> como dices. ¿Cómo podemos/ puedo ayudar?...
>
>
> Un saludo,
>
> Carlos Medina
>
>
> --
> *De:* Xavier Barnada 
> *Enviado:* sábado, 6 de agosto de 2016 14:19
> *Para:* Discusión en Español de OpenStreetMap
> *Asunto:* [Talk-es] Reunion con el Ayntamiento de Girona
>
> Hola lista,
>
> Ayer tuve una reunión con el Ayuntamiento de Girona i me gustaría
> explicaros lo que me comentaron que querían hacer:
>
> Quieren revisar y actualizar los datos de Girona de los siguientes
> elementos:
>
>1. Calles
>2. Edificios
>3. Números de puerta
>
> El problema con que se encuentran es que publicando la información en
> otras plataformas(no libres) no tienen control sobre los datos finales, ni
> con el tiempo de actualización, en cambio con OpenStreetMap puede publicar
> los datos, saben como se publicaran finalmente y que se actualizaran al
> instante.
>
> Por otro lado el hecho de que terceros usen los datos de OpenStreetMap
> requiere que los datos de calles,edificios y números de puerta de la ciudad
> de Girona estén el máximo de correctos posible.
>
> En el caso que esto funcione correctamente el siguiente paso que seria
> hacer lo mismo con los datos de navegación.
>
> A parte de esto también me comentaron que están abiertos a ayudarnos y
> colaborar ya sea con eventos o aportación de tatos para mejorar y difundir
> OpenStreeetMap.
>
> Personalmente creo que es una oportunidad muy interesante y puede ser
> exportada a otros municipios.
>
> Si alguien quiere colaborar en alguna cosa solo lo tiene que decir. Ahora
> mismos estoy mirando como vigilar los cambios en una zona.
>
> Saludos
> Xavier Barnada
>
>
> ___
> 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: [Talk-it] [english 100%] Re: Edit war Sardegna

2016-08-07 Per discussione EneaSuper
Buona sera gente, sono nuovo in questa mailing list, per cui perdonate
eventuali errori di scrittura o formato dei testi (per facilitare il mio
lavoro sto utilizzando il forum GIS).

Sono giunto in questa discussione dopo aver letto i changelog sulla Sardegna
ed essermi confrontato privatamente con fayor, che gentilmente mi ha
spiegato tutta la storia e portato in questa discussione appunto.
Inoltre, sono sardo e fiero sostenitore del bilinguismo, astenermi da tutto
ciò sarebbe stato una stupidaggine, sia da sardo che da mappatore!

Ritengo l'operato di l2212 ingiusto, perché ha agito di sua spontanea
volontà ben prima del termine delle discussioni del 2013 e 2014 sulla
questione, fayor ha semplicemente agito per riparare al danno fatto.
Sostengo comunque il bilinguismo del name tag principale secondo la formula
esposta da questo utente:


Damjan Gerli wrote
> Forse ci sarebbe ancora una 8. opzione, una via di mezzo: scrivere in name
> tutti e due i nomi, ma prima quello in italiano e poi il sardo...
> 
> Ciao
> Damjan

Quindi, esponendo la mia opinione in termini più tecnici, una lista di name
tag corretta sarebbe questa:

name = nome_italiano/nome_sardo (invertiti rispetto alla formula
precedente);
name:it/sc sempre presenti e, nel caso del secondo, in TUTTI i comuni della
Regione dove serve;
name:ca/co/lij specificatamente dove necessari.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Edit-war-Sardegna-tp5879638p5880057.html
Sent from the Italy General mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] Changement de nom réseau / opérateurs suite changement de type de regroupement de communes

2016-08-07 Per discussione osm . sanspourriel

Le 07/08/2016 à 17:37, Christian Quest - cqu...@openstreetmap.fr a écrit :
Le 7 août 2016 à 13:31, > a écrit :


L'idée c'est de remplacer les ref:FR:CUB par exemple par des
ref:Q1117116
L'avantage c'est qu'à périmètre constant (ce qui est le cas de la
CUB devenue BM ou de ERDF devenu Enedis), on n'a rien à changer.


Est-on sur de la stabilité, non pas des ID wikidata, mais que 
lorsqu'il y a des évolutions sur les entités qu'ils représentent on 
garde bien le meme ID ?


D'autres exemples que la CUB pour valider ?
Oui, c'est le principe : l'identifiant Wikidata doit être stable dans le 
temps.
Deux en un : je réponds en même temps à Alain en donnant l'exemple qui 
nous a fait parler des Wikidata.

Toute page Wikipedia a un numéro wikidata associé.
Prenons Enedis https://fr.wikipedia.org/wiki/Enedis.
Dans la colonne de gauche tu vois Élément Wikidata 
.
Christian, la stabilité vient du fait que la page ERDF a été renommée en 
Enedis :


 * (actu
   

   | diff
   
)
   1 juin 2016 à 15:51
   ‎
   Gustave2001 
   (discuter
    |
   contributions
   )‎
   m . . (30 973 octets) (0)‎ . . (Gustave2001 a déplacé la page
   Électricité Réseau Distribution France
   

   vers ENEDIS
    :
   changement du nom de l'entreprise) (annuler
   
)

Donc un ref:wikidata:Q3587594 aurait été une référence d'ERDF et 
maintenant d'Enedis.
Par contre ça n'aurait pas résolu la découpe PTT en La Poste et France 
Télécoms.

D'ailleurs vous voyez que l'entreprise est Groupe La Poste !
*Et là ça se complique car Groupe La Poste Q373724 a remplacé La Poste 
Q20746370 qui a remplacé...*


Donc l'intérêt des Wikidata me semble moindre car l'identifiant peut 
changer même à périmètre constant.


Dans le cas contraire, on perd ce qui me semble etre le principal 
avantage à l'usage de wikidata et on complexifie énormément la lecture 
pour les contributeurs...
On a bien le principal avantage de wikidata... dans les bons cas et non 
on ne complexifie pas si comme je dis on mène un chantier pour adapter 
les outils.
Maintenant si on a une base de ref:*:* et des outils pour changer 
ref:FR:ERDF en ref:FR:Enedis... c'est peut-être plus simple.


Dans le fil consacré aux wikidata, j'avais aussi envisagé d'ingérer 
certaines parties des Wikidata (ici id, noms) afin d'avoir des sortes de 
métadonnées car on ne doit pas avoir des la poste, La poste, La Poste, 
Groupe La Poste, etc...
Car même si on n'utilise pas les Wikidata, la saisie de tout texte libre 
est sujette à caution. OK, ici c'est en clé pas en valeur mais une 
référence à Groupe La Poste doit suggérer brand=La Poste.
D'une manière générale on a pas mal de choses dans la wiki qui 
pourraient être stockée plus judicieusement au niveau de la base : par 
exemple les références qui proviennent de l'opendata (ou autre) : par 
exemple comment savoir où récupérer les ref:FR:LaPoste ?
C'est juste un exemple. Ou que les bal de ref:FR:LaPoste ont pour 
brand="La Poste".


Jean-Yvon

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


Re: [Talk-us] [Imports] Proposing import of sidewalk data Seattle, WA, USA

2016-08-07 Per discussione Greg Morgan
On Sun, Aug 7, 2016 at 5:04 AM, Marc Gemis  wrote:
> On Sun, Aug 7, 2016 at 12:40 AM, Greg Morgan  wrote:
>> look at the recent turn lane work that MapBox is performing. They
>> have done a wonderful job of finding issues and developing use cases
>> for the rest of the community.  Far worse than the alleged GIGO of
>> this import is the NINO.  Without out MapBox's activity we would not
>> have a well developed definition of turn lanes.  Without sideway data
>> mapped and worked on, we'll get no where with these kinds-of
>> discussions.  I look forward to see what the Washington community will
>> find.  I am still working out details of my sidewalk edits.  I'd like
>> to build on the Washington data that will be developed.
>> https://github.com/mapbox/mapping/wiki/Mapping-guide-for-turn-lanes-from-imagery
>> https://github.com/mapbox/mapping/wiki/QA-for-turn-lane-data
>
> Huh ? The German community had turn:lane mapping as a week project
> (don't take  that too literally) back in November 2014. Thousands of
> turn lanes have been added in the months after the idea was launched
> in "DACH" (Germany, Switserland & Austria). I had been mapping
> hundreds of them in Belgium since spring 2014, all based on the JOSM
> style developed by Martin Vonwald.
> Please do not make it sound like Mapbox pushed turn:lane mapping
> forward. Maybe this is true for the US, but not for Western Europe.
> OsmAnd has turn lane navigation since the summer of 2015.

In 2014 turn:lane mapping was not on my radar.  I have not used
OsmAnd. I had/have no clue of your activity until now.  In the last
six years I have often turned to Western Europe for examples but
turn:lane mapping has not been one of them. What MapBox has pushed
forward is excellent documentation and published it in such a way that
the documentation was clear and drew my interest.  Moreover, what
really caught my eye is how the Portland community responded to a
mistake during the mapping process.  The Portland community did not
call in the DWC to break both of the mapper's knee caps with a
baseball bat.  The issue was repaired and the community moved forward.

Regards,
Greg

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


Re: [OSM-talk-fr] Osmose erreur Post box without ref

2016-08-07 Per discussione Frédéric Rodrigo

Le 07/08/2016 à 19:37, Francois Gouget a écrit :

On Sat, 6 Aug 2016, Balaïtous wrote:


Bonjour,

Je pense qu'il y a en ce moment de gros problèmes sur l'intégration des
données de la poste. osmose me signale cette erreur, alors que c'est
une annexe de la poste que j'ai très récemment ajouté avec l'aide du
josm-fix de osmose.

Oui, Osmose m'a sorti tout plein d'autres erreurs sur des boites aux
lettres et des agences de la Poste :

Osmose ne voit pas ref=A2C5R3 sur cette boite aux lettres :
http://osmose.openstreetmap.fr/en/error/7467367399

Osmose ne voit pas ref:FR:LaPoste=17298A sur ce bureau de poste :
http://osmose.openstreetmap.fr/en/error/7458703888


J'ai aussi eu des erreurs de FINESS manquant non justifiées mais je les
ai marquées comme corrigées en espérant que ce serait Osmose qui serait
corrigé d'ici son prochain passage.

Il y a clairement quelque chose qui ne va pas : soit un problème
temporaire coté Osmose (peut-être un problème de téléchargement /
rafraichissement des bases de référence ?), soit si ces erreurs sont
justifiées un gros problème de documentation vu que personne ne sait ce
qu'elles veulent dire.

Un bug a été identifié qui ressemble beaucoup à ce problème.
https://github.com/osm-fr/osmose-backend/pull/124


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


Re: [Talk-us] [Imports] Proposing import of sidewalk data Seattle, WA, USA

2016-08-07 Per discussione Greg Morgan
> Again this seems to be is the "I'm waiting for someone else to do something"
> line.  If you want a map rendering that shows stop signs, create one, like I

I am not standing in any line.  If I find an issue that I don't think
has been addressed or the original author did not understand is an
issue, then I file a bug report to the best my abilities.  That
doesn't mean I have to pick up the language and supply the patch.  The
way that open source works is that you don't always have to be the
coder.  Besides I would put up Butt ugly tiles that only a mother
would dare hang on her fridge and be proud of.  Then again, Tiles At
Home was Butt ugly and effective for mappers to see there changes.
https://github.com/openstreetview/josm-plugin/issues/2
https://github.com/openstreetview/uploader/issues/5

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


Re: [Talk-de] Umwandeln von .osm-Dateien in PDF

2016-08-07 Per discussione Marvin Gülker
Hallo Leute,

On Fri, Aug 05, 2016 at 08:02:38PM +0200, Hartmut Holzgraefe wrote:
> On 05.08.2016 16:08, Sven Geggus wrote:
> Alternativ gibt es auch nik4 das zumindest von sich selbst behauptet
> etwas bessere Ergebnisse zu liefern als nik2img:
> 
> https://github.com/Zverik/Nik4

Ich lese diese Mailingliste eigentlich mehr oder weniger passiv mit
(abgesehen von meiner letzten Mail, die scheinbar bei der
Listen-Administration stecken geblieben ist), aber speziell mit diesem
Thema habe ich mich vor einiger Zeit einmal befasst und einen Blogpost
dazu geschrieben, wie man mit nik4, PostgreSQL und den OSM-Daten lokal
Karten im PDF-Format erzeugen kann. Hier gibt es das ganze zum
Nachlesen:

http://www.guelkerdev.de/articles/2015/07/19/openstreetmap-karten-mapnik-ii/

Viele Grüße
Marvin

-- 
Blog: http://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F

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


Re: [OSM-talk-fr] Changement de nom réseau / opérateurs suite changement de type de regroupement de communes

2016-08-07 Per discussione Alain VASSAULT
Question de débutant 
Ref:wikidata:   
?

Le 7 août 2016 17:37:47 CEST, Christian Quest  a écrit 
:
>Le 7 août 2016 à 13:31,  a écrit :
>
>> L'idée c'est de remplacer les ref:FR:CUB par exemple par des
>ref:Q1117116
>> L'avantage c'est qu'à périmètre constant (ce qui est le cas de la CUB
>> devenue BM ou de ERDF devenu Enedis), on n'a rien à changer.
>>
>
>Est-on sur de la stabilité, non pas des ID wikidata, mais que lorsqu'il
>y a
>des évolutions sur les entités qu'ils représentent on garde bien le
>meme ID
>?
>
>D'autres exemples que la CUB pour valider ?
>
>Dans le cas contraire, on perd ce qui me semble etre le principal
>avantage
>à l'usage de wikidata et on complexifie énormément la lecture pour les
>contributeurs...
>
>-- 
>Christian Quest - OpenStreetMap France
>
>
>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-fr

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Changement de nom réseau / opérateurs suite changement de type de regroupement de communes

2016-08-07 Per discussione Christian Quest
Le 7 août 2016 à 13:31,  a écrit :

> L'idée c'est de remplacer les ref:FR:CUB par exemple par des ref:Q1117116
> L'avantage c'est qu'à périmètre constant (ce qui est le cas de la CUB
> devenue BM ou de ERDF devenu Enedis), on n'a rien à changer.
>

Est-on sur de la stabilité, non pas des ID wikidata, mais que lorsqu'il y a
des évolutions sur les entités qu'ils représentent on garde bien le meme ID
?

D'autres exemples que la CUB pour valider ?

Dans le cas contraire, on perd ce qui me semble etre le principal avantage
à l'usage de wikidata et on complexifie énormément la lecture pour les
contributeurs...

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


Re: [Talk-it] Suddivisioni di Roma

2016-08-07 Per discussione Fayor Uno
attualmente ogni zona toponomastica è strutturata così (esempi):


name=Rione IV Campo Marzio

place=quarter

ref=R. IV

type=multipolygon

wikipedia=it.Campo Marzio


name=Quartiere XII Gianicolense

place=quarter

ref=Q. XII

type=multipolygon

wikipedia=it.Gianicolense


name=Suburbio VIII Gianicolense

place=quarter

ref=S. VIII

type=multipolygon

wikipedia=it.Gianicolense (Suburbio di Roma)


name=Zona LIII Tomba di Nerone

place=quarter

ref=Z. LIII

type=multipolygon

wikipedia=it.Tomba di Nerone


Ogni zona non è diversa dall'altra dal punto di vista strutturale, sono tutte 
suddivisioni di pari livello anche se di "importanza" diversa. Per fare un 
paragone amministrativo sarebbe un po' come le province e le città 
metropolitane (sempre livello 6)



Da: Martin Koppenhoefer 
Inviato: domenica 7 agosto 2016 16.04
A: openstreetmap list - italiano
Oggetto: Re: [Talk-it] Suddivisioni di Roma



sent from a phone

Il giorno 07 ago 2016, alle ore 15:39, Fayor Uno 
> ha scritto:


Dici di usare tag diversi per ognuno dei quattro tipi? e quali?


no, non dico di usare tag diversi per ogni tipo, ma di usare evventualmente tag 
diversi per certi tipi. quarter per me va bene per i quartieri e rioni, non 
conosco i suburbi, e come si presentano ad oggi, e se sono ancora simili tra di 
loro (la classificazione che stai citando pare che risale al 1909)




Cosa intendi per "la classe in italiano"?


nel caso che ci sia una classe ufficiale (Rione, ecc.) di avere un tag per 
metterlo, oppure integrarlo nel nome, tipo "Rione Monti"

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


[Talk-us] Fwd: School districts

2016-08-07 Per discussione Mike Dupont
Hi guys,

Need advice on how to setup a OSM searchable school district lookup system
using a static js driven site.

Can we start adding the school districts for the map in the usa?

For Lawrence Township they assign individual houses or streets.

Here is the best map I have come up with for lawrence so far :
https://twitter.com/h4ck3rm1k3/status/761970059430486020

Basically the question is, can we store the school district information
attached to a house number or street as needed or do we have to store it
externally?

I would like to add this information to the house or street level in osm or
find a way to link a customer layer to osm. Basically I want to have the
user search and find the location in osm, I have added all the house
numbers to osm where the streets are split. So we would find a street or a
house number, and for that number I need to return the custom data.

I have setup and cleaned all the data for Lawrence Township, NJ.  We have a
project page for mercer county here :
https://github.com/codefortrenton/school-districts

I am making progress on this topic, the way I am planning on doing it now
is to have a geojson file with all the district areas borders for the
township and then use a leaflet slippy map to display it on top of osm, and
nominatim to search for house numbers, and then take the coordinates found
at a give point to lookup the bounding parcel.

The problem that I see is that the id might change over time, otherwise I
would use the osm id. I guess I could take the streetname and house number
and add it to a look up table.

mike

-- 
James Michael DuPont
Kansas Linux Fest http://kansaslinuxfest.us
Free/Libre Open Source and Open Knowledge Association of Kansas
http://openkansas.us
Member of Free Libre Open Source Software Kosova http://www.flossk.org
Saving Wikipedia(tm) articles from deletion http://SpeedyDeletion.wikia.com



-- 
James Michael DuPont
Kansas Linux Fest http://kansaslinuxfest.us
Free/Libre Open Source and Open Knowledge Association of Kansas
http://openkansas.us
Member of Free Libre Open Source Software Kosova http://www.flossk.org
Saving Wikipedia(tm) articles from deletion http://SpeedyDeletion.wikia.com
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us


Re: [Talk-it] Suddivisioni di Roma

2016-08-07 Per discussione Martin Koppenhoefer


sent from a phone

> Il giorno 07 ago 2016, alle ore 15:39, Fayor Uno  ha 
> scritto:
> 
> Dici di usare tag diversi per ognuno dei quattro tipi? e quali?
> 


no, non dico di usare tag diversi per ogni tipo, ma di usare evventualmente tag 
diversi per certi tipi. quarter per me va bene per i quartieri e rioni, non 
conosco i suburbi, e come si presentano ad oggi, e se sono ancora simili tra di 
loro (la classificazione che stai citando pare che risale al 1909)


> 
> Cosa intendi per "la classe in italiano"?
> 


nel caso che ci sia una classe ufficiale (Rione, ecc.) di avere un tag per 
metterlo, oppure integrarlo nel nome, tipo "Rione Monti"


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


Re: [Talk-cat] Reunio amb l'Ajuntament de Girona (Xavier Barnada)

2016-08-07 Per discussione Albert
Em sembla molt interessant. Com saps estem fent cartografia pel parc de bombers 
de Girona basada en OSM . Així que si podem colaborar d´alguna manera ,dins les 
nostres limitacions, compta amb nosaltres.

On 7 d’agost de 2016 14:00:14 CEST, talk-cat-requ...@openstreetmap.org wrote:
>Send Talk-cat mailing list submissions to
>   talk-cat@openstreetmap.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.openstreetmap.org/listinfo/talk-cat
>or, via email, send a message with subject or body 'help' to
>   talk-cat-requ...@openstreetmap.org
>
>You can reach the person managing the list at
>   talk-cat-ow...@openstreetmap.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Talk-cat digest..."
>
>
>Today's Topics:
>
>   1. Reunio amb l'Ajuntament de Girona (Xavier Barnada)
>
>
>--
>
>Message: 1
>Date: Sat, 06 Aug 2016 12:19:39 +
>From: Xavier Barnada 
>To: OpenStreetMap in catalan 
>Subject: [Talk-cat] Reunio amb l'Ajuntament de Girona
>Message-ID:
>   
>Content-Type: text/plain; charset="utf-8"
>
>Hola llista,
>
>Ahir vaig tenir una reunió amb l'Ajuntament de Girona i m'agradaria
>explicar-vos el que em van comentar que voldrien fer:
>
>Volen revisar i actualitzar les dades de Girona dels següents elements:
>
>   1. Carrers
>   2. Edificis
>   3. Números de porta
>
>El problema amb que es troben es que publicant la informació a altres
>plataformes(no lliure) no tenen control sobre les dades finals , ni
>temps
>d'actualització, en canvi amb OpenStreetMap poden publicar les dades ,
>saben com acabaran publicades finalment i que s'actualitza al instant.
>
>Per altre banda el fet de que tercers facin servir les dades
>d'OpenStreetMap requereix que les dades de carrers, edificis i números
>de
>porta de la ciutat de Girona siguin el màxim de correctes possible.
>
>Per assegurar que les dades que s'insereixen a OpenStreetMap d'aquests
>elements el que vaig recomanar es usar el sistema de canvis que té
>OpenStreetMap (API) per detectar possibles errors que s'introdueixin.
>
>En el cas de que tot això funcioni correctament el següent pas seria
>fer el
>mateix amb les dades de navegació.
>
>A part d'això també em van comentar que estan oberts a ajudar-nos i
>col·laborar ja sigui amb events o aportació de dades per millorar i
>difondre OpenStreetMap
>
>Personalment crec que és una oportunitat molt interessant i que pot ser
>exportada a altres municipis.
>
>Si algú vol col·laborar en alguna cosa només ho ha de dir. Jo estic
>mirant
>a veure com "vigilar" els canvis d'una zona.
>
>Salutacions
>Xavier Barnada
>-- next part --
>An HTML attachment was scrubbed...
>URL:
>
>
>--
>
>Subject: Digest Footer
>
>___
>Talk-cat mailing list
>Talk-cat@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-cat
>
>
>--
>
>End of Talk-cat Digest, Vol 38, Issue 1
>***

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Talk-cat mailing list
Talk-cat@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cat


Re: [Talk-it] Suddivisioni di Roma

2016-08-07 Per discussione Fayor Uno

I municipi (level 10) ci sono, le zone toponomastiche (place=quarter) anche, le 
zone urbanistiche non ancora (è il caso di inserirle? e come taggarle 
eventualmente?)


La distinzione tra rioni, quartieri, suburbi e zone, se non ho capito male, è 
questa:


Rioni: suddivisioni del centro storico di Roma (entro le mura Aureliane o nei 
pressi)

Quartieri: suddivisioni della restante parte dell'abitato (sia di Roma che di 
Ostia)

Suburbi: suddivisioni di transizione (prossimi a divenire quartieri)

Zone: suddivisioni del rimanente territorio (più rurale che urbano)


Dici di usare tag diversi per ognuno dei quattro tipi? e quali?


Cosa intendi per "la classe in italiano"?



Da: Martin Koppenhoefer 
Inviato: domenica 7 agosto 2016 15.09
A: openstreetmap list - italiano
Oggetto: Re: [Talk-it] Suddivisioni di Roma



sent from a phone

Il giorno 24 lug 2016, alle ore 23:17, Fayor Uno 
> ha scritto:


15 circoscrizioni (chiamate municipi): relazioni boundary (i membri sono 
confini) con amin_level 10


i municipi già ci sono (in osm), non so le "zone urbanistiche" (155) che sono 
suddivisioni dei municipi (lo dice Wikipedia) 
https://it.m.wikipedia.org/wiki/Zone_urbanistiche_di_Roma#/media/File%3AZU_mappa.jpg

sarebbero penso admin_level=11? Roma Capitale è level 8, come un qualsiasi 
altra comune?

Poi ci sono i piani di zona, che individuano altre aree (amministrative?). Non 
so se li vogliamo (il PRG per esempio non lo vogliamo in OSM, penso)



116 zone toponomastiche (rioni, quartieri, suburbi e zone): relazioni 
multypoligon (i membri sono percorsi) senza admin_level e con place=quarter


ha senso avere rioni e suburbi allo stesso livello, visto che le Rioni sono più 
piccoli? Il livello toponomastico più piccolo previsto in OSM è neighbourhood, 
sopra possiamo inventare quanti ci servono, in ogni caso vorrei rintracciare 
anche la classe in italiano/lingua originale  (Rione, Quartiere, ecc.)


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


Re: [OSM-talk] New Google Maps style - interesting cartographic innovation

2016-08-07 Per discussione Martin Koppenhoefer


sent from a phone

> Il giorno 07 ago 2016, alle ore 01:43, Michał Brzozowski 
>  ha scritto:
> 
> Now, traditional topo maps use building type attribute for this, eg.
> Polish ones use dark brown for public/retail buildings, orange for
> residential, violet for industrial and gray for everything else.


I guess you meant to write "use" or usage type, our building types are 
architectural types.

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


[Talk-cz] Nejdou nahravat rozcestniky

2016-08-07 Per discussione Miroslav Suchý

Ahoj,
nejdou mi nahravat rozcestniky pres
  http://map.openstreetmap.cz/osmcz/#
Visi to v Uploading stavu a pise: No bbox provided.

Mirek

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


Re: [Talk-it] Suddivisioni di Roma

2016-08-07 Per discussione Martin Koppenhoefer


sent from a phone

> Il giorno 24 lug 2016, alle ore 23:17, Fayor Uno  ha 
> scritto:
> 
> 15 circoscrizioni (chiamate municipi): relazioni boundary (i membri sono 
> confini) con amin_level 10
> 


i municipi già ci sono (in osm), non so le "zone urbanistiche" (155) che sono 
suddivisioni dei municipi (lo dice Wikipedia) 
https://it.m.wikipedia.org/wiki/Zone_urbanistiche_di_Roma#/media/File%3AZU_mappa.jpg

sarebbero penso admin_level=11? Roma Capitale è level 8, come un qualsiasi 
altra comune? 

Poi ci sono i piani di zona, che individuano altre aree (amministrative?). Non 
so se li vogliamo (il PRG per esempio non lo vogliamo in OSM, penso)


> 116 zone toponomastiche (rioni, quartieri, suburbi e zone): relazioni 
> multypoligon (i membri sono percorsi) senza admin_level e con place=quarter
> 


ha senso avere rioni e suburbi allo stesso livello, visto che le Rioni sono più 
piccoli? Il livello toponomastico più piccolo previsto in OSM è neighbourhood, 
sopra possiamo inventare quanti ci servono, in ogni caso vorrei rintracciare 
anche la classe in italiano/lingua originale  (Rione, Quartiere, ecc.)


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


Re: [OSM-talk-fr] Changement de nom réseau / opérateurs suite changement de type de regroupement de communes

2016-08-07 Per discussione lenny.libre


Je n'ai pas trouvé dans les datas de BM des infos sur les couleurs en 
hex
Je suis donc parti des couleurs représentées sur le site TBM que j'ai 
mises à gauche et à droite celles que j'ai trouvées approchantes. N'y 
a-t-il pas dans le wiki une page Bordeaux comme celle de Toulouse 
(http://wiki.openstreetmap.org/wiki/Toulouse/Transports_en_commun) ?

bleu #008BCF

#008DD0

orange #ED862F

#F58220

vert #7B9C41

#7B9C41

bleu foncé #292059

#292059
Je suis parti de la page initiale et ai utilisé le greffon ColorPicker.
Bien plus pratique (et plus sûr)

Jean-Yvon

Merci, on en apprend tous les jours
léni
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk] New Google Maps style - interesting cartographic innovation

2016-08-07 Per discussione Michał Brzozowski
On Sun, Aug 7, 2016 at 8:53 AM, Maarten Deen  wrote:
>So it's a heatmap for POI's?

A thresholded heatmap, maybe. But really the area thingy seen on zooms
lower than buildings is a concave hull on slightly expanded outlines
of "interesting" buildings (as I said the ones which contain most of
given POIs). The area only includes most concentrated areas, so lone
interesting buildings don't count toward it.
Therefore, it's a hybrid of a point-in-polygon, spatial buffer,
concave hull and a heatmap.

>I still don't see the innovation.

The notion that something is not innovative just because it uses
familiar methods is fundamentally wrong. A solution consists of a
method (like an algorithm) and its application, that is a problem it
solves. If you apply an existing algorithm in a new and meaningful
way, that also is innovative. In fact, if the former were true, we
would have to dismiss half of science papers, if not more.

The classical heatmap on some random OSM hacker's website serves a
different purpose - analysis. It hasn't been used on general purpose
maps in a context of presenting "interesting" places automatically.
Still, if anybody can give an example of anybody doing similar thing
as Google did, I stand to be corrected.

The bottom line is that we don't live in a vacuum and it's beneficial
to look for fresh or unusual ideas wherever they come from. No need to
perpetuate an echo chamber.

Michał

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


Re: [Talk-es] Asociación OSM España

2016-08-07 Per discussione Pepe Casado
Gran trabajo Santiago

El 7 ago. 2016 13:32, "Santiago Crespo" 
escribió:

> Hola,
>
> Ya están creados los hilos en el foro.
>
> Revisión de los estatutos:
> http://forum.openstreetmap.org/viewtopic.php?id=55389
>
> Pasos siguientes refundación:
> http://forum.openstreetmap.org/viewtopic.php?id=55390
>
> Cuotas:
> http://forum.openstreetmap.org/viewtopic.php?id=55391
>
> Grupo de trabajo de Datos:
> http://forum.openstreetmap.org/viewtopic.php?id=55392
>
> Grupo de trabajo de Operaciones:
> http://forum.openstreetmap.org/viewtopic.php?id=55393
>
> Grupo de trabajo de Comunicaciones:
> http://forum.openstreetmap.org/viewtopic.php?id=55394
>
> Grupo de trabajo de Ingeniería:
> http://forum.openstreetmap.org/viewtopic.php?id=55395
>
> Grupo de trabajo Estado del mapa:
> http://forum.openstreetmap.org/viewtopic.php?id=55396
>
> Pasos siguientes no cubiertos por los grupos de trabajo:
> http://forum.openstreetmap.org/viewtopic.php?id=55397
>
> "Local Chapter" de la OSMF:
> http://forum.openstreetmap.org/viewtopic.php?id=55398
>
> Varios:
> http://forum.openstreetmap.org/viewtopic.php?id=55399
>
> Saludos,
> Santiago
>
> On 08/01/2016 11:16 AM, Santiago Crespo wrote:
> > Hola,
> >
> > Hasta ahora hemos participado en el doodle [1] 9 personas y no
> > coincidimos en ninguno de las fechas propuestas: nos podríamos juntar 5
> > en el mejor de los casos.
> >
> > Por lo que si os parece bien, propongo empezar la reunión de forma
> > asíncrona, en un foro. Que cada punto del orden del día propuesto [2]
> > vaya en un hilo separado.
> >
> > Imagino que para septiembre tendremos una reunión más formal, esto del
> > foro es por ir avanzando.
> >
> > Esperaré al miércoles antes de crear los hilos, por si queréis modificar
> > la propuesta del orden del día o comentar sobre la idea del foro.
> >
> > Saludos,
> > Santiago
> >
> > [1] http://doodle.com/poll/cu5ht4sgz5ityki7
> > [2] https://public.pad.fsfe.org/p/osm-es
> >
> > On 07/26/2016 05:09 PM, Santiago Crespo wrote:
> >> Hola,
> >>
> >> Contad conmigo.
> >>
> >> Podemos acordar una fecha usando este doodle:
> >>
> >> http://doodle.com/poll/cu5ht4sgz5ityki7
> >>
> >> Nos podemos reunir en el canal #osm-es del servidor IRC de
> >> openstreetmap.org[1] o en un hangout si preferís vernos las caras.
> >>
> >> Hasta que nos reunamos y tengamos un canal propio, propongo usar esta
> >> lista si nadie tiene inconveniente. Más adelante podemos solicitar la
> >> creación de una lista para la asociación o crear una nosotros.
> >>
> >> He recopilado los puntos que habéis hablado hasta ahora y alguno más.
> >> Los he puesto en un pad a modo de borrador del orden del día. Por favor,
> >> revisadlo y añadid o cambiad lo que veáis oportuno:
> >>
> >> https://public.pad.fsfe.org/p/osm-es
> >>
> >> Saludos,
> >> Santiago Crespo
> >>
> >> [1] http://irc.openstreetmap.org/
> >>
> >> On 07/25/2016 11:18 PM, Miguel Sevilla-Callejo wrote:
> >>> Vuelvo a escribir sobre el tema retomando el mensaje de Santiago
> Higuera
> >>> en el otro hilo de la lista [1] en el que proponía:
> >>>
> >>> 1. entregar los papeles a una gestoría especializada en ONGs --> A mi
> me
> >>> parece genial que haya alguien que nos pueda echar una mano y entre
> >>> todos podríamos asumir un pequeño coste. Santiago, ¿sigues dispuesto a
> >>> llevar los papeles allí? Tendría que devolvértelos Pedro-Juan, ¿no?
> >>>
> >>> 2. quedar vía hangout --> alguien se atreve a hacerlo esta misma
> semana,
> >>> ¿o ya para septiembre? (doy por descontado que en agosto estamos muchos
> >>> lejos del ordenador)
> >>>
> >>> Quizá podemos ir pronunciándonos por esta vía o por Telegram e ir
> >>> atacando las ideas que se nos vayan ocurriendo ya con los estatutos de
> >>> la asociación sobre la mesa.
> >>>
> >>> Un saludo
> >>>
> >>> Miguel
> >>>
> >>> [1] https://lists.openstreetmap.org/pipermail/talk-es/2016-
> April/013979.html
> >>>
> >>> --
> >>> *Miguel Sevilla-Callejo*
> >>> *
> >>> Doctor in Geography*
> >>> a. Associate Lecturer at Dpto. of Geography & Territorial Planning at
> >>> University of Zaragoza
> >>> b. Fellow at the Pyrenean Institute of Ecology - Spanish National
> >>> Research Council
> >>> c. Freelance consultant & researcher - Member #698, Spanish
> Professional
> >>> Association of Geographers
> >>>
> >>> *Doctor en Geografía*
> >>> a. Profesor asociado en el Dpto. de Geografía y Ordenación del
> >>> Territorio de la Univ. de Zaragoza
> >>> b. Colaborador del Instituto Pirenaico de Ecología - Consejo Superior
> de
> >>> Investigaciones Científicas
> >>> c. Consultor e investigador freelance - Colegiado 698 del Colegio
> >>> Oficial de Geógrafos
> >>>
> >>> 2016-07-25 18:19 GMT+02:00 Miguel Sevilla-Callejo <
> msevill...@gmail.com
> >>> >:
> >>>
> >>> Hola,
> >>>
> >>> Han pasado ya casi cuatro meses desde que nos dimos un ultimátum
> >>> para ver si nos poníamos manos a la obra para reactivar la
> >>> asociación OpenStreetMap España que os 

Re: [Talk-us] [Imports] Proposing import of sidewalk data Seattle, WA, USA

2016-08-07 Per discussione ajt1...@gmail.com

On 06/08/2016 23:40, Greg Morgan wrote:


Again relevance:  I am still waiting for a stop sign to be rendered a
year after it was requested. If we wait until a stop sign gets all
artsie and fartsie, then it will never be rendered and it will never
be mapped or shall I say mappers will become uninterested without a
reward for their efforts.  We deny one stop light towns the pleasure
of seeing something happen on the map.  We need this kind of data
before the renders can even have some use cases to work from.
https://github.com/gravitystorm/openstreetmap-carto/issues/1683




Again this seems to be is the "I'm waiting for someone else to do 
something" line.  If you want a map rendering that shows stop signs, 
create one, like I did for sidewalks*.  Back in the day of hand-crafting 
Mapnik XML there was a seriously high bar to clear before "making your 
own map style", but now with CartoCSS (for which thanks, Mapbox!) that 
simply isn't the case any more.  If what you do makes sense at a local 
or national level it can get picked up at that level, and it'll stand 
much more chance of being included in one of the styles on the main 
osm.org site if you've got an example that says "here's how to do it and 
here's what it looks like"**.


Best Regards,

Andy


* https://www.openstreetmap.org/user/SomeoneElse/diary/38136

** 
https://github.com/gravitystorm/openstreetmap-carto/issues/1260#issuecomment-225009856



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


Re: [OSM-ja] 証券会社の定義、ありましたっけ

2016-08-07 Per discussione ribbon
On Sun, Aug 07, 2016 at 06:39:26PM +0900, yuu hayashi wrote:
>   amenity=bank
>   bank=investment
> name=〇〇証券
> とすれば証券会社と銀行の区別がつきます。

Wikipediaで軽く調べて見たんですが、どうも、外国の方は、
銀行と証券の区別がそれほど明確ではないような感じですね。
日本だと、結構きっちりと分かれていたのですけど。

今は、郵便局でも投資信託売る時代ですから。

ただ、日本の証券会社は英語名だと  Securities となるんですね。
そうなると、investment もどうなんでしょ?

ribbon

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


Re: [OSM-talk-fr] Changement de nom réseau / opérateurs suite changement de type de regroupement de communes

2016-08-07 Per discussione osm . sanspourriel



Le 07/08/2016 à 10:42, lenny.libre - lenny.li...@orange.fr a écrit :

Le 06/08/2016 à 14:33, osm.sanspourr...@spamgourmet.com a écrit :


Sur https://www.wikidata.org/wiki/Q1117116 les noms hormis en 
français et occitan sont toujours basés sur la CUB.


si on avait les ref:Q1117116 on n'aurait pas à les changer mais il 
faut adapter les outils. Car un tel code est sujet à typo et côté 
ergonomie homme-machine on a vu mieux.


Je n'avais pas compris grand-chose dans la précédente discussion ... 
est-ce un tag a ajouter (lequel) ou une modification de josm, ID, ... 
ou doit-il encore faire l'objet de discutions au niveau des listes 
internationales ?

L'idée c'est de remplacer les ref:FR:CUB par exemple par des ref:Q1117116
L'avantage c'est qu'à périmètre constant (ce qui est le cas de la CUB 
devenue BM ou de ERDF devenu Enedis), on n'a rien à changer.

L'inconvénient c'est que c'est inutilisable en brut comme présenté ici :
- pas de contrôle (un ref:FR:CUN au lieu de ref:FR:CUB, ça se voit plus 
facilement qu'un ref:Q1171116 au lieu d'un ref:Q1117116)
il faut donc que les outils principaux (JOSM, ID, Potlatch) proposent 
déjà une interface qui intègre cela (si la personne tape CUB on lui 
propose ref:Q1117116 - affiché Bordeaux Métropole avec un indicateur 
Wikidata, idem si on trouve un ref:Q1117116 on doit afficher Bordeaux 
Métropole avec un indicateur Wikidata).


Je ne sais si quelqu'un a lancé la discussion sur une liste internationale.

Je n'ai jamais fait de remplacement systématique, mais, j'ai préparé 
(ce que je pensais possible de faire) et j'aimerais qu'on me dise si 
c'est ok:

Moi non plus mais ça me semble correct.


- il trouve une liste d'avertissements longue comme "un jour sans
pain" (89) je suis pas prêt de tous les vérifier

Comme tu modifies il te propose de corriger des erreurs précédentes. 
Stricto sensu tu pourrais passer outre et corriger plus tard. Car si tu 
attends 3 semaines il y a des risques que d'autres modifient ces objets 
et que tu te retrouves avec un conflit d'édition : d'accord avec Frédéric.

Je n'ai pas trouvé dans les datas de BM des infos sur les couleurs en hex
Je suis donc parti des couleurs représentées sur le site TBM que j'ai 
mises à gauche et à droite celles que j'ai trouvées approchantes. N'y 
a-t-il pas dans le wiki une page Bordeaux comme celle de Toulouse 
(http://wiki.openstreetmap.org/wiki/Toulouse/Transports_en_commun) ?

bleu #008BCF

#008DD0

orange #ED862F

#F58220

vert #7B9C41

#7B9C41

bleu foncé #292059

#292059
Je suis parti de la page initiale et ai utilisé le greffon ColorPicker.
Bien plus pratique (et plus sûr)

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


Re: [Talk-es] Asociación OSM España

2016-08-07 Per discussione Santiago Crespo
Hola,

Ya están creados los hilos en el foro.

Revisión de los estatutos:
http://forum.openstreetmap.org/viewtopic.php?id=55389

Pasos siguientes refundación:
http://forum.openstreetmap.org/viewtopic.php?id=55390

Cuotas:
http://forum.openstreetmap.org/viewtopic.php?id=55391

Grupo de trabajo de Datos:
http://forum.openstreetmap.org/viewtopic.php?id=55392

Grupo de trabajo de Operaciones:
http://forum.openstreetmap.org/viewtopic.php?id=55393

Grupo de trabajo de Comunicaciones:
http://forum.openstreetmap.org/viewtopic.php?id=55394

Grupo de trabajo de Ingeniería:
http://forum.openstreetmap.org/viewtopic.php?id=55395

Grupo de trabajo Estado del mapa:
http://forum.openstreetmap.org/viewtopic.php?id=55396

Pasos siguientes no cubiertos por los grupos de trabajo:
http://forum.openstreetmap.org/viewtopic.php?id=55397

"Local Chapter" de la OSMF:
http://forum.openstreetmap.org/viewtopic.php?id=55398

Varios:
http://forum.openstreetmap.org/viewtopic.php?id=55399

Saludos,
Santiago

On 08/01/2016 11:16 AM, Santiago Crespo wrote:
> Hola,
> 
> Hasta ahora hemos participado en el doodle [1] 9 personas y no
> coincidimos en ninguno de las fechas propuestas: nos podríamos juntar 5
> en el mejor de los casos.
> 
> Por lo que si os parece bien, propongo empezar la reunión de forma
> asíncrona, en un foro. Que cada punto del orden del día propuesto [2]
> vaya en un hilo separado.
> 
> Imagino que para septiembre tendremos una reunión más formal, esto del
> foro es por ir avanzando.
> 
> Esperaré al miércoles antes de crear los hilos, por si queréis modificar
> la propuesta del orden del día o comentar sobre la idea del foro.
> 
> Saludos,
> Santiago
> 
> [1] http://doodle.com/poll/cu5ht4sgz5ityki7
> [2] https://public.pad.fsfe.org/p/osm-es
> 
> On 07/26/2016 05:09 PM, Santiago Crespo wrote:
>> Hola,
>>
>> Contad conmigo.
>>
>> Podemos acordar una fecha usando este doodle:
>>
>> http://doodle.com/poll/cu5ht4sgz5ityki7
>>
>> Nos podemos reunir en el canal #osm-es del servidor IRC de
>> openstreetmap.org[1] o en un hangout si preferís vernos las caras.
>>
>> Hasta que nos reunamos y tengamos un canal propio, propongo usar esta
>> lista si nadie tiene inconveniente. Más adelante podemos solicitar la
>> creación de una lista para la asociación o crear una nosotros.
>>
>> He recopilado los puntos que habéis hablado hasta ahora y alguno más.
>> Los he puesto en un pad a modo de borrador del orden del día. Por favor,
>> revisadlo y añadid o cambiad lo que veáis oportuno:
>>
>> https://public.pad.fsfe.org/p/osm-es
>>
>> Saludos,
>> Santiago Crespo
>>
>> [1] http://irc.openstreetmap.org/
>>
>> On 07/25/2016 11:18 PM, Miguel Sevilla-Callejo wrote:
>>> Vuelvo a escribir sobre el tema retomando el mensaje de Santiago Higuera
>>> en el otro hilo de la lista [1] en el que proponía:
>>>
>>> 1. entregar los papeles a una gestoría especializada en ONGs --> A mi me
>>> parece genial que haya alguien que nos pueda echar una mano y entre
>>> todos podríamos asumir un pequeño coste. Santiago, ¿sigues dispuesto a
>>> llevar los papeles allí? Tendría que devolvértelos Pedro-Juan, ¿no?
>>>
>>> 2. quedar vía hangout --> alguien se atreve a hacerlo esta misma semana,
>>> ¿o ya para septiembre? (doy por descontado que en agosto estamos muchos
>>> lejos del ordenador)
>>>
>>> Quizá podemos ir pronunciándonos por esta vía o por Telegram e ir
>>> atacando las ideas que se nos vayan ocurriendo ya con los estatutos de
>>> la asociación sobre la mesa.
>>>
>>> Un saludo
>>>
>>> Miguel
>>>
>>> [1] https://lists.openstreetmap.org/pipermail/talk-es/2016-April/013979.html
>>>
>>> --
>>> *Miguel Sevilla-Callejo*
>>> *
>>> Doctor in Geography*
>>> a. Associate Lecturer at Dpto. of Geography & Territorial Planning at
>>> University of Zaragoza
>>> b. Fellow at the Pyrenean Institute of Ecology - Spanish National
>>> Research Council
>>> c. Freelance consultant & researcher - Member #698, Spanish Professional
>>> Association of Geographers
>>>
>>> *Doctor en Geografía*
>>> a. Profesor asociado en el Dpto. de Geografía y Ordenación del
>>> Territorio de la Univ. de Zaragoza
>>> b. Colaborador del Instituto Pirenaico de Ecología - Consejo Superior de
>>> Investigaciones Científicas
>>> c. Consultor e investigador freelance - Colegiado 698 del Colegio
>>> Oficial de Geógrafos
>>>
>>> 2016-07-25 18:19 GMT+02:00 Miguel Sevilla-Callejo >> >:
>>>
>>> Hola,
>>>
>>> Han pasado ya casi cuatro meses desde que nos dimos un ultimátum
>>> para ver si nos poníamos manos a la obra para reactivar la
>>> asociación OpenStreetMap España que os recuerdo surgió de la última
>>> reunión con el IGN y que prosiguió en el siguiente hilo de esta lista:
>>> https://lists.openstreetmap.org/pipermail/talk-es/2016-April/013972.html
>>>
>>> Como se comentó en el mismo hilo, estábamos dispuestos a arrimar el
>>> hombro un buen puñado de personas (cerca de una veintena tengo ahora
>>> contabilizados) y 

Re: [Talk-es] Reunion con el Ayntamiento de Girona

2016-08-07 Per discussione Carlos m
Hola Xavier,


Sí que es buena idea, y más aún si llegara a exportarse a otros municipios como 
dices. ¿Cómo podemos/ puedo ayudar?...


Un saludo,

Carlos Medina



De: Xavier Barnada 
Enviado: sábado, 6 de agosto de 2016 14:19
Para: Discusión en Español de OpenStreetMap
Asunto: [Talk-es] Reunion con el Ayntamiento de Girona

Hola lista,

Ayer tuve una reunión con el Ayuntamiento de Girona i me gustaría explicaros lo 
que me comentaron que querían hacer:

Quieren revisar y actualizar los datos de Girona de los siguientes elementos:

  1.  Calles
  2.  Edificios
  3.  Números de puerta

El problema con que se encuentran es que publicando la información en otras 
plataformas(no libres) no tienen control sobre los datos finales, ni con el 
tiempo de actualización, en cambio con OpenStreetMap puede publicar los datos, 
saben como se publicaran finalmente y que se actualizaran al instante.

Por otro lado el hecho de que terceros usen los datos de OpenStreetMap requiere 
que los datos de calles,edificios y números de puerta de la ciudad de Girona 
estén el máximo de correctos posible.

En el caso que esto funcione correctamente el siguiente paso que seria hacer lo 
mismo con los datos de navegación.

A parte de esto también me comentaron que están abiertos a ayudarnos y 
colaborar ya sea con eventos o aportación de tatos para mejorar y difundir 
OpenStreeetMap.

Personalmente creo que es una oportunidad muy interesante y puede ser exportada 
a otros municipios.

Si alguien quiere colaborar en alguna cosa solo lo tiene que decir. Ahora 
mismos estoy mirando como vigilar los cambios en una zona.

Saludos
Xavier Barnada


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


Re: [OSM-talk-fr] Changement de nom réseau / opérateurs suite changement de type de regroupement de communes

2016-08-07 Per discussione lenny.libre



Le 07/08/2016 à 11:29, Frédéric Rodrigo a écrit :

Le 07/08/2016 à 10:42, lenny.libre a écrit :




Le 06/08/2016 à 14:33, osm.sanspourr...@spamgourmet.com a écrit :


J'aime beaucoup la page Wikipédia qui annonce un budget 2011 pour 
une entité datant de 2015.


Car oui comme dit la CUB est devenue Bordeaux Métropole.

Sur https://www.wikidata.org/wiki/Q1117116 les noms hormis en 
français et occitan sont toujours basés sur la CUB.


si on avait les ref:Q1117116 on n'aurait pas à les changer mais il 
faut adapter les outils. Car un tel code est sujet à typo et côté 
ergonomie homme-machine on a vu mieux.


Je n'avais pas compris grand-chose dans la précédente discussion ... 
est-ce un tag a ajouter (lequel) ou une modification de josm, ID, ... 
ou doit-il encore faire l'objet de discutions au niveau des listes 
internationales ?


L'autre CUB (Communauté Urbaine de Brest) est devenue Brest 
Métropole Océane puis plus simplement Brest Métropole.


Je n'ai pas trouvé de traces de CUB dans le coin. Et name:bm ce 
n'est pas du bordelais mais du bambara.


Je serais plutôt pour un remplacement systématique.

Je n'ai jamais fait de remplacement systématique, mais, j'ai préparé 
(ce que je pensais possible de faire) et j'aimerais qu'on me dise si 
c'est ok:


- j'ai recherché dans http://overpass-turbo.eu/ les objets
"network=TBC" sur une surface équivalente à la métropole
- chargement des données vers josm avec réparation
- dans josm recherche des objets "network=TBC",
- il m'en ramène 2494
- je remplace "TBC" par "TBM"
- il trouve des erreurs "nœuds dupliqués", vérification (ils ont
les mêmes attributs) et suppression des plus récents
- il trouve une liste d'avertissements longue comme "un jour sans
pain" (89) je suis pas prêt de tous les vérifier
- dans quelques semaines, quand j'ai tout vérifié et corrigé si
nécessaire j'envoie ?

Moi je suis ok sur le principe. Mais il je pense qu'il vaut mieux 
séparer toutes les actions. Un changeset par opération, corriger les 
doublons avec JOSM par exemple... peut d’ailleurs déjà être fait, vu 
que ça n'a aucun lien avec le reste.
Tout à fait d'accord, j'ai le remplacement dans un calque (sur lequel il 
n'y a que les éléments "TBC") et un autre calque dans lequel je 
télécharge la zone de l'erreur.


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


[Talk-gb-westmidlands] Notes from yesterday

2016-08-07 Per discussione Rob Nickerson
Hi all,

Good to see so many people in Pershore yesterday. As we spoke about
OpenStreetView I promised I'd share the link to the video from SotM US.
Here it is:

http://stateofthemap.us/2016/openstreetview/

It's very impressive and brings a lot of new ideas that Mapillary doesn't
include. I used it yesterday and found it to be good (a few small issues
but not bad considering this is the very first version).

Examples:
http://openstreetview.com/details/11546/28
http://openstreetview.com/details/11544/44

We didn't speak about this, but there will be an award ceremony at State of
the Map. Please submit nominations (after logging in to your OSM account):

https://lists.openstreetmap.org/pipermail/osmf-talk/2016-August/003904.html

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


Re: [OSM-talk-fr] Changement de nom réseau / opérateurs suite changement de type de regroupement de communes

2016-08-07 Per discussione Frédéric Rodrigo

Le 07/08/2016 à 10:42, lenny.libre a écrit :




Le 06/08/2016 à 14:33, osm.sanspourr...@spamgourmet.com a écrit :


J'aime beaucoup la page Wikipédia qui annonce un budget 2011 pour une 
entité datant de 2015.


Car oui comme dit la CUB est devenue Bordeaux Métropole.

Sur https://www.wikidata.org/wiki/Q1117116 les noms hormis en 
français et occitan sont toujours basés sur la CUB.


si on avait les ref:Q1117116 on n'aurait pas à les changer mais il 
faut adapter les outils. Car un tel code est sujet à typo et côté 
ergonomie homme-machine on a vu mieux.


Je n'avais pas compris grand-chose dans la précédente discussion ... 
est-ce un tag a ajouter (lequel) ou une modification de josm, ID, ... 
ou doit-il encore faire l'objet de discutions au niveau des listes 
internationales ?


L'autre CUB (Communauté Urbaine de Brest) est devenue Brest Métropole 
Océane puis plus simplement Brest Métropole.


Je n'ai pas trouvé de traces de CUB dans le coin. Et name:bm ce n'est 
pas du bordelais mais du bambara.


Je serais plutôt pour un remplacement systématique.

Je n'ai jamais fait de remplacement systématique, mais, j'ai préparé 
(ce que je pensais possible de faire) et j'aimerais qu'on me dise si 
c'est ok:


- j'ai recherché dans http://overpass-turbo.eu/ les objets
"network=TBC" sur une surface équivalente à la métropole
- chargement des données vers josm avec réparation
- dans josm recherche des objets "network=TBC",
- il m'en ramène 2494
- je remplace "TBC" par "TBM"
- il trouve des erreurs "nœuds dupliqués", vérification (ils ont
les mêmes attributs) et suppression des plus récents
- il trouve une liste d'avertissements longue comme "un jour sans
pain" (89) je suis pas prêt de tous les vérifier
- dans quelques semaines, quand j'ai tout vérifié et corrigé si
nécessaire j'envoie ?

Moi je suis ok sur le principe. Mais il je pense qu'il vaut mieux 
séparer toutes les actions. Un changeset par opération, corriger les 
doublons avec JOSM par exemple... peut d’ailleurs déjà être fait, vu que 
ça n'a aucun lien avec le reste.



Tu vas aussi pouvoir changer les couleurs des lignes de bus ;-)

Je ne me suis jamais préoccupé des couleurs, mais bon il faut bien le 
faire un jour :

Je n'ai pas trouvé dans les datas de BM des infos sur les couleurs en hex
Je suis donc parti des couleurs représentées sur le site TBM que j'ai 
mises à gauche et à droite celles que j'ai trouvées approchantes. N'y 
a-t-il pas dans le wiki une page Bordeaux comme celle de Toulouse 
(http://wiki.openstreetmap.org/wiki/Toulouse/Transports_en_commun) ?

bleu #008BCF
orange #ED862F
vert #7B9C41
bleu foncé #292059
Cela vous semble correct ? Par contre, je ne pourrais pas le faire 
avant 2 semaines.


Bon dimanche
léni


___
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-de] Mappingparties - OSM Usergroup Bremen

2016-08-07 Per discussione Günther Meyer

Hallo Mapper,

OSM Usergroup Bremen führt diese Jahr zwei Mappingparties durch. Die 
erste Party findet am 20.08.2016 statt. Sie soll Anfänger in die Lage 
versetzen POIs zu erstellen, ergänzen und zu pflegen. Die zweite Party 
ist am 03.09.2016. Sie richtet sich an Fortgeschrittene Mapper, und wird 
das Thema Relationen am Beispiel von ÖPNV-Linien behandeln. Siehe: 
www.osm-bremen.de


LG gm-bremen


---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de


Re: [OSM-talk-fr] Changement de nom réseau / opérateurs suite changement de type de regroupement de communes

2016-08-07 Per discussione lenny.libre



Le 06/08/2016 à 14:33, osm.sanspourr...@spamgourmet.com a écrit :


J'aime beaucoup la page Wikipédia qui annonce un budget 2011 pour une 
entité datant de 2015.


Car oui comme dit la CUB est devenue Bordeaux Métropole.

Sur https://www.wikidata.org/wiki/Q1117116 les noms hormis en français 
et occitan sont toujours basés sur la CUB.


si on avait les ref:Q1117116 on n'aurait pas à les changer mais il 
faut adapter les outils. Car un tel code est sujet à typo et côté 
ergonomie homme-machine on a vu mieux.


Je n'avais pas compris grand-chose dans la précédente discussion ... 
est-ce un tag a ajouter (lequel) ou une modification de josm, ID, ... ou 
doit-il encore faire l'objet de discutions au niveau des listes 
internationales ?


L'autre CUB (Communauté Urbaine de Brest) est devenue Brest Métropole 
Océane puis plus simplement Brest Métropole.


Je n'ai pas trouvé de traces de CUB dans le coin. Et name:bm ce n'est 
pas du bordelais mais du bambara.


Je serais plutôt pour un remplacement systématique.

Je n'ai jamais fait de remplacement systématique, mais, j'ai préparé (ce 
que je pensais possible de faire) et j'aimerais qu'on me dise si c'est ok:


   - j'ai recherché dans http://overpass-turbo.eu/ les objets
   "network=TBC" sur une surface équivalente à la métropole
   - chargement des données vers josm avec réparation
   - dans josm recherche des objets "network=TBC",
   - il m'en ramène 2494
   - je remplace "TBC" par "TBM"
   - il trouve des erreurs "nœuds dupliqués", vérification (ils ont les
   mêmes attributs) et suppression des plus récents
   - il trouve une liste d'avertissements longue comme "un jour sans
   pain" (89) je suis pas prêt de tous les vérifier
   - dans quelques semaines, quand j'ai tout vérifié et corrigé si
   nécessaire j'envoie ?


Tu vas aussi pouvoir changer les couleurs des lignes de bus ;-)

Je ne me suis jamais préoccupé des couleurs, mais bon il faut bien le 
faire un jour :

Je n'ai pas trouvé dans les datas de BM des infos sur les couleurs en hex
Je suis donc parti des couleurs représentées sur le site TBM que j'ai 
mises à gauche et à droite celles que j'ai trouvées approchantes. N'y 
a-t-il pas dans le wiki une page Bordeaux comme celle de Toulouse 
(http://wiki.openstreetmap.org/wiki/Toulouse/Transports_en_commun) ?

bleu #008BCF
orange #ED862F
vert #7B9C41
bleu foncé #292059
Cela vous semble correct ? Par contre, je ne pourrais pas le faire avant 
2 semaines.


Bon dimanche
léni
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk] New Google Maps style - interesting cartographic innovation

2016-08-07 Per discussione Maarten Deen

On 2016-08-07 08:29, Michał Brzozowski wrote:

On Sun, Aug 7, 2016 at 8:05 AM, Maarten Deen  wrote:
I don't know if I understand you right, but different colors for 
different

purposes is hardly an innovation.


You haven't got the point I guess. The new thing is that this process
is carried out automatically (for most cases).


I still don't see the innovation. So it's a heatmap for POI's?

Maarten


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


Re: [OSM-talk] New Google Maps style - interesting cartographic innovation

2016-08-07 Per discussione Michał Brzozowski
On Sun, Aug 7, 2016 at 8:05 AM, Maarten Deen  wrote:
> I don't know if I understand you right, but different colors for different
> purposes is hardly an innovation.

You haven't got the point I guess. The new thing is that this process
is carried out automatically (for most cases).

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


[OSM-ja] 証券会社の定義、ありましたっけ

2016-08-07 Per discussione ribbon
街中でよく見かけるお店(?)として、証券会社があります。
野村證券とか。

証券会社の定義、ありましたっけ?

ribbon

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


Re: [OSM-talk] New Google Maps style - interesting cartographic innovation

2016-08-07 Per discussione Maarten Deen

On 2016-08-07 01:43, Michał Brzozowski wrote:

There has been an update to Google Maps styling [1] and I have to say,
they left me impressed.
The overall look is cleaner, which is very welcome after a series of
disappointing changes, but the thing I consider very innovative is how
buildings (and on lower zooms - areas) with lots of "activities" (i.e.
POIs) are highlighted in beige.


I don't know if I understand you right, but different colors for 
different purposes is hardly an innovation.


And overall I find the new Google Maps look not an improvement. The same 
as with the last OSM change, every color was toned down. All colors came 
closer together, highlights are gone, everything is more bland. If you 
evolve this you would get a white map.


Regards,
Maarten


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