date:20161213

@Thundercel, talvez pode até ser que a gente esteja generalizando
todas as suas edições equivocadamente, por causa de um/alguns erro(s)
quem sabe. Mas é fato que ele, em pelo menos algumas edições, copiou
dados do google. São coisas que ficam muito evidente, senão como se
explicaria o seguinte (veja esta imagem explicativa que eu fiz:
http://imgur.com/a/hB9om). Alguém discorda?

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

Re: [Talk-br] Correção de alguns postos de combustível no Brasil

@Gerald, É bem provável que a maioria das coisas vão bem no maps.me,
porém deve haver algumas coisas, sei lá, mal traduzidas quem sabe. Vou
citar um exemplo. Já vi mais de uma pessoa adicionar uma lavanderia de
roupas quando na verdade queria ter adicionado um lava rápido de
carros. Ex.: https://www.openstreetmap.org/node/4552435003 +
https://www.openstreetmap.org/note/815097

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

Re: [Talk-br] Possível cópia de nomes de ruas do Google

2016-12-13 Per discussione thundercel

Não perguntei a ele se copiou dados do Google, ao contrário, disse-lhe que 
não pode empregar dados do google e isso ele entendeu.


Aí está a questão do approach ao editor. Ao acusarmos que copiou dados do 
google já estamos sentenciando e se o indivíduo não copiou esse pode se 
ofender com a acusação.


Como citei no grupo do telegram, difícil acusar alguém se não soubermos a 
fonte empregada para a edição. As vezes alguns dados podem estar semelhantes 
aos estampados no google, mas devemos ter em mente que em caso de igualdade 
é de suma importância que busquemos as fontes de referencia empregadas 
porque tanto o google como o editor podem ter empregado a mesma fonte.


Quando cheguei em Vila Velha - ES, onde resido desde janeiro deste ano, a 
rua onde moro estava no Google e OSM como Rua Aquino de Araújo quando na 
verdade ela se chama Aquino Araújo, sem o "de". Alterei no OSM e pude 
constatar que assim está no mapa do IBGE, sem o "de".


Não sei de onde o Google tirou o "de" no nome, mas a placa na Rua tem 
erradamente o "de". A placa está errada e o IBGE certo.


Nesse exemplo prático alguns poderiam concluir que o editor copiou o erro do 
"de" do google e acusar quem editou a ter copiado.


Acho que não até porque a placa na rua tem o "de".

Com tudo isso quero concluir instando aos amigos a não tirarem conclusões 
precipitadas de um fato observado em edições que sabemos não serem maldosas.


[]s
Marcio

-Mensagem Original- 
From: santamariense

Sent: Tuesday, December 13, 2016 10:17 PM
To: talk-br@openstreetmap.org
Subject: Re: [Talk-br]Possível cópia de nomes de ruas do Google

@Thundercel, concordo contigo que a intenção do Gabriel é boa (ver o
OSM progredir), mas  como comentei numa changeset, não adianta
construir um castelo de areia. Porque se foi copiado dados
indevidamente, eles tem que ser excluídos, e quanto mais tarde, pior,
porque se bobear teremos ainda que excluir dados que porventura possam
ter sido derivados dos dados que ele adicionou (bola de neve). E pode
crer que isso não dói só a ele, porque aposto que qualquer um de nós
fica sentido de ter que regredir o OSM. Enfim, que bom que ele fala
com alguém de nós. Não acho que ele deva ser afastado, mas ele precisa
estar ciente das consequências das cópias inadequadas que ele fez para
não persistir no erro.
Se tu ensinar ele a usar a camada do IBGE para pegar os nomes das ruas
e ele começar a usar, as coisas se alinham.

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



---
Este email foi escaneado pelo Avast antivírus.
https://www.avast.com/antivirus


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

Re: [Talk-br] Mitula esta usando mapas do OSM sem dar créditos

Enviei um e-mail solicitando a atribuição. Vou esperar 15 dias (???) e
então em caso de não correção, vou contactar a Mapbox pelo link que o
@naoliv apresentou.

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

Re: [OSM-talk-fr] Du bon usage des tags loc_name et historic

2016-12-13 Per discussione Jérôme Amagat

Avec les autre tag que historic=* il faut tagger ce que c'est aujourd'hui,
par exemple si c'est encore un moulin mettre man_made=waterfill sinon
seulement building=yes s'il reste juste un bâtiment. Dans osm on ne met
normalement que le présent.
Par contre pour historic=* indiquer ce qui fait de cette endroit quelque
chose d'historique qui appartient au patrimoine un ancien moulin :
historic=waterfill, une ancienne ferme : historic=farm (sur un bâtiment ou
quelque chose de plus grand si si le terrain aussi a "quelque chose
d'historique").
On peut perdre des info en nottant historic=waterfill plutot que quelque
chose comme historic:man_made=waterfill mais c'est l'usage jusqu'a
maintenant.

Enfin c'est comme ça que j'ai fait jusqu’à maintenant, j'ai ajouter des
historic=* avec les monuments historiques en France. J'ai ajouter, par
exemple, des historic=church en plus des amenity=place_of_worship (et
building=church) quand l’église était inscrit ou classé et servait toujours
d’église. des historic=house pour un bâtiment d'habitation historique. (et
beaucoup de historic=yes quand je savais pas trop quoi mettre).

En rapport avec ça j'ai une question sur le tag historic=castle, c'est
comme ça qu'il faut indiqué les châteaux mais c'est quoi un château? Un
bâtiment, des remparts ou murs et tous ce qu'il y a à l’intérieur, des
bâtiments et ce qui en dépend (jardins, parcs, écuries, bâtiments annexe,
...) ou autre chose?

Pour ton problème des noms locaux je sais pas trop, ça a une valeur donc
pourquoi pas l'indiquer dans osm mais c'est pas vraiment le nom de l'objet
indiqué sauf ci par exemple c'est la "Cazelle Machin" sinon je pense pas
que ça a vraiment sa place dans name ou loc_name.
Pour cazelle (je viens de regarder la définition) c'est un type de bâtiment
donc pourquoi pas building=cazelle mais sinon peut être dans description=*
ça a plus sa place.
Pour lavogne (pareil je viens de regarder la définition) peut etre
natural=water water=lavogne. (le natural dans natural=water ne veux pas
dire que c'est "naturel" "sans intervention de l'homme" vu qu'on l’utilise
aussi pour par exemple les lacs de barrage ou les canaux)

Le 13 décembre 2016 à 23:24, Christian Quest  a
écrit :

> Le 13 décembre 2016 à 20:49, domlysz  a écrit :
>
>> Je travail actuellement sur un ensemble de tags concernant du patrimoine
>> bâti
>> agropastorale et il y a deux points qui me pose question :
>>
>> Bien souvent ces élèments de patrimoine sont désignés par des noms locaux
>> très spécifiques par exemple cazelle, lavogne, jasse, clapas...
>>
>> Pour le moment dans mes tags j'utilise la clé /loc_name/ pour renseigner
>> cette information. Ce choix est inspiré par  ce glossaire
>> > Garrigues_Histoire>
>> mais il me semble que cette clé est mal choisie car elle devrait être le
>> pendant de /name/ et donc désigner un nom de lieu en usage localement et
>> non
>> un type de bâti.
>>
>> Néanmoins il est primordial que ces dénominations apparaissent dans mes
>> tags
>> et qu'elles soient associées à une clé parfaitement identifiable et
>> commune
>> à toute ma typologie car il s'agit pour moi d'un élément filtrant fort.
>> Malheureusement j'ai bien du mal à trouver quelque-chose de mieux que
>> /loc_name/, c'est pourquoi j'en appel à vos connaissance pour des
>> suggestions.
>>
>>
>> L'autre point concerne le tag /historic/. Ce tag me semble indispensable
>> pour refléter le fait qu'il s'agisse de patrimoine, pourtant son usage à
>> tendance à cacher d'autre information. Par exemple pour une ferme on
>> écrira
>> simplement /building=farm/ mais s'il s'agit d'un bâtiment à l'architecture
>> vernaculaire remarquable on écrira plutôt /historic=farm/ or dans ce cas
>> on
>> perds l'information building qui devient implicite au tag historic.
>
>
> A mon avis, historic=* doit décrire le caractère historique d'un objet,
> pas ce qu'est cet objet.
>
> Dans le cas d'une ferme, historic=farm peut très bien être mis sur un
> polygone qui englobe toute l'emprise de la ferme alors que building=farm
> pourra être mis sur un polygone d'un des bâtiments qui composent la ferme.
>
> Au pire, on peut avoir les deux tags sur le même polygone (building=farm +
> historic=yes), cela ne posera pas de problème... et un tag historic seul me
> ferait plus penser que le bâtiment n'existe plus que d'imaginer qu'on a
> implicitement un bâtiment. L'implicite de ce genre ça ne marche pas trop.
>
>
>
>
>> De la
>> même façon si je veux décrire un ancien moulin je peux écrire
>> /man_made=waterfill/ ou bien /historic=waterfill/, pour un chemin
>> historique
>> /highway=path/ ou /historic=path/ ...
>>
>>
> historic=yes... comme indiqué dans le wiki: "Used to add the historic
> significance of the objects described by other tags."
>
>
>> Pour résoudre ce problème j'aurai tendance à vouloir écrire
>> /historic:building=farm, historic:man_made=waterfill/ ... mais je
>>

Re: [Talk-br] Possível cópia de nomes de ruas do Google

@Thundercel, concordo contigo que a intenção do Gabriel é boa (ver o
OSM progredir), mas  como comentei numa changeset, não adianta
construir um castelo de areia. Porque se foi copiado dados
indevidamente, eles tem que ser excluídos, e quanto mais tarde, pior,
porque se bobear teremos ainda que excluir dados que porventura possam
ter sido derivados dos dados que ele adicionou (bola de neve). E pode
crer que isso não dói só a ele, porque aposto que qualquer um de nós
fica sentido de ter que regredir o OSM. Enfim, que bom que ele fala
com alguém de nós. Não acho que ele deva ser afastado, mas ele precisa
estar ciente das consequências das cópias inadequadas que ele fez para
não persistir no erro.
Se tu ensinar ele a usar a camada do IBGE para pegar os nomes das ruas
e ele começar a usar, as coisas se alinham.

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

Re: [Talk-pt] Importações em massa

2016-12-13 Per discussione Pedro Pereira

Boas,
Concordo que foram situações sem intenção de prejudicar o projeto.
Eu já fiz tb algumas importações, mas sorte minha, fui mais prudente e
apenas importei alguns locais (alguns dos mais incompletos), porque também
desconhecia que teria que discutir o assunto aqui na lista.
Agora já sei, assim que tenha mais informação tratarei de a partilhar e
discutir o seu interesse e forma de carregamento.
Abraço,
Pedro


2016-12-13 23:32 GMT+00:00 Jorge Gustavo Rocha :

> Olá Alexandre, olá malta,
>
> Acho que se devem discutir as importações exatamente para discutir como se
> concilia o que se importa com o que se faz no terreno.
>
> Neste caso, como em muitos outros, parece-me que o trabalho foi feito com
> boas intenções, mas não deixa de ser uma importação não discutida, que
> entra em conflito com o que se faz no terreno.
>
> Concordo que se deve reverter a importação da CLC neste local.
>
> Acho que se deve mandar uma mensagem ao utilizador "Reino Baptista" [1] a
> dizer que há trabalho que está a ser feito no terreno, cuja atualidade e
> qualidade é superior ao CLC e que, por isso, se deve reverter a importação
> da CLC. Sugiro até que seja o Alexandre a mandar a mensagem, argumentando
> que o caso já foi discutido na lista. Envolver o mapeador é simpático e
> pedagógico.
>
> Abraço,
>
> J. Gustavo
>
> [1] https://www.openstreetmap.org/user/Reino%20Baptista
>
> Às 22:38 de 13-12-2016, Marcos Oliveira escreveu:
>
>> Os scripts de importação não poderiam detectar estas sobreposições?
>>>
>>
>> No JOSM se for utilizada a validação dos dados detecta, quando são tags
>> idênticas ou similares (ex. usos do solo). Mas ai está, há quem não a
>> faça (ou pior, ignora). :)
>>
>> No dia 13 de dezembro de 2016 às 21:38, Alexandre Moleiro
>> >
>> escreveu:
>>
>> Sim, são esses changesets.
>>
>> Pois o que me desagrada é a sobreposição. Há áreas onde até parece
>> fazer sentido a importação pois eram um "deserto" em termos de
>> "landuse".
>>
>> Mas em zonas onde já existiam áreas a definir o landuse não me faz
>> sentido importar para cima e ficar uma mixórdia.
>>
>> Os scripts de importação não poderiam detectar estas sobreposições?
>>
>> A minha opinião pessoal é de reverter essas importações, por isso
>> até haver decisão da comunidade vou "pausar" o mapeamento desta zona.
>>
>> Saudações
>> Alexandre
>>
>> 2016-12-13 19:26 GMT+00:00 > >:
>>
>>
>> A posição do Data Working Group nos imports é brutal : se não
>> houve discussão o import é revertido (mesmo com um import bem
>> feito para obrigar as pessoas a entrar sempre em contacto com a
>> comunidade antes).
>>
>> Reverter ou não, acho que é uma decisão que deve ser tomado pela
>> comunidade (mais tempo se espera, pior é).
>> O importante para mim o é o conhecimento local, podemos sempre
>> importar dados, encontrar pessoal da região que dedica o seu
>> tempo para o OSM é o mais complicado.
>>
>> Francisco
>>
>>
>>
>> ___
>> Talk-pt mailing list
>> Talk-pt@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-pt
>> 
>>
>>
>>
>>
>> --
>> Um Abraço,
>> Marcos Oliveira
>>
>>
>> ___
>> Talk-pt mailing list
>> Talk-pt@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-pt
>>
>>
> J. Gustavo
> --
> Jorge Gustavo Rocha
> Departamento de Informática
> Universidade do Minho
> 4710-057 Braga
> Tel: +351 253604480
> Fax: +351 253604471
> Móvel: +351 910333888
> skype: nabocudnosor
>
>
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>



-- 
Pedro Pereira
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

Re: [Talk-br] Possível cópia de nomes de ruas do Google

Eu passei por acaso por uma das edições dele, de 3 ou 4 meses atrás,
explicando que era desnecessário colocar o nome "Estrada" nas vias. Depois
enviei uma mensagem convidando-o a participar das listas. Não recebi
resposta. Isto foi no dia 8/12. Procuro sempre ser o mais educado possível,
mas nem sempre tenho sucesso.

Se temos o contato dele acho que podemos ir com calma. Me preocupa são os
casos em que a pessoa não responde de jeito nenhum.

Realmente verificar 10 mil micro-edições é osso. Não tem algum script
esperto para aglutinar isto em macro-edições que facilitem a verificação?
Tipo comparando a data-hora da edição? Não é possível que só nós temos este
problema.

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

Re: [Talk-br] Possível cópia de nomes de ruas do Google

2016-12-13 21:27 GMT-02:00  :
> Quanto a exclusões de nomenclaturas feitas por ele no dia de hoje deduzo que
> isso ocorreu por comentários que fiz a ele quanto a nunca empregar dados do
> google. Se empregou e excluiu os dados, pelo menos a mim comprova as boas
> intensões dele e a vontade de aprender e corrigir seus erros.

Mas você consegue ver que fica o problema de identificar onde foi
copiado e também de remover isso? Não apenar apagar o nome, mas
precisa remover do banco de dados.

Independente de ter sido com boas ou más intenções, os nomes copiados
do Google precisam ser removidos.

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

Re: [Talk-br] Correção de alguns postos de combustível no Brasil

Eu fiz exatamente 1 edição via maps.me para entender o procedimento. Fica
claro que vai pro OSM, mas se você não sabe do que se trata não sei que
diferença faz. Fico imaginando o que será que o sujeito que coloou "casa da
sogra" estava pensando.

O que achei estranho é o que o aplicativo diz que tudo é verificado.
Verificado por quem? Nós?

Agora da minha parte, até o momento o que eu encontrei mapeado via maps.me
estava válido.

abraço

Geald

2016-12-13 21:44 GMT-02:00 Luiz Gustavo :

> O maps.me deixa (mais) claro na primeira edição que os dados vão para o
> OSM.
>
> Mas no fim do formulário de toda edição é exibida a informação na *imagem
> em anexo.*
>
>
> Em 13/12/2016 6:16 PM, "santamariense"  escreveu:
>
>> Também tenho percebido a criação destes eletropostos em locais muito
>> improváveis. Eu pessoalmente não conheço nenhum.
>>
>> Eu não uso o maps.me, mas parece que além dele introduzir os erros no
>> mapa, ele não deixa muito claro que os objetos são publicados no OSM.
>> Ou deixa claro?
>>
>> Tenho visto muito "Casa", "Casa do Fulano", "Casa do Ciclano", até
>> "Casa da sogra"
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Correção de alguns postos de combustível no Brasil

2016-12-13 Per discussione Luiz Gustavo

O maps.me deixa (mais) claro na primeira edição que os dados vão para o OSM.

Mas no fim do formulário de toda edição é exibida a informação na *imagem
em anexo.*


Em 13/12/2016 6:16 PM, "santamariense"  escreveu:

> Também tenho percebido a criação destes eletropostos em locais muito
> improváveis. Eu pessoalmente não conheço nenhum.
>
> Eu não uso o maps.me, mas parece que além dele introduzir os erros no
> mapa, ele não deixa muito claro que os objetos são publicados no OSM.
> Ou deixa claro?
>
> Tenho visto muito "Casa", "Casa do Fulano", "Casa do Ciclano", até
> "Casa da sogra"
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Possível cópia de nomes de ruas do Google

2016-12-13 Per discussione thundercel


Minha opinião:

Conversando hoje com ele por telefone esse me disse que residiu por muito 
tempo no Acre e que bem conhece toda aquela região. Algumas edições dele no 
Acre foram questionadas de forma não recomendada.


Volto a citar que ele demonstra querer colaborar com a comunidade, mas está 
muito desmotivado pela falta de respeito a ele quando de alguns 
questionamentos em seus changsets.


Quanto a exclusões de nomenclaturas feitas por ele no dia de hoje deduzo que 
isso ocorreu por comentários que fiz a ele quanto a nunca empregar dados do 
google. Se empregou e excluiu os dados, pelo menos a mim comprova as boas 
intensões dele e a vontade de aprender e corrigir seus erros. Erros que por 
sinal todos nós tivemos quando iniciamos e continuamos tendo já que o 
aprendizado é constante.


Não o conheço pessoalmente, só por telefone, entretanto esse a mim 
transparece que só quer contribuir e apesar de defender que quantidade não 
significa qualidade, não vejo com bons olhos afastamentos de elementos que 
querem ajudar.


Acredito que devemos nos preocupar mais com aqueles que editam de forma 
maldosa, estragando o trabalho dos demais. Esses sim,  devem ser banidos 
apesar de sabermos que banimento não impede que o usuário volte com outro 
nome.


[]s

Marcio



-Mensagem Original- 
From: Nelson A. de Oliveira

Sent: Tuesday, December 13, 2016 5:24 PM
To: OSM talk-br
Subject: [Talk-br] Possível cópia de nomes de ruas do Google

Verificando alguns problemas de locais eu reparei que os nomes de ruas
daqui são muito similares aos nomes do Google:

https://www.openstreetmap.org/#map=17/-22.72876/-44.84862

Inclusive tendo o nome do local
https://www.openstreetmap.org/node/4472678103 idêntico ao do Google
(Chácara São Judas Tadeu),
como pode ser visto em
https://www.google.com.br/maps/@-22.7285485,-44.849262,18z

Pela camada do IBGE rural o local talvez poderia ser "São Bom Jesus".

Se alguém clicar no POI da chácara no Google e ir para o website (que
vai cair numa página do Facebook) verá que ela está localizada no
"Bairro do Bom Jesus".

Independente do nome ser "São Bom Jesus", "Bairro do Bom Jesus" ou
alguma outra variação, é certo que "Chácara São Judas Tadeu" não é o
nome dessa localidade.
Parece claro que, neste caso, houve também uma cópia incorreta do nome
do local (que é apenas uma chácara particular).

Um outro exemplo:
http://mc.bbbike.org/mc/?lon=-67.732649=-10.14355=17=4=mapnik=google-map=bing-map=nokia-map

A "Rua Felício Abraão" só existe no Google (e no OSM)
Em todo os outros, incluindo o IBGE, é Abrahão (com H).

Muitas ruas nesse lugar batem com o Google, sendo identificáveis nos
pequenos detalhes de grafia.

Nos changesets vistos rapidamente dá para ver que não foi habilitada a
camada do IBGE ao inserir o nome das ruas.

No Telegram foi questionado que ele "Talvez conheça o nome das ruas de
onde mora".
Saber o nome das ruas de onde a pessoa mora é aceitável. Saber o nome
das ruas de um lugar distante, coincidindo com o Google, já passa a
ficar estranho.

Outro ponto é que algumas ruas aparentam estar representadas com nomes
de conhecidos ou familiares.

Exemplos:
Estava com nome de "Rua Lécio Rus Tôrres"
https://www.openstreetmap.org/way/279927998/history e ele retirou hoje
(não existe nenhuma rua com esse nome na Internet)

Estava com nome de "Rua Júlio Vilela"
https://www.openstreetmap.org/way/442473942/history e ele retirou hoje
(repare que o sobrenome é Vilela)

Estava com nome de "Rua Helana Da Silva Vilela"
https://www.openstreetmap.org/way/279728229/history e ele retirou hoje
(sobrenome Vilela)

Estava com nome de  "Rua Rosilene Vilela"
https://www.openstreetmap.org/way/279927994/history (mesma coisa)

Estranhamente essas ruas de cima tiveram os nomes removidos hoje.

Mas ainda é possível ver algumas ruas que não foram modificadas por
outros usuários, todas contendo "Vilela" em seus nomes:
http://overpass-turbo.eu/s/kDs

Tem nome que dá para procurar na Internet e ver que é uma pessoa real,
com endereço, telefone, etc, e que reside em Barra Mansa (onde
aparentemente o Gabriel reside).

Nessa parte me parece que muitas ruas foram nomeadas, de forma
incorreta, com nome de familiares ou conhecidos.

Muitas mensagens que foram enviadas ele não respondeu (desde outra
época, onde alguns dados foram alterados de forma incorreta).

Segundo o Marcio (Thundercel) ele é idoso e tem algumas limitações no
uso da Internet (e que por isso não recebeu os avisos de mensagens).
Ele também disse que o Gabriel se sentiu ofendido em um dos comentários.

Por mais bem intencionada que a pessoa esteja, dá para ver que algumas
coisas foram inseridas de maneira incorreta, com outras possivelmente
copiadas de onde não possuímos permissão.

O problema é que são quase 10 mil changesets.
Não dá para verificar um por um, além de ter duas questões
importantes: quais objetos possuem de fato um nome correto (e não um
nome fictício ou de conhecido) e quais objetos possuem o nome copiado.

Alguma sugestão?

Re: [Talk-br] Mitula esta usando mapas do OSM sem dar créditos

2016-12-13 20:57 GMT-02:00 santamariense :
> Mapbox, talvez?

É do Mapbox sim.
Já mandou e-mail para eles do Mitula?

Se não responderem após algumas tentativas de contato, talvez o
caminho seja https://www.mapbox.com/blog/report-attribution-problems/

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

Re: [Talk-br] Possível cópia de nomes de ruas do Google

2016-12-13 20:51 GMT-02:00 santamariense :
> eu sou plenamente favorável a pressionar
> que o editor ID salve as modificações numa mesma changeset.

Já tentaram isso https://github.com/openstreetmap/iD/issues/1598
Já tentamos também https://github.com/openstreetmap/iD/issues/2251

Deve ter vários outros tickets. Isso não vai mudar nunca no iD.

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

[Talk-br] Mitula esta usando mapas do OSM sem dar créditos

Hoje percebi que o site Mitula>Imóveis está usando mapa derivado do
OSM sem dar o devido crédito. Não estou bem certo de qual é a
renderização daquele mapa. Vejam exemplo em
http://imoveis.mitula.com.br/searchRE/q-Santa-Maria-RS . Mapbox,
talvez? Mas tenho certeza que é do OSM.

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

Re: [Talk-br] Possível cópia de nomes de ruas do Google

Desfazer tudo? Errar é humano. Só não corre o risco de errar no OSM
aqueles que não contribuem. Se ao menos ele respondesse, a gente
poderia achar uma solução mais apropriada.

Independente desta changeset, eu sou plenamente favorável a pressionar
que o editor ID salve as modificações numa mesma changeset. Ou seja, a
pessoa abre o editor, vai fazendo suas contribuições, todas em uma
mesma changeset, depois que ela sair fecha a changeset, tal como
funciona o Potlatch2. No ID o que acontece... (se estou enganado me
corrijam)... você move um nó e salva (1 changeset), você adiciona uma
tag e salva (2 changeset), ... Enfim pelos meus cálculos as changesets
do Gabriel poderiam girar em torno de 150, e não o astronômico 10 mil.

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

Re: [Talk-pt] Importações em massa

2016-12-13 Per discussione Marcos Oliveira

>Os scripts de importação não poderiam detectar estas sobreposições?

No JOSM se for utilizada a validação dos dados detecta, quando são tags
idênticas ou similares (ex. usos do solo). Mas ai está, há quem não a faça
(ou pior, ignora). :)

No dia 13 de dezembro de 2016 às 21:38, Alexandre Moleiro <
alexandre.mole...@gmail.com> escreveu:

> Sim, são esses changesets.
>
> Pois o que me desagrada é a sobreposição. Há áreas onde até parece fazer
> sentido a importação pois eram um "deserto" em termos de "landuse".
>
> Mas em zonas onde já existiam áreas a definir o landuse não me faz sentido
> importar para cima e ficar uma mixórdia.
>
> Os scripts de importação não poderiam detectar estas sobreposições?
>
> A minha opinião pessoal é de reverter essas importações, por isso até
> haver decisão da comunidade vou "pausar" o mapeamento desta zona.
>
> Saudações
> Alexandre
>
> 2016-12-13 19:26 GMT+00:00 :
>
>>
>> A posição do Data Working Group nos imports é brutal : se não houve
>> discussão o import é revertido (mesmo com um import bem feito para obrigar
>> as pessoas a entrar sempre em contacto com a comunidade antes).
>>
>> Reverter ou não, acho que é uma decisão que deve ser tomado pela
>> comunidade (mais tempo se espera, pior é).
>> O importante para mim o é o conhecimento local, podemos sempre importar
>> dados, encontrar pessoal da região que dedica o seu tempo para o OSM é o
>> mais complicado.
>>
>> Francisco
>>
>
>
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>
>


-- 
Um Abraço,
Marcos Oliveira
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

Re: [Talk-it] Fwd: problema rendering mappe su alcuni punti di interesse

2016-12-13 Per discussione scratera

...non lo so ma per me ora sta peggiorando la situazione
area=yes
natural=stone
...un area circolare attorno al masso...



--
View this message in context: 
http://gis.19327.n8.nabble.com/problema-rendering-mappe-su-alcuni-punti-di-interesse-tp5887285p5887466.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-es] IGN en página de copyright de OSM y reunión inminente

2016-12-13 Per discussione yo paseopor

Va, voy a ser optimista, de hecho voy a soñar.
Y voy a "pulsar" la opinión directa de la "comunidad".  A partir de ahora
voy a hablar entre "pajamental" y "ciencia ficción", pero si alguien se ve
reflejado o entiende a qué me refiero es que vamos en la buena dirección.
Aunque sea un poco utópico imaginaos un Cartociudad + OSM. Este "Cartopaís"
vendría por la introducción de datos de Cartociudad siguiendo todas las
normas y protocolos que se nos exige en OSM para introducir datos. Es
cierto que tardaríamos un tiempo (lo veo como proyecto a medio plazo
empezando...ya) pero tendríamos por fases temáticas los datos de IGN más
actualizados que se dispongan, al hacer la importación deberíamos hacer la
conflación de datos con lo cual al final de cada proceso tendríamos los
datos más actualizados de Cartociudad + OSM.
Probablemente estos "proyectos de introducción de datos" pudieran ser de
dos tipos y en general a nivel español (sí sí, de todo el Estado,
Cartociudad funciona en todo el Estado Español, islas y otras naciones
incluídas ;)
-de temáticas concretas: vías de un tipo determinado (sí, la conflación
puede ser muy complicada, pero dado que seguro que no somos perfectos,
habrá datos no introducidos  - no ya trazados solo sino, nombres,
referencias, carriles, maxspeed, hgv..., masas de agua, cimas...
-de sitios concretos: zonas determinadas que no fueren significativas,
pequeñas a nivel de población, poco actualizadas, en definitiva, "poca
cobertura". En todas las provincias las hay, y quien más quien menos las
conoce y sabe dónde quedan.

Las dos cosas nos llevan a un "leve" cambio de fundamento del proyecto y
que alguna vez hemos debatido:el hecho de editar/trabajar/colaborar en
zonas que no son nuestras, o en intereses que son directamente los
nuestros. Mi experiencia en la comunidad catalana me dice que cuando todos
colaboramos en un mismo fin, aunque no sea exactamente nuestra zona, como
la campaña "1carrer1nom" se avanza mucho o muchísimo.
Porque claro, ¿qué es nuestra zona? ¿Mi ciudad? ¿Mi comarca? ¿Mi provincia?
¿Mi comunidad autónoma? ¿Mi estado? el hecho de colaborar con las
instituciones que pago y que me sirven? ¿Colaborar con mi sociedad?
Y como habitante de esa zona ¿qué me interesa? Sólo las carreteras? O "mis
ríos", "mis torrentes" , "mis montañas", mis parques"?

Eh, que no hablo de colaborar en "cosas que NO ME interesan" o "que NO ME
gustan". Hablo de ,personalmente, plantearnos qué "es lo nuestro" y qué es
lo que "nos gusta" referente a este proyecto que seguirá siendo
colaborativo, y que sin o con IGN seguirá dependiendo de todos nosotros.

Pasando los procesos correspondientes, ahora podemos hablar de cómo se
agilizaría. Lo que el otro día denominé como un cambio de actitud: actitud
proactiva.

-El debate en la lista española se haría por exigencia de imports, pero no
creo que saliera ninguna visión negativa, y sí muchos ánimos y ganas de
tirarlo adelante.
-Las páginas de la wiki podrían ser muy elaboradas no tanto con el
Workflow, que todos lo conoceríamos, y que debe estar, sino más técnicas,
sobretodo mucho más completas, gracias a las descripciones que la gente del
IGN nos podría suministrar, veo una wiki llena de índices de proyectos
realizados.
-El hecho de que el debate fuera afirmativo influiría positivamente en la
visión de imports.
-Dispondríamos de algún permiso expreso del IGN así que ese paso se
justificaría como se justifican las actuales importaciones del Ayuntamiento
de Madrid, con la misma carta, para todas de la misma fuente.
-Probablemente según el proyecto que fuera dentro de nuestra comunidad se
sumaría gente incluso del mismo IGN, y sin más validez que la de cualquier
usuario (a imagen y semejanza de cuando en el HOT trabajamos los de siempre
o la viejecita que viene atraída por MSF y con muchas ganas de colaborar
por primera vez). Es decir tendríamos usuarios "extra" usando el Gestor de
Tareas (o cualquier otra plataforma de trabajo parecida o usable - y en el
servidor que fuere) para coordinarnos e ir completando las fases del
proyecto. Y por lo tanto podríamos tener una dualidad de recorridos a la
hora de pasar a la siguiente fase: validadores del IGN dando por buenos los
datos conseguidos en base a su profesionalidad o bien colaboradores de la
zona dando por buenos los datos conseguidos en base a su conocimiento
territorial.
-Finalmente nosotros, las diversas comunidades y grupos, y por supuesto el
propio IGN - gobiernos, administraciones y su madre montada en bicicleta
podrían dar difusión a estas actualizaciones de CartoPaís OSM (y le llamo
de dos maneras porque pienso que IGN querrá hacerse su propio portal...pero
TODOS los datos estarán en OSM) así como en prensa, radio, televisión y
redes a nivel estatal, lo cual atraería a más gente, a colaborar.

Finalizada mi "masturbación SIGnificativa" me despido, esperando haber dado
alguna idea de cara los futuros retos que se nos vienen encima, y que yo,
como colaborador de dos comunidades, estoy dispuesto a llevar

Re: [OSM-talk-fr] Du bon usage des tags loc_name et historic

2016-12-13 Per discussione Christian Quest

Le 13 décembre 2016 à 20:49, domlysz  a écrit :

> Je travail actuellement sur un ensemble de tags concernant du patrimoine
> bâti
> agropastorale et il y a deux points qui me pose question :
>
> Bien souvent ces élèments de patrimoine sont désignés par des noms locaux
> très spécifiques par exemple cazelle, lavogne, jasse, clapas...
>
> Pour le moment dans mes tags j'utilise la clé /loc_name/ pour renseigner
> cette information. Ce choix est inspiré par  ce glossaire
>  Glossaire_Garrigues_Histoire>
> mais il me semble que cette clé est mal choisie car elle devrait être le
> pendant de /name/ et donc désigner un nom de lieu en usage localement et
> non
> un type de bâti.
>
> Néanmoins il est primordial que ces dénominations apparaissent dans mes
> tags
> et qu'elles soient associées à une clé parfaitement identifiable et commune
> à toute ma typologie car il s'agit pour moi d'un élément filtrant fort.
> Malheureusement j'ai bien du mal à trouver quelque-chose de mieux que
> /loc_name/, c'est pourquoi j'en appel à vos connaissance pour des
> suggestions.
>
>
> L'autre point concerne le tag /historic/. Ce tag me semble indispensable
> pour refléter le fait qu'il s'agisse de patrimoine, pourtant son usage à
> tendance à cacher d'autre information. Par exemple pour une ferme on écrira
> simplement /building=farm/ mais s'il s'agit d'un bâtiment à l'architecture
> vernaculaire remarquable on écrira plutôt /historic=farm/ or dans ce cas on
> perds l'information building qui devient implicite au tag historic.


A mon avis, historic=* doit décrire le caractère historique d'un objet, pas
ce qu'est cet objet.

Dans le cas d'une ferme, historic=farm peut très bien être mis sur un
polygone qui englobe toute l'emprise de la ferme alors que building=farm
pourra être mis sur un polygone d'un des bâtiments qui composent la ferme.

Au pire, on peut avoir les deux tags sur le même polygone (building=farm +
historic=yes), cela ne posera pas de problème... et un tag historic seul me
ferait plus penser que le bâtiment n'existe plus que d'imaginer qu'on a
implicitement un bâtiment. L'implicite de ce genre ça ne marche pas trop.




> De la
> même façon si je veux décrire un ancien moulin je peux écrire
> /man_made=waterfill/ ou bien /historic=waterfill/, pour un chemin
> historique
> /highway=path/ ou /historic=path/ ...
>
>
historic=yes... comme indiqué dans le wiki: "Used to add the historic
significance of the objects described by other tags."


> Pour résoudre ce problème j'aurai tendance à vouloir écrire
> /historic:building=farm, historic:man_made=waterfill/ ... mais je
> m'inquiète
> de la façon dont cette notation peu fréquente pourra concrètement être
> valorisée dans les rendus OSM. Des avis ?
>
>
Oui, très négatif l'avis... pourquoi faire compliqué quand on peut faire
simple et générique ?

KISS !

https://fr.wikipedia.org/wiki/Principe_KISS

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

Re: [Talk-es] BCN Housenumbers import - Importación de números de portal de BCN

2016-12-13 Per discussione Rafael Avila Coya

Hola:

Este verano pasado organicé una importación de nodos housenumber de
Thimphu, Bhután [1]. Quizás te valga de algo o te aporte alguna idea,
copia/pega, etc.

Quizás para la de Barcelona es mejor usar el Gestor de Tareas. Si no lo
hice así en Thimphu es porque los nodos no tenían asociados las calles a
las que pertenecían, caso diferente que el de Barcelona.

Saludos,

Rafael.

[1]
wiki.openstreetmap.org/wiki/WikiProject_Bhutan/Thimphu_Thromde_data_house_number_and_streets_import_workflow

On 13/12/16 11:11, Alejandro S. wrote:

Hola,

Me alegro Yopaseopor de que te hayas decidido a tirar para adelante de
la importación, tiene muy buena pinta. Sólo aseguraos de que la posición
de los portales está adecuadamente posicionada con respecto a la
realidad y a los elementos existentes en osm, edificios, calles, etc.

Saludos,
Alejandro Suárez

On Mon, Dec 12, 2016, 22:15 yo paseopor > wrote:

Siguiendo el consejo de Santiago Crespo sobre el proceso de
importación vuelvo a describir el proceso que se quiere realizar.

Vamos a poner a trabajar en la importación de los números de portal
de Barcelona ciudad, con los datos de OpenData del Ajuntament de
Barcelona. Gracias a un script de su diseño (de kresp0) se
conjugarán dos archivos en los que quedarán las principales
propiedades: número de portal, calle a la que pertenece y código
postal. Hemos comprobado los datos , son fiables, y hablaremos con
el ayuntamiento para obtener un permiso explícito y claro sobre el
uso de esos datos. Podeis consultar la wiki
en https://wiki.openstreetmap.org/wiki/BCN_Housenumbers_Import (si
falla alguna cosa, si no está del todo clarificado es que se ha
hecho a imagen y semejanza de las importaciones de Madrid y puede
tener cosas a modificar aún) .
Es una importación grande (más de 17 nodos) así que aunque se
haga colaborativa va a requerir trabajo, por lo que contamos con
toda la comunidad para ello.

Muchas gracias a todos y todas los que habeis colaborado (desde que
iniciamos este debate) ,colaborais y colaborareis en este y en
futuros procesos de este tipo destinados a mejorar notablemente la
calidad y la usabilidad de OSM en España.

Salut i importacióBCN
yopaseopor
___
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] Fwd: problema rendering mappe su alcuni punti di interesse

2016-12-13 Per discussione girarsi_liste

Il 13/12/2016 15:53, Volker Schmidt ha scritto:
> Rispedisco un messaggio che era diventato illeggibile grazie alla mia
> ignoranza sul funzionamento dello spelling checker automatico di Android.
> Mi scuso per il disagio.
> Era una risposta a Simone.

Pensa che pensavo già male, perchè dicevo, è quasi Natale e manco mi fà
la grazia :)

Quindi ripropongo:

natural=stone
historic=stone/natural_stone
tourism=attraction
name=*
layer=-1 (vedo sulla foto che è sott'acqua)

E poi c'è anche la mappatura dell'acqua, ma nn ho capito se è mare o
acqua spontanea o che.


> Ecco la versione migliorata
> 
> 
> Guardando la wiki[0], non trovo geological=historic,
> 
> 
> Non lo trovi perché qualsiasi oggetto geologico è vecchio.
> 
> 
> geological=palaeontological_site (se di altra era, va identificata).
> 
> No. La roccia in questione non contiene fossili, quindi non è n sito
> paleontologico
> 
> name=
> 
> OK
> 
> natural=stone [1]
> 
> OK
> 
> historic=archeological_site
> 
> No. Non è un sito archeologico ma naturale, se ho capito bene
> 
> site_type=* [2]
> 
> No
> 
> tourism=attraction
> 
> Ok
> 
> 
> Volker
> 
> 
> 
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
> 


-- 
Simone Girardelli
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|



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

Re: [OSM-talk-fr] intégration des référentiels STIF

effectivement, les membres de relations ne devraient pas se lier l'un à
l'autre, ce devrait être des parentés strictes dans une hiérarchie, donc
sans boucle.

Il y a cependant quelques cas où de telles boucles existent entre relations
(mais pour des rôles différents), notamment pour les "default" values
applicables à une région.

Pour de tels cas, JOSM a inclus il y a maintenant près de 3 ans un "fix"
lui évitant de créer une boucle infinie lors de l'énumération récursive des
membres enfants: il détecte tout cas de retour d'un descendant vers un des
ancêtres déjà en cours d'énumération et dans ce cas n'ira pas parcourir ce
lien "descendant" qui en fait revient à un ascendant. Il utilise pour cela
une simple pile, en empilant l'objet dont on va énumérer les enfants, puis
en parcourant chacun les enfants (sans rien faire s'ils sont déjà présents
quelque part dans la pile), puis une fois parcourus tous les enfants en
dépilant le premier objet parent.

C'est un garde-fou simple à implémenter (la pile est en fait non ordonnée,
c'est une simple collection indexée par référence d'objet, l'index pouvant
être très efficace si c'est une simple "hashtable"; de plus il ne sera
jamais très grand car limité en taille à la longueur maximale de parcours
hiérarchique d'un ancêtre vers le dernier de ses descendants, qui ne va
jamais au delà d'un poignée: les parcours d'arbres de relation sont en fait
beaucoup plus "larges" que "hauts" avec souvent beaucoup de membres dans
une relation mais peu de niveaux de relations, je n'ai pas vu un seul cas
où la profondeur atteint ou dépasse 16): si jamais on tombe sur un cas où
en enfant est présent à la fois dans la liste des membres d'une relation et
déjà dans la pile, on n'a aucun moyen de retraiter cet objet une deuxième
fois, tout au plus on peut détecter une éventuelle incohérence de tags et
journaliser ce cas, mais on ne doit pas traiter cet enfant à nouveau sans
créer une boucle infinie: il suffit donc juste de savoir, si un objet qui
peut avoir des descendants est déjà en cours de traitement dans la pile, si
oui ne rien faire d'autre, sinon on commence à traiter l'objet en
l'incluant d'abord dans la pile, puis en le retirant une fois le traitement
de cet enfant terminé.




Le 13 décembre 2016 à 22:17, Éric Gillet  a
écrit :

> Le 13 décembre 2016 à 21:27,  a écrit :
>
>> J'ai peut-être la réponse à la longueur du traitement :
>>
>> https://www.openstreetmap.org/relation/6789691 a pour membre :
>>
>>- Relation Noctilien N21 : Châtelet → Chilly-Mazarin – Libération (
>>2504515) 
>>et fait partie de :
>>- Relation Noctilien N21 : Châtelet → Chilly-Mazarin – Libération (
>>2504515) 
>>
>> Faut-il vraiment le second lien (sans rôle) ? Quelle signification ?
>> Retrouver la relation maîtresse ?
>>
>
> Cela me semble être une erreur, il n'est pas nécessaire de "boucler" comme
> ça les relations. Les outils, notamment Overpass, savent gérer les liens de
> parenté entre les relations.
>
> ___
> 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-pt] Importações em massa

2016-12-13 Per discussione Alexandre Moleiro

Sim, são esses changesets.

Pois o que me desagrada é a sobreposição. Há áreas onde até parece fazer
sentido a importação pois eram um "deserto" em termos de "landuse".

Mas em zonas onde já existiam áreas a definir o landuse não me faz sentido
importar para cima e ficar uma mixórdia.

Os scripts de importação não poderiam detectar estas sobreposições?

A minha opinião pessoal é de reverter essas importações, por isso até haver
decisão da comunidade vou "pausar" o mapeamento desta zona.

Saudações
Alexandre

2016-12-13 19:26 GMT+00:00 :

>
> A posição do Data Working Group nos imports é brutal : se não houve
> discussão o import é revertido (mesmo com um import bem feito para obrigar
> as pessoas a entrar sempre em contacto com a comunidade antes).
>
> Reverter ou não, acho que é uma decisão que deve ser tomado pela
> comunidade (mais tempo se espera, pior é).
> O importante para mim o é o conhecimento local, podemos sempre importar
> dados, encontrar pessoal da região que dedica o seu tempo para o OSM é o
> mais complicado.
>
> Francisco
>
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

Re: [Talk-it] Le piazze

2016-12-13 Per discussione girarsi_liste

Il 13/12/2016 12:56, Marco Ciampa ha scritto:
> On Tue, Dec 13, 2016 at 09:48:53AM +0100, girarsi_liste wrote:
>> Il 13/12/2016 08:55, Marco Ciampa ha scritto:
>>>
>>> Conclusione? No perché io non sono un esperto e mi piacerebbe capire per 
>>> esempio
>>> come mappare la piazza di Piedicastello a Trento:
>>>
>>> http://www.openstreetmap.org/#map=19/46.07092/11.11338
>>>
>>> che sul rendering non esce e attualmente è mappata come strada chiusa.
>>>
>>
>> Perchè è mappata come highway=residential, e non come pedestrian.
> 
> Perché dovrebbe essere mappata come pedestrian? Normalmente auto circolano e 
> parcheggiano...
> 

Lo spiega qui:
http://wiki.openstreetmap.org/wiki/IT:Tag:highway%3Dpedestrian

Ovviamente in aggunta al tag consigliato place=square.

Poi er il resto attendo la discussione qui.

-- 
Simone Girardelli
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|



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

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-13 Per discussione Éric Gillet

Le 13 décembre 2016 à 21:27,  a écrit :

> J'ai peut-être la réponse à la longueur du traitement :
>
> https://www.openstreetmap.org/relation/6789691 a pour membre :
>
>- Relation Noctilien N21 : Châtelet → Chilly-Mazarin – Libération (
>2504515) 
>et fait partie de :
>- Relation Noctilien N21 : Châtelet → Chilly-Mazarin – Libération (
>2504515) 
>
> Faut-il vraiment le second lien (sans rôle) ? Quelle signification ?
> Retrouver la relation maîtresse ?
>

Cela me semble être une erreur, il n'est pas nécessaire de "boucler" comme
ça les relations. Les outils, notamment Overpass, savent gérer les liens de
parenté entre les relations.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-br] Possível cópia de nomes de ruas do Google

2016-12-13 Per discussione Pedro vida torta

Creio que o mais correto seria reverter todos infelizmente , impossível
saber o que e correto.

Em 13/12/2016 17:25, "Nelson A. de Oliveira"  escreveu:

> Verificando alguns problemas de locais eu reparei que os nomes de ruas
> daqui são muito similares aos nomes do Google:
>
> https://www.openstreetmap.org/#map=17/-22.72876/-44.84862
>
> Inclusive tendo o nome do local
> https://www.openstreetmap.org/node/4472678103 idêntico ao do Google
> (Chácara São Judas Tadeu),
> como pode ser visto em
> https://www.google.com.br/maps/@-22.7285485,-44.849262,18z
>
> Pela camada do IBGE rural o local talvez poderia ser "São Bom Jesus".
>
> Se alguém clicar no POI da chácara no Google e ir para o website (que
> vai cair numa página do Facebook) verá que ela está localizada no
> "Bairro do Bom Jesus".
>
> Independente do nome ser "São Bom Jesus", "Bairro do Bom Jesus" ou
> alguma outra variação, é certo que "Chácara São Judas Tadeu" não é o
> nome dessa localidade.
> Parece claro que, neste caso, houve também uma cópia incorreta do nome
> do local (que é apenas uma chácara particular).
>
> Um outro exemplo:
> http://mc.bbbike.org/mc/?lon=-67.732649=-10.14355=
> 17=4=mapnik=google-map=bing-map=nokia-map
>
> A "Rua Felício Abraão" só existe no Google (e no OSM)
> Em todo os outros, incluindo o IBGE, é Abrahão (com H).
>
> Muitas ruas nesse lugar batem com o Google, sendo identificáveis nos
> pequenos detalhes de grafia.
>
> Nos changesets vistos rapidamente dá para ver que não foi habilitada a
> camada do IBGE ao inserir o nome das ruas.
>
> No Telegram foi questionado que ele "Talvez conheça o nome das ruas de
> onde mora".
> Saber o nome das ruas de onde a pessoa mora é aceitável. Saber o nome
> das ruas de um lugar distante, coincidindo com o Google, já passa a
> ficar estranho.
>
> Outro ponto é que algumas ruas aparentam estar representadas com nomes
> de conhecidos ou familiares.
>
> Exemplos:
> Estava com nome de "Rua Lécio Rus Tôrres"
> https://www.openstreetmap.org/way/279927998/history e ele retirou hoje
> (não existe nenhuma rua com esse nome na Internet)
>
> Estava com nome de "Rua Júlio Vilela"
> https://www.openstreetmap.org/way/442473942/history e ele retirou hoje
> (repare que o sobrenome é Vilela)
>
> Estava com nome de "Rua Helana Da Silva Vilela"
> https://www.openstreetmap.org/way/279728229/history e ele retirou hoje
> (sobrenome Vilela)
>
> Estava com nome de  "Rua Rosilene Vilela"
> https://www.openstreetmap.org/way/279927994/history (mesma coisa)
>
> Estranhamente essas ruas de cima tiveram os nomes removidos hoje.
>
> Mas ainda é possível ver algumas ruas que não foram modificadas por
> outros usuários, todas contendo "Vilela" em seus nomes:
> http://overpass-turbo.eu/s/kDs
>
> Tem nome que dá para procurar na Internet e ver que é uma pessoa real,
> com endereço, telefone, etc, e que reside em Barra Mansa (onde
> aparentemente o Gabriel reside).
>
> Nessa parte me parece que muitas ruas foram nomeadas, de forma
> incorreta, com nome de familiares ou conhecidos.
>
> Muitas mensagens que foram enviadas ele não respondeu (desde outra
> época, onde alguns dados foram alterados de forma incorreta).
>
> Segundo o Marcio (Thundercel) ele é idoso e tem algumas limitações no
> uso da Internet (e que por isso não recebeu os avisos de mensagens).
> Ele também disse que o Gabriel se sentiu ofendido em um dos comentários.
>
> Por mais bem intencionada que a pessoa esteja, dá para ver que algumas
> coisas foram inseridas de maneira incorreta, com outras possivelmente
> copiadas de onde não possuímos permissão.
>
> O problema é que são quase 10 mil changesets.
> Não dá para verificar um por um, além de ter duas questões
> importantes: quais objetos possuem de fato um nome correto (e não um
> nome fictício ou de conhecido) e quais objetos possuem o nome copiado.
>
> Alguma sugestão?
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [OSM-talk-fr] transport en commun à lyon et osmose

Tou n'est pas fini effectivement, j'en suis à peine à énuméroer les lignes,
et les routes master sont à peine rendus aux numéros 200 (au delà pour les
lignes complémentaires il en manque encore, et je ne parle même pas des
lignes scolaires "TsXXX" (dont on a peine une ébauche pour deux ou 3 lignes
seulement). Mais toutes les lignes non scolaires (et non spéciales)
devraient avoir leur route_master contenant au moins 2 routes, certaines
n'étant pas encore complètes, juste parfois les deux arrêts d'extrémité,
mais effectivement certaines encore sans rien du tout. Mais elles sont
référencées toutes dans la relation network.

Le 13 décembre 2016 à 21:11, Jérôme Amagat  a
écrit :

> je viens de faire les changement dans osm : j'ai remplacé ref:fr_star par
> ref:FR:STAR ("FR" en majuscule) et network=fr_star par network=STAR (le
> réseau s'appelle STAR pas FR:STAR ou autre chose). J'ai aussi supprimé les
> ref=* quand c’étaient les même valeurs que ref:FR:STAR.
> Il y a aussi 59 relations sans membres (avec les tags network=STAR
> operator=Keolis Rennes) soit des type=route soit des type=route_master.
> certaines ça doit être Philippe qui n'a pas fini je pense d'autre sont la
> depuis plus longtemps. il y avait aussi des relation stop_area sans membre
> que j'ai modifié ou supprimé.
>
> Il faudrait modifié l'analyse osmose en remplaçant ref:FR:Star par
> ref:FR:STAR sinon je ne vois pas ce qui ne va pas dans ce que donne osmose
> comme tag à ajouter.
>
> Le 13 décembre 2016 à 19:29, Philippe Verdy  a écrit :
>
>> Note: Osmose "propose" d'intégrer "ref:FR:Star=*" __en plus__ des actuels
>> tags "ref:fr_star=*" (mais "ref:FR:Star=*" n'a jamais été discuté nulle
>> part: Oui je suis pour "ref:FR:STAR=*")
>>
>> Au passage, quelques pages de wiki à modifier (dans les exemples
>> utilisant le modèle Sketchline et la page consacrée aux transports à
>> Rennes) où on devrait aussi utiliser "network=FR:STAR" au lieu de
>> "network=fr_star", afin d'être cohérent !
>>
>>
>> Le 13 décembre 2016 à 10:26, Christian Quest  a
>> écrit :
>>
>>> ref:FR:STAR !
>>>
>>> La convention c'est:
>>>
>>> fr = français (la langue)
>>>
>>> FR = France (le pays)
>>>
>>> Le 13/12/2016 à 01:46, Jérôme Amagat a écrit :
>>>
>>> Et pour Rennes il faudrait changer les tags existants ref:fr_star=* en
>>> ref:fr:Star=* comme sur osmose déjà il y aurait moins d’arrêt à ajouter
>>> d’après osmose. (ou changer en ref:fr:STAR mais il faut aussi le changer
>>> dans le test osmose)
>>> il y a aussi sur des arrêts des tag ref=* qui correspondent au ref de
>>> Star.
>>> Je pense qu'il faudrait déjà faire un peu de changement et de ménage la
>>> dedans avant qu'osmose soit vraiment utile.
>>>
>>>
>>>
>>> --
>>> 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
>>
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] (osm: message 8 of 20) transport en commun à lyon et osmose

Tu n'aurais pas du supprimer les ref=* (même s'ils sont identiques). De
plus je suis aussi d'avis que network= soit aussi FR:STAR (comme pour la
ref): ce n'est pas un nom c'est une valeur clé.

Le 13 décembre 2016 à 21:28,  a écrit :

> > network=STAR (le réseau s'appelle STAR pas FR:STAR ou autre chose)
>
> Certes, mais la clé est network, pas name ou network:name;-).
>
> Quand tu vas rechercher un réseau il va te falloir trouver par un bbox ou
> un autre discriminant (operator ? brand ?).
>
> Pas évident non plus.
> Si tu vois des ref:FR:STAR, tu t'attends à trouver un FR:STAR quelque part.
>
> Le 13/12/2016 à 21:11, Jérôme Amagat - jerome.ama...@gmail.com a écrit :
>
> je viens de faire les changement dans osm : j'ai remplacé ref:fr_star par
> ref:FR:STAR ("FR" en majuscule) et network=fr_star par network=STAR (le
> réseau s'appelle STAR pas FR:STAR ou autre chose). J'ai aussi supprimé les
> ref=* quand c’étaient les même valeurs que ref:FR:STAR.
>
>
>
> ___
> 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-cz] Galileo startuje

2016-12-13 Per discussione Miroslav Suchý

Tohle může být pro mnohé z nás dobrá zpráva:

http://mobil.idnes.cz/start-galileo-mobily-0rb-/mob_tech.aspx?c=A161213_160553_mob_tech_oma

Mirek


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

Re: [OSM-talk-fr] (osm: message 8 of 20) transport en commun à lyon et osmose


> network=STAR (le réseau s'appelle STAR pas FR:STAR ou autre chose)

Certes, mais la clé est network, pas name ou network:name;-).

Quand tu vas rechercher un réseau il va te falloir trouver par un bbox 
ou un autre discriminant (operator ? brand ?).


Pas évident non plus.

Si tu vois des ref:FR:STAR, tu t'attends à trouver un FR:STAR quelque part.

Le 13/12/2016 à 21:11, Jérôme Amagat - jerome.ama...@gmail.com a écrit :
je viens de faire les changement dans osm : j'ai remplacé ref:fr_star 
par ref:FR:STAR ("FR" en majuscule) et network=fr_star par 
network=STAR (le réseau s'appelle STAR pas FR:STAR ou autre chose). 
J'ai aussi supprimé les ref=* quand c’étaient les même valeurs que 
ref:FR:STAR.


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

Re: [OSM-talk-fr] intégration des référentiels STIF


J'ai peut-être la réponse à la longueur du traitement :

https://www.openstreetmap.org/relation/6789691 a pour membre :

 * Relation Noctilien N21 : Châtelet → Chilly-Mazarin – Libération
   (2504515) 
   et fait partie de :
 * Relation Noctilien N21 : Châtelet → Chilly-Mazarin – Libération
   (2504515) 

Faut-il vraiment le second lien (sans rôle) ? Quelle signification ? 
Retrouver la relation maîtresse ?



Le 13/12/2016 à 13:31, Florian LAINEZ - winner...@free.fr a écrit :
Bon j'ai créé une route_master pour faire le test 
https://www.openstreetmap.org/relation/6789691
à priori j'ai pas fait de connerie, mais c'est teeellement long de 
faire ça à la mano. Je confirme qu'il nous faut un outil plus adapté 
si on veut créer 600 lignes ...




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

Re: [OSM-talk-fr] intégration des référentiels STIF

J'ajoute aussi qu'Osmose propose (n plus d'ajouter des tags faux) de
remplacer des "shelter=yes" pour des arrêts de bus alors qu'on a un
"shelter=yes" (vérifié et bien visible sur le terrain et sur les photos) La
raison à cela: l'absence d'information sur ce sujet dans les données
OpenData, ce qui ne signifie PAS qu'il n'y a pas d'abris bus (dans certains
cas les données de la STAR sont fausses, pour cet arrêt : il y a bel et
bien un abri bus).

La STAR n'est pas forcément à jour dans sa base de ce que la mairie locale
a pu aménager à la demande des usagers locaux. On a des erreurs à ce niveau
dans les communes rurales de la métropole, pour des arrêts près de
carrefours en zone rurale, très exposés aux intempéries: à l'origine
c'était juste un bateau avec un poteau indicateur, mais depuis l'abris a
été aménagé et la STAR n'a pas enregistré dans sa base cet aménagement.
Mais la plupart du temps dans ces cas l'OpenData de la STAR ne mentionne
rien ou alors mentionne un "abri=faux" juste par défaut (parce que son
export de données n'a prévu à cet endroit qu'une valeur booléenne et pas
une valeur "null" non renseignée). Pourtant l'abri bus est bien là (et même
depuis plusieurs décennies !)

Bref, ne tenez pas compte du tout de ce que propose Osmose concernant le
réseau bus STAR dans Rennes Métropole, c'est du quasi-100% faux (hormis
peut être quelques très rares points difficiles à voir) et à revoir
intégralement (pas la peine de perdre du temps à signaler du faux positif
sur des milliers de noeuds) ! Dans l'état actuel, cette proposition
"d'intégration" est beaucoup plus une nuisance qui devrait être retirée.
Cette analyse est à refaire de façon plus précise.

Concernant le changement de référence "ref:fr_star=*" en "ref:FR_STAR=*"
c'est à corriger, de même que le changement de réseau "network=fr_star" en
"network=Star" (totalement faux) à corriger plutôt en "network=FR:STAR".
Mais dans les deux cas ce n'est pas de "l'intégration" mais plutôt une
suggestion de changement (avec un niveau de gravité faible), pour lequel
Osmose pourrait même se passer totalement de le signaler: ce type de
changement est facile à faire sans Osmose, qui n'a pas non plus à chercher
à imposer un tel choix qui n'a été discuté et documenté nulle part.


Le 13 décembre 2016 à 20:35, Philippe Verdy  a écrit :

> Au passage, concernant Rennes, ce que propose "d'intégrer" Osmose c'est
> quasiment du 100% faux positif !!
>
> Bref Osmose est totalement à revoir concernant Rennes (ses règles sont
> totalement fausses) !!!
>
> Le 13 décembre 2016 à 20:31,  a écrit :
>
>> Je parlais en général pour le bien de la communauté, pas pour mon réseau
>> local (Lorient a des données sur le portail data.gouv.fr mais pas le
>> réseau transport à ma connaissance, Quimperlé n'a pas grand chose en
>> disponible : une carte PDF, ce n'est pas ce que l'on fait de mieux, comme
>> dit joliment par Christian open mais pas data).
>>
>> Entièrement d'accord il faut des données libres et stables, je pense que
>> pour la STAR (Rennes) c'est le cas.
>> Après autant commencer par les principaux réseaux (Nantes, Lille, Lyon,
>> Strasbourg... : que ceux qui veulent un cadeau de Noël écrive à la mère
>> Noëlle, heu Noémie.
>> Merci pour l'offre !
>>
>> Je pense que la faible couverture de public_transport=stop_position
>> montre que c'est une lubie de tagueur fou : pas de réalité sur le terrain
>> (il faut observer l'arrêt du bus, pour le train suivant la longueur
>> pourtant on ne peut en mettre qu'un (quoique ce n'est pas précisé dans le
>> wiki
>> )
>> et si la voie n'est pas fixe, on va mettre n arrêts ? Si les opérateurs
>> disposent de l'info, la publie et que ça tombe sur une voie OSM, OK, sinon
>> on tague pour le schéma (ce qui me semble pire que taguer pour le rendu).
>> On parle de faciliter l'entrée des nouveaux contributeurs. Là ça vaut
>> opening_hours : sans outil adapté c'est galère : tu veux entrer un arrêt de
>> bus et tu te manges une relation avec des tags qui feront que ton arrêt ne
>> se sera pas affiché.
>>
>> Jean-Yvon
>>
>>
>>
>> Le 13/12/2016 à 20:03, Noémie Lehuby - noemie.leh...@openmailbox.org a
>> écrit :
>>
>> Bonsoir,
>>
>> Jean-Yvon, je veux bien tenter d'adapter mon outil pour d'autres régions,
>> mais il faut s'assurer avant que les codes qu'on importera sont stables.
>> S'ils ne représentent plus rien dans 6 mois, on va le regretter.
>> C'est pourquoi en île-de-france ça a du sens : le STIF propose un
>> référentiel sur son portail opendata donc on peut penser qu'on aura une
>> certaine pérennité de ces codes.
>> Quel réseau te ferait plaisir pour Noël ?
>>
>> C'est amusant ça : la couverture en public_transport = stop_position est
>> si faible que j'avais jamais remarqué le problème de rendu avec Skechtline
>> que tu cites Philippe.
>>
>> Noémie
>>
>> Date: Mon, 12 Dec 2016 21:17:49 +0100
>> From:

Re: [Talk-br] Correção de alguns postos de combustível no Brasil

Também tenho percebido a criação destes eletropostos em locais muito
improváveis. Eu pessoalmente não conheço nenhum.

Eu não uso o maps.me, mas parece que além dele introduzir os erros no
mapa, ele não deixa muito claro que os objetos são publicados no OSM.
Ou deixa claro?

Tenho visto muito "Casa", "Casa do Fulano", "Casa do Ciclano", até
"Casa da sogra"

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

Re: [OSM-talk-fr] transport en commun à lyon et osmose

2016-12-13 Per discussione Jérôme Amagat

je viens de faire les changement dans osm : j'ai remplacé ref:fr_star par
ref:FR:STAR ("FR" en majuscule) et network=fr_star par network=STAR (le
réseau s'appelle STAR pas FR:STAR ou autre chose). J'ai aussi supprimé les
ref=* quand c’étaient les même valeurs que ref:FR:STAR.
Il y a aussi 59 relations sans membres (avec les tags network=STAR
operator=Keolis Rennes) soit des type=route soit des type=route_master.
certaines ça doit être Philippe qui n'a pas fini je pense d'autre sont la
depuis plus longtemps. il y avait aussi des relation stop_area sans membre
que j'ai modifié ou supprimé.

Il faudrait modifié l'analyse osmose en remplaçant ref:FR:Star par
ref:FR:STAR sinon je ne vois pas ce qui ne va pas dans ce que donne osmose
comme tag à ajouter.

Le 13 décembre 2016 à 19:29, Philippe Verdy  a écrit :

> Note: Osmose "propose" d'intégrer "ref:FR:Star=*" __en plus__ des actuels
> tags "ref:fr_star=*" (mais "ref:FR:Star=*" n'a jamais été discuté nulle
> part: Oui je suis pour "ref:FR:STAR=*")
>
> Au passage, quelques pages de wiki à modifier (dans les exemples utilisant
> le modèle Sketchline et la page consacrée aux transports à Rennes) où on
> devrait aussi utiliser "network=FR:STAR" au lieu de "network=fr_star", afin
> d'être cohérent !
>
>
> Le 13 décembre 2016 à 10:26, Christian Quest  a
> écrit :
>
>> ref:FR:STAR !
>>
>> La convention c'est:
>>
>> fr = français (la langue)
>>
>> FR = France (le pays)
>>
>> Le 13/12/2016 à 01:46, Jérôme Amagat a écrit :
>>
>> Et pour Rennes il faudrait changer les tags existants ref:fr_star=* en
>> ref:fr:Star=* comme sur osmose déjà il y aurait moins d’arrêt à ajouter
>> d’après osmose. (ou changer en ref:fr:STAR mais il faut aussi le changer
>> dans le test osmose)
>> il y a aussi sur des arrêts des tag ref=* qui correspondent au ref de
>> Star.
>> Je pense qu'il faudrait déjà faire un peu de changement et de ménage la
>> dedans avant qu'osmose soit vraiment utile.
>>
>>
>>
>> --
>> 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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Fwd: problema rendering mappe su alcuni punti di interesse

2016-12-13 Per discussione Luca Delucchi

2016-12-13 18:38 GMT+01:00 scratera :
> 
>
> ...se osm facesse vedere tutto quello inserito a mio giudizio sarebbe
> inservibile..sta a chi poi esporta i dati far vedere e come far vedere i
> vari punti su cui rivolge il suo interesse...
>

+100

Sono già troppi quelli mostrati sullo stile Standard


-- 
ciao
Luca

www.lucadelu.org

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

Re: [OSM-talk-fr] intégration des référentiels STIF

Tu oneteras que la STAR différencie bel et bie ndans ses données les
plateformes (géolocalisée précisément) en les séparant des itinéraires (qui
ne passent jamais exactement par ces points mais seulement à proximité).

Tu peux critiquer les "stop_position", mais c'et ce qui assure de ne pas
avoir à chercher dans la liste des chemins celui pui pourrait correspondre
à une des "plateform" indiqués comme desservis par la ligne. On a les deux
concepts, mais dans une logique de calculs d'itinéraires, avoir les
stop_position (même approximatifs et ne venant pas des open data mais de la
pose d'un point raisonnablement proche de la plateform évite d'avoir à se
poser des questions.

Les "stop_position" n'ont pas vocation à être rendus sur la carte (d'autant
plus qu'ils sont mis sur la voie, généralement tracée au milieu dans la
plupart des rues, sans tenir compte de la position exacte des "bateaux" ni
de la longueur des zones d'arrêt zébrées sur une des voies de la chaussée,
donc pas au milieu). Ces stop_position sont aussi approximatifs que le
tracé des rues avec un seul chemin "central" quel que soit le nombre de
voies ou la largeur de chaussée.

Ces deux éléments (chemins highway=* et noeuds "stop_position") sont là
dans une logique d'itinéraires et non réellement de rendu (qui devrait
tenir compte de la surface), et cela restera là tant qu'on continuera à
taguer des rues/routes comme de simples traits et non comme des surfaces en
détaillant les voies). Quand on voudra aller plus loin, ont repositionnera
aussi correctement les feux (pas au milieu de la chaussée), on mettra la
surface réelle des passages piétons, on taguera les trottoirs (non pas
comme des chemins parallèles mais comme des surfaces jointives à celle des
voies de la chaussée. Cela ne risque pas d'arriver avant longtemps.

Donc on reste dans une logique d'itinéraire pour l'instant, en sachant que
le rendu reste approximatif (en supposant un "buffer" raisonnable de +/-
3,50 mètres de chaque côté du chemin tracé, ce qui correspond à une largeur
"moyenne" estimée d'une rue à deux voies, une largeur qu'on peut ajuster un
peu si on trouve des tags précisément le nombre de voies ou la présence de
voies supplémentaires pour bus=+4 mètres environ, ou juste pour
cyclistes=+2mètres, ou la présence de stationnement latéral=+3mètres
environ; les rendus ensuite, selon l'échelle de représentation ou ce qu'ils
veulent afficher peuvent ajuster les largeurs de tracé, mais elles sont
rarement proportionnelles à la largeur exacte, c'est là encore juste une
estimation raisonnable).

Pourtant concernant les arrêts de bus et les autres équipements et
mobiliers urbains sur les trottoirs (éclairage public, arbres, bancs,
poubelles, points d'eau...) on aimerait déjà les voir posés hors du milieu
de la chaussée (donc déjà hors des itinéraires tracés dans la base). Mais
il n'y a pas de moyen correct pour associer les arrêtes de bus avec
l'itinéraire sans avoir à chercher. Les stop_position ont l'avantage de
pouvoir être vérifiés automatiquement et très facilement: on en déduit
alors quel "plateform" fait effectivement partie ou pas de l'itinéraire, ou
si l'itinéraire indiqué par les chemins est complet ou pas.


Le 13 décembre 2016 à 20:31,  a écrit :

> Je parlais en général pour le bien de la communauté, pas pour mon réseau
> local (Lorient a des données sur le portail data.gouv.fr mais pas le
> réseau transport à ma connaissance, Quimperlé n'a pas grand chose en
> disponible : une carte PDF, ce n'est pas ce que l'on fait de mieux, comme
> dit joliment par Christian open mais pas data).
>
> Entièrement d'accord il faut des données libres et stables, je pense que
> pour la STAR (Rennes) c'est le cas.
> Après autant commencer par les principaux réseaux (Nantes, Lille, Lyon,
> Strasbourg... : que ceux qui veulent un cadeau de Noël écrive à la mère
> Noëlle, heu Noémie.
> Merci pour l'offre !
>
> Je pense que la faible couverture de public_transport=stop_position montre
> que c'est une lubie de tagueur fou : pas de réalité sur le terrain (il faut
> observer l'arrêt du bus, pour le train suivant la longueur pourtant on ne
> peut en mettre qu'un (quoique ce n'est pas précisé dans le wiki
> )
> et si la voie n'est pas fixe, on va mettre n arrêts ? Si les opérateurs
> disposent de l'info, la publie et que ça tombe sur une voie OSM, OK, sinon
> on tague pour le schéma (ce qui me semble pire que taguer pour le rendu).
> On parle de faciliter l'entrée des nouveaux contributeurs. Là ça vaut
> opening_hours : sans outil adapté c'est galère : tu veux entrer un arrêt de
> bus et tu te manges une relation avec des tags qui feront que ton arrêt ne
> se sera pas affiché.
>
> Jean-Yvon
>
>
>
> Le 13/12/2016 à 20:03, Noémie Lehuby - noemie.leh...@openmailbox.org a
> écrit :
>
> Bonsoir,
>
> Jean-Yvon, je veux bien tenter d'adapter mon outil pour d'autres régions,
> mais il faut

[OSM-talk-fr] Du bon usage des tags loc_name et historic

2016-12-13 Per discussione domlysz

Je travail actuellement sur un ensemble de tags concernant du patrimoine bâti
agropastorale et il y a deux points qui me pose question :

Bien souvent ces élèments de patrimoine sont désignés par des noms locaux
très spécifiques par exemple cazelle, lavogne, jasse, clapas... 

Pour le moment dans mes tags j'utilise la clé /loc_name/ pour renseigner
cette information. Ce choix est inspiré par  ce glossaire
 
 
mais il me semble que cette clé est mal choisie car elle devrait être le
pendant de /name/ et donc désigner un nom de lieu en usage localement et non
un type de bâti.

Néanmoins il est primordial que ces dénominations apparaissent dans mes tags
et qu'elles soient associées à une clé parfaitement identifiable et commune
à toute ma typologie car il s'agit pour moi d'un élément filtrant fort.
Malheureusement j'ai bien du mal à trouver quelque-chose de mieux que
/loc_name/, c'est pourquoi j'en appel à vos connaissance pour des
suggestions.


L'autre point concerne le tag /historic/. Ce tag me semble indispensable
pour refléter le fait qu'il s'agisse de patrimoine, pourtant son usage à
tendance à cacher d'autre information. Par exemple pour une ferme on écrira
simplement /building=farm/ mais s'il s'agit d'un bâtiment à l'architecture
vernaculaire remarquable on écrira plutôt /historic=farm/ or dans ce cas on
perds l'information building qui devient implicite au tag historic. De la
même façon si je veux décrire un ancien moulin je peux écrire
/man_made=waterfill/ ou bien /historic=waterfill/, pour un chemin historique
/highway=path/ ou /historic=path/ ...

Pour résoudre ce problème j'aurai tendance à vouloir écrire
/historic:building=farm, historic:man_made=waterfill/ ... mais je m'inquiète
de la façon dont cette notation peu fréquente pourra concrètement être
valorisée dans les rendus OSM. Des avis ?


En vous remerciant par avance pour tout élément de réponse.

Dominique



--
View this message in context: 
http://gis.19327.n8.nabble.com/Du-bon-usage-des-tags-loc-name-et-historic-tp5887449.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] intégration des référentiels STIF

Au passage, concernant Rennes, ce que propose "d'intégrer" Osmose c'est
quasiment du 100% faux positif !!

Bref Osmose est totalement à revoir concernant Rennes (ses règles sont
totalement fausses) !!!

Le 13 décembre 2016 à 20:31,  a écrit :

> Je parlais en général pour le bien de la communauté, pas pour mon réseau
> local (Lorient a des données sur le portail data.gouv.fr mais pas le
> réseau transport à ma connaissance, Quimperlé n'a pas grand chose en
> disponible : une carte PDF, ce n'est pas ce que l'on fait de mieux, comme
> dit joliment par Christian open mais pas data).
>
> Entièrement d'accord il faut des données libres et stables, je pense que
> pour la STAR (Rennes) c'est le cas.
> Après autant commencer par les principaux réseaux (Nantes, Lille, Lyon,
> Strasbourg... : que ceux qui veulent un cadeau de Noël écrive à la mère
> Noëlle, heu Noémie.
> Merci pour l'offre !
>
> Je pense que la faible couverture de public_transport=stop_position montre
> que c'est une lubie de tagueur fou : pas de réalité sur le terrain (il faut
> observer l'arrêt du bus, pour le train suivant la longueur pourtant on ne
> peut en mettre qu'un (quoique ce n'est pas précisé dans le wiki
> )
> et si la voie n'est pas fixe, on va mettre n arrêts ? Si les opérateurs
> disposent de l'info, la publie et que ça tombe sur une voie OSM, OK, sinon
> on tague pour le schéma (ce qui me semble pire que taguer pour le rendu).
> On parle de faciliter l'entrée des nouveaux contributeurs. Là ça vaut
> opening_hours : sans outil adapté c'est galère : tu veux entrer un arrêt de
> bus et tu te manges une relation avec des tags qui feront que ton arrêt ne
> se sera pas affiché.
>
> Jean-Yvon
>
>
>
> Le 13/12/2016 à 20:03, Noémie Lehuby - noemie.leh...@openmailbox.org a
> écrit :
>
> Bonsoir,
>
> Jean-Yvon, je veux bien tenter d'adapter mon outil pour d'autres régions,
> mais il faut s'assurer avant que les codes qu'on importera sont stables.
> S'ils ne représentent plus rien dans 6 mois, on va le regretter.
> C'est pourquoi en île-de-france ça a du sens : le STIF propose un
> référentiel sur son portail opendata donc on peut penser qu'on aura une
> certaine pérennité de ces codes.
> Quel réseau te ferait plaisir pour Noël ?
>
> C'est amusant ça : la couverture en public_transport = stop_position est
> si faible que j'avais jamais remarqué le problème de rendu avec Skechtline
> que tu cites Philippe.
>
> Noémie
>
> Date: Mon, 12 Dec 2016 21:17:49 +0100
> From: osm.sanspourr...@spamgourmet.com
> To: talk-fr@openstreetmap.org
> Subject: Re: [OSM-talk-fr] intégration des référentiels STIF
> Message-ID: <45f27b94-1092-e208-08f9-3b2c4b830...@gmx.net>
> <45f27b94-1092-e208-08f9-3b2c4b830...@gmx.net>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Logiquement, on se dit que tu vas nous faire la même chose pour l'open
> data des lignes hors du STIF : il y a des réseaux de transports en
> dehors de l'Île-de-France, si, si ;-).
>
> Pense qu'une seule personne a profité de l'outil, c'est un peu abuser,
> non ? :-D
>
> Jean-Yvon
>
> Le 12/12/2016 à 21:01, Noémie Lehuby - noemie.leh...@openmailbox.org a
> écrit :
>
> Bonsoir,
>
> J'ai poussé une mise à jour de l'outil, avec quelques améliorations
> mineures : https://ref-lignes-stif.5apps.com/
> Je pense que je ne vais pas faire beaucoup d'autres évolutions dans
> l'outil, vu que Florian a déjà associé plus des 3/4 des lignes ;)
> Belle performance !
>
>
> -- section suivante --
> Une pièce jointe HTML a été nettoyée...
> URL:
>  attachments/20161212/e1a79ea5/attachment-0001.html>
> 
>
> --
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ancienne modélisation des multipolygones

2016-12-13 Per discussione Frédéric Rodrigo


Le 13/12/2016 à 13:17, Vincent de Château-Thierry a écrit :

Bonjour,

Le 13/12/2016 à 10:22, JB a écrit :


J'avais vu ces outils passer, par contre je n'avais pas trouvé de
manière facile pour les exploiter : en gros, quels sont les MP
problématiques près de chez moi. Est-ce que j'ai raté une information,
ou ils n'existent pas ? Par exemple, OSMInspector vers qui le site
renvoie ne semble pas avoir de couche correspondante.


Oui récupérer 300Mo de données en pbf[1] n'est pas des plus 
confortable, je reconnais. La carte permet de grapiller des cas, sur 
Paris au moins il y a en suffisamment pour ne pas avoir à les 
chercher. Quelques exemples tous dans la même zone :

https://www.openstreetmap.org/relation/1102282
https://www.openstreetmap.org/relation/1465396
https://www.openstreetmap.org/relation/1515925

Pour les 2 derniers on peut se demander si la notion d'espace public 
piéton a bien une correspondance dans OSM. C'est un peu fourre-tout là.


OSMInspector en effet ne reprend pas dans la rubrique area ce qu'on 
s'attend à trouver à la lecture du readme de Github. On peut à la 
rigueur cocher "inner way has same tags" pour un type de souci 
approchant.


Sinon Osmose indique certains polygones comme devant être retaggués, 
dans la rubrique "multipolygon". Ils sont indiqués avec l'en-tête : 
"Inconsistant multipolygon nature with members nature"
C'est un peu usine à gaz comme proposition, mais si Osmose pouvait 
extraire strictement du pbf les "old-style multipolygons" ça pourrait 
alimenter une analyse ciblée ?


vincent 


Osmose signalement les cas ou le/les rôles outter et la relation 
définissent des choses contradictoires.


http://osmose.openstreetmap.fr/fr/errors/?item=1170=2

Une analyse pour migrer la nature sur la relation (avec proposition de 
correction) est simple à faire. Par contre je ne suis pas pour l'instant 
convaincu que l'on doive e faire. J'essaye qu'Osmose ne pousse pas un 
schéma de taging plutôt qu'un autre.



Frédéric.



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

Re: [OSM-talk-fr] intégration des référentiels STIF

Je parlais en général pour le bien de la communauté, pas pour mon réseau 
local (Lorient a des données sur le portail data.gouv.fr mais pas le 
réseau transport à ma connaissance, Quimperlé n'a pas grand chose en 
disponible : une carte PDF, ce n'est pas ce que l'on fait de mieux, 
comme dit joliment par Christian open mais pas data).


Entièrement d'accord il faut des données libres et stables, je pense que 
pour la STAR (Rennes) c'est le cas.


Après autant commencer par les principaux réseaux (Nantes, Lille, Lyon, 
Strasbourg... : que ceux qui veulent un cadeau de Noël écrive à la mère 
Noëlle, heu Noémie.

Merci pour l'offre !

Je pense que la faible couverture de public_transport=stop_position 
montre que c'est une lubie de tagueur fou : pas de réalité sur le 
terrain (il faut observer l'arrêt du bus, pour le train suivant la 
longueur pourtant on ne peut en mettre qu'un (quoique ce n'est pas 
précisé dans le wiki 
) 
et si la voie n'est pas fixe, on va mettre n arrêts ? Si les opérateurs 
disposent de l'info, la publie et que ça tombe sur une voie OSM, OK, 
sinon on tague pour le schéma (ce qui me semble pire que taguer pour le 
rendu).
On parle de faciliter l'entrée des nouveaux contributeurs. Là ça vaut 
opening_hours : sans outil adapté c'est galère : tu veux entrer un arrêt 
de bus et tu te manges une relation avec des tags qui feront que ton 
arrêt ne se sera pas affiché.


Jean-Yvon


Le 13/12/2016 à 20:03, Noémie Lehuby - noemie.leh...@openmailbox.org a 
écrit :

Bonsoir,

Jean-Yvon, je veux bien tenter d'adapter mon outil pour d'autres 
régions, mais il faut s'assurer avant que les codes qu'on importera 
sont stables. S'ils ne représentent plus rien dans 6 mois, on va le 
regretter.
C'est pourquoi en île-de-france ça a du sens : le STIF propose un 
référentiel sur son portail opendata donc on peut penser qu'on aura 
une certaine pérennité de ces codes.

Quel réseau te ferait plaisir pour Noël ?

C'est amusant ça : la couverture en public_transport = stop_position 
est si faible que j'avais jamais remarqué le problème de rendu avec 
Skechtline que tu cites Philippe.


Noémie


Date: Mon, 12 Dec 2016 21:17:49 +0100
From: osm.sanspourr...@spamgourmet.com
To: talk-fr@openstreetmap.org
Subject: Re: [OSM-talk-fr] intégration des référentiels STIF
Message-ID: <45f27b94-1092-e208-08f9-3b2c4b830...@gmx.net>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Logiquement, on se dit que tu vas nous faire la même chose pour l'open
data des lignes hors du STIF : il y a des réseaux de transports en
dehors de l'Île-de-France, si, si ;-).

Pense qu'une seule personne a profité de l'outil, c'est un peu abuser,
non ? :-D

Jean-Yvon

Le 12/12/2016 à 21:01, Noémie Lehuby - noemie.leh...@openmailbox.org a
écrit :

Bonsoir,

J'ai poussé une mise à jour de l'outil, avec quelques améliorations
mineures : https://ref-lignes-stif.5apps.com/
Je pense que je ne vais pas faire beaucoup d'autres évolutions dans
l'outil, vu que Florian a déjà associé plus des 3/4 des lignes ;)
Belle performance !


-- section suivante --
Une pièce jointe HTML a été nettoyée...
URL:
 



--



___
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-pt] Importações em massa

2016-12-13 Per discussione f . dos . santos

Olá Alexandre,

Penso que estas a referir aos changeset como este :
- https://www.openstreetmap.org/changeset/40814732

De memoria não houve discussão em Portugal para a importação de dados Corine 
Land Cover.
Esses dados já foram importados em outros paises :
- http://wiki.openstreetmap.org/wiki/WikiProject_Corine_Land_Cover

Aqui não há problema de licença mas um problema de qualidade dos dados :
- frescura dos dados : CLC 2006 já passaram 10 anos ...
- precisão dos dados : CLC é bem conhecido por ter uma resolução muita fraca

A CLC permite "encher" rapidamente o mapa mais necessita depois muito tempo 
para melhorar a qualidade dos polígonos.

O problema dos imports é sempre o mesmo : a manutenção dos dados. Não acho 
correto deixar aos outros (ou deixar sem manutenção) lidar com os problemas dos 
dados importados.

A posição do Data Working Group nos imports é brutal : se não houve discussão o 
import é revertido (mesmo com um import bem feito para obrigar as pessoas a 
entrar sempre em contacto com a comunidade antes).

Reverter ou não, acho que é uma decisão que deve ser tomado pela comunidade 
(mais tempo se espera, pior é).
O importante para mim o é o conhecimento local, podemos sempre importar dados, 
encontrar pessoal da região que dedica o seu tempo para o OSM é o mais 
complicado.

Francisco


- Mail original -
From: "Nelson A. de Oliveira" 
To: "OSM Portugal" 
Date: 13/12/2016 18:50:57
Subject: Re: [Talk-pt] Importações em massa

2016-12-13 15:41 GMT-02:00 Alexandre Moleiro :
> Devo alterar as áreas que foram importadas para não colidirem com as
> existentes? E nas zonas em que a importação não bate certo com o
> conhecimento local que tenho da zona?

Se a importação não foi discutida e apresenta/insere erros, geralmente
ela é revertida.
Se você arrumar os dados da importação muito provavelmente você terá o
seu trabalho e tempo perdidos, portanto.

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

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

Re: [OSM-talk-fr] intégration des référentiels STIF

Oui elle est faible, voilà comment un modèle v2 approuvé depuis plus d'un
an, pour d'excellentes raisons, n'avance pas: les outils ne suivent
toujours pas (hormi JOSM qui reconnait très bien le nouveau schéma, les
rendus n'en tiennent toujours pas compte, donc n'affichent rien, donc les
utilisateurs ne sont pas poussés non plus à adopter ce schéma).

Il faut bien commencer, quitte à ce que les rendus aient des anomalies (des
arrêts bien tagués mais pour l'instant non affichés): c'est aux rendus donc
de s'adapter, on ne devrait pas taguer juste pour le rendu actuel (qui de
toute façon ne sait pas faire correctement la différence entre arrêts et
plateformes, qui de toute façon ont été confondus et mélangés un peu
partout depuis le début avec "bus_stop".

Si on veut gérer la transition, il faut décider vers lequel de "platform"
ou "stop_position" on doit basculer les "bus_stop" actuels. En majorité les
"bus_stop" ont été mis sur ce qui devrait être des "plateform" en v2 (c'est
à dire à côté des chemins de la relation "route"). Mais si on tague les 2
("platform" + "stop_position" ) en v2

Et si on veut être compatible avec sketchline, les "bus_stop" devraient
être déplacés vers les nouveaux noeuds "stop_position". Le rendu actuel les
affichera au milieu de la chaussée, un nouveau rendu optera pour ne pas les
afficher du tout si on a la combinaison "bus_stop"+"stop_position" sur un
même noeud, et affichera plutôt les "plateform", et les "bus_stop" restants
non associés à un "stop_position". On aura donc le meilleur des deux
mondes, et une transition possible en relative douceur (sachant que cela
prendra beaucoup de temps pour tout basculer en v2, avant de finalement
supprimer le tag "bus_stop" devenu obsolète).


Le 13 décembre 2016 à 20:03, Noémie Lehuby 
a écrit :

> Bonsoir,
>
> Jean-Yvon, je veux bien tenter d'adapter mon outil pour d'autres régions,
> mais il faut s'assurer avant que les codes qu'on importera sont stables.
> S'ils ne représentent plus rien dans 6 mois, on va le regretter.
> C'est pourquoi en île-de-france ça a du sens : le STIF propose un
> référentiel sur son portail opendata donc on peut penser qu'on aura une
> certaine pérennité de ces codes.
> Quel réseau te ferait plaisir pour Noël ?
>
> C'est amusant ça : la couverture en public_transport = stop_position est
> si faible que j'avais jamais remarqué le problème de rendu avec Skechtline
> que tu cites Philippe.
>
> Noémie
>
> Date: Mon, 12 Dec 2016 21:17:49 +0100
>> From: osm.sanspourr...@spamgourmet.com
>> To: talk-fr@openstreetmap.org
>> Subject: Re: [OSM-talk-fr] intégration des référentiels STIF
>> Message-ID: <45f27b94-1092-e208-08f9-3b2c4b830...@gmx.net>
>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>
>> Logiquement, on se dit que tu vas nous faire la même chose pour l'open
>> data des lignes hors du STIF : il y a des réseaux de transports en
>> dehors de l'Île-de-France, si, si ;-).
>>
>> Pense qu'une seule personne a profité de l'outil, c'est un peu abuser,
>> non ? :-D
>>
>> Jean-Yvon
>>
>> Le 12/12/2016 à 21:01, Noémie Lehuby - noemie.leh...@openmailbox.org a
>> écrit :
>>
>>> Bonsoir,
>>>
>>> J'ai poussé une mise à jour de l'outil, avec quelques améliorations
>>> mineures : https://ref-lignes-stif.5apps.com/
>>> Je pense que je ne vais pas faire beaucoup d'autres évolutions dans
>>> l'outil, vu que Florian a déjà associé plus des 3/4 des lignes ;)
>>> Belle performance !
>>>
>>
>> -- section suivante --
>> Une pièce jointe HTML a été nettoyée...
>> URL:
>> > s/20161212/e1a79ea5/attachment-0001.html>
>>
>> --
>>
>
>
> ___
> 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-br] Possível cópia de nomes de ruas do Google

Verificando alguns problemas de locais eu reparei que os nomes de ruas
daqui são muito similares aos nomes do Google:

https://www.openstreetmap.org/#map=17/-22.72876/-44.84862

Inclusive tendo o nome do local
https://www.openstreetmap.org/node/4472678103 idêntico ao do Google
(Chácara São Judas Tadeu),
como pode ser visto em
https://www.google.com.br/maps/@-22.7285485,-44.849262,18z

Pela camada do IBGE rural o local talvez poderia ser "São Bom Jesus".

Se alguém clicar no POI da chácara no Google e ir para o website (que
vai cair numa página do Facebook) verá que ela está localizada no
"Bairro do Bom Jesus".

Independente do nome ser "São Bom Jesus", "Bairro do Bom Jesus" ou
alguma outra variação, é certo que "Chácara São Judas Tadeu" não é o
nome dessa localidade.
Parece claro que, neste caso, houve também uma cópia incorreta do nome
do local (que é apenas uma chácara particular).

Um outro exemplo:
http://mc.bbbike.org/mc/?lon=-67.732649=-10.14355=17=4=mapnik=google-map=bing-map=nokia-map

A "Rua Felício Abraão" só existe no Google (e no OSM)
Em todo os outros, incluindo o IBGE, é Abrahão (com H).

Muitas ruas nesse lugar batem com o Google, sendo identificáveis nos
pequenos detalhes de grafia.

Nos changesets vistos rapidamente dá para ver que não foi habilitada a
camada do IBGE ao inserir o nome das ruas.

No Telegram foi questionado que ele "Talvez conheça o nome das ruas de
onde mora".
Saber o nome das ruas de onde a pessoa mora é aceitável. Saber o nome
das ruas de um lugar distante, coincidindo com o Google, já passa a
ficar estranho.

Outro ponto é que algumas ruas aparentam estar representadas com nomes
de conhecidos ou familiares.

Exemplos:
Estava com nome de "Rua Lécio Rus Tôrres"
https://www.openstreetmap.org/way/279927998/history e ele retirou hoje
(não existe nenhuma rua com esse nome na Internet)

Estava com nome de "Rua Júlio Vilela"
https://www.openstreetmap.org/way/442473942/history e ele retirou hoje
(repare que o sobrenome é Vilela)

Estava com nome de "Rua Helana Da Silva Vilela"
https://www.openstreetmap.org/way/279728229/history e ele retirou hoje
(sobrenome Vilela)

Estava com nome de "Rua Rosilene Vilela"
https://www.openstreetmap.org/way/279927994/history (mesma coisa)

Estranhamente essas ruas de cima tiveram os nomes removidos hoje.

Mas ainda é possível ver algumas ruas que não foram modificadas por
outros usuários, todas contendo "Vilela" em seus nomes:
http://overpass-turbo.eu/s/kDs

Tem nome que dá para procurar na Internet e ver que é uma pessoa real,
com endereço, telefone, etc, e que reside em Barra Mansa (onde
aparentemente o Gabriel reside).

Nessa parte me parece que muitas ruas foram nomeadas, de forma
incorreta, com nome de familiares ou conhecidos.

Muitas mensagens que foram enviadas ele não respondeu (desde outra
época, onde alguns dados foram alterados de forma incorreta).

Segundo o Marcio (Thundercel) ele é idoso e tem algumas limitações no
uso da Internet (e que por isso não recebeu os avisos de mensagens).
Ele também disse que o Gabriel se sentiu ofendido em um dos comentários.

Por mais bem intencionada que a pessoa esteja, dá para ver que algumas
coisas foram inseridas de maneira incorreta, com outras possivelmente
copiadas de onde não possuímos permissão.

O problema é que são quase 10 mil changesets.
Não dá para verificar um por um, além de ter duas questões
importantes: quais objetos possuem de fato um nome correto (e não um
nome fictício ou de conhecido) e quais objetos possuem o nome copiado.

Alguma sugestão?

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

Re: [Talk-pt] request for interview about the Portuguese OSM

2016-12-13 Per discussione Marcos Oliveira

Welcome Ed, thank you for considering our community for your next country
profile!

Please be patient, while our mailing list community is small and not that
active, a rather sizable portion of it is very wise and knowledgeable, with
some editors' history going back as far as the beginning of this project.

I hate listing names (because I'm sure to forget some) but if I had to make
a list of very interesting editors to interview i'd say: Francisco dos
Santos, Jorge Gustavo Rocha, Victor Ferreira, Rui Oliveira, Helder Brandão,
Nuno Gomes Lopes, Ana Rita Melo, Hugo Santos, TopoLusitania, Alexandre
Moleiro, Rúben Mendes, Marta Alarcão, etc.

2016-12-13 8:49 GMT+00:00 Ed Freyfogle :

>
> Olá,
>
> apologies I will have to continue in English as I dont speak Portuguese
>
> I'm Ed, OSM user 'freyfogle' http://www.openstreetmap.org/user/freyfogle
>
> I run the OpenCage Geocoder, a geocoding API built on OSM.
> On our blog we regularly interview people from OSM communities around the
> world, please see
> http://blog.opencagedata.com/tagged/countryprofile
>
> Would anyone be interested in doing an interview about OSM in Portugal?
> It's all by email, I just send you some questions. My guess is it will
> take you about 20 minutes.
>
> I hope it leads to more contributors and more awareness of OSM.
>
> Please let me know if interested.
>
> Thanks for your help and your support of OSM
>
> obrigado,
> Ed
>
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>
>


-- 
Um Abraço,
Marcos Oliveira
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-13 Per discussione Noémie Lehuby


Bonsoir,

Jean-Yvon, je veux bien tenter d'adapter mon outil pour d'autres 
régions, mais il faut s'assurer avant que les codes qu'on importera sont 
stables. S'ils ne représentent plus rien dans 6 mois, on va le 
regretter.
C'est pourquoi en île-de-france ça a du sens : le STIF propose un 
référentiel sur son portail opendata donc on peut penser qu'on aura une 
certaine pérennité de ces codes.

Quel réseau te ferait plaisir pour Noël ?

C'est amusant ça : la couverture en public_transport = stop_position est 
si faible que j'avais jamais remarqué le problème de rendu avec 
Skechtline que tu cites Philippe.


Noémie


Date: Mon, 12 Dec 2016 21:17:49 +0100
From: osm.sanspourr...@spamgourmet.com
To: talk-fr@openstreetmap.org
Subject: Re: [OSM-talk-fr] intégration des référentiels STIF
Message-ID: <45f27b94-1092-e208-08f9-3b2c4b830...@gmx.net>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Logiquement, on se dit que tu vas nous faire la même chose pour l'open
data des lignes hors du STIF : il y a des réseaux de transports en
dehors de l'Île-de-France, si, si ;-).

Pense qu'une seule personne a profité de l'outil, c'est un peu abuser,
non ? :-D

Jean-Yvon

Le 12/12/2016 à 21:01, Noémie Lehuby - noemie.leh...@openmailbox.org a
écrit :

Bonsoir,

J'ai poussé une mise à jour de l'outil, avec quelques améliorations
mineures : https://ref-lignes-stif.5apps.com/
Je pense que je ne vais pas faire beaucoup d'autres évolutions dans
l'outil, vu que Florian a déjà associé plus des 3/4 des lignes ;)
Belle performance !


-- section suivante --
Une pièce jointe HTML a été nettoyée...
URL:


--



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

Re: [OSM-talk-fr] transport en commun à lyon et osmose

Note: Osmose "propose" d'intégrer "ref:FR:Star=*" __en plus__ des actuels
tags "ref:fr_star=*" (mais "ref:FR:Star=*" n'a jamais été discuté nulle
part: Oui je suis pour "ref:FR:STAR=*")

Au passage, quelques pages de wiki à modifier (dans les exemples utilisant
le modèle Sketchline et la page consacrée aux transports à Rennes) où on
devrait aussi utiliser "network=FR:STAR" au lieu de "network=fr_star", afin
d'être cohérent !


Le 13 décembre 2016 à 10:26, Christian Quest  a
écrit :

> ref:FR:STAR !
>
> La convention c'est:
>
> fr = français (la langue)
>
> FR = France (le pays)
>
> Le 13/12/2016 à 01:46, Jérôme Amagat a écrit :
>
> Et pour Rennes il faudrait changer les tags existants ref:fr_star=* en
> ref:fr:Star=* comme sur osmose déjà il y aurait moins d’arrêt à ajouter
> d’après osmose. (ou changer en ref:fr:STAR mais il faut aussi le changer
> dans le test osmose)
> il y a aussi sur des arrêts des tag ref=* qui correspondent au ref de Star.
> Je pense qu'il faudrait déjà faire un peu de changement et de ménage la
> dedans avant qu'osmose soit vraiment utile.
>
>
>
> --
> 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-hr] OSM meetup 2016-12-14

2016-12-13 Per discussione hbogner


Dolazim i ja :D

On 13.12.2016 18:08, Matija Nalis wrote:

ja dolazim sutra

On Fri, Dec 09, 2016 at 10:42:50AM +0100, hbogner wrote:

U srijedu 14.12.2016. u 18:00, pivnica Zlatni Medo, Savska cesta 56.
Nalazimo se na druženju uz pivo,vino,čaj, kavu ili napitak po želji.


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






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

Re: [OSM-talk-fr] intégration des référentiels STIF

J'ai dit "ovales" juste pour simplifier, car évidemment ce sont en fait des
formes créées par un polygone convexe englobant tous les arrêts inclus,
élargis par un petit "buffer" créé autour avec des angles arrondis. Ca
donne des formes qui dépendent de la listance entre les arrêts et de leur
nombre (il peut arriver qu'on ait 4 arrêts sur les 4 rues d'un même
carrefour, formant plus ou moins un grand carré, ça donnera une forme qui
ne sera pas nécessairement "oblongue" non plus. On dit en général "ovale"
pour désigner le tracé de tells formes désignant des ensembles dans des
représentations schématiques simplifiées comme c'est le cas ici.

Etant donné l'absence de rendu actuel des platform et stop_position, et que
seuls les bus_stop sont rendus, il faut je pense garder pour l'instant la
redondance bus_stop + platform pour passer au schéma v2 (donc vérifier que
les bus_stop sont bien tous des "platforms", sinon transformer ces noeuds
uniquement en en stop_position et créer un "platform"+"bus_stop" à côté de
la voie.

Et mettre à jour les relations route pour qu'elles incluent les deux
noeuds: rôle "stop" pour le noeud "stop_position", rôle "platform" pour le
noeud (ou le chemin si on a tracé une zone/un quai, voire un abri) avec
"bus_stop"+"platform".

Au passage sur Rennes je fais l'essai sur la ligne C1. J'avais au départ
supprimé les tags "bus_stop" du schéma v1, mais je vais les remettre en
redondance sur les "platform".

Sachant aussi que l'outil "sketchline" (fourni par l'Overpass Turbo)
affichera alors les deux points comme deux arrêts distincts car il traite
"bus_stop" et "stop_position" comme des arrêts distincts (d'autant plus
qu'il ne seront pas à la même position puisque "bus_stop" se retrouvera sur
la "plateform" à côté de la voie alors que "stop_postion" sera sur le
chemin !) on pourrait aussi décider de faire l'inverse :
* garder "bus_stop" (pour les rendus actuels) uniquement sur le noeud
"stop_position", mais alors on verra l'icône au milieu de la chaussée et on
ne verra plus les icones à l'emplacement des stations sur les trottoirs. On
voit que la décision de garder "bus_stop" (sur l'un ou l'autre), est juste
destinée à "taguer pour le rendu". Ce qui montre bien que "bus_stop" est
mal fichu depuis le début et devra à terme être viré des données !!!

Autre anomalie relevée dans le schéma v2: des membres pour les stations
peuvent être ajoutés aux relations "route", mais aucun rôle n'a été défini.
Ces stations sont typiquement des chemins (pour désigner des bâtiments de
gares par exemple). On peut aussi les inclure comme noeuds simples (plus ou
moins centrés sur la zone d'une "gare" ou d'une "stop_area"). Mais pour
inclure un batiment, pas moyen de le faire avec autre chose qu'un seul
chemin fermé. JOSM râle si on y met une relation (pour des batiments
complexes ayant des enclaves par exemple), par ce que la documentation n'a
pas prévu qu'un bâtiment doive être décrit de façon plus compliquée qu'un
seul chemin fermé. Et la documentation du Wiki indique même (à tord !)
"onRelation=no" et semble vouloir l'interdire (ce qui est carrément stupide
ou irréfléchi!).

Au lieu de mettre une telle restriction, il aurait mieux valu prévoir un
rôle particulier "station" pour décrire des noeuds/chemins/relation
destinés à décrire toute une station/gare (laquelle peut avoir même
plusieurs bâtiments proches mais séparés (par exemple deux gares de chaque
côté d'une ligne, reliées par un souterrain, une passerelle, voire encore
un passage à niveau dans les plus petites gares plus rurales, mais
associées aux mêmes arrêts). Et dans l'immédiat je suis pour qu'on retire
la restriction "onrelation=no" pour les bâtiments d'une station/gare (la
documentation de leurs autres tags sont aussi mal fichus, regardez un peu
le détail!).

Ca mériterait d'être discuté sur la page de discussion associée pour une
vue plus internationale: ce schéma v2, bien qu'approuvé depuis des mois
demande à avancer et à être corrigé de ses problèmes !







Le 13 décembre 2016 à 13:05,  a écrit :

> Le 12/12/2016 à 23:06, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> en revanche les "stop_area" sont reconnus par le rendu "Public Transport"
> qui affiche des ovales autour des arrêts "stop_position"
>
> Avec le schéma V1 on a déjà ça avec les highway
> =bus_stop
> 
> comme ici :
>
> http://www.openstreetmap.org/node/717560945#map=18/48.
> 39228/-4.48753=T
>
> Mais on voit que changer un schéma sans prévoir des règles d'adaptation
> des données et des moteurs (de rendu, de calcul d'itinéraire, etc...) n'est
> pas très raisonnable.
>
> De plus ce concept de zone de correspondance est assez fumeux : quand on
> va du point a au point b qui ne sont pas reliés par la même ligne, on va
> accepter de marcher entre les deux stations les plus proches... sauf si ça
> rallonge de

Re: [OSM-talk-be] GRB hackday december 11th

2016-12-13 Per discussione Jonathan Beliën

Haha,

Awesome ! Let's make a LEGO version of OSM \o/
But I think I'm disgressing from the current topic...

I'm not good at art stuff and I'm definitely not a designer but I'm sure we
can manage to do something good (or not too bad) anyway.
Any designer available in OpenStreetMap crew ?


Jonathan

Le mar. 13 déc. 2016 à 17:18, Glenn Plas  a écrit :

> Hey Jonathan,
>
> On 13-12-16 17:05, Jonathan Beliën wrote:
> > Hi Glenn,
> >
> > We didn't really discuss about that last Sunday but I'll be happy to
> help with PHP/JAVASCRIPT/HTML/CSS !
>
> Thanks Jonathan, we seem to share a lot of interests (*) ;-)
>
> I didn't really yell for help on Sunday, probably should have.  I will
> send you the details asap and where I'm at.  It would be awesome to not
> have to worry about GUI stuff, I'm not a artistic person, I'm visually
> challenged in CSS.
>
> Glenn
>
> * : http://bricks.stackexchange.com/users/1122/glenn-plas
>
> >
> > Good afternoon.
> >
> > Jonathan Beliën
> >
> > -Message d'origine-
> > De : Glenn Plas [mailto:gl...@byte-consult.be]
> > Envoyé : mardi 13 décembre 2016 16:44
> > À : OpenStreetMap Belgium
> > Objet : Re: [OSM-talk-be] GRB hackday december 11th
> >
> > On 13-12-16 14:18, Santens Seppe wrote:
> >> Looking forward to it!
> >>
> >> I had a quick look at the documentation and tried the tools, but I
> >> don’t feel confident enough to have a go at it. A short training would
> be nice.
> >
> > The tool will also be updated before we start, since it's a R version
> right now.  A v2 version is on the way, the source code is public too.
> > It will be a lot more user-friendly, less-nerdy.  I'm about halfway
> through merging functionalities.
> >
> > We will organise workshops to get everyone aligned.  The meeting was
> quite productive and rather fast as well.  We have a main strategy and 2
> backup strategies to get this proposal accepted.
> >
> > Looking at my schedule, it will probably be ready mid januari but I'm
> swamped in paid work so this target is optimistic.  with all the festivit
> >
> > If anyone who knows some php/javascript/css (or even the Laravel
> > framework) and you want to help, please contact me and I will get the
> ball rolling.  I could use a CSS expert to assist me in making it pretty
> and functional on the GUI side.
> >
> > Thanks for the patience and also thanks for showing restraint in
> importing data when you are not sure, it's an excellent decision in the
> context and timing of this project.
> >
> >
> > Glenn
> >
> >>
> >>
> >>
> >> Seppe
> >>
> >>
> >>
> >> *Van:*Ben Abelshausen [mailto:ben.abelshau...@gmail.com]
> >> *Verzonden:* dinsdag 13 december 2016 14:10 *Aan:*OpenStreetMap
> >> Belgium
> >> *Onderwerp:* Re: [OSM-talk-be] GRB hackday december 11th
> >>
> >>
> >>
> >> We are working on a blogpost... :-)
> >>
> >>
> >>
> >> Met vriendelijke groeten,
> >> Best regards,
> >>
> >> Ben Abelshausen
> >>
> >>
> >>
> >> On Tue, Dec 13, 2016 at 1:54 PM, Marc Gemis  >> > wrote:
> >>
> >> Any chance we see a list of accomplishments somewhere ?
> >>
> >> regards
> >>
> >> m
> >>
> >>
> >> ___
> >> Talk-be mailing list
> >> Talk-be@openstreetmap.org 
> >> https://lists.openstreetmap.org/listinfo/talk-be
> >>
> >>
> >>
> >>
> >>
> >> ___
> >> Talk-be mailing list
> >> Talk-be@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-be
> >>
> >
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
> >
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-pt] Importações em massa

2016-12-13 15:41 GMT-02:00 Alexandre Moleiro :
> Devo alterar as áreas que foram importadas para não colidirem com as
> existentes? E nas zonas em que a importação não bate certo com o
> conhecimento local que tenho da zona?

Se a importação não foi discutida e apresenta/insere erros, geralmente
ela é revertida.
Se você arrumar os dados da importação muito provavelmente você terá o
seu trabalho e tempo perdidos, portanto.

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

Re: [Talk-it] Fwd: problema rendering mappe su alcuni punti di interesse

2016-12-13 Per discussione scratera

 

...se osm facesse vedere tutto quello inserito a mio giudizio sarebbe
inservibile..sta a chi poi esporta i dati far vedere e come far vedere i
vari punti su cui rivolge il suo interesse...



--
View this message in context: 
http://gis.19327.n8.nabble.com/problema-rendering-mappe-su-alcuni-punti-di-interesse-tp5887285p5887441.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-cz] Vývoj RUIAN vs. KM prvků na serveru poloha.net za rok

2016-12-13 Per discussione Zdeněk Pražák

nerozumím co tím míníte,
používám JOSM

Dne 13. prosince 2016 17:25 Janda Martin  napsal(a):

> Dobry den,
>
>  ve svem programu pouzivat pro zpracovani "building:ruian:type" protoze
> nektere typy nejsou zadefinovany pomoci OSM tagu. Napr.
> building:ruian:type=8
>
>   Martin
>
>
> --
> *From: *"Zdeněk Pražák" 
> *To: *"OpenStreetMap Czech Republic" 
> *Sent: *Tuesday, December 13, 2016 5:05:16 PM
> *Subject: *Re: [Talk-cz]Vývoj RUIAN vs. KM prvků na serveru
> poloha.net za rok
>
> Chtěl jsem se zeptat, zda mám tedy pomocí traceru RUIAN přetrasovávat
> budovy, které byly natrasovány již dříve a nemají v popisu identifikátory
> RUIAN
>
> Pražák
>
> -- Původní zpráva --
> Od: Petr Schönmann 
> Komu: OpenStreetMap Czech Republic 
> Datum: 2. 12. 2016 12:05:39
> Předmět: [Talk-cz] Vývoj RUIAN vs. KM prvků na serveru poloha.net za rok
>
> Ahoj, sepsal jsem takový menší článek jak to vypadá když se mapují budovy
> z poloha.net.
> Zajímavý graf vývoje prvků, jak se nám daří přemapovávat CUZK:KM
>
> http://gpsfreemaps.net/openstreetmap/vyvoj-ruian-vs-
> km-prvku-na-serveru-poloha-net-za-rok
>
> Pěkné počtení.
> --
> 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
>
> ___
> 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-hr] OSM meetup 2016-12-14

2016-12-13 Per discussione Matija Nalis

ja dolazim sutra

On Fri, Dec 09, 2016 at 10:42:50AM +0100, hbogner wrote:
> U srijedu 14.12.2016. u 18:00, pivnica Zlatni Medo, Savska cesta 56.
> Nalazimo se na druženju uz pivo,vino,čaj, kavu ili napitak po želji.
> 
> 
> ___
> Talk-hr mailing list
> Talk-hr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-hr

-- 
Opinions above are GNU-copylefted.

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

[Talk-se] Status Östergötland

2016-12-13 Per discussione Björkman Gunnar

Hej!

Vi kommer efter jul att sjösätta ett projekt kallat "Status Östergötland". Det 
är ett öppen data projekt som visar hälsoläget i Östergötland baserat på ett 
antal enkäter som går ut till skolor och medborgare. I applikationen finns en 
rapportdel (MS SSRS) och en kartdel som är baserad på Svenska Open Streetmap. 
Demo för en begränsad grupp sker i veckan.

Hälsn

/Gunnar

Gunnar Björkman
Enhetschef Systemutveckling
CMIT kompetens
Centrum för Medicinteknik och IT

Region Östergötland
Klostergatan 19
581 85 Linköping
Telefon: 072-210 45 77

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

Re: [OSM-talk-fr] SIG "open data" Communauté d'Aglomération du Grand Sénonais (89)

2016-12-13 Per discussione Christian Quest

Le 13 décembre 2016 à 17:09, Alain VASSAULT <
alain.vassa...@tranquillement.info> a écrit :

> Hello,
>
> je vient de les appeler.
>
> Pour le moment ils sont "OpenData" dans le sens qu'ils donnent accès en
> visibilité au publique.
>
Open oui, mais pas data alors...

> Mais ils ne peuvent proposer au téléchargement les données qu'aux "Mairie
> et agent technique" sous condition de se créer un compte, car dans le même
> outils ils ont des informations confidentielles interne (PLU, Projet, accès
> aux informations propriétaire des parcelles cadastrale par exemple).
>
Effectivement, il faut avoir organisé en amont ses données pour séparer ce
qui peut librement partagé et ce qui ne peut pas l'être.


> La personne que j'ai eu m'a indiqué que cela devrais bouger avec un
> changement d'outils début d'année prochaine, il a même ajouter "de toute
> façon on vas être obligé pour ce mettre en conformité".
>
L'intention est là, il faut laisser un peu de temps pour s'organiser,
surtout sur des collectivit


> Il connaissait déjà le projet OpenStreetMap et y a déjà contribué.
>
> Quand je lui ai proposé de verser des données dans OSM, il m'a répondu ne
> pas avoir le temps humain disponible, car ils ne sont que 2 pour l'ensemble
> des 27 communes.
>
> Vu que je contribue petit à petit sur ma ville, il m'a dis regarder
> bientôt OSM voir ce que j'ai pu entrer comme données, et il a pris mes
> coordonnées quand, en rigolant, je lui ai proposer un "partenariat" pour
> remplir notre base ;-)
>
> Je lui ai parler de JOSM comme éditeur pour un accès facile aux images
> cadastrale, qu'il ne semblais pas connaitre.
> Bref, wait and see ^^
>
> Tranquille
>
>
C'est une première prise de contact qui semble prometteuse mais ça prendra
sûrement du temps avant de déboucher sur du concret... c'est ce qu'on voit
la plupart du temps.

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

Re: [Talk-se] Status Östergötland

2016-12-13 Per discussione Jan Ainali

Hej Gunnar!

Kul! Är detta mail mer för kännedom, eller söker du folk som vill vara med
i demon?

Med vänliga hälsningar
Jan Ainali
http://ainali.com

Den 12 december 2016 11:17 skrev Björkman Gunnar <
gunnar.bjork...@regionostergotland.se>:

> Hej!
>
>
>
> Vi kommer efter jul att sjösätta ett projekt kallat ”Status Östergötland”.
> Det är ett öppen data projekt som visar hälsoläget i Östergötland baserat
> på ett antal enkäter som går ut till skolor och medborgare. I applikationen
> finns en rapportdel (MS SSRS) och en kartdel som är baserad på Svenska Open
> Streetmap. Demo för en begränsad grupp sker i veckan.
>
>
>
> Hälsn
>
>
>
> /Gunnar
>
>
>
> Gunnar Björkman
>
> Enhetschef Systemutveckling
>
> CMIT kompetens
>
> Centrum för Medicinteknik och IT
>
>
>
> Region Östergötland
>
> Klostergatan 19
>
> 581 85 Linköping
> Telefon: 072-210 45 77
>
>
>
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>
>
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-cz] Vývoj RUIAN vs. KM prvků na serveru poloha.net za rok

2016-12-13 Per discussione Janda Martin

Dobry den, 

ve svem programu pouzivat pro zpracovani "building:ruian:type" protoze nektere 
typy nejsou zadefinovany pomoci OSM tagu. Napr. building:ruian:type=8 

Martin 



From: "Zdeněk Pražák"  
To: "OpenStreetMap Czech Republic"  
Sent: Tuesday, December 13, 2016 5:05:16 PM 
Subject: Re: [Talk-cz] Vývoj RUIAN vs. KM prvků na serveru poloha.net za rok 

Chtěl jsem se zeptat, zda mám tedy pomocí traceru RUIAN přetrasovávat budovy, 
které byly natrasovány již dříve a nemají v popisu identifikátory RUIAN 

Pražák 


-- Původní zpráva -- 
Od: Petr Schönmann  
Komu: OpenStreetMap Czech Republic  
Datum: 2. 12. 2016 12:05:39 
Předmět: [Talk-cz] Vývoj RUIAN vs. KM prvků na serveru poloha.net za rok 



Ahoj, sepsal jsem takový menší článek jak to vypadá když se mapují budovy z 
poloha.net . 
Zajímavý graf vývoje prvků, jak se nám daří přemapovávat CUZK:KM 

http://gpsfreemaps.net/openstreetmap/vyvoj-ruian-vs-km-prvku-na-serveru-poloha-net-za-rok
 

Pěkné počtení. 
-- 
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 
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk-be] GRB hackday december 11th

2016-12-13 Per discussione Glenn Plas

Hey Jonathan,

On 13-12-16 17:05, Jonathan Beliën wrote:
> Hi Glenn,
> 
> We didn't really discuss about that last Sunday but I'll be happy to help 
> with PHP/JAVASCRIPT/HTML/CSS !

Thanks Jonathan, we seem to share a lot of interests (*) ;-)

I didn't really yell for help on Sunday, probably should have.  I will
send you the details asap and where I'm at.  It would be awesome to not
have to worry about GUI stuff, I'm not a artistic person, I'm visually
challenged in CSS.

Glenn

* : http://bricks.stackexchange.com/users/1122/glenn-plas

> 
> Good afternoon.
> 
> Jonathan Beliën
> 
> -Message d'origine-
> De : Glenn Plas [mailto:gl...@byte-consult.be] 
> Envoyé : mardi 13 décembre 2016 16:44
> À : OpenStreetMap Belgium
> Objet : Re: [OSM-talk-be] GRB hackday december 11th
> 
> On 13-12-16 14:18, Santens Seppe wrote:
>> Looking forward to it!
>>
>> I had a quick look at the documentation and tried the tools, but I 
>> don’t feel confident enough to have a go at it. A short training would be 
>> nice.
> 
> The tool will also be updated before we start, since it's a R version right 
> now.  A v2 version is on the way, the source code is public too.
> It will be a lot more user-friendly, less-nerdy.  I'm about halfway through 
> merging functionalities.
> 
> We will organise workshops to get everyone aligned.  The meeting was quite 
> productive and rather fast as well.  We have a main strategy and 2 backup 
> strategies to get this proposal accepted.
> 
> Looking at my schedule, it will probably be ready mid januari but I'm swamped 
> in paid work so this target is optimistic.  with all the festivit
> 
> If anyone who knows some php/javascript/css (or even the Laravel
> framework) and you want to help, please contact me and I will get the ball 
> rolling.  I could use a CSS expert to assist me in making it pretty and 
> functional on the GUI side.
> 
> Thanks for the patience and also thanks for showing restraint in importing 
> data when you are not sure, it's an excellent decision in the context and 
> timing of this project.
> 
> 
> Glenn
> 
>>
>>  
>>
>> Seppe
>>
>>  
>>
>> *Van:*Ben Abelshausen [mailto:ben.abelshau...@gmail.com]
>> *Verzonden:* dinsdag 13 december 2016 14:10 *Aan:*OpenStreetMap 
>> Belgium
>> *Onderwerp:* Re: [OSM-talk-be] GRB hackday december 11th
>>
>>  
>>
>> We are working on a blogpost... :-)
>>
>>  
>>
>> Met vriendelijke groeten,
>> Best regards,
>>
>> Ben Abelshausen
>>
>>  
>>
>> On Tue, Dec 13, 2016 at 1:54 PM, Marc Gemis > > wrote:
>>
>> Any chance we see a list of accomplishments somewhere ?
>>
>> regards
>>
>> m
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>>  
>>
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 


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

Re: [OSM-talk-fr] SIG "open data" Communauté d'Aglomération du Grand Sénonais (89)

2016-12-13 Per discussione Alain VASSAULT


Hello,

je vient de les appeler.

Pour le moment ils sont "OpenData" dans le sens qu'ils donnent accès en 
visibilité au publique. Mais ils ne peuvent proposer au téléchargement 
les données qu'aux "Mairie et agent technique" sous condition de se 
créer un compte, car dans le même outils ils ont des informations 
confidentielles interne (PLU, Projet, accès aux informations 
propriétaire des parcelles cadastrale par exemple).


La personne que j'ai eu m'a indiqué que cela devrais bouger avec un 
changement d'outils début d'année prochaine, il a même ajouter "de toute 
façon on vas être obligé pour ce mettre en conformité".


Il connaissait déjà le projet OpenStreetMap et y a déjà contribué.

Quand je lui ai proposé de verser des données dans OSM, il m'a répondu 
ne pas avoir le temps humain disponible, car ils ne sont que 2 pour 
l'ensemble des 27 communes.


Vu que je contribue petit à petit sur ma ville, il m'a dis regarder 
bientôt OSM voir ce que j'ai pu entrer comme données, et il a pris mes 
coordonnées quand, en rigolant, je lui ai proposer un "partenariat" pour 
remplir notre base ;-)


Je lui ai parler de JOSM comme éditeur pour un accès facile aux images 
cadastrale, qu'il ne semblais pas connaitre.


Bref, wait and see ^^

Tranquille

Le 10/12/2016 à 19:20, Christian Quest a écrit :
Créditer ne suffit pas toujours... ça semble être une rédaction qui 
méconnait les droits (surtout quand on lit un "droits réservés" ou

*

©

*).

Données IGN:
- le scan 25 n'est pas open, aucune info ne peut y être reprise
- BD Ortho, nous avons signé une convention en mai dernier avec l'IGN 
qui nous permet de l'utiliser pour améliorer les données OSM, voir 
http://openstreetmap.fr/bdortho


Cadastre:
- nous avons le feu vert depuis de nombreuses années nous permettant 
de l'utiliser pour améliorer les données OSM


Si pour les autres données du SIG il suffit de mentionner la source, 
ça semble ok... mais c'est quand même à confirmer.

Je n'ai par contre pas trouvé comment télécharger des données...


Le 10 décembre 2016 à 11:45, Alain VASSAULT 
> a écrit :


Hello,

contributeur débutant quand l'hôpital et mes enfants me laissent
le temps et l'énergie, je vient de découvrir un site, fait par la
communauté de commune, de cartographie avec nombreuses
informations et calques.

"Aujourd’hui, dans un contexte, d’ouverture de données (open
data*) et de transparence de l’information, la CCS souhaite mettre
à disposition du public certaines de ses données via une
application cartographie interactive : Géo*S*énonais."
http://www.grand-senonais.fr/presentation_geosenonais.php


L'accès à cette carte touchant les 27 communes de la zone est ici:
http://ccs.sirap.fr/simap/

Il y a les coordonnées du service SIG sur la première page citée
ci-dessus.

Je ne vois pas d'accès direct aux données, ni d'accès aux
coordonnées des différents points qui m'intéresserais pour
compléter ce que j'ai commencé à rentrer dans OSM pour ma commune
"Saint-Martin-Du-Tertre 89100".

Bref je trouve leur interface non pratique (la carte colle à ma
sourie après un déplacement...) et pas mal de data pourrais être
versée dans la DB OSM.
Ils indiquent qu'on peut utiliser les dites data, si et seulement
si, on crédite les droits:

"Dans un souci de droits de propriété intellectuelle, merci de
bien vouloir mentionner la source et les mentions obligatoires de
chaque donnée dans une utilisation professionnelle ou personnelle,
à savoir :

  * *pour les données IGN :

copyright « © IGN – BD Ortho juillet 2007 ou 2011 » ;
copyright « © IGN – scan25 »

*
  * *pour les données cadastrales :

« Direction Générale des Finances Publiques – Cadastre- Droits
réservés »

*
  * *pour les autres données :

« service S.I.G. de la Communauté de Communes du Sénonais »

*

"

L'IGN et le cadastre aucun problème avec OSM, mais quid de leurs
données? A part "OpenData" aucune mention de licence (du moins de
ce que j'ai vu)
Une personne "habituée" à ce genre de service pourrais les
contacter pour les "migrer" ou rentre dispo les data sur OSM? ^^

tranquille

___
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

Re: [OSM-talk-be] GRB hackday december 11th

2016-12-13 Per discussione Jonathan Beliën

Hi Glenn,

We didn't really discuss about that last Sunday but I'll be happy to help with 
PHP/JAVASCRIPT/HTML/CSS !

Good afternoon.

Jonathan Beliën

-Message d'origine-
De : Glenn Plas [mailto:gl...@byte-consult.be] 
Envoyé : mardi 13 décembre 2016 16:44
À : OpenStreetMap Belgium
Objet : Re: [OSM-talk-be] GRB hackday december 11th

On 13-12-16 14:18, Santens Seppe wrote:
> Looking forward to it!
> 
> I had a quick look at the documentation and tried the tools, but I 
> don’t feel confident enough to have a go at it. A short training would be 
> nice.

The tool will also be updated before we start, since it's a R version right 
now.  A v2 version is on the way, the source code is public too.
It will be a lot more user-friendly, less-nerdy.  I'm about halfway through 
merging functionalities.

We will organise workshops to get everyone aligned.  The meeting was quite 
productive and rather fast as well.  We have a main strategy and 2 backup 
strategies to get this proposal accepted.

Looking at my schedule, it will probably be ready mid januari but I'm swamped 
in paid work so this target is optimistic.  with all the festivit

If anyone who knows some php/javascript/css (or even the Laravel
framework) and you want to help, please contact me and I will get the ball 
rolling.  I could use a CSS expert to assist me in making it pretty and 
functional on the GUI side.

Thanks for the patience and also thanks for showing restraint in importing data 
when you are not sure, it's an excellent decision in the context and timing of 
this project.

Glenn

> 
>  
> 
> Seppe
> 
>  
> 
> *Van:*Ben Abelshausen [mailto:ben.abelshau...@gmail.com]
> *Verzonden:* dinsdag 13 december 2016 14:10 *Aan:*OpenStreetMap 
> Belgium
> *Onderwerp:* Re: [OSM-talk-be] GRB hackday december 11th
> 
>  
> 
> We are working on a blogpost... :-)
> 
>  
> 
> Met vriendelijke groeten,
> Best regards,
> 
> Ben Abelshausen
> 
>  
> 
> On Tue, Dec 13, 2016 at 1:54 PM, Marc Gemis  > wrote:
> 
> Any chance we see a list of accomplishments somewhere ?
> 
> regards
> 
> m
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-be
> 
>  
> 
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 

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

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

Re: [Talk-cz] Vývoj RUIAN vs. KM prvků na serveru poloha.net za rok

2016-12-13 Per discussione Zdeněk Pražák

Chtěl jsem se zeptat, zda mám tedy pomocí traceru RUIAN přetrasovávat 
budovy, které byly natrasovány již dříve a nemají v popisu identifikátory 
RUIAN

Pražák

-- Původní zpráva --
Od: Petr Schönmann 
Komu: OpenStreetMap Czech Republic 
Datum: 2. 12. 2016 12:05:39
Předmět: [Talk-cz] Vývoj RUIAN vs. KM prvků na serveru poloha.net za rok

"

Ahoj, sepsal jsem takový menší článek jak to vypadá když se mapují budovy z 
poloha.net(http://poloha.net).
Zajímavý graf vývoje prvků, jak se nám daří přemapovávat CUZK:KM

http://gpsfreemaps.net/openstreetmap/vyvoj-ruian-vs-km-prvku-na-serveru-
poloha-net-za-rok
(http://gpsfreemaps.net/openstreetmap/vyvoj-ruian-vs-km-prvku-na-serveru-poloha-net-za-rok)



Pěkné počtení.


-- 



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: [OSM-talk-be] GRB hackday december 11th

2016-12-13 Per discussione Glenn Plas

On 13-12-16 14:18, Santens Seppe wrote:
> Looking forward to it!
> 
> I had a quick look at the documentation and tried the tools, but I don’t
> feel confident enough to have a go at it. A short training would be nice.

The tool will also be updated before we start, since it's a R version
right now.  A v2 version is on the way, the source code is public too.
It will be a lot more user-friendly, less-nerdy.  I'm about halfway
through merging functionalities.

We will organise workshops to get everyone aligned.  The meeting was
quite productive and rather fast as well.  We have a main strategy and 2
backup strategies to get this proposal accepted.

Looking at my schedule, it will probably be ready mid januari but I'm
swamped in paid work so this target is optimistic.  with all the festivit

If anyone who knows some php/javascript/css (or even the Laravel
framework) and you want to help, please contact me and I will get the
ball rolling.  I could use a CSS expert to assist me in making it pretty
and functional on the GUI side.

Thanks for the patience and also thanks for showing restraint in
importing data when you are not sure, it's an excellent decision in the
context and timing of this project.

Glenn

> 
>  
> 
> Seppe
> 
>  
> 
> *Van:*Ben Abelshausen [mailto:ben.abelshau...@gmail.com]
> *Verzonden:* dinsdag 13 december 2016 14:10
> *Aan:*OpenStreetMap Belgium
> *Onderwerp:* Re: [OSM-talk-be] GRB hackday december 11th
> 
>  
> 
> We are working on a blogpost... :-)
> 
>  
> 
> Met vriendelijke groeten,
> Best regards,
> 
> Ben Abelshausen
> 
>  
> 
> On Tue, Dec 13, 2016 at 1:54 PM, Marc Gemis  > wrote:
> 
> Any chance we see a list of accomplishments somewhere ?
> 
> regards
> 
> m
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-be
> 
>  
> 
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 

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

[Talk-it] Fwd: problema rendering mappe su alcuni punti di interesse

2016-12-13 Per discussione Volker Schmidt

Rispedisco un messaggio che era diventato illeggibile grazie alla mia
ignoranza sul funzionamento dello spelling checker automatico di Android.
Mi scuso per il disagio.
Era una risposta a Simone.
Ecco la versione migliorata


Guardando la wiki[0], non trovo geological=historic,


Non lo trovi perché qualsiasi oggetto geologico è vecchio.


geological=palaeontological_site (se di altra era, va identificata).

No. La roccia in questione non contiene fossili, quindi non è n sito
paleontologico

name=

OK

natural=stone [1]

OK

historic=archeological_site

No. Non è un sito archeologico ma naturale, se ho capito bene

site_type=* [2]

No

tourism=attraction

Ok


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

[Talk-GB] December Nottingham Pub meeting

2016-12-13 Per discussione SK53

Just a reminder that this is tonight at the Lincs Poacher 19:30
https://wiki.openstreetmap.org/wiki/Nottingham/Pub_Meetup.

I will aim to put next years meeting dates on the wiki shortly, but will
aim for 3rd Tuesday in the month.

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

Re: [Talk-br] tutorial JOSM na UFMG

2016-12-13 Per discussione George Silva

Gerald, parabéns pela oficina.

Mas aqui vai uma reclamação (não a você) direcionada aos meus colegas de
curso, os geógrafos, arquitetos-urbanistas e áreas correlatas: cadê vocês
gente?! Poderiam muito dar uma mão nos conceitos de mapeamento e contribuir
ativamente no OSM, mas vejo pouca participação.

Já tem um tempo que queremos fazer uma na geografia (UFU-MG) mas são poucos
interessados, infelizmente.

2016-12-13 12:07 GMT-02:00 Gerald Weber :

> Oi Pessoal
>
> não sei se avisei nesta lista, vamos fazer um turorial informal amanhã
> sobre o uso do JOSM.
>
> Vai ser no departamento de física da UFMG amanhã 14/12 ás 15h na sala 3090.
>
> se tiver mais alguém interessado me avise para eu passar o detalhe de como
> chega na sala.
>
> abraço
>
> Gerald
>
> --
>
> Dr. Gerald Weber
>
> gwebe...@gmail.com
>
> Personal website 
>
> ResearchGate Profile 
>
> for urgent questions: https://telegram.me/gweberbh
>
>
> Departamento de Física/Universidade Federal de Minas Gerais
>
> Department of Physics/Federal University of Minas Gerais
>
> Campus da Pampulha
>
> Av. Antônio Carlos, 6627, 31270-901 Belo Horizonte, MG, Brazil
>
>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>


-- 
George R. C. Silva
Sigma Geosistemas LTDA

http://www.sigmageosistemas.com.br/
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] tutorial JOSM na UFMG

Oi Pessoal

não sei se avisei nesta lista, vamos fazer um turorial informal amanhã
sobre o uso do JOSM.

Vai ser no departamento de física da UFMG amanhã 14/12 ás 15h na sala 3090.

se tiver mais alguém interessado me avise para eu passar o detalhe de como
chega na sala.

abraço

Gerald

-- 

Dr. Gerald Weber

gwebe...@gmail.com

Personal website 

ResearchGate Profile 

for urgent questions: https://telegram.me/gweberbh


Departamento de Física/Universidade Federal de Minas Gerais

Department of Physics/Federal University of Minas Gerais

Campus da Pampulha

Av. Antônio Carlos, 6627, 31270-901 Belo Horizonte, MG, Brazil
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Correção de alguns postos de combustível no Brasil

2016-12-13 11:51 GMT-02:00 Gerald Weber :
> o pessoal do maps.me já foi alertado sobre isto?

Já.
Tem 5 meses que a gente já enviou correção (mas ainda não foi incorporada).

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

[Talk-it] Call per coordinatori regionali OSM per OpenStreetMap Italia, scadenza venerdì 23 dicembre 2016

2016-12-13 Per discussione Cristian Consonni

(dato che il thread precedente si è perso per colpa mia, reinvio)

Ciao a tutti,

Qualche mese fa (a marzo) avevamo lanciato una call sulla lista per
trovare dei coordinatori regionali che portassero avanti delle attività
locali legate a OpenStreetMap in maniera ufficiale per il capitolo
OpenStreetMap Italia/Wikimedia Italia.

Questo primo tentativo è andato bene in termini di quante persone si
sono fatte avanti come volontarie, ma non siamo stati in grado di
sostenere adeguatamente la disponibilità tua e degli altri che si sono
fatti avanti.

Vorremmo riprovare con il 2017 a ripartire, inserendo i coordinatori OSM
nei vari canali di comunicazione e nelle attività che l'associazione già
fa per i coordinatori delle altre aree tematiche (scuole, biblioteche e
musei).

Abbiamo chiesto alle persone che si sono candidate a marzo e se ne sono
fatte avanti di nuove, vedete qui:
https://wiki.openstreetmap.org/wiki/Local_chapter/OpenStreetMap_Italia#candidates_2017

Come vedete, Napo ha deciso di rinunciare al ruolo per il Trentino per i
troppi impegni. Grazie comunque Napo!

Se ci fossero altre persone interessate per le altre regioni fatevi avanti!

Come per lo scorso giro, l'unico requisito per candidarsi a coordinatori
è essere soci del capitolo, cosa necessaria sia dal punto di vista
pratico (per ricevere comunicazioni), sia per il fatto che in alcune
occasioni i coordinatori di fatto rappresentano il capitolo.

Il direttivo si riunirà questo week-end in sede a BASE a Milano per
valutare le candidature e nominare formalmente le varie persone.

Se avete domande potete farle qui o contattare me e/o Alessandro Palmas
(in copia).

Grazie!

Ciao,

Cristian

== Chi è un coordinatore regionale OSM per OSM Italia ==

Un coordinatore regionale OSM è un socio del capitolo che:
* fa da punto di contatto e coordinamento tra i soci (e anche i non
soci) che vogliano organizzare delle attività sul territorio di una data
reegione;
* fa da punto di contatto con gli esterni (stampa, ecc.) in una data
regione per ulteriori informazioni;
* fa da ponte e comunica con il resto dell'associazione, con il
Direttore esecutivo e con il direttivo

== Quali sono gli obiettivi di un coordinatore regionale OSM? ==

Un coordinatore è un collegamento tra la comunità e l'associazione: tra
gli obiettivi dei coordinatori dovrebbe esserci il rafforzamento dei
rapporti tra i membri della comunità e l'ampliamento della stessa,
magari tramite l'organizzazione di piccoli eventi e incontri (ad esempio
mapping party o semplici raduni informali, ad esempio un aperitivo per
conoscersi meglio e per raccontare a chi ancora non conosce OSM cosa si
fa e cosa si può fare per collaborare al progetto).

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

Re: [Talk-br] Correção de alguns postos de combustível no Brasil

Oi Nelson

o pessoal do maps.me já foi alertado sobre isto?

abraço

Gerald

2016-12-13 11:10 GMT-02:00 Nelson A. de Oliveira :

> O maps.me tem um problema de tradução onde eletropostos (estações de
> recarga de veículos elétricos) são confundidos com postos de
> combustível.
>
> Para quem tiver um tempo (mesmo que pouco), poderia verificar alguns
> desses locais através do desafio em http://maproulette.org/map/1447
>
> Creio que seja bem simples, rápido e fácil para colaborar, bastando
> apenas efetuar o login com a conta do OSM e começar a corrigir os
> postos, um por um.
>
> Há uma descrição da tarefa no site.
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [OSM-talk-be] GRB hackday december 11th

2016-12-13 Per discussione joost schouppe

We're not quite there yet, Seppe. There will definitely be training
sessions once we have a go from the imports mailing list.

If you can't wait for the blog post, here's the pad we used for live
reporting: https://mensuel.framapad.org/p/grbhackaton
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

[OSM-talk-fr] Appel à candidatures responsables de thèmes RMLL 2017 - LinuxFr.org

2016-12-13 Per discussione Benoit Fournier

Pour information, voici un appel pour participer et aider à
l'organisation des RMLL - Rencontres Mondiales du Logiciel Libre.

--
From: Marc Hépiègne
Subject: Appel à candidatures responsables de thèmes RMLL 2017 - LinuxFr.org

Hello,

Les RMLL (Rencontres Mondiales du Logiciel Libre) se dérouleront à
Saint‐Étienne du 1er au 7 juillet 2017.
L'orga des RMLL2017 a lancé un appel à candidature pour animer les
thèmes de l'édition, tout est expliqué dans cette page :
http://linuxfr.org/news/appel-a-candidatures-responsables-de-themes-rmll-2017
N'hésitez pas à rejoindre l'équipe.

Comme il est possible de proposer un atelier, un stand, une conf.
Ne pas hésiter à contribuer, welcome.

Marc Hépiègne
oisux.org

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

Re: [Talk-it] Query elementi vicini

2016-12-13 Per discussione Martin Raifer

Sì:
* scuole con palestra: http://overpass-turbo.eu/s/kCQ
* scuole senza palestra: http://overpass-turbo.eu/s/kCO

2016-12-12 18:36 GMT+01:00 Cascafico Giovanni :
> Sarebbe possibile fare una query overpass che estragga scuole con o senza
> palestra nelle vicinanze? Anche in mancanza della relazione "site"?
>
>
> ___
> 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-be] GRB hackday december 11th

2016-12-13 Per discussione Santens Seppe

Looking forward to it!
I had a quick look at the documentation and tried the tools, but I don’t feel 
confident enough to have a go at it. A short training would be nice.

Seppe

Van: Ben Abelshausen [mailto:ben.abelshau...@gmail.com]
Verzonden: dinsdag 13 december 2016 14:10
Aan: OpenStreetMap Belgium
Onderwerp: Re: [OSM-talk-be] GRB hackday december 11th

We are working on a blogpost... :-)

Met vriendelijke groeten,
Best regards,

Ben Abelshausen

On Tue, Dec 13, 2016 at 1:54 PM, Marc Gemis 
> wrote:
Any chance we see a list of accomplishments somewhere ?

regards

m

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

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

[Talk-br] Correção de alguns postos de combustível no Brasil

O maps.me tem um problema de tradução onde eletropostos (estações de
recarga de veículos elétricos) são confundidos com postos de
combustível.

Para quem tiver um tempo (mesmo que pouco), poderia verificar alguns
desses locais através do desafio em http://maproulette.org/map/1447

Creio que seja bem simples, rápido e fácil para colaborar, bastando
apenas efetuar o login com a conta do OSM e começar a corrigir os
postos, um por um.

Há uma descrição da tarefa no site.

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

Re: [OSM-talk-be] GRB hackday december 11th

2016-12-13 Per discussione Ben Abelshausen

We are working on a blogpost... :-)

Met vriendelijke groeten,
Best regards,

Ben Abelshausen

On Tue, Dec 13, 2016 at 1:54 PM, Marc Gemis  wrote:

> Any chance we see a list of accomplishments somewhere ?
>
> regards
>
> m
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] GRB hackday december 11th

2016-12-13 Per discussione Marc Gemis

Any chance we see a list of accomplishments somewhere ?

regards

m

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

Re: [Talk-it] problema rendering mappe su alcuni punti di interesse

2016-12-13 Per discussione Marco Bartalini

Io uso molto il sito di osm per condividere posizioni ecc.ecc..  quindi
sarebbe importante far vedere tutto...

la roccia in questione è questa
http://www.salentoacolory.it/la-marmitta-del-gigante/

non saprei bene che altri tag usare




*Marco Bartalini,marcobartal...@gmail.com *

On Mon, Dec 12, 2016 at 2:57 PM, Volker Schmidt  wrote:

>
> Guardando la wiki[0], non trovo geological=historic,
>
>
> Non lo trovo perché qualitative oggetto geological è vecchio.
>
>
> geological=palaeontological_site (se di altra era, va identificata).
>
> No. La roccia on questione non continue fossili
>
> name=
>
> Ok
>
> natural=stone [1]
>
> Ok
>
> historic=archeological_site
>
> No. Non è un sito archeologico ma naturale
>
> site_type=* [2]
>
> No
>
> tourism=attraction
>
> Ok
>
>
> Volker
>
> ___
> 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] intégration des référentiels STIF

2016-12-13 Per discussione Florian LAINEZ

Bon j'ai créé une route_master pour faire le test
https://www.openstreetmap.org/relation/6789691
à priori j'ai pas fait de connerie, mais c'est teeellement long de
faire ça à la mano. Je confirme qu'il nous faut un outil plus adapté si on
veut créer 600 lignes ...

Le 13 décembre 2016 à 13:05,  a écrit :

> Le 12/12/2016 à 23:06, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> en revanche les "stop_area" sont reconnus par le rendu "Public Transport"
> qui affiche des ovales autour des arrêts "stop_position"
>
> Avec le schéma V1 on a déjà ça avec les highway
> =bus_stop
> 
> comme ici :
>
> http://www.openstreetmap.org/node/717560945#map=18/48.
> 39228/-4.48753=T
>
> Mais on voit que changer un schéma sans prévoir des règles d'adaptation
> des données et des moteurs (de rendu, de calcul d'itinéraire, etc...) n'est
> pas très raisonnable.
>
> De plus ce concept de zone de correspondance est assez fumeux : quand on
> va du point a au point b qui ne sont pas reliés par la même ligne, on va
> accepter de marcher entre les deux stations les plus proches... sauf si ça
> rallonge de beaucoup le trajet motorisé.
>
> Typiquement au niveau de calcul d'itinéraires on va facilement passer par
> quelques nœuds de convergence des réseaux qui ne seront pas nécessairement
> très proches. Pour rester sur Brest : typiquement les arrêts autour de la
> place de la Liberté, République pour Rennes, etc... même si les arrêts
> n'ont pas le même nom et sans qu'on veuille je crois mettre toutes les
> stations du coin dans une même stop_area - le rendu serait peut-être des
> zones oblongues (ce ne sont pas des ovales) reliés par des traits conne
> c'est souvent schématisé sur des schémas de transports, faire un gros
> polygone/ovale n'aurait pas de sens (5 fois 2 arrêts Liberté* et 1 fois 2
> Multiplexe
> ). Et
> pourtant les gens changent à "Liberté" ou "République".
>
> Jean-Yvon
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 

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

Re: [OSM-talk-fr] Ancienne modélisation des multipolygones

2016-12-13 Per discussione Vincent de Château-Thierry


Bonjour,

Le 13/12/2016 à 10:22, JB a écrit :


J'avais vu ces outils passer, par contre je n'avais pas trouvé de
manière facile pour les exploiter : en gros, quels sont les MP
problématiques près de chez moi. Est-ce que j'ai raté une information,
ou ils n'existent pas ? Par exemple, OSMInspector vers qui le site
renvoie ne semble pas avoir de couche correspondante.


Oui récupérer 300Mo de données en pbf[1] n'est pas des plus confortable, 
je reconnais. La carte permet de grapiller des cas, sur Paris au moins 
il y a en suffisamment pour ne pas avoir à les chercher. Quelques 
exemples tous dans la même zone :

https://www.openstreetmap.org/relation/1102282
https://www.openstreetmap.org/relation/1465396
https://www.openstreetmap.org/relation/1515925

Pour les 2 derniers on peut se demander si la notion d'espace public 
piéton a bien une correspondance dans OSM. C'est un peu fourre-tout là.


OSMInspector en effet ne reprend pas dans la rubrique area ce qu'on 
s'attend à trouver à la lecture du readme de Github. On peut à la 
rigueur cocher "inner way has same tags" pour un type de souci approchant.


Sinon Osmose indique certains polygones comme devant être retaggués, 
dans la rubrique "multipolygon". Ils sont indiqués avec l'en-tête : 
"Inconsistant multipolygon nature with members nature"
C'est un peu usine à gaz comme proposition, mais si Osmose pouvait 
extraire strictement du pbf les "old-style multipolygons" ça pourrait 
alimenter une analyse ciblée ?


vincent

[1] : http://area.jochentopf.com/download/old-style.osm.pbf

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

Re: [OSM-talk-fr] intégration des référentiels STIF