Re: [Talk-br] RES: RES: OSM - CNEFE

[Lists]

Pra mim zoom fui bom ate agora, vou ter problemas participar com hangout este 
semana, talvez melhor pra semana que vem.

O Zoom tem o opção liga pra um telefone (numero do RJ?) se não ha acesso a 
computador, que pode me ajudar quando viajando

Aun Johnsen

> On Jul 15, 2015, at 10:56, Vitor George  wrote:
> 
> Estava escrevendo sobre isso agora, Lucas.
> 
> Estou vendo se usamos o Zoom, que é bom para reunião online, mas também 
> podemos fazer um hangout.
> 
> Quem for participar da reunião me avise por e-mail que eu chamo pra sala que 
> criarmos.
> 
> Vitor
> 
> 2015-07-15 10:53 GMT-03:00 Lucas Ferreira Mation  >:
> Pessoal, 
> 
> e ai, vamos ter a conversa mesmo hoje? 
> 12h00?
> 
> alguém pode "criar" a reunião (google hangouts, ou alguma outra plataforma)?
> (se precisar tenho skype também)
> 
> 
> 
> 
> 
> 
> 2015-07-14 12:12 GMT-03:00 Peter Krauss  >:
> Oi Lucas, ótimo trabalho (!), assim que sobrar um tempo (algum final de 
> semana) ponho a mão-na-massa, para entender o que voce fez e como podemos 
> conversar mais tecnicamente ;-)
>  (se tiver ilustrações, ex. UML, de modelo de dados para postar no git também 
> ajuda)
> Como sou novato, pretendo seguir um pouco "pelas bordas" e no escopo mais 
> geral das discussões...
> 
> A ideia geral do projeto de Mapa-do-CEP ainda é rascunho mas pode ser 
> apreciada em
>http://wiki.okfn.org/Open_Knowledge_Brasil/Mapa-do-CEP 
> 
> que tal começarmos pelo CEP2?
> 
> - - - - 
> Quanto os problemas legais (direitos autorais reclamados pela ECT bem como 
> lei do monopólio) , precisamos de apoio internacional, inclusive da OSM... 
> Comecei a busca por essa discussão (link abaixo), e senti receptividade,   
> http://opendata.stackexchange.com/q/5600/1313 
> 
> a parte juridica é importante para não jogarmos nosso tempo no lixo... Até 
> onde conversei com advogados, se criarmos uma metodologia (algoritmos) para 
> espacialização do CEP (ver links Wikipedia com preliminares), não tem 
> problema algum: o primeiro a publicar é o autor... Por isso acho importante 
> termos resultado a curto prazo de um projeto-piloto com OSM e publicarmos no 
> http://arxiv.org 
> 
> 
>  
> 
> 
> Em 14 de julho de 2015 11:13, Lucas Ferreira Mation  > escreveu:
> Pessoal, estou colocando o que já tenho de código em: 
> 
> 
> https://github.com/lucasmation/osm_cnefe_import 
> 
> (que perdoe a lingua portuguesa, escrevi em ingles para poder pegar mais 
> feedback dos desenvolvedores do OSM no mundo, foruns, etc) 
> 
> Peter, bem vindo. Eu usei mesmo esta pergunta do gis.stackexchange. E 
> elaborei em cima. Esta questão de dois lados do mesmo seguimento de rua 
> teremo o mesmo CEP eu poderia explorar para melhorar o paramento, mesmo em 
> quadras não pareadas. Mas o quão certo, 100% é isso?
> 
> abs
> Lucas
> 
> 
> 
> 
> 2015-07-13 19:01 GMT-03:00 Peter Krauss  >:
> Oi gente, acabo de me inscrever na lista... Posso participar da discussão?
> 
> Eu tenho interesse no mapeamento do CEP e do CNEFE, que justamente ajudam a 
> resolver ambiguidades e
> dar mais confiança à geocodificação... Até onde verifiquei, o Mapa-do-CEP não 
> oferece problema jurídico...
> Postei um esboço metodológico da sua construção, na Wikipedia,  
>   
> https://en.wikipedia.org/wiki/Postal_code#Codes_defined_indirectly_to_administrative_borders
>  
> 
> que acham?
> Alguem falou em quadras por aqui, é justamente o foco metodológico... 
>   http://gis.stackexchange.com/q/80498/7505 
> 
> 
> PS: sobre pontos de endereçamento de utilidade publica, um bom projeto de 
> referencia é o http://adresse.data.gouv.fr/ 
> 
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-br 
> 
> 
> 
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-br 
> 
> 
> 
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-br 
> 
> 
> 
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-br 
> 

Re: [Talk-br] Necessidade de intermediação

[Lists]

> On Jul 7, 2015, at 01:08, thunder...@gpsinfo.com.br wrote:
> 
> Leu errado.
> Leia novamente e verá que me referi ao desenho de acessos que o Aun fez 
> extraídos de tracklogs de bicicletas e pedestres.
> Esse acessos ainda estão no mapa e eles não existem, pelo menos até agora.
Estranho esse trevo, como tem tao muito fluxo do pedestres meia num obra, mas 
talvez e assim eles faco no ilha governador, deixando as pedestres passa pelo 
onde ha obras? Porque e impossível que as Brasileiras usar o tracklog do Strava 
quando estou no carro.

Fala isso, eu mapiou quase todos as ruas no Salinópolis/PA pelo MapBox/Strava, 
provavelmente fui muito errado de mim, porque ambos não e a confiar. Eu deveria 
perguntar o Marcio contatar algum usuários do COCAR morando la.___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] [Talk-pt] Declaração de renúncia de voto para decidir traduções de etiquetação (RESUMO + OPINIÃO)

[Lists]

“plaza” pode ser amenity=marketplace 

Aun Johnsen

> On Jul 3, 2015, at 19:17, Rogério Plisk  wrote:
> 
> 
> Shopping Center é meu voto (termo em pt-br para o inglês mall)
> 
> Para os centrinhos comerciais de bairro (igual ao da foto do Centro Alecrim) 
> na California/Eua me lembro que eram chamados de "Plaza".
> 
> Temos o "plaza" etiquetado em inglês?
> 
> Sds,
> Rogério.
> 
> Le 3 juil. 2015 à 14:29, Fernando Trebien  > a écrit :
> 
>> Cara, tu tá brigando com pessoas nas DUAS listas, AINDA? Essa prepotência 
>> (que já não é opinião só minha) de querer ser ouvido a todo custo, sem 
>> querer ter experiência, não contribui em nada com o OSM, só nos faz perder 
>> tempo. Reavalie.
>> 
>> On 3 Jul 2015 09:49, "Alexandre Magno Brito de Medeiros" 
>> mailto:alexandre@gmail.com>> wrote:
>> Esta resposta está endereçada (no cabeçalho) à talk-br, ao Pedro Santos 
>> (Portugal) e ao Fernando Trebien; apesar de que infelizmente este último, 
>> muito provavelmente, não exercerá seu direito de conhecê-la, já que resolveu 
>> me filtrar em sua Caixa de Entrada. Ainda vai para a talk-br porque é do meu 
>> interesse deixar lá, ao menos no histórico, um conhecimento mais completo 
>> dos fatos. Só não a envio à talk-pt porque, após pedir desculpas à talk-pt, 
>> e sabendo que Fernando não retornaria, eu disse "o tópico finda aqui".
>> 
>> É possível que o tópico não devesse nunca ter estado na talk-pt. Mas com 
>> certeza a talk-br era lugar para ele. Não na expectativa de interessar a 
>> cada participante, mas na expectativa de fazer uma renúncia pública que 
>> realmente tivesse valor.
>> 
>> Não abro mão do direito à opinião. Mas, como declarado posteriormente, nem 
>> tenho tanta vontade de exercê-lo no que diz respeito a etiquetação. Aquilo a 
>> que eu me agarro mesmo é o direito de relatar sobre o nome e a existência 
>> das coisas que conheço a partir de minhas vivências.
>> 
>> Pedro Santos envolveu-se e a talk-pt é pública.
>> 
>> Pedro dá a entender, em sua interpretação, que minha renúncia é como um 
>> brado inconsequente de um opinativo qualquer  que ficou insatisfeito porque 
>> não teve seus pitacos de momento considerados, quando na verdade o problema 
>> que tento resolver e existe entre eu e Fernando (com consequências para a 
>> comunidade) já era público e datava de alguns meses.
>> 
>> PT-PT e PT-BR são variantes linguísticas, tratadas idealmente no OSM (não 
>> sei no iD) como idiomas diferentes. Na realidade, há misturas e as traduções 
>> realizadas em um país afetam as traduções usadas no outro. Sabendo disso, eu 
>> julguei que publicaria a renúncia na talk-pt sem abusar do âmbito de 
>> comunicação desse meio. E assim permanece meu juízo. Eu apenas reconheço 
>> que, de forma complicadora para mim, o tópico se estendeu para além da 
>> renúncia.
>> 
>> Você leitor, se fala português, de um ou de outro lado do oceano, saiba que 
>> pode me reclamar a renúncia. Ela não é algo que dou somente ao Fernando.
>> 
>> Eu disse "o tópico finda aqui" e por isso não o estou reabrindo na talk-pt. 
>> O Pedro Santos deixar sua interpretação de mim após isso, deveria obrigar a 
>> consciência dele a exibir na talk-pt esta minha defesa. Não é correto opinar 
>> publicamente sobre "uma pessoa" quando esta já se comprometeu publicamente a 
>> ausentar-se. Então Pedro, você tenha a pachorra de ao menos exibir 
>> integralmente esse meu e-mail presente de defesa, lá na talk-pt. Minha 
>> sugestão é que você me responda, se o for fazer, pela talk-br com cópia 
>> (esta vez) para a talk-pt. Eu vou me abster de voltar à talk-pt.
>> 
>> Alexandre Magno
>> 
>> Em 3 de julho de 2015 03:37, Fernando Trebien > > escreveu:
>> Da minha parte, peço inclusive desculpas, no princípio nem me dei conta que 
>> a lista talk-pt estava incluída na nossa discussão, que certamente deveria 
>> ter se limitado à lista talk-br. Ou melhor, deveria ter ocorrido em 
>> particular.
>> 
>> Faço parte da talk-pt apenas como observador, em boa parte para obter 
>> inspiração para os trabalhos de tradução do OSM.
>> 
>> On 3 Jul 2015 03:20, "Pedro Santos" > > wrote:
>> Bom dia!
>> 
>> Agora que foram despejadas 4 páginas de texto (A4, 12pt, parágrafo simples), 
>> + de 2.400 palavras ou então + de 14.000 caracteres nesta lista, achei que 
>> devia tentar fazer um apanhado para aqueles que não têm a minha pachorra, 
>> acrescentando mais uma página. Por acréscimo segue a minha opinião, bem 
>> distinguível do relato.
>> 
>> Devo salientar que faço uma análise o mais isenta de preconceitos xenófobos 
>> que consigo. Se isto se transformar numa picardia Portugal/Brasil, não vou 
>> perder tempo. Simplesmente ignorarei este tópico.
>> 
>> A tradução da tag shop=mall foi posta a discussão no fórum users: Brazil 
>> :
>> http://forum.openstreetmap.org/viewtopic.php?pid=513600#p513600 
>> 

Re: [Talk-br] classificação de subprefeituras.

[Lists]

com boundary=administrative o admin_level geralmente e suficiente, e tem mesmo 
função em diferenciar entre limites de nível diferente. Para nos e util onde ha 
mais que um tipo limite no mesmo nível, que e caso do admin_level=9

Com outro tipos de limites (boundary=maritime, boundary=political, entre 
outros) onde não ha admin_level o border_type e para diferenciar entre os 
tipos. Não todos e aplicável no brasil mas para quem também editando fora e bom 
conhecer.

Aun Johnsen

> On Jun 14, 2015, at 13:53, Nelson A. de Oliveira  wrote:
> 
> 2015-06-14 12:20 GMT-03:00 Vítor Rodrigo Dias :
>> Como é isso de border_type, Nelson? Nunca vi essa tag antes...
> 
> É uma outra forma de diferenciar fronteiras/limites, quando place e
> admin_level não são suficientes.
> Não creio que exista muita coisa que utilize isso, mas vai dar para a
> gente saber o que é uma subprefeitura, por exemplo.
> 
> Portugal tem uma equivalência de 1 para 1 entre border_type e admin_level:
> http://wiki.openstreetmap.org/wiki/Key:border_type#Portugal
> 
> Nesse caso eu acho que não há necessidade (já que tudo pode ser
> representado diretamente por admin_level).
> A ideia não é definir border_type pro que já é possível distinguir com
> admin_level.
> 
> No nosso caso a gente teria diferentes border_types para diferenciar
> área representadas pelo menos admin_level.
> Por exemplo, locais que possuem tanto distrito e subdistrito, poderiam
> ser representados por:
> 
> admin_level=9 + border_type=district
> ou
> admin_level=9 + border_type=subdistrict
> 
> ___
> 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] classificação de subprefeituras.

[Lists]

Entao

São Paulo SP tem subprefeituras e distritos no admin_level 9

Vitoria ES tem distritos e subdistritos no admin_level 9

Que mais?

Aun Johnsen

> On Jun 14, 2015, at 01:21, Nelson A. de Oliveira  wrote:
> 
> Aproveitem e embalem nisso aqui tudo o que precisa ser discutido de
> coisa diferente que existe no Brasil, como subdistrito.
> 
> ___
> 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] Relação Cidade

[Lists]

Verdade

Ate algum municipios usando distrito (border_type=district) e outros 
subdistrito (border_type=subdistrict), e discobri que pelo menus Vitória ES 
usando ambos entre municipio (admin_level=8) e bairro (admin_level=10)

Aun Johnsen

> On Jun 13, 2015, at 23:58, Blademir Andrade de Lima  
> wrote:
> 
> É impossível querer padronizar o Brasil, porque existem realidades diferentes 
> pra querer aplicar as mesmas regras no país inteiro.
> 
> O admin_level:9 pode ser tanto aplicado em distritos como este aonde se usa 
> 'border_type:district' 
> http://www.openstreetmap.org/relation/5172637#map=12/-22.1896/-46.2210 
>  , ou 
> então pode ser usado quando um conjunto de bairros level 10 formam uma área 
> suburbana.
> 
> Até mesmo em dados oficiais (federais, estaduais ou prefeituras) existe 
> confusão, e não conseguiremos harmonizar isto com o OSM.
> 
> Minha cidade foi exemplo desta confusão de bairros, foi difícil passar pro 
> OSM.
> 
> Att,
> BladeTC
> 
> > From: thunder...@gpsinfo.com.br 
> > To: talk-br@openstreetmap.org 
> > Date: Sat, 13 Jun 2015 22:07:05 -0300
> > Subject: Re: [Talk-br] Relação Cidade
> > 
> > Nelson,
> > esqueci do Distrito (admin_level=9) e tampouco comentei sobre o 
> > admin_level=2 porque acredito ser esse ultimo óbvio.
> > o 9, de distrito, deve ser semelhante a bairro (admin_level=10),
> > 
> > Assim seria para o 9 e 10:
> > 
> > Relação admin_level=9, 10
> > name=*
> > type=boundary
> > boundary=administrative
> > admin_level=9 ou 10
> > label= ponto do distrito ou bairro
> > 
> > Nó
> > 
> > name=*
> > place=districts ou suburb
> > 
> > Seria muito util essa regra de validação no JOSM.
> > 
> > []s
> > Marcio
> > 
> > 
> > -Mensagem Original- 
> > From: Nelson A. de Oliveira
> > Sent: Saturday, June 13, 2015 9:47 PM
> > To: OpenStreetMap no Brasil
> > Subject: Re: [Talk-br] Relação Cidade
> > 
> > Parece que está tendo uma convergência boa para a definição aqui.
> > Se não tiver alguma opinião muito diferente ou contrária eu crio uma
> > regra de validação no JOSM para isso.
> > 
> > 
> > ___
> > 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] Relação Cidade

[Lists]

Em relação dos admin_level=3, 5, 6, 7, e 9 que não estampam admin_center, eles 
pode ter (e deve ter) um no com papel label

concordo com admin_level=4 e 8

Aun Johnsen

> On Jun 13, 2015, at 21:35, Marcio - Thundercel  
> wrote:
> 
> Minha opinião:
> 
> Relação admin_level=4 ou 8
>name=*
>type=boundary
>boundary=administrative
>admin_level=4 ou 8
>   admin_centre= ponto da cidade
> 
> Relação admin_level=10
>name=*
>type=boundary
>boundary=administrative
>admin_level=10
>label= ponto do bairro
> 
> Nó
> 
>name=*
>place=*
> 
> 
> Os admin_level= 3, 5, 6, 7 e 9 não estampam admin_centre.
> 
> Essas, na minha opinião, são as tags mínimas a serem incluídas nas relações 
> citadas.
> 
> A tag place só faz sentido para mim se empregada no nó e não na relação, até 
> porque essa tag tem sentido de lugar (cidade) e não área (região 
> administrativa - município).
> 
> Há diferença entre cidade e município. Cidade refere-se só ao núcleo urbano. 
> Município abrange tudo: o núcleo urbano e o rural.
> 
> A área urbana do município, onde se encontra o marco zero, é que deve 
> receber, na minha opinião, valores City, Town, etc.
> 
> Quanto a tag population fico em duvida para inclusão de dados porque teremos 
> a população do município (áreas urbana e rural) e a população só da área 
> urbana. Já observei muitos dados estatísticos separando área rural de urbana.
> 
> Não podemos esquecer o admin_centre na relação e tampouco o ponto de bairro 
> incluído com a regra label na relação admin-level=10.
> 
> []s
> Marcio
> 
> 
> 
> -Mensagem Original- From: Tarcisio Oliveira
> Sent: Saturday, June 13, 2015 8:05 PM
> To: OSM talk-br
> Subject: [Talk-br] Relação Cidade
> Boa noite a todos,
> devido a ultima discussão sobre relações de cidades e como deve ser as
> coisas, sugiro uma padronização das relações de cidades.
> Quais as tags que deverão estar na relação e quais devem ficar no nó.
> 
> Segue a minha opinião
> Relação
>name=*
>type=boundary
>boundary=administrative
>admin_level=*
>place=*
>population=*
>wikipedia=pt:*
> 
> Nó
>name=*
>place=*
>population=*
> 
> 
> As tags duplicadas de place e populations são justificadas pois se ela o
> nó não seria renderizado, o que poderia gerar que ele fosse apagado
> varais vezes por não enxergarem "nada" nele.
> 
> Tarcisio Oliveira
> ___
> 
> 
> ___
> 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] São Carlos, SP

[Lists]

OCAR e com isso estamos 
> recebendo inúmeros “feedbacks” de erros existentes no mapa.
>  
> Recentemente recebemos uma critica de um utilizador que reside em Ponte Nova 
> – MG. Disse ele que não empregava o mapa COCAR porque não era loteável em sua 
> cidade.
>  
> Fomo verificar o porque e identificamos que o editor Elias Lopes desenhou as 
> vias mas não as interligou nos entroncamentos.
>  
> Enviamos mensagem para ele, mas infelizmente não nos respondeu. Decidimos 
> então corrigir o problema interligando as vias, entretanto muitas continuam 
> por serem interligadas como, por exemplo, 
> http://www.openstreetmap.org/way/346557829 
> <http://www.openstreetmap.org/way/346557829>
>  
> Outro utilizador, agora residente em São Luís – MA, também fez critica quanto 
> ao roteamento pela cidade. Fomo identificar e realmente existem inúmeros 
> problemas ali que aos poucos estamos corrigindo.
>  
> Perdoem o desabafo, mas como abraçamos a causa e estamos divulgando o mapa 
> OSM nos sites que administramos, acabamos por ser o receptor de elogios e 
> também de críticas.
>  
> []s
> Marcio
>  
>  
>  
>  
> From: Lists <mailto:li...@gimnechiske.org>
> Sent: Saturday, June 13, 2015 9:02 AM
> To: OpenStreetMap no Brasil <mailto:talk-br@openstreetmap.org>
> Subject: Re: [Talk-br] São Carlos, SP
>  
> Marcio
>  
> Desculpa que nao pode ver o video voce me mando nem atualizar as mapas, to 
> offshore Patagonia e meu conecao internet nao dar para ver youtube e nem 
> baixar arquivos grandes.
>  
> Bem, vejo algum de seus problemas sobre garmin.openstreetmap.nl 
> <http://garmin.openstreetmap.nl/>, principalmente em calcular tempo nos 
> roteamentos, como voce dis não uso regras especificas por brasil, que 
> resultando velocidade padrão no autoestrada (highway=motorway) ser 250km/h, 
> no trunk 130 e no primary 90km/h por exemplo. Mas seus problemas de indexacao 
> não parecendo valido por esse mapa.
>  
> Eu nao tem mapas do link ES que voce mandou e não pode relatar resultado ai.
>  
> Como mapas do garmin.openstreetmap.nl <http://garmin.openstreetmap.nl/> 
> indexando as ruas e POI certas, o problema com indexacao nao e no banco dados 
> OSM, mas provavelmente nos regras voce utilizando. Antes de começar mexer com 
> o banco dados, verificar se ha problemas indicados nos ferramentas QA que tem 
> monte, e também verificar se problema também existe no outro fontes do mapa 
> Garmin.
>  
> Proximo vez voce encontrando problemas assim, se e com indexo, roteamento, ou 
> outros coisas, me manda informação sobre o problema, sobre como voce 
> testando, o que testes não dar resultado que voce espero, e o resultado voce 
> espero. Assim eu posso te ajudar reproduzir esses problemas para verificar 
> que realmente e no banco dados ou se consigo identificar outro fonte de 
> problema.
>  
> Eu sei que tem monte erros no mapa, enquanto tava tentando entender seu 
> problema encontrou ruas com nomes sigintes: “Rua !”, “Rua -1”, "A", "1", 
> "(7)", "(Trevo)", "(Rua Do Estacionamento Do Atacadao E Dicico Usada Pela 
> Comunidade Como Saida Do Transito Da Parada De Taipas)”, "Avenida 1? de Maio"
>  
> Também parecendo que temos muitos ruas com erros tipo “Ria” em vez de “Rua”, 
> em monte abreviações errados “R. A” e mais
>  
> Antes que começando corregir no banco dados que não dar erro no outros 
> fontes, temos um monte a concertar.
>  
> Aun Johnsen
>  
>> On Jun 13, 2015, at 08:36, > <mailto:thunder...@gpsinfo.com.br>> > <mailto:thunder...@gpsinfo.com.br>> wrote:
>>  
>> Aun Johnsen,
>> perdoe, mas ontem fui obrigado a me ausentar e não pude lhe responder na 
>> lista.
>>  
>> Conforme comentei anteriormente, os mapas do Brasil produzidos e fornecidos 
>> em http://garmin.openstreetmap.nl/ <http://garmin.openstreetmap.nl/> 
>> ouhttp://mapas.alternativaslibres.es/descargas.php 
>> <http://mapas.alternativaslibres.es/descargas.php> não atendem as 
>> necessidades brasileiras porque eles empregam os styles default do Mkgmap, 
>> sem o devido tratamento para o Brasil.
>>  
>> Testamos esses mapas exaustivamente e concluímos que quando empregados no 
>> Brasil geram inúmeros problemas aos utilizadores, em especial aos 
>> inexperientes.
>>  
>> Visando melhor demonstrar os problemas desses mapas, decidi gravar um vídeo 
>> tutorial mostrando o que ocorre quando os styles do Mkgmap não são tratados 
>> pelo utilizador.
>>  
>> Por gentileza veja o vídeo em https://www.youtube.com/watch?v=mwQNV0ndR44 
>> <https://www.youtube.com/watch?v=mwQNV

Re: [Talk-br] São Carlos, SP

[Lists]

Marcio

Desculpa que nao pode ver o video voce me mando nem atualizar as mapas, to 
offshore Patagonia e meu conecao internet nao dar para ver youtube e nem baixar 
arquivos grandes.

Bem, vejo algum de seus problemas sobre garmin.openstreetmap.nl 
<http://garmin.openstreetmap.nl/>, principalmente em calcular tempo nos 
roteamentos, como voce dis não uso regras especificas por brasil, que 
resultando velocidade padrão no autoestrada (highway=motorway) ser 250km/h, no 
trunk 130 e no primary 90km/h por exemplo. Mas seus problemas de indexacao não 
parecendo valido por esse mapa.

Eu nao tem mapas do link ES que voce mandou e não pode relatar resultado ai.

Como mapas do garmin.openstreetmap.nl <http://garmin.openstreetmap.nl/> 
indexando as ruas e POI certas, o problema com indexacao nao e no banco dados 
OSM, mas provavelmente nos regras voce utilizando. Antes de começar mexer com o 
banco dados, verificar se ha problemas indicados nos ferramentas QA que tem 
monte, e também verificar se problema também existe no outro fontes do mapa 
Garmin.

Proximo vez voce encontrando problemas assim, se e com indexo, roteamento, ou 
outros coisas, me manda informação sobre o problema, sobre como voce testando, 
o que testes não dar resultado que voce espero, e o resultado voce espero. 
Assim eu posso te ajudar reproduzir esses problemas para verificar que 
realmente e no banco dados ou se consigo identificar outro fonte de problema.

Eu sei que tem monte erros no mapa, enquanto tava tentando entender seu 
problema encontrou ruas com nomes sigintes: “Rua !”, “Rua -1”, "A", "1", "(7)", 
"(Trevo)", "(Rua Do Estacionamento Do Atacadao E Dicico Usada Pela Comunidade 
Como Saida Do Transito Da Parada De Taipas)”, "Avenida 1? de Maio"

Também parecendo que temos muitos ruas com erros tipo “Ria” em vez de “Rua”, em 
monte abreviações errados “R. A” e mais

Antes que começando corregir no banco dados que não dar erro no outros fontes, 
temos um monte a concertar.

Aun Johnsen

> On Jun 13, 2015, at 08:36,  
>  wrote:
> 
> Aun Johnsen,
> perdoe, mas ontem fui obrigado a me ausentar e não pude lhe responder na 
> lista.
>  
> Conforme comentei anteriormente, os mapas do Brasil produzidos e fornecidos 
> em http://garmin.openstreetmap.nl/ <http://garmin.openstreetmap.nl/> ou 
> http://mapas.alternativaslibres.es/descargas.php 
> <http://mapas.alternativaslibres.es/descargas.php>  não atendem as 
> necessidades brasileiras porque eles empregam os styles default do Mkgmap, 
> sem o devido tratamento para o Brasil.
>  
> Testamos esses mapas exaustivamente e concluímos que quando empregados no 
> Brasil geram inúmeros problemas aos utilizadores, em especial aos 
> inexperientes.
>  
> Visando melhor demonstrar os problemas desses mapas, decidi gravar um vídeo 
> tutorial mostrando o que ocorre quando os styles do Mkgmap não são tratados 
> pelo utilizador.
>  
> Por gentileza veja o vídeo em https://www.youtube.com/watch?v=mwQNV0ndR44 
> <https://www.youtube.com/watch?v=mwQNV0ndR44> onde nele aponto o problema 
> empregando o mapa do Brasil renderizado no dia 10/06/2015 pelo 
> http://garmin.openstreetmap.nl/ <http://garmin.openstreetmap.nl/>
>  
> []s
> Marcio
>  
> From: Lists <mailto:li...@gimnechiske.org>
> Sent: Friday, June 12, 2015 8:32 PM
> To: OpenStreetMap no Brasil <mailto:talk-br@openstreetmap.org>
> Subject: Re: [Talk-br] São Carlos, SP
>  
> Marcio
>  
> Me notei nomes de algumas ruas no São Carlos e fiz busca por nome da rua, 
> tudo deles achei sem problema.
>  
> Se consigo busca pelo nome da rua significando que e indexado, ne?
>  
> Isso e com mapas do garmin.openstreetmap.nl <http://garmin.openstreetmap.nl/> 
> compilado 29-03-2015, reproducido no BaseCamp e no meu Garmin Nüvi 50
>  
> https://i.imgur.com/Xk4FdoK.png <https://i.imgur.com/Xk4FdoK.png> 
>  
> Aun Johnsen
>  
>>  
> ___
> 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] São Carlos, SP

[Lists]

Marcio

Me notei nomes de algumas ruas no São Carlos e fiz busca por nome da rua, tudo 
deles achei sem problema.

Se consigo busca pelo nome da rua significando que e indexado, ne?

Isso e com mapas do garmin.openstreetmap.nl <http://garmin.openstreetmap.nl/> 
compilado 29-03-2015, reproducido no BaseCamp e no meu Garmin Nüvi 50

https://i.imgur.com/Xk4FdoK.png <https://i.imgur.com/Xk4FdoK.png> 

Aun Johnsen

> On Jun 12, 2015, at 19:25, Lists  wrote:
> 
> Marcio
> 
> Ja fiz algum testes, e parecendo que dos cidades que tentei, o maioria, 
> incluindo São Carlos SP, Belém PA, Manaus AM, Ribeirão Preto SP e Vitória ES 
> indexando certo, mas Cariacica ES e Guarapari ES parecendo que dar errado. 
> Sem um lista dos testes especifico não dar para reproduzir seus erros, então 
> favor me mandar um lista dos testes, que podemos testar com fontes diferentes 
> do Garmin alem do fontes externas como OSRM, Nominatim, Google Maps entre 
> outros.
> 
> Como outro vez voce tinha problemas com mapas Garmin eu pedi testes para 
> reproduzir seus problemas e voce não me respondeu com esses. Eu oferecendo te 
> ajudar achar a problema mas voce não me dar o que preciso para te ajudar.
> 
> Aun Johnsen
> 
>> On Jun 12, 2015, at 19:09, Lists > <mailto:li...@gimnechiske.org>> wrote:
>> 
>> Marcio,
>> 
>> Não tem certeza disso, porque nunca ha problemas com busca de endereços do 
>> São Sebastião SP. Não tentei com outros cidades do SP assim não sei se SSEB 
>> fui caso único ou não,
>> 
>> Se voce me dar um lista do buscas do cidades indexado certo, e cidades que 
>> faltam indexo, eu posso analizar isso, e ver mais certo se dar ou nao.
>> 
>> O que vai precisar e algum endereços e POIs dentro esses cidades, por 
>> exemplo hotéis, lojas ou posto gasolinas por nome, rua e numero do algum 
>> endereços, etc.
>> 
>> Eu vejo seus argumentos, e quer reproduzir seus problemas para eliminar onde 
>> ha problema.
>> 
>> Aun Johnsen
>> 
>>> On Jun 12, 2015, at 18:27, >> <mailto:thunder...@gpsinfo.com.br>> >> <mailto:thunder...@gpsinfo.com.br>> wrote:
>>> 
>>> Aun,
>>> pelos nossos testes, a única cidade que não está sendo indexada é São 
>>> Carlos – SP.
>>>  
>>> Fizemos testes com os mapas NL ( http://garmin.openstreetmap.nl/ 
>>> <http://garmin.openstreetmap.nl/> ) e ES ( 
>>> http://mapas.alternativaslibres.es/descargas.php 
>>> <http://mapas.alternativaslibres.es/descargas.php> ) e em ambos não 
>>> obtivemos sucesso na indexação de São Carlos – SP.  Neles, além São Carlos, 
>>> outras cidades de São Paulo também não indexam, em especial as contidas em 
>>> mesorregiões e microrregiões.
>>>  
>>> Empregando esses mapas em seu GPS não terá voce indexação de algumas 
>>> cidades de São Paulo porque recentemente o Blad incluiu Mesorregiões 
>>> (admin_level=5) e Microrregiões (admin_level=7) no estado, em especial na 
>>> região de Araraquara e São Carlos.
>>>  
>>> Esses sites que disponibilizam os mapas do Brasil empregam os styles 
>>> default do Mkgmap e com isso a relação boundary admin_level=8 é suplantada 
>>> pelas admin_level de menores valores incluidas (5 e 7) se o utilizador nada 
>>> fizer. 
>>>  
>>> Se observar no GPS carregado com um desses mapas, no para Onde / Cidade, a 
>>> cidade desejada só é encontrada se digitar no campo estado mesorregião ou a 
>>> microrregião correspondente, a de menor admin_level.
>>>  
>>> Para solucionar esse problema fomos obrigados a comandar no Mkgmap “drop” 
>>> dos admin_level 5 e 7 permitindo que o 8, o que queremos, fosse indexado. 
>>> Poderíamos até no style inserir os admin level 5 e 7 para serem processados 
>>> depois do 8, mas como em gps não empregamos mesorregião e microrregião 
>>> decidimos por exclui-las dos dados baixados
>>>  
>>> Em nosso style só empregamos os admin_level 2, 3, 4, 8, 9 e 10.
>>>  
>>> []s
>>> Marcio
>>>  
>>>  
>>>  
>>> From: Lists <mailto:li...@gimnechiske.org>
>>> Sent: Friday, June 12, 2015 5:52 PM
>>> To: OpenStreetMap no Brasil <mailto:talk-br@openstreetmap.org>
>>> Subject: Re: [Talk-br] São Carlos, SP
>>>  
>>> Marcio,
>>>  
>>> Eu vou jantar agora, depois eu pode fazer simulações nos meus aparelhos 
>>> buscar POIs e endereços no meus mapas garmin no computador através BaseCamp 
>>> e no meu Nüvi, espero que voce me mandar um lista 

Re: [Talk-br] São Carlos, SP

[Lists]

Marcio

Ja fiz algum testes, e parecendo que dos cidades que tentei, o maioria, 
incluindo São Carlos SP, Belém PA, Manaus AM, Ribeirão Preto SP e Vitória ES 
indexando certo, mas Cariacica ES e Guarapari ES parecendo que dar errado. Sem 
um lista dos testes especifico não dar para reproduzir seus erros, então favor 
me mandar um lista dos testes, que podemos testar com fontes diferentes do 
Garmin alem do fontes externas como OSRM, Nominatim, Google Maps entre outros.

Como outro vez voce tinha problemas com mapas Garmin eu pedi testes para 
reproduzir seus problemas e voce não me respondeu com esses. Eu oferecendo te 
ajudar achar a problema mas voce não me dar o que preciso para te ajudar.

Aun Johnsen

> On Jun 12, 2015, at 19:09, Lists  wrote:
> 
> Marcio,
> 
> Não tem certeza disso, porque nunca ha problemas com busca de endereços do 
> São Sebastião SP. Não tentei com outros cidades do SP assim não sei se SSEB 
> fui caso único ou não,
> 
> Se voce me dar um lista do buscas do cidades indexado certo, e cidades que 
> faltam indexo, eu posso analizar isso, e ver mais certo se dar ou nao.
> 
> O que vai precisar e algum endereços e POIs dentro esses cidades, por exemplo 
> hotéis, lojas ou posto gasolinas por nome, rua e numero do algum endereços, 
> etc.
> 
> Eu vejo seus argumentos, e quer reproduzir seus problemas para eliminar onde 
> ha problema.
> 
> Aun Johnsen
> 
>> On Jun 12, 2015, at 18:27, > <mailto:thunder...@gpsinfo.com.br>> > <mailto:thunder...@gpsinfo.com.br>> wrote:
>> 
>> Aun,
>> pelos nossos testes, a única cidade que não está sendo indexada é São Carlos 
>> – SP.
>>  
>> Fizemos testes com os mapas NL ( http://garmin.openstreetmap.nl/ 
>> <http://garmin.openstreetmap.nl/> ) e ES ( 
>> http://mapas.alternativaslibres.es/descargas.php 
>> <http://mapas.alternativaslibres.es/descargas.php> ) e em ambos não 
>> obtivemos sucesso na indexação de São Carlos – SP.  Neles, além São Carlos, 
>> outras cidades de São Paulo também não indexam, em especial as contidas em 
>> mesorregiões e microrregiões.
>>  
>> Empregando esses mapas em seu GPS não terá voce indexação de algumas cidades 
>> de São Paulo porque recentemente o Blad incluiu Mesorregiões (admin_level=5) 
>> e Microrregiões (admin_level=7) no estado, em especial na região de 
>> Araraquara e São Carlos.
>>  
>> Esses sites que disponibilizam os mapas do Brasil empregam os styles default 
>> do Mkgmap e com isso a relação boundary admin_level=8 é suplantada pelas 
>> admin_level de menores valores incluidas (5 e 7) se o utilizador nada fizer. 
>>  
>> Se observar no GPS carregado com um desses mapas, no para Onde / Cidade, a 
>> cidade desejada só é encontrada se digitar no campo estado mesorregião ou a 
>> microrregião correspondente, a de menor admin_level.
>>  
>> Para solucionar esse problema fomos obrigados a comandar no Mkgmap “drop” 
>> dos admin_level 5 e 7 permitindo que o 8, o que queremos, fosse indexado. 
>> Poderíamos até no style inserir os admin level 5 e 7 para serem processados 
>> depois do 8, mas como em gps não empregamos mesorregião e microrregião 
>> decidimos por exclui-las dos dados baixados
>>  
>> Em nosso style só empregamos os admin_level 2, 3, 4, 8, 9 e 10.
>>  
>> []s
>> Marcio
>>  
>>  
>>  
>> From: Lists <mailto:li...@gimnechiske.org>
>> Sent: Friday, June 12, 2015 5:52 PM
>> To: OpenStreetMap no Brasil <mailto:talk-br@openstreetmap.org>
>> Subject: Re: [Talk-br] São Carlos, SP
>>  
>> Marcio,
>>  
>> Eu vou jantar agora, depois eu pode fazer simulações nos meus aparelhos 
>> buscar POIs e endereços no meus mapas garmin no computador através BaseCamp 
>> e no meu Nüvi, espero que voce me mandar um lista do exemplos que, algum 
>> indexados e algum que voce não conseguir indexar, assim eu posso ver se 
>> mapas do garmin.openstreetmap.nl <http://garmin.openstreetmap.nl/> tem 
>> problemas indexar mesmas.
>>  
>> So para avisar, nao deu atualizar meus mapas desde 29-03-2015, assim edições 
>> feito e abril e ate agora não estou disponível nos meus mapas.
>>  
>> Aun Johnsen
>>  
>>>  
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/talk-br
> 

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

Re: [Talk-br] São Carlos, SP

[Lists]

Marcio,

Não tem certeza disso, porque nunca ha problemas com busca de endereços do São 
Sebastião SP. Não tentei com outros cidades do SP assim não sei se SSEB fui 
caso único ou não,

Se voce me dar um lista do buscas do cidades indexado certo, e cidades que 
faltam indexo, eu posso analizar isso, e ver mais certo se dar ou nao.

O que vai precisar e algum endereços e POIs dentro esses cidades, por exemplo 
hotéis, lojas ou posto gasolinas por nome, rua e numero do algum endereços, etc.

Eu vejo seus argumentos, e quer reproduzir seus problemas para eliminar onde ha 
problema.

Aun Johnsen

> On Jun 12, 2015, at 18:27,  
>  wrote:
> 
> Aun,
> pelos nossos testes, a única cidade que não está sendo indexada é São Carlos 
> – SP.
>  
> Fizemos testes com os mapas NL ( http://garmin.openstreetmap.nl/ 
> <http://garmin.openstreetmap.nl/> ) e ES ( 
> http://mapas.alternativaslibres.es/descargas.php 
> <http://mapas.alternativaslibres.es/descargas.php> ) e em ambos não obtivemos 
> sucesso na indexação de São Carlos – SP.  Neles, além São Carlos, outras 
> cidades de São Paulo também não indexam, em especial as contidas em 
> mesorregiões e microrregiões.
>  
> Empregando esses mapas em seu GPS não terá voce indexação de algumas cidades 
> de São Paulo porque recentemente o Blad incluiu Mesorregiões (admin_level=5) 
> e Microrregiões (admin_level=7) no estado, em especial na região de 
> Araraquara e São Carlos.
>  
> Esses sites que disponibilizam os mapas do Brasil empregam os styles default 
> do Mkgmap e com isso a relação boundary admin_level=8 é suplantada pelas 
> admin_level de menores valores incluidas (5 e 7) se o utilizador nada fizer. 
>  
> Se observar no GPS carregado com um desses mapas, no para Onde / Cidade, a 
> cidade desejada só é encontrada se digitar no campo estado mesorregião ou a 
> microrregião correspondente, a de menor admin_level.
>  
> Para solucionar esse problema fomos obrigados a comandar no Mkgmap “drop” dos 
> admin_level 5 e 7 permitindo que o 8, o que queremos, fosse indexado. 
> Poderíamos até no style inserir os admin level 5 e 7 para serem processados 
> depois do 8, mas como em gps não empregamos mesorregião e microrregião 
> decidimos por exclui-las dos dados baixados
>  
> Em nosso style só empregamos os admin_level 2, 3, 4, 8, 9 e 10.
>  
> []s
> Marcio
>  
>  
>  
> From: Lists <mailto:li...@gimnechiske.org>
> Sent: Friday, June 12, 2015 5:52 PM
> To: OpenStreetMap no Brasil <mailto:talk-br@openstreetmap.org>
> Subject: Re: [Talk-br] São Carlos, SP
>  
> Marcio,
>  
> Eu vou jantar agora, depois eu pode fazer simulações nos meus aparelhos 
> buscar POIs e endereços no meus mapas garmin no computador através BaseCamp e 
> no meu Nüvi, espero que voce me mandar um lista do exemplos que, algum 
> indexados e algum que voce não conseguir indexar, assim eu posso ver se mapas 
> do garmin.openstreetmap.nl <http://garmin.openstreetmap.nl/> tem problemas 
> indexar mesmas.
>  
> So para avisar, nao deu atualizar meus mapas desde 29-03-2015, assim edições 
> feito e abril e ate agora não estou disponível nos meus mapas.
>  
> Aun Johnsen
>  
>>  
> ___
> 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] São Carlos, SP

[Lists]

Marcio

Lembro um tempo atraz Amasonas se identificei como “Amasonas (old)”, esse fui 
por caso do um relação apagado, mas pertenci no Nominatim por quase 2 anos 
depois

Então problemas interna no Nominatim pode fica por muito tempo

Aun Johnsen

> On Jun 12, 2015, at 17:58,  
>  wrote:
> 
> Isso havia eu reparado, mas nas formatações no OSM não identifiquei essa 
> situação. Seria um BUG do nominatim?
> 
> Estranho o nominatim não se atualizar em inclusões feitas há 1 mês.
> 
> -Mensagem Original- From: Nelson A. de Oliveira
> Sent: Friday, June 12, 2015 5:36 PM
> To: OpenStreetMap no Brasil
> Subject: Re: [Talk-br] São Carlos, SP
> 
> Repare aqui:
> 
> http://i.imgur.com/0CB2iAB.png
> 
> Note que existe um city (o primeiro) e um town (o segundo).
> Desconfio que tenha sido pela adição de addr:place há 1 mês atrás (e
> alguns índices do nominatim não são atualizados em tempo real).
> 
> 
> ___
> 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] São Carlos, SP

[Lists]

Marcio,

Eu vou jantar agora, depois eu pode fazer simulações nos meus aparelhos buscar 
POIs e endereços no meus mapas garmin no computador através BaseCamp e no meu 
Nüvi, espero que voce me mandar um lista do exemplos que, algum indexados e 
algum que voce não conseguir indexar, assim eu posso ver se mapas do 
garmin.openstreetmap.nl <http://garmin.openstreetmap.nl/> tem problemas indexar 
mesmas.

So para avisar, nao deu atualizar meus mapas desde 29-03-2015, assim edições 
feito e abril e ate agora não estou disponível nos meus mapas.

Aun Johnsen

> On Jun 12, 2015, at 17:43,  
>  wrote:
> 
> Aun Johnsen,
> o mkgmap não acusa erro, mas também não indexa a cidade quando da busca no 
> GPS. Interessante que só não indexa essa cidade de São Carlos. Todas as 
> demais de São Paulo indexa.
>  
> O importante aqui, no meu propósito, é padronizarmos o emprego de tags nas 
> relações boundarys e acertarmos de uma vez por todas o que é incluído nela.
>  
> Identificamos nas relações boundarys os mais variados empregos de tags. Não 
> existe uma padronização.
>  
> Estamos fazendo um esforço de incluir o membro admin_centre nas relações 
> boundarys já que muitas delas não contemplam isso, em especial nas do Estado 
> de São Paulo.
>  
> Muitas tem o is_in e ainda não ficou decidido se é redundante ou não esse 
> emprego.
>  
> Muitas tem o place= na relação e também no POI da cidade. Até agora não 
> sabemos se deve permanecer em ambas ou somente no POI da cidade, apesar de 
> deduzirmos que place só deve ficar no POI e não na relação, uma vez que a 
> relação define o limite administrativo do município e não o marco zero da 
> cidade.
>  
> Todas essas situações e outra existentes nada acusam de aviso ou erro no JOSM.
>  
> []s
> Marcio
>  
>  
>  
> From: Lists <mailto:li...@gimnechiske.org>
> Sent: Friday, June 12, 2015 5:20 PM
> To: OpenStreetMap no Brasil <mailto:talk-br@openstreetmap.org>
> Subject: Re: [Talk-br] São Carlos, SP
>  
> Marcio
>  
> Voce nao respondi meu segundo pergunta
>  
>>  
>> 2) O que erro, alertas ou outros informações esses dar no Mkgmap, 
>> validadador JOSM e outros ferramentas QA ou processamento?
>>  
> 
>  
> O que mensagem dar no mkgmap?
>  
> Dar erro no validador JOSM?
>  
> o KeepRight indicando algum coisas keepright.at <http://keepright.at/> ?
>  
> tem algum coisas indicado aqui: 
> http://developer.mapquest.com/web/products/open/nominatim/broken-polygon 
> <http://developer.mapquest.com/web/products/open/nominatim/broken-polygon> ?
>  
> ou aqui http://ra.osmsurround.org/ <http://ra.osmsurround.org/> ?
>  
> ou aqui http://tools.geofabrik.de/osmi/# <http://tools.geofabrik.de/osmi/#> ?
>  
> ou aqui http://osmose.openstreetmap.fr/en/map/ 
> <http://osmose.openstreetmap.fr/en/map/#zoom=12&lat=-20.6532&lon=-40.5116&layer=Mapnik&overlays=FFFT&item=&level=1&tags=&fixable=&bbox=-40.769920349121094,-20.761250430919638,-40.35621643066406,-20.53732786084848>
>  ?
>  
>  
> Aun Johnsen
>  
>>  
> ___
> 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] São Carlos, SP

[Lists]

Marcio

Voce nao respondi meu segundo pergunta

>  
> 2) O que erro, alertas ou outros informações esses dar no Mkgmap, validadador 
> JOSM e outros ferramentas QA ou processamento?
>  


O que mensagem dar no mkgmap?

Dar erro no validador JOSM?

o KeepRight indicando algum coisas keepright.at <http://keepright.at/> ?

tem algum coisas indicado aqui: 
http://developer.mapquest.com/web/products/open/nominatim/broken-polygon 
<http://developer.mapquest.com/web/products/open/nominatim/broken-polygon> ?

ou aqui http://ra.osmsurround.org/ <http://ra.osmsurround.org/> ?

ou aqui http://tools.geofabrik.de/osmi/# <http://tools.geofabrik.de/osmi/#> ?

ou aqui http://osmose.openstreetmap.fr/en/map/ 
<http://osmose.openstreetmap.fr/en/map/#zoom=12&lat=-20.6532&lon=-40.5116&layer=Mapnik&overlays=FFFT&item=&level=1&tags=&fixable=&bbox=-40.769920349121094,-20.761250430919638,-40.35621643066406,-20.53732786084848>
 ?


Aun Johnsen

> On Jun 12, 2015, at 16:54,  
>  wrote:
> 
> Aun Johnsen,
>  
> quando identificamos o problema verificamos que as edições do POI e relação 
> eram muito antigas.
>  
> []s
> Marcio
>  
>  
> From: Lists <mailto:li...@gimnechiske.org>
> Sent: Friday, June 12, 2015 4:44 PM
> To: OpenStreetMap no Brasil <mailto:talk-br@openstreetmap.org>
> Subject: Re: [Talk-br] São Carlos, SP
>  
> Marcio
>  
> Com buscas do Nominatim pode demorar um pouco para atualizações ser 
> realizadas. Meus perguntas e assim:
>  
> 1) no seu 2 exemplos, quando fui os últimos edições das POI e relação? Eles 
> foram criados, ou tags principais alterados no esses edições?
>  
> 2) O que erro, alertas ou outros informações esses dar no Mkgmap, validadador 
> JOSM e outros ferramentas QA ou processamento?
>  
> Aun Johnsen
>  
>> On Jun 12, 2015, at 16:36, > <mailto:thunder...@gpsinfo.com.br>> > <mailto:thunder...@gpsinfo.com.br>> wrote:
>>  
>> Amigos,
>> Por alguma razão, ainda desconhecida por mim, a Cidade de São Carlos não 
>> está indexando em nosso mapa Cocar que emprega o Mkgmap.
>>  
>> Analisando no OSM as configurações da relação São Carlos ( 
>> http://www.openstreetmap.org/relation/297986 
>> <http://www.openstreetmap.org/relation/297986> ) identificamos que pelo 
>> nomination só é indexado o POI da cidade como admin_centre e não é indexado 
>> o POI isoladamente em função ao place=city incluido no POI.
>>  
>> A cidade de Concórdia – SC,  por exemplo, tem o seguinte retorno:
>>  
>> Resultados de OpenStreetMap Nominatim <http://nominatim.openstreetmap.org/>
>> Limite de Município Concórdia, Microrregião de Concórdia, Mesorregião do 
>> Oeste Catarinense, Santa Catarina, Região Sul, Brasil 
>> <http://www.openstreetmap.org/relation/296692>
>> Cidade Concórdia, Microrregião de Concórdia, Mesorregião do Oeste 
>> Catarinense, Santa Catarina, Região Sul, 8970, Brasil 
>> <http://www.openstreetmap.org/node/415523393>
>> No nosso entender esse retorno duplo é correto já que existe a relação 
>> (Concordia – Limite de Municipio) e o POI (São Carlos – Place=city).
>>  
>> Observem que para Concordia aparece na busca o POI isolado da cidade: 
>> http://www.openstreetmap.org/node/415523393 
>> <http://www.openstreetmap.org/node/415523393>
>>  
>>  
>> Já para São Carlos – SP assim aparece:
>>  
>>  
>> Resultados de OpenStreetMap Nominatim <http://nominatim.openstreetmap.org/>
>> Cidade São Carlos, Microrregião de São Carlos, Mesorregião de Araraquara, 
>> São Paulo, Região Sudeste, Brasil 
>> <http://www.openstreetmap.org/relation/297986>
>>  
>> Não existe pela busca o POI da cidade isoladamente. Só existe pela busca a 
>> Cidade que na verdade não é a cidade e sim o Limite de Municipio, a relação 
>> São Carlos.
>>  
>> Afinal quem está certo nessas duas buscas?
>>  
>> []s
>> Marcio
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/talk-br
> 
>  
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br

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

Re: [Talk-br] São Carlos, SP

[Lists]

Marcio

Com buscas do Nominatim pode demorar um pouco para atualizações ser realizadas. 
Meus perguntas e assim:

1) no seu 2 exemplos, quando fui os últimos edições das POI e relação? Eles 
foram criados, ou tags principais alterados no esses edições?

2) O que erro, alertas ou outros informações esses dar no Mkgmap, validadador 
JOSM e outros ferramentas QA ou processamento?

Aun Johnsen

> On Jun 12, 2015, at 16:36,  
>  wrote:
> 
> Amigos,
> Por alguma razão, ainda desconhecida por mim, a Cidade de São Carlos não está 
> indexando em nosso mapa Cocar que emprega o Mkgmap.
>  
> Analisando no OSM as configurações da relação São Carlos ( 
> http://www.openstreetmap.org/relation/297986 
>  ) identificamos que pelo 
> nomination só é indexado o POI da cidade como admin_centre e não é indexado o 
> POI isoladamente em função ao place=city incluido no POI.
>  
> A cidade de Concórdia – SC,  por exemplo, tem o seguinte retorno:
>  
> Resultados de OpenStreetMap Nominatim 
> Limite de Município Concórdia, Microrregião de Concórdia, Mesorregião do 
> Oeste Catarinense, Santa Catarina, Região Sul, Brasil 
> 
> Cidade Concórdia, Microrregião de Concórdia, Mesorregião do Oeste 
> Catarinense, Santa Catarina, Região Sul, 8970, Brasil 
> 
> No nosso entender esse retorno duplo é correto já que existe a relação 
> (Concordia – Limite de Municipio) e o POI (São Carlos – Place=city).
>  
> Observem que para Concordia aparece na busca o POI isolado da cidade: 
> http://www.openstreetmap.org/node/415523393 
> 
>  
>  
> Já para São Carlos – SP assim aparece:
>  
>  
> Resultados de OpenStreetMap Nominatim 
> Cidade São Carlos, Microrregião de São Carlos, Mesorregião de Araraquara, São 
> Paulo, Região Sudeste, Brasil 
>  
> Não existe pela busca o POI da cidade isoladamente. Só existe pela busca a 
> Cidade que na verdade não é a cidade e sim o Limite de Municipio, a relação 
> São Carlos.
>  
> Afinal quem está certo nessas duas buscas?
>  
> []s
> Marcio
> ___
> 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] A boa vontade embutida no OpenStreetMap não pode tudo

[Lists]

Ivaldo

Viu seu resposta depois que mandei iltimo mail

Se podemos influir o processo de liberar o banco dados do CEP para importação 
no OSM ajudaria, mas ate a licença do banco dados e resolvido esperamos.

Aun Johnsen

> On Jun 8, 2015, at 20:57, Ivaldo Nunes de Magalhães  
> wrote:
> 
> Oi Aun...
> 
> Veja, eu não disse para ninguém trabalhar na ilegalidade e muito menos que se 
> deva se submeter aos correios para mapear. Muito pelo contrário. Apenas que a 
> base de cep disponível na internet é livre e pode ser utilizado, por quem 
> quiser. Nisso, havendo restrições de aplicabilidade (isto é, utilizar a base 
> de cep disponível na internet) no OSM (uai) que não se use.
> 
> 
> ___
> 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] Digest Talk-br, volume 81, assunto 9

[Lists]

Ivaldo

Voce e certo e errado no mesmo tempo.

Voce e livre a usar os resultados do pesquisas simples, não ha restrições em 
como voce utilizando dados assim, mas o banco dados do CEP tem um licença 
comercial que evitando reprodução do banco dados. Como importar esses dados pra 
OSM e um reprodução do banco dados, não podemos fazer isso.

Tambem nao sei se o site tem restrição em quantos pesquisas voce pode fazer por 
dia. O limit com certeza e mais alto que uso normal, mas se voce vai pesquisar 
os CEPs do cada rua num cidade grande sairmos ao ~20.000 pesquisas ou mais. Se 
o limite e 500 por dia (que e bastante para uso pessoal), verificar os CEPs do 
um cidade como Vitoria vai demora 40 dias. Com 5500 municípios no Brasil, algum 
maiores a algum menores, podemos levar uns 5000 meses ou 416 anos terminar 
esses pesquisas.

Eu nao conheco bem os limites técnicas no site ou licença do esse banco dados, 
mas que tem certeza que sem os dados liberados sob um licença certa para 
importação, não valer a pena tentar importa-los

Aun Johnsen

> On Jun 8, 2015, at 20:41, Ivaldo Nunes de Magalhães  
> wrote:
> 
> Oi Alexandre... 
> 
> Quanto ao CEP no site dos correios, pode ser utilizado sem restrições sim. 
> Aliás é até bom para os correios, pois dissemina o uso pela população. Eles 
> (correios) querem isso. Já trabalhei com cadastro de CEP/DNE. O que não pode 
> é o cara comprar a base do DNE e fazer milhares de cópias e revender, para 
> fins lucrativos, como todo o soft. Alías, o DNE, não está tão caro, como foi 
> dito aqui. Para as empresas ou pessoas com contrato, dependendo do caso, 
> parece que está saindo free.
> 
> Quanto ao CEP ser estratégico, eu concordo com você também. O que quis dizer 
> foi: o que é melhor/possível: mapear uma cidade que nem aparece no mapa ou 
> colocar CEP nas existentes? Claro que eu posso já mapear e colocar o CEP, 
> como todas as outras tags necessárias... asfalto, nome, restrições, faixas de 
> pedestre, sinais. e tudo mais. O ideal seria se colocar tudo... mas nem 
> sempre (ou quase sempre) isso é possivel.
> 
> Abraços.
> 
> 
>  
> 
> 
> 
> 
> Ivaldo Nunes de Magalhães
> E-mail: ivald...@gmail.com 
> Blog: makermaps.blogspot.com.br 
> (67) 8108-7415 - 3431-2810
> (61) 9139-7560
> 
> Em 8 de junho de 2015 18:26,  > escreveu:
> Enviar submissões para a lista de discussão Talk-br para
> talk-br@openstreetmap.org 
> 
> Para se cadastrar ou descadastrar via WWW, visite o endereço
> https://lists.openstreetmap.org/listinfo/talk-br 
> 
> ou, via email, envie uma mensagem com a palavra 'help' no assunto ou
> corpo da mensagem para
> talk-br-requ...@openstreetmap.org 
> 
> 
> Você poderá entrar em contato com a pessoa que gerencia a lista pelo
> endereço
> talk-br-ow...@openstreetmap.org 
> 
> 
> Quando responder, por favor edite sua linha Assunto assim ela será
> mais específica que "Re: Contents of Talk-br digest..."
> 
> 
> Tópicos de Hoje:
> 
>1. A boa vontade embutida no OpenStreetMap não pode tudo
>   (Alexandre Magno Brito de Medeiros)
>2. RES:  Digest Talk-br, volume 81, assunto 7 (Reinaldo Neves)
> 
> 
> --
> 
> Message: 1
> Date: Mon, 8 Jun 2015 19:10:20 -0300
> From: Alexandre Magno Brito de Medeiros  >
> To: OpenStreetMap no Brasil  >
> Subject: [Talk-br] A boa vontade embutida no OpenStreetMap não pode
> tudo
> Message-ID:
>  >
> Content-Type: text/plain; charset="utf-8"
> 
> *Era: "Re: [Talk-br] Digest Talk-br, volume 81, assunto 7"*
> 
> Olá a todos!
> 
> Meus comentários sobre alguns pontos trazidos pelo Ivaldo Nunes.
> 
> Toda a base de dados do DNE está disponível no busca CEP dos correios:
> > http://www.bucacep.correios.com.br , 
> > onde é disponibilizado várias formas
> > de consultas. Nisso a informação é publica, sem restrições de acesso.Não é
> > muito complicado extrair relatórios lá, por bairros - por exemplo - enviar
> > para o excel e depois csv, etc... Agora, as funcionalidades do sistema
> > realmente são restritas à empresa.
> >
> 
> Pode não haver restrição de acesso, mas certamente há restrição de uso,
> implícita, para vários tipos de uso. Alguém se meta a fazer essa
> "exportação", usar o resultado a seu bel prazer, e vejamos quanto tempo
> demora para a empresa "buscar seus direitos" na Justiça!
> 
> Realmente a seria muito bom que os correios tornasse público a base de
> > dados do DNE via gratuidade da licença do sistema, mas para quê serviria
> > isso? Bom, talvez para alguém ter algum nicho de trabalho facilit

Re: [Talk-br] A boa vontade embutida no OpenStreetMap não pode tudo

[Lists]

Mesmo que a licença dos dados CEP dos correios e duvidoso legalmente e 
politicamente devemos espera os dados liberado corretamente antes de fazer um 
importação. Com o velocidade glacial desse processo acho temos assuntos mais 
importante a resolver enquanto esperamos os dados liberados.

Aun Johnsen

> On Jun 8, 2015, at 19:10, Alexandre Magno Brito de Medeiros 
>  wrote:
> 
> Era: "Re: [Talk-br] Digest Talk-br, volume 81, assunto 7"
> 
> Olá a todos!
> 
> Meus comentários sobre alguns pontos trazidos pelo Ivaldo Nunes.
> 
> Toda a base de dados do DNE está disponível no busca CEP dos correios: 
> http://www.bucacep.correios.com.br , 
> onde é disponibilizado várias formas de consultas. Nisso a informação é 
> publica, sem restrições de acesso.Não é muito complicado extrair relatórios 
> lá, por bairros - por exemplo - enviar para o excel e depois csv, etc... 
> Agora, as funcionalidades do sistema realmente são restritas à empresa.
> 
> Pode não haver restrição de acesso, mas certamente há restrição de uso, 
> implícita, para vários tipos de uso. Alguém se meta a fazer essa 
> "exportação", usar o resultado a seu bel prazer, e vejamos quanto tempo 
> demora para a empresa "buscar seus direitos" na Justiça!
> 
> Realmente a seria muito bom que os correios tornasse público a base de dados 
> do DNE via gratuidade da licença do sistema, mas para quê serviria isso? Bom, 
> talvez para alguém ter algum nicho de trabalho facilitado, [...]
> 
> Só a partir de uma coisa dessas é que o OpenStreetMap poderia licitamente 
> importar aqueles dados. Não estou opinando se a coisa toda está moralmente 
> certa ou moralmente errada. Só estou dizendo que hoje o OpenStreetMap não tem 
> o apoio da lei, evidenciado e indiscutível, para fazer uso daqueles dados de 
> CEP que são disponibilizados pelo site dos Correios.
> 
> Desse modo, não vejo o CEP como um problema, mas uma prioridade menos 
> importante, não urgente, frente ao nosso mapa atual: milhares de cidades nem 
> aparecem. 
> 
> Ter o CEP desde o início é uma questão estratégica. Alguns podem achar que é 
> imprescindível, para se aproveitar um grande primeiro esforço de mapeamento, 
> que será quase o único. Outros podem achar que CEP é algo que pode ficar pra 
> depois, a ser importado com automatizações ou grandes facilitações obtidas 
> por software. Eu penso que os dois estilos são importantes e não deveriam se 
> excluir mutuamente, já que o contexto é o projeto OpenStreetMap movido por 
> voluntarismo, e não um empreendimento corporativo originado por $$.
> 
> Alexandre Magno
> 
> 
> Em 8 de junho de 2015 18:24, Ivaldo Nunes de Magalhães  > escreveu:
> Pessoal, relativamente aos tópicos DNE, CEP, ECT, e CNEFE, gostaria de fazer 
> alguns comentários pois recentemente estive envolvido com processos ligados 
> aos mesmos, tendo trabalhando com o DNE e ainda sendo analista da ECT - 
> correios, mas não falo em nome da mesma, mais sim por convicção própria.
> 
> 1. ECT/Empresa Pública: realmente os correios são uma empresa publica, mas 
> ela é uma empresa e não um órgão público (como um posto de saúde ou escola), 
> fazendo parte da administração indireta. Nesse ponto, possui vários sistemas 
> corporativos cuja utilização é restrita à empresa, no caso o DNE. Por 
> exemplo: o BB - Banco do Brasil, também tem seus sistemas, entre eles o 
> SISBB. É complicado para eles divulgarem sua base de dados ao público.
> 
> Toda a base de dados do DNE está disponível no busca CEP dos correios: 
> http://www.bucacep.correios.com.br , 
> onde é disponibilizado várias formas de consultas. Nisso a informação é 
> publica, sem restrições de acesso.Não é muito complicado extrair relatórios 
> lá, por bairros - por exemplo - enviar para o excel e depois csv, etc... 
> Agora, as funcionalidades do sistema realmente são restritas à empresa.
> 
> 2. Não existe, ainda, georreferenciamento no CEP, pois ele não identifica um 
> ponto (identificação num mapa de um cruzamento de latitude com longitude), 
> mas sim uma linha/logradouro, no caso de a cidade ter CEP por logradouros.
> 
> 3. O CNEFE (Cadastro Nacional de Endereços para Fins Estatísticos) é outro 
> ponto que deve ser visto com ressalvas. Veja que o próprio nome fiz:... para 
> Fins Estatísticos. O que significa isso? Não é oficial.
> 
> Explico: embora o IBGE seja um órgão público, e portanto oficial, não 
> significa que os endereços do CNEFE sejam oficiais. A única entidade com 
> poder sobre os endereços são as prefeituras municipais, e as respectivas 
> câmaras de vereadores. Porque isso? Qualquer loteamento, condomínio, bairro 
> ou logradouro (rua, avenidas, etc) para existir dependem de decreto ou lei 
> municipal. Sem isso, oficialmente não existe e não é reconhecida pelos órgão 
> públicos.
> 
> Muitos dos endereços do CNEFE são coletados dos moradores nos censos. Quando 
> a rua existe (fisicamente) ou não é of

Re: [Talk-br] Layer do IBGE no iD

[Lists]

Paulo

Em caso do JOSM e differente, eles fazendo um “limpeza” vez e outro com a 
repositório do editor-imagery-index, mas tem nada diretamente ligado ao 
repositório. Se voce quer utilizar este lista ao vivo no JOSM preciso mudar um 
preference, como eu fiz, ai eu usando este lista em vez da lista official do 
JOSM.

Como este lista e integrada no outros editores, como iD, Potlatch2 o Vespucci, 
eu não pode responder, eu achava iD usava lista ao vivo, mas parecendo que nao.

Aun Johnsen

> On May 26, 2015, at 14:52, Paulo Carvalho  <mailto:paulo.r.m.carva...@gmail.com>> wrote:
> 
> Vitor, as alterações ainda não foram mergeadas para o repositório principal, 
> que dá origem ao JOSM oficial.
> 
> Em 26 de maio de 2015 10:29, Vitor George  <mailto:vitor.geo...@gmail.com>> escreveu:
> Oi Aun, este pull request do Arlindo deveria fazer funcionar no iD. Queria 
> saber se o problema é só comigo. 
> 
> 2015-05-26 10:09 GMT-03:00 Lists  <mailto:li...@gimnechiske.org>>:
> 
> Vitor, pessoal
> 
> Este funciona bem no JOSM, onde substitui a lista padrão do JOSM com esse, 
> não to usando iD, e provavelmente eles ainda tem a lista antigua no cache, 
> não que com que intervalo eles atualizando, ou se a lista e carregado no 
> nível de navigador. Talvez preciso abre ticket com iD?
> 
> Aun Johnsen
> 
>> On May 26, 2015, at 10:03, Vitor George > <mailto:vitor.geo...@gmail.com>> wrote:
>> 
>> Oi pessoal,
>> 
>> Aceitaram o pull request do Arlindo para os layers do IBGE aparecerem no iD, 
>> mas não consegui fazer funcionar. Alguém pode testar também?
>> 
>> Aqui está o PR: 
>> 
>> https://github.com/osmlab/editor-imagery-index/issues/71 
>> <https://github.com/osmlab/editor-imagery-index/issues/71>
>> 
>> Abraço,
>> Vitor
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/talk-br 
>> <https://lists.openstreetmap.org/listinfo/talk-br>
> 
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-br 
> <https://lists.openstreetmap.org/listinfo/talk-br>
> 
> 
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-br 
> <https://lists.openstreetmap.org/listinfo/talk-br>
> 
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-br 
> <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] Layer do IBGE no iD

[Lists]

Paulo

Em caso do JOSM e differente, eles fazendo um “limpeza” vez e outro com a 
repositório do editor-imagery-index, mas tem nada diretamente ligado ao 
repositório. Se voce quer utilizar este lista ao vivo no JOSM preciso mudar um 
preference, como eu fiz, ai eu usando este lista em vez da lista official do 
JOSM.

Como este lista e integrada no outros editores, como iD, Potlatch2 o Vespucci, 
eu não pode responder, eu achava iD usava lista ao vivo, mas parecendo que nao.

Aun Johnsen

> On May 26, 2015, at 14:52, Paulo Carvalho  <mailto:paulo.r.m.carva...@gmail.com>> wrote:
> 
> Vitor, as alterações ainda não foram mergeadas para o repositório principal, 
> que dá origem ao JOSM oficial.
> 
> Em 26 de maio de 2015 10:29, Vitor George  <mailto:vitor.geo...@gmail.com>> escreveu:
> Oi Aun, este pull request do Arlindo deveria fazer funcionar no iD. Queria 
> saber se o problema é só comigo. 
> 
> 2015-05-26 10:09 GMT-03:00 Lists  <mailto:li...@gimnechiske.org>>:
> 
> Vitor, pessoal
> 
> Este funciona bem no JOSM, onde substitui a lista padrão do JOSM com esse, 
> não to usando iD, e provavelmente eles ainda tem a lista antigua no cache, 
> não que com que intervalo eles atualizando, ou se a lista e carregado no 
> nível de navigador. Talvez preciso abre ticket com iD?
> 
> Aun Johnsen
> 
>> On May 26, 2015, at 10:03, Vitor George > <mailto:vitor.geo...@gmail.com>> wrote:
>> 
>> Oi pessoal,
>> 
>> Aceitaram o pull request do Arlindo para os layers do IBGE aparecerem no iD, 
>> mas não consegui fazer funcionar. Alguém pode testar também?
>> 
>> Aqui está o PR: 
>> 
>> https://github.com/osmlab/editor-imagery-index/issues/71 
>> <https://github.com/osmlab/editor-imagery-index/issues/71>
>> 
>> Abraço,
>> Vitor
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/talk-br 
>> <https://lists.openstreetmap.org/listinfo/talk-br>
> 
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-br 
> <https://lists.openstreetmap.org/listinfo/talk-br>
> 
> 
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-br 
> <https://lists.openstreetmap.org/listinfo/talk-br>
> 
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-br 
> <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] Layer do IBGE no iD

[Lists]

Paulo

Em caso do JOSM e differente, eles fazendo um “limpeza” vez e outro com a 
repositório do editor-imagery-index, mas tem nada diretamente ligado ao 
repositório. Se voce quer utilizar este lista ao vivo no JOSM preciso mudar um 
preference, como eu fiz, ai eu usando este lista em vez da lista official do 
JOSM.

Como este lista e integrada no outros editores, como iD, Potlatch2 o Vespucci, 
eu não pode responder, eu achava iD usava lista ao vivo, mas parecendo que nao.

Aun Johnsen

> On May 26, 2015, at 14:52, Paulo Carvalho  <mailto:paulo.r.m.carva...@gmail.com>> wrote:
> 
> Vitor, as alterações ainda não foram mergeadas para o repositório principal, 
> que dá origem ao JOSM oficial.
> 
> Em 26 de maio de 2015 10:29, Vitor George  <mailto:vitor.geo...@gmail.com>> escreveu:
> Oi Aun, este pull request do Arlindo deveria fazer funcionar no iD. Queria 
> saber se o problema é só comigo. 
> 
> 2015-05-26 10:09 GMT-03:00 Lists  <mailto:li...@gimnechiske.org>>:
> 
> Vitor, pessoal
> 
> Este funciona bem no JOSM, onde substitui a lista padrão do JOSM com esse, 
> não to usando iD, e provavelmente eles ainda tem a lista antigua no cache, 
> não que com que intervalo eles atualizando, ou se a lista e carregado no 
> nível de navigador. Talvez preciso abre ticket com iD?
> 
> Aun Johnsen
> 
>> On May 26, 2015, at 10:03, Vitor George > <mailto:vitor.geo...@gmail.com>> wrote:
>> 
>> Oi pessoal,
>> 
>> Aceitaram o pull request do Arlindo para os layers do IBGE aparecerem no iD, 
>> mas não consegui fazer funcionar. Alguém pode testar também?
>> 
>> Aqui está o PR: 
>> 
>> https://github.com/osmlab/editor-imagery-index/issues/71 
>> <https://github.com/osmlab/editor-imagery-index/issues/71>
>> 
>> Abraço,
>> Vitor
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/talk-br 
>> <https://lists.openstreetmap.org/listinfo/talk-br>
> 
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-br 
> <https://lists.openstreetmap.org/listinfo/talk-br>
> 
> 
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-br 
> <https://lists.openstreetmap.org/listinfo/talk-br>
> 
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-br

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

Re: [Talk-br] Layer do IBGE no iD

[Lists]

Paulo

Em caso do JOSM e differente, eles fazendo um “limpeza” vez e outro com a 
repositório do editor-imagery-index, mas tem nada diretamente ligado ao 
repositório. Se voce quer utilizar este lista ao vivo no JOSM preciso mudar um 
preference, como eu fiz, ai eu usando este lista em vez da lista official do 
JOSM.

Como este lista e integrada no outros editores, como iD, Potlatch2 o Vespucci, 
eu não pode responder, eu achava iD usava lista ao vivo, mas parecendo que nao.

Aun Johnsen

> On May 26, 2015, at 14:52, Paulo Carvalho  
> wrote:
> 
> Vitor, as alterações ainda não foram mergeadas para o repositório principal, 
> que dá origem ao JOSM oficial.
> 
> Em 26 de maio de 2015 10:29, Vitor George  <mailto:vitor.geo...@gmail.com>> escreveu:
> Oi Aun, este pull request do Arlindo deveria fazer funcionar no iD. Queria 
> saber se o problema é só comigo. 
> 
> 2015-05-26 10:09 GMT-03:00 Lists  <mailto:li...@gimnechiske.org>>:
> 
> Vitor, pessoal
> 
> Este funciona bem no JOSM, onde substitui a lista padrão do JOSM com esse, 
> não to usando iD, e provavelmente eles ainda tem a lista antigua no cache, 
> não que com que intervalo eles atualizando, ou se a lista e carregado no 
> nível de navigador. Talvez preciso abre ticket com iD?
> 
> Aun Johnsen
> 
>> On May 26, 2015, at 10:03, Vitor George > <mailto:vitor.geo...@gmail.com>> wrote:
>> 
>> Oi pessoal,
>> 
>> Aceitaram o pull request do Arlindo para os layers do IBGE aparecerem no iD, 
>> mas não consegui fazer funcionar. Alguém pode testar também?
>> 
>> Aqui está o PR: 
>> 
>> https://github.com/osmlab/editor-imagery-index/issues/71 
>> <https://github.com/osmlab/editor-imagery-index/issues/71>
>> 
>> Abraço,
>> Vitor
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/talk-br 
>> <https://lists.openstreetmap.org/listinfo/talk-br>
> 
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-br 
> <https://lists.openstreetmap.org/listinfo/talk-br>
> 
> 
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-br 
> <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] Layer do IBGE no iD

[Lists]

Vitor, pessoal

Este funciona bem no JOSM, onde substitui a lista padrão do JOSM com esse, não 
to usando iD, e provavelmente eles ainda tem a lista antigua no cache, não que 
com que intervalo eles atualizando, ou se a lista e carregado no nível de 
navigador. Talvez preciso abre ticket com iD?

Aun Johnsen

> On May 26, 2015, at 10:03, Vitor George  wrote:
> 
> Oi pessoal,
> 
> Aceitaram o pull request do Arlindo para os layers do IBGE aparecerem no iD, 
> mas não consegui fazer funcionar. Alguém pode testar também?
> 
> Aqui está o PR: 
> 
> https://github.com/osmlab/editor-imagery-index/issues/71 
> 
> 
> Abraço,
> Vitor
> ___
> 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] Reunião Periodica - OSM Brasil

[Lists]

Thierry

Infelizmente nao poderia entrar

Você pode manda um resumo?

Aun Johnsen

> On May 20, 2015, at 09:55, Thierry Jean  wrote:
> 
> Caros,
>  
> Precisamos reativar as nossas reuniões periodicas. Sugiro que elas aconteçam 
> a cada 2 semanas, nas quartas-feiras ao meio dia. Vamos faze-la hoje ao meio 
> dia.
>  
> Comprei uma licença do ZOOM que funicona muito bem em mobile, além de 
> funcionar em notebooks. É só baixar o app do Zoom e digitar o id do meeting.
>  
> ===//===
> Topic: Reunião periodica - OSM Brasil
> 
> 
> Time: May 20, 2015 12:00 PM (GMT-3:00) Sao Paulo 
> 
> 
> Join from PC, Mac, iOS or Android: https://zoom.us/j/5694747229 
> 
> Or join by phone:
> 
> 
> +55 (213) 958-7888 (Brazil Toll)
> 
> Meeting ID: 569 474 7229 
> International numbers available: https://zoom.us/zoomconference 
> 
> //=
>  
> Os assuntos:
>  
> Local chapter - OSM Brasil
>  
> Negociação com INDE do ministerio do planejamento
>  
> Visita ao IBGE, a semana passada
>  
> Palestras dadas recentementes (MundoGeo, Tela Viva)
>  
> Materia que passou na Globo na Universidade de São Carlos
>  
> SOTM Latam que aocntecerá em Setembro em Santiago do Chile
> --> Necessidade de ajudar o Julio a criar os tópicos e convidar 
> palestrantes como Correios, INDE, IBGE, outros
>  
>  
> 
> 
> Thierry Jean
> +55 11 99607 1319
> 
>  
> ___
> 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] mapeando ciclofaixa

[Lists]

Arlindo, Wille

Talvez procura mais imagens como exemplos pro o wiki

Aun Johnsen

> On May 12, 2015, at 14:11, Arlindo Pereira  
> wrote:
> 
> Sim, ali é ciclovia e não ciclofaixa. São coisas distintas.
> 
> 
> Em ter, 12 de mai de 2015 14:06,  > escreveu:
> Lendo a explicação do Willie sobre ciclovia e como ela deve ser
> conectada a faixa já existente , a que existe nas margens do rio
> Pinheiros não se enquadraria . Ela está fora da via e há um muro que a
> separa da marginal Pinheiros . Me parece que ela é acessada nas pontes
> via escadaria .
> 
> 
> ___
> 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] edições e pesquisa no OSM e talk

[Lists]

Blademir

Bom voce começando monitorar este. Fica atento no este site com os mudanças 
voce fazendo, e corrigir/reverter quando voce ver erros aparecendo. Voce pode 
também junta este processo com outros pessoas que trabalhando com limites 
administrativas.

Eu acho que com este, meu alerta do situação deu resultado bom no final

Obrigado

Aun Johnsen

> On May 11, 2015, at 20:24, Blademir Andrade de Lima  
> wrote:
> 
> Boa noite meu caros, gostaria de tecer minhas ponderações ao ocorrido.
> 
> Aun Johnsen, realmente, o "OSM.wno-edv-service" alertou inicialmente sobre as 
> vias que foram particionadas devido a sua longa extensão (por metros ou 
> pontos em excesso).
> 
> Acontece que durante este processo usando o ID, elas não são automaticamente 
> REORGANIZADAS, permanecendo quebradas, o que não acontece no JOSM.
> Bom, foi isto o que ocorreu primeiro, vamos dar sequencia aos fatos.
> 
> Em Seguida, foram excluídos as 'TAGs' admin_level que estão marcadas na via 
> (way) e não as que estão na relação (relation). Foram dois trabalhos 
> diferentes.
> 
> É redundante adicionar esta TAG diretamente na via, se a mesma ja esta 
> marcada DENTRO da relação, inclusive, essa informação redundante pode gerar 
> conflitos, como o que estamos tentando resolver.
> 
> Como forma de evitar quaisquer problemas com as relações, das quais me 
> interessa o assunto, verificarei diariamente qualquer alteração pelo site 
> "OSM.wno-edv-service", em se tratando de Brasil.
> 
> Quanto as TAGs 'admin_level' esta discussão tem de ser levada para o OSM, e 
> sabermos se continuaremos da forma como esta ou se evoluímos o processo.
> 
> Um forte abraço a todos,
> Blademir Andrade de Lima
> BladeTC
> 
> From: li...@gimnechiske.org <mailto:li...@gimnechiske.org>
> Date: Mon, 11 May 2015 14:17:01 -0300
> To: talk-br@openstreetmap.org <mailto:talk-br@openstreetmap.org>
> Subject: Re: [Talk-br] edições e pesquisa no OSM e talk
> 
> Eu nao sei exatamente o que alertou os revicoes, mas os chagesets tem 
> referencia desse pagina: 
> http://osm.wno-edv-service.de:82/index.php/10-osm-reports/186-countries-compare-2015-05-11
>  
> <http://osm.wno-edv-service.de:82/index.php/10-osm-reports/186-countries-compare-2015-05-11>
> 
> Favor para esses edições dos limites ate vocês entender o que chegando esse 
> lista para evitar um edit war
> 
> Aun Johnsen
> 
> On May 11, 2015, at 14:05, Blademir Andrade de Lima  <mailto:blademi...@hotmail.com>> wrote:
> 
> Quebrados,  OU fora da sequência. Corrigi alguns em que a sequência dentro da 
> relação estava fora da ordem. 
> O JOSM corrige isso facilmente.
> 
> Abraços, 
> BladeTc
> 
> --- Mensagem Original ---
> 
> De: "Lists" mailto:li...@gimnechiske.org>>
> Enviado: 11 de maio de 2015 11:16
> Para: "OpenStreetMap no Brasil"  <mailto:talk-br@openstreetmap.org>>
> Assunto: Re: [Talk-br] edições e pesquisa no OSM e talk
> 
> Para ai
> 
> Eu comecando ver changesets do tipo “concertando relacoes de limites 
> administrativos quebrados” que parecendo chegar do OSMI ou outros sistemas de 
> QA, tem certeza que o trabalho voces fiz fui certo? Ou vocês quebrou alguma 
> coisa no processo?
> 
> Ainda nao ha tempo verificar o que fui editado nesses changesets
> 
> Aun Johnsen
> 
> On May 11, 2015, at 11:01,  <mailto:thunder...@gpsinfo.com.br>>  <mailto:thunder...@gpsinfo.com.br>> wrote:
> 
> Todos os créditos devem ir para o Bladimir, já que nesse aspecto de relações 
> administrativas ele é seguramente bem mais experiente do que eu.
>  
> Comecei a experimentar essa edição recentemente e nesse aprendizado acabei 
> cometendo alguns erros como particionar (quebrar) o way para retirar o aviso 
> no JOSM de longo caminho.
>  
> Apesar de muitos aqui defenderem o JOSM somente agora entendi o quanto ele é 
> superior ao ID.
>  
> Quando um Way é membro de mais de uma relação boundary, quando o 
> particionamos pelo ID é quebrada alguma relação boundary da qual ele faz 
> parte. Particionado pelo JOSM existe uma validação desse que o particiona 
> também em todas as relações boundarys que ele é membro, sem quebrá-las.
> Ontem a noite identifiquei as que quebrei e as corrigi quase todas. O 
> Bladimir (“meu gurú”) já tinha corrigido a de São Paulo e, portanto, os 
> créditos do trabalho devem ser dirigidos a ele.
>  
> []s
> Marcio
>  
> From: Helio Cesar Tomio <mailto:hcto...@gmail.com>
> Sent: Sunday, May 10, 2015 10:29 PM
> To: talk-br@openstreetmap.org <mailto:talk-br@openstreetmap.org>
> Subject: [Talk-br] edições e pesquisa no OSM e talk
&g

Re: [Talk-br] Digest Talk-br, volume 80, assunto 28

[Lists]

Pelo que intendi e nem ciclofaixa e nem ciclovia, e um via dedicada para onibus 
compartilhada com bicicletas (via nao ha acesso em geral access=no, so psv=yes 
e bicycle=yes)

Aun Johnsen

> On May 11, 2015, at 19:53, belnu...@pop.com.br wrote:
> 
> Não  entendi o exemplo B4 . Ela é  uma ciclofaixa ou uma ciclovia ?
> 
> --
> Enviado do aplicativo myMail para Android
> 
> sábado, 09 maio 2015, 09:00AM -03:00 de talk-br-requ...@openstreetmap.org:
> 
> Enviar submissões para a lista de discussão Talk-br para
> talk-br@openstreetmap.org
> Para se cadastrar ou descadastrar via WWW, visite o endereço
> https://lists.openstreetmap.org/listinfo/talk-br
> ou, via email, envie uma mensagem com a palavra 'help' no assunto ou
> corpo da mensagem para
> talk-br-requ...@openstreetmap.org
> Você poderá entrar em contato com a pessoa que gerencia a lista pelo
> endereço
> talk-br-ow...@openstreetmap.org
> Quando responder, por favor edite sua linha Assunto assim ela será
> mais específica que "Re: Contents of Talk-br digest..."
> Tópicos de Hoje:
>1. Re: Mapeando ciclofaixa (Márcio Vinícius Pinheiro)
> --
> Message: 1
> Date: Fri, 8 May 2015 20:36:41 -0300
> From: Márcio Vinícius Pinheiro  < marcioviniciu...@gmail.com >
> To: OpenStreetMap no Brasil < talk-br@openstreetmap.org >
> Subject: Re: [Talk-br] Mapeando ciclofaixa
> Message-ID:
> < CAPMOee=ccMTa9pSVJ_ABsP+uT1KKJ7knOt=+dgu-4zzztfh...@mail.gmail.com >
> Content-Type: text/plain; charset="utf-8"
> Não estou entendo essa discussão toda. Qual situação não está exemplificada
> em  http://wiki.openstreetmap.org/wiki/Pt-br:Bicycle ?
> Atenciosamente,
> Márcio Vinícius Pinheiro.
> http://about.me/Doideira
> Em 08/05/2015 20:12, < thunder...@gpsinfo.com.br > escreveu:
> >   Existem comentários muito interessantes sobre isso em
> >  http://vadebike.org/2008/07/ciclista-so-de-e-usar-o-lado-direito-da-ia/
> >
> >  *From:* Arlindo Pereira < openstreet...@arlindopereira.com >
> > *Sent:* Friday, May 8, 2015 6:36 PM
> > *To:* OpenStreetMap no Brasil < talk-br@openstreetmap.org >
> > *Subject:* Re: [Talk-br] Mapeando ciclofaixa
> >
> >  O CTB diz o seguinte:
> >
> > "Art. 58. Nas vias urbanas e nas rurais de pista dupla, a circulação de
> > bicicletas deverá ocorrer, quando não houver ciclovia, ciclofaixa, ou
> > acostamento, ou quando não for possível a utilização destes, nos bordos da
> > pista de rolamento, no mesmo sentido de circulação regulamentado para a
> > via, com preferência sobre os veículos automotores."
> >
> >
> > ___
> > Talk-br mailing list
> >  Talk-br@openstreetmap.org
> >  https://lists.openstreetmap.org/listinfo/talk-br
> >
> >
> -- Próxima Parte --
> Um anexo em HTML foi limpo...
> URL: < 
> http://lists.openstreetmap.org/pipermail/talk-br/attachments/20150508/71f793e3/attachment-0001.html
>  >
> --
> Subject: Legenda do Digest
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
> --
> Fim da Digest Talk-br, volume 80, assunto 28
> 
> 
> ___
> 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] edições e pesquisa no OSM e talk

[Lists]

 
http://osm.wno-edv-service.de:82/index.php/10-osm-reports/186-countries-compare-2015-05-11
 


Aun Johnsen

> On May 11, 2015, at 16:16, Blademir Andrade de Lima  
> wrote:
> 
> Ok, aonde posso ver essas reversões?
> 
> BladeTC

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

Re: [Talk-br] edições e pesquisa no OSM e talk

[Lists]

Eu conheço nada sobre mensagens ou comunicação sobre este assunto, o caso e que 
muitos relações fui quebrado devido seus edições.

O fato e que relações fui quebrado, e chagesets revertidos.

Aun Johnsen

> On May 11, 2015, at 16:04, Blademir Andrade de Lima  
> wrote:
> 
> Não recebi nenhuma mensagem no website do OSM sobre qualquer erro nem 
> discussão em alguma 'changeset' feita por mim.
> 
> Não recordo de ter quebrado relação nenhuma. Alias, nos ultimos dias tenho 
> concentrado esforços para criar relações administrativas 5 e 7, e não sair 
> "quebrando" nós por aí.
> 
> Abraços,
> BladeTC
> 
> 
> From: li...@gimnechiske.org <mailto:li...@gimnechiske.org>
> Date: Mon, 11 May 2015 15:50:33 -0300
> To: talk-br@openstreetmap.org <mailto:talk-br@openstreetmap.org>
> Subject: Re: [Talk-br] edições e pesquisa no OSM e talk
> 
> Baldemir e Marcio
> 
> Aqui e resposta do 4rch sobre o que aconteceu com seus edições.
> 
> Voces quebrou pelo menus 40 limites administrativas, não so no Brasil mas 
> também Venezuela e Colombia.
> 
> --
> Hallo,
> 4rch hinterließ einen Kommentar zu einem Kartenänderungssatz, den du 
> beobachtest, erstellt von 4rch am 2015-05-11 18:44:47 UTC mit dem Kommentar 
> „repaired damaged boundaries“
> ==In CS #30952748 (*) Thundercel splitted some boundary ways but he hasn't 
> loaded all affected boundary relations into JOSM and so he created about 40 
> boundary relations in Venezuela, Columbia and Brazil with gaps (unclosed 
> multipolygons) because the existing relations didn’t reference the newly 
> created ways.
> (*) https://www.openstreetmap.org/changeset/30952748 
> <https://www.openstreetmap.org/changeset/30952748>
> ==Weitere Einzelheiten über den Änderungssatz können gefunden werden unter 
> http://www.openstreetmap.org/changeset/30993496 
> <http://www.openstreetmap.org/changeset/30993496>.
> 
> Aun Johnsen
> 
> On May 11, 2015, at 15:35, Lists  <mailto:li...@gimnechiske.org>> wrote:
> 
> Baldemir
> 
> Os edicoes voces fiz os ultimos dias foram revertido por um grupo no alemão 
> que monitorando e corrigindo limites administrativos
> 
> O site que deu link e um ferramento que dar alerta em mudanças dos limites
> 
> Entao, maioria do trabalho que vocês fiz com os limites os últimos dias foram 
> no lixao porque vocês fiz algum coisas errados.
> 
> Olha este site, entender o que eles monitorando, e se não entendo este site, 
> não editar mais limites.
> 
> Aun Johnsen
> 
> On May 11, 2015, at 15:29, Blademir Andrade de Lima  <mailto:blademi...@hotmail.com>> wrote:
> 
> Desculpe Aun Johnsen, não estou lhe entendendo.
> 
> Poderia ser mais claro?
> 
> BladeTC
> 
> From: li...@gimnechiske.org <mailto:li...@gimnechiske.org>
> Date: Mon, 11 May 2015 14:17:01 -0300
> To: talk-br@openstreetmap.org <mailto:talk-br@openstreetmap.org>
> Subject: Re: [Talk-br] edições e pesquisa no OSM e talk
> 
> Eu nao sei exatamente o que alertou os revicoes, mas os chagesets tem 
> referencia desse pagina: 
> http://osm.wno-edv-service.de:82/index.php/10-osm-reports/186-countries-compare-2015-05-11
>  
> <http://osm.wno-edv-service.de:82/index.php/10-osm-reports/186-countries-compare-2015-05-11>
> 
> Favor para esses edições dos limites ate vocês entender o que chegando esse 
> lista para evitar um edit war
> 
> Aun Johnsen
> 
> On May 11, 2015, at 14:05, Blademir Andrade de Lima  <mailto:blademi...@hotmail.com>> wrote:
> 
> Quebrados,  OU fora da sequência. Corrigi alguns em que a sequência dentro da 
> relação estava fora da ordem. 
> O JOSM corrige isso facilmente.
> 
> Abraços, 
> BladeTc
> 
> --- Mensagem Original ---
> 
> De: "Lists" mailto:li...@gimnechiske.org>>
> Enviado: 11 de maio de 2015 11:16
> Para: "OpenStreetMap no Brasil"  <mailto:talk-br@openstreetmap.org>>
> Assunto: Re: [Talk-br] edições e pesquisa no OSM e talk
> 
> Para ai
> 
> Eu comecando ver changesets do tipo “concertando relacoes de limites 
> administrativos quebrados” que parecendo chegar do OSMI ou outros sistemas de 
> QA, tem certeza que o trabalho voces fiz fui certo? Ou vocês quebrou alguma 
> coisa no processo?
> 
> Ainda nao ha tempo verificar o que fui editado nesses changesets
> 
> Aun Johnsen
> 
> On May 11, 2015, at 11:01,  <mailto:thunder...@gpsinfo.com.br>>  <mailto:thunder...@gpsinfo.com.br>> wrote:
> 
> Todos os créditos devem ir para o Bladimir, já que nesse aspecto de relações 
> administrativas ele é seguramente bem mais experiente do que eu.
>  
> Comecei a experimentar essa ed

Re: [Talk-br] edições e pesquisa no OSM e talk

[Lists]

Baldemir e Marcio

Aqui e resposta do 4rch sobre o que aconteceu com seus edições.

Voces quebrou pelo menus 40 limites administrativas, não so no Brasil mas 
também Venezuela e Colombia.

--
Hallo,

4rch hinterließ einen Kommentar zu einem Kartenänderungssatz, den du 
beobachtest, erstellt von 4rch am 2015-05-11 18:44:47 UTC mit dem Kommentar 
„repaired damaged boundaries“

==
In CS #30952748 (*) Thundercel splitted some boundary ways but he hasn't loaded 
all affected boundary relations into JOSM and so he created about 40 boundary 
relations in Venezuela, Columbia and Brazil with gaps (unclosed multipolygons) 
because the existing relations didn’t reference the newly created ways.

(*) https://www.openstreetmap.org/changeset/30952748 
<https://www.openstreetmap.org/changeset/30952748>==
Weitere Einzelheiten über den Änderungssatz können gefunden werden unter 
http://www.openstreetmap.org/changeset/30993496 
<http://www.openstreetmap.org/changeset/30993496>.


Aun Johnsen

> On May 11, 2015, at 15:35, Lists  wrote:
> 
> Baldemir
> 
> Os edicoes voces fiz os ultimos dias foram revertido por um grupo no alemão 
> que monitorando e corrigindo limites administrativos
> 
> O site que deu link e um ferramento que dar alerta em mudanças dos limites
> 
> Entao, maioria do trabalho que vocês fiz com os limites os últimos dias foram 
> no lixao porque vocês fiz algum coisas errados.
> 
> Olha este site, entender o que eles monitorando, e se não entendo este site, 
> não editar mais limites.
> 
> Aun Johnsen
> 
>> On May 11, 2015, at 15:29, Blademir Andrade de Lima > <mailto:blademi...@hotmail.com>> wrote:
>> 
>> Desculpe Aun Johnsen, não estou lhe entendendo.
>> 
>> Poderia ser mais claro?
>> 
>> BladeTC
>> 
>> From: li...@gimnechiske.org <mailto:li...@gimnechiske.org>
>> Date: Mon, 11 May 2015 14:17:01 -0300
>> To: talk-br@openstreetmap.org <mailto:talk-br@openstreetmap.org>
>> Subject: Re: [Talk-br] edições e pesquisa no OSM e talk
>> 
>> Eu nao sei exatamente o que alertou os revicoes, mas os chagesets tem 
>> referencia desse pagina: 
>> http://osm.wno-edv-service.de:82/index.php/10-osm-reports/186-countries-compare-2015-05-11
>>  
>> <http://osm.wno-edv-service.de:82/index.php/10-osm-reports/186-countries-compare-2015-05-11>
>> 
>> Favor para esses edições dos limites ate vocês entender o que chegando esse 
>> lista para evitar um edit war
>> 
>> Aun Johnsen
>> 
>> On May 11, 2015, at 14:05, Blademir Andrade de Lima > <mailto:blademi...@hotmail.com>> wrote:
>> 
>> Quebrados,  OU fora da sequência. Corrigi alguns em que a sequência dentro 
>> da relação estava fora da ordem. 
>> O JOSM corrige isso facilmente.
>> 
>> Abraços, 
>> BladeTc
>> 
>> --- Mensagem Original ---
>> 
>> De: "Lists" mailto:li...@gimnechiske.org>>
>> Enviado: 11 de maio de 2015 11:16
>> Para: "OpenStreetMap no Brasil" > <mailto:talk-br@openstreetmap.org>>
>> Assunto: Re: [Talk-br] edições e pesquisa no OSM e talk
>> 
>> Para ai
>> 
>> Eu comecando ver changesets do tipo “concertando relacoes de limites 
>> administrativos quebrados” que parecendo chegar do OSMI ou outros sistemas 
>> de QA, tem certeza que o trabalho voces fiz fui certo? Ou vocês quebrou 
>> alguma coisa no processo?
>> 
>> Ainda nao ha tempo verificar o que fui editado nesses changesets
>> 
>> Aun Johnsen
>> 
>> On May 11, 2015, at 11:01, > <mailto:thunder...@gpsinfo.com.br>> > <mailto:thunder...@gpsinfo.com.br>> wrote:
>> 
>> Todos os créditos devem ir para o Bladimir, já que nesse aspecto de relações 
>> administrativas ele é seguramente bem mais experiente do que eu.
>>  
>> Comecei a experimentar essa edição recentemente e nesse aprendizado acabei 
>> cometendo alguns erros como particionar (quebrar) o way para retirar o aviso 
>> no JOSM de longo caminho.
>>  
>> Apesar de muitos aqui defenderem o JOSM somente agora entendi o quanto ele é 
>> superior ao ID.
>>  
>> Quando um Way é membro de mais de uma relação boundary, quando o 
>> particionamos pelo ID é quebrada alguma relação boundary da qual ele faz 
>> parte. Particionado pelo JOSM existe uma validação desse que o particiona 
>> também em todas as relações boundarys que ele é membro, sem quebrá-las.
>> Ontem a noite identifiquei as que quebrei e as corrigi quase todas. O 
>> Bladimir (“meu gurú”) já tinha corrigido a de São Paulo e, portanto, os 
>> créditos do trabalho devem ser dirigidos a ele.
>&g

Re: [Talk-br] edições e pesquisa no OSM e talk

[Lists]

Baldemir

Os edicoes voces fiz os ultimos dias foram revertido por um grupo no alemão que 
monitorando e corrigindo limites administrativos

O site que deu link e um ferramento que dar alerta em mudanças dos limites

Entao, maioria do trabalho que vocês fiz com os limites os últimos dias foram 
no lixao porque vocês fiz algum coisas errados.

Olha este site, entender o que eles monitorando, e se não entendo este site, 
não editar mais limites.

Aun Johnsen

> On May 11, 2015, at 15:29, Blademir Andrade de Lima  
> wrote:
> 
> Desculpe Aun Johnsen, não estou lhe entendendo.
> 
> Poderia ser mais claro?
> 
> BladeTC
> 
> From: li...@gimnechiske.org <mailto:li...@gimnechiske.org>
> Date: Mon, 11 May 2015 14:17:01 -0300
> To: talk-br@openstreetmap.org <mailto:talk-br@openstreetmap.org>
> Subject: Re: [Talk-br] edições e pesquisa no OSM e talk
> 
> Eu nao sei exatamente o que alertou os revicoes, mas os chagesets tem 
> referencia desse pagina: 
> http://osm.wno-edv-service.de:82/index.php/10-osm-reports/186-countries-compare-2015-05-11
>  
> <http://osm.wno-edv-service.de:82/index.php/10-osm-reports/186-countries-compare-2015-05-11>
> 
> Favor para esses edições dos limites ate vocês entender o que chegando esse 
> lista para evitar um edit war
> 
> Aun Johnsen
> 
> On May 11, 2015, at 14:05, Blademir Andrade de Lima  <mailto:blademi...@hotmail.com>> wrote:
> 
> Quebrados,  OU fora da sequência. Corrigi alguns em que a sequência dentro da 
> relação estava fora da ordem. 
> O JOSM corrige isso facilmente.
> 
> Abraços, 
> BladeTc
> 
> --- Mensagem Original ---
> 
> De: "Lists" mailto:li...@gimnechiske.org>>
> Enviado: 11 de maio de 2015 11:16
> Para: "OpenStreetMap no Brasil"  <mailto:talk-br@openstreetmap.org>>
> Assunto: Re: [Talk-br] edições e pesquisa no OSM e talk
> 
> Para ai
> 
> Eu comecando ver changesets do tipo “concertando relacoes de limites 
> administrativos quebrados” que parecendo chegar do OSMI ou outros sistemas de 
> QA, tem certeza que o trabalho voces fiz fui certo? Ou vocês quebrou alguma 
> coisa no processo?
> 
> Ainda nao ha tempo verificar o que fui editado nesses changesets
> 
> Aun Johnsen
> 
> On May 11, 2015, at 11:01,  <mailto:thunder...@gpsinfo.com.br>>  <mailto:thunder...@gpsinfo.com.br>> wrote:
> 
> Todos os créditos devem ir para o Bladimir, já que nesse aspecto de relações 
> administrativas ele é seguramente bem mais experiente do que eu.
>  
> Comecei a experimentar essa edição recentemente e nesse aprendizado acabei 
> cometendo alguns erros como particionar (quebrar) o way para retirar o aviso 
> no JOSM de longo caminho.
>  
> Apesar de muitos aqui defenderem o JOSM somente agora entendi o quanto ele é 
> superior ao ID.
>  
> Quando um Way é membro de mais de uma relação boundary, quando o 
> particionamos pelo ID é quebrada alguma relação boundary da qual ele faz 
> parte. Particionado pelo JOSM existe uma validação desse que o particiona 
> também em todas as relações boundarys que ele é membro, sem quebrá-las.
> Ontem a noite identifiquei as que quebrei e as corrigi quase todas. O 
> Bladimir (“meu gurú”) já tinha corrigido a de São Paulo e, portanto, os 
> créditos do trabalho devem ser dirigidos a ele.
>  
> []s
> Marcio
>  
> From: Helio Cesar Tomio <mailto:hcto...@gmail.com>
> Sent: Sunday, May 10, 2015 10:29 PM
> To: talk-br@openstreetmap.org <mailto:talk-br@openstreetmap.org>
> Subject: [Talk-br] edições e pesquisa no OSM e talk
>  
> Parabéns Blademir e Márcio pelo valoroso empenho nas edições do OSM, 
> referente as relações dos limites administrativos.
>  
> Colegas, como posso fazer uma pesquisa no OSM, para gerar um relatorio ou 
> lista das ruas e servidões da cidade de Jaraguá do Sul?
> Gostaria de checar as informações.
>  
> E como posso pesquisar os historico das mensagens da talk-br@openstreetmap 
> (as mensagens mais antigas)?
>  
> Grato,
> hctomio.
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-br 
> <https://lists.openstreetmap.org/listinfo/talk-br>
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-br 
> <https://lists.openstreetmap.org/listinfo/talk-br>
> 
> ___ Talk-br mailing list 
> Talk-br@openstreetmap.org 
> <mailto:Talk-br@openstreetmap.org>https://lists.openstreetmap.org/listinfo/talk-br
>  
> <https://lists.openstreetmap.org/listinfo/talk-br>___
> Talk-br mailing list
> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-br 
> <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] edições e pesquisa no OSM e talk

[Lists]

Eu nao sei exatamente o que alertou os revicoes, mas os chagesets tem 
referencia desse pagina: 
http://osm.wno-edv-service.de:82/index.php/10-osm-reports/186-countries-compare-2015-05-11
 
<http://osm.wno-edv-service.de:82/index.php/10-osm-reports/186-countries-compare-2015-05-11>

Favor para esses edições dos limites ate vocês entender o que chegando esse 
lista para evitar um edit war

Aun Johnsen

> On May 11, 2015, at 14:05, Blademir Andrade de Lima  
> wrote:
> 
> Quebrados,  OU fora da sequência. Corrigi alguns em que a sequência dentro da 
> relação estava fora da ordem. 
> O JOSM corrige isso facilmente.
> 
> Abraços, 
> BladeTc
> 
> --- Mensagem Original ---
> 
> De: "Lists" mailto:li...@gimnechiske.org>>
> Enviado: 11 de maio de 2015 11:16
> Para: "OpenStreetMap no Brasil"  <mailto:talk-br@openstreetmap.org>>
> Assunto: Re: [Talk-br] edições e pesquisa no OSM e talk
> 
> Para ai
> 
> Eu comecando ver changesets do tipo “concertando relacoes de limites 
> administrativos quebrados” que parecendo chegar do OSMI ou outros sistemas de 
> QA, tem certeza que o trabalho voces fiz fui certo? Ou vocês quebrou alguma 
> coisa no processo?
> 
> Ainda nao ha tempo verificar o que fui editado nesses changesets
> 
> Aun Johnsen
> 
>> On May 11, 2015, at 11:01, > <mailto:thunder...@gpsinfo.com.br>> > <mailto:thunder...@gpsinfo.com.br>> wrote:
>> 
>> Todos os créditos devem ir para o Bladimir, já que nesse aspecto de relações 
>> administrativas ele é seguramente bem mais experiente do que eu.
>>  
>> Comecei a experimentar essa edição recentemente e nesse aprendizado acabei 
>> cometendo alguns erros como particionar (quebrar) o way para retirar o aviso 
>> no JOSM de longo caminho.
>>  
>> Apesar de muitos aqui defenderem o JOSM somente agora entendi o quanto ele é 
>> superior ao ID.
>>  
>> Quando um Way é membro de mais de uma relação boundary, quando o 
>> particionamos pelo ID é quebrada alguma relação boundary da qual ele faz 
>> parte. Particionado pelo JOSM existe uma validação desse que o particiona 
>> também em todas as relações boundarys que ele é membro, sem quebrá-las.
>> Ontem a noite identifiquei as que quebrei e as corrigi quase todas. O 
>> Bladimir (“meu gurú”) já tinha corrigido a de São Paulo e, portanto, os 
>> créditos do trabalho devem ser dirigidos a ele.
>>  
>> []s
>> Marcio
>>  
>> From: Helio Cesar Tomio <mailto:hcto...@gmail.com>
>> Sent: Sunday, May 10, 2015 10:29 PM
>> To: talk-br@openstreetmap.org <mailto:talk-br@openstreetmap.org>
>> Subject: [Talk-br] edições e pesquisa no OSM e talk
>>  
>> Parabéns Blademir e Márcio pelo valoroso empenho nas edições do OSM, 
>> referente as relações dos limites administrativos.
>>  
>> Colegas, como posso fazer uma pesquisa no OSM, para gerar um relatorio ou 
>> lista das ruas e servidões da cidade de Jaraguá do Sul?
>> Gostaria de checar as informações.
>>  
>> E como posso pesquisar os historico das mensagens da talk-br@openstreetmap 
>> (as mensagens mais antigas)?
>>  
>> Grato,
>> hctomio.
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/talk-br 
>> <https://lists.openstreetmap.org/listinfo/talk-br>
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-br 
> <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] edições e pesquisa no OSM e talk

[Lists]

Para ai

Eu comecando ver changesets do tipo “concertando relacoes de limites 
administrativos quebrados” que parecendo chegar do OSMI ou outros sistemas de 
QA, tem certeza que o trabalho voces fiz fui certo? Ou vocês quebrou alguma 
coisa no processo?

Ainda nao ha tempo verificar o que fui editado nesses changesets

Aun Johnsen

> On May 11, 2015, at 11:01,  
>  wrote:
> 
> Todos os créditos devem ir para o Bladimir, já que nesse aspecto de relações 
> administrativas ele é seguramente bem mais experiente do que eu.
>  
> Comecei a experimentar essa edição recentemente e nesse aprendizado acabei 
> cometendo alguns erros como particionar (quebrar) o way para retirar o aviso 
> no JOSM de longo caminho.
>  
> Apesar de muitos aqui defenderem o JOSM somente agora entendi o quanto ele é 
> superior ao ID.
>  
> Quando um Way é membro de mais de uma relação boundary, quando o 
> particionamos pelo ID é quebrada alguma relação boundary da qual ele faz 
> parte. Particionado pelo JOSM existe uma validação desse que o particiona 
> também em todas as relações boundarys que ele é membro, sem quebrá-las.
> Ontem a noite identifiquei as que quebrei e as corrigi quase todas. O 
> Bladimir (“meu gurú”) já tinha corrigido a de São Paulo e, portanto, os 
> créditos do trabalho devem ser dirigidos a ele.
>  
> []s
> Marcio
>  
> From: Helio Cesar Tomio 
> Sent: Sunday, May 10, 2015 10:29 PM
> To: talk-br@openstreetmap.org 
> Subject: [Talk-br] edições e pesquisa no OSM e talk
>  
> Parabéns Blademir e Márcio pelo valoroso empenho nas edições do OSM, 
> referente as relações dos limites administrativos.
>  
> Colegas, como posso fazer uma pesquisa no OSM, para gerar um relatorio ou 
> lista das ruas e servidões da cidade de Jaraguá do Sul?
> Gostaria de checar as informações.
>  
> E como posso pesquisar os historico das mensagens da talk-br@openstreetmap 
> (as mensagens mais antigas)?
>  
> Grato,
> hctomio.
> ___
> 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] border_type

[Lists]

Marcio et al

Um bom aviso e evitar criar caminhos muito longe (por exemplo tenta fica com 
menus que 500 nos sempre), onde existe caminhos mais longe, e onde esses dar 
problemas com aplicativos, acho que e isso voce tem Marcio, separa-los em 
caminhos menores, e sempre fica atento em relações onde faz parte.

Aun Johnsen

> On May 9, 2015, at 21:51,  
>  wrote:
> 
> E como corrigir way longo?
>  
> Particionei (quebrei) um trecho de um way e continuou o aviso. Será que teria 
> de particionar mais vezes o way?
>  
> From: Lists <mailto:li...@gimnechiske.org>
> Sent: Saturday, May 9, 2015 9:29 PM
> To: OpenStreetMap no Brasil <mailto:talk-br@openstreetmap.org>
> Subject: Re: [Talk-br] border_type
>  
> Marcio
>  
> O distancia nao pode responder, mas o API aceitar ate 5000 nos, que e demais, 
> existe aplicativos que tem problemas em cima do 1000, acho que JOSM avisar 
> com 500
>  
> Aun Johnsen
>  
>>  
> ___
> 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] border_type

[Lists]

Marcio

O distancia nao pode responder, mas o API aceitar ate 5000 nos, que e demais, 
existe aplicativos que tem problemas em cima do 1000, acho que JOSM avisar com 
500

Aun Johnsen

> On May 9, 2015, at 21:25,  
>  wrote:
> 
> Aun e demais companheiros,
> quero deixar registrado o nosso agradecimento ao Blad que não mediu esforços 
> nesses últimos dias, a nosso pedido, para revisar determinados ways membros 
> de algumas relações retirando dele a tag admin_level quando diferente da 
> contida em alguma relação que era membro.
>  
> Nos juntamos a esse trabalho e nessa madrugada passada revisamos dessa forma 
> os estados que não estavam sendo indexados pelo Mkgmap:
>  
> Amazonas
> Pará
> Goiás
> Mato Grosso
> Mato Grosso do Sul
> Minas Gerais
> São Paulo
> Paraná
>  
> Acabamos de renderizar um novo mapa Cocar com o PBF fornecido pelo Geofrabick 
> ( http://download.geofabrik.de/south-america/brazil.html 
> <http://download.geofabrik.de/south-america/brazil.html>) e na busca todos os 
> estados do Brasil passaram a indexar.
>  
> Em que pese que o Brasil está sendo indexado normalmente e não gerando 
> problema, estou curioso para saber como se limpar os avisos que aparecem na 
> relação: boundary
>  
> A grande maioria deles é a respeito a “very long segment x kilometers”
>  
> Imaginei que seria particionar o longo way membro da relação, mas pelo visto 
> não é.
>  
> Como corrigir esse aviso?  Alguém sabe qual o valor máximo em distância ou 
> nós para um way membro ,ou não, de uma relação?
>  
> []s
> Marcio
>  
>  
> From: Lists <mailto:li...@gimnechiske.org>
> Sent: Saturday, May 9, 2015 7:45 PM
> To: OpenStreetMap no Brasil <mailto:talk-br@openstreetmap.org>
> Subject: Re: [Talk-br] border_type
>  
> Marcio
>  
> Eu nao sei exatamente que deu seus problemas, seria bom se vocês pode 
> compartilhar logs, ou outros dados sobre isso, para a gente pode compartilhar 
> o processo. Eu acho que um processo assim, principalmente com dados tao 
> importante e complicado como limites administrativos, deve ser transparente, 
> ambos para evitar problemas no futuro e para mais contribuidores fazer parte 
> do processo.
>  
> Aun Johnsen
>  
>>  
> ___
> 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] border_type

[Lists]

Marcio

Eu nao sei exatamente que deu seus problemas, seria bom se vocês pode 
compartilhar logs, ou outros dados sobre isso, para a gente pode compartilhar o 
processo. Eu acho que um processo assim, principalmente com dados tao 
importante e complicado como limites administrativos, deve ser transparente, 
ambos para evitar problemas no futuro e para mais contribuidores fazer parte do 
processo.

Aun Johnsen

> On May 9, 2015, at 19:35,  
>  wrote:
> 
> Aun,
> em que pese que o OSM não é voltado para determinada aplicação, sou de 
> opinião que os resultados encontrados na aplicação por vezes estampam 
> necessidade de revisão de certos parâmetros inseridos nos ways do OSM.
>  
> Como produzimos o mapa Cocar, nos testes constantemente identificamos alguma 
> necessidade de aperfeiçoamento da forma que empregamos o Mkgmap, ora 
> inserindo comandos nele, ora alterando, removendo ou inserindo dados nos 
> Styles dele.
>  
> A nível Mkgmap só podemos alterar pedindo help aos desenvolvedores dele como 
> fizemos para remoção do POI de cidade criado dentro da relação boundary, 
> mesmo existindo o admin_centre na relação.
>  
> Como alguns estados do Brasil começaram a não indexar surtiu a necessidade de 
> se revisar os limites desses estados e por coincidência, ou não, não estavam 
> indexando exatamente aqueles que tinham essa situação de admin_level na 
> relação e admin_level diferente em way membro da relação. Logicamente aquele 
> way fazia parte da relação do vizinho também e também por coincidência, ou 
> não, também não indexam o estado.
>  
> []s
> Marcio
>  
> From: Lists <mailto:li...@gimnechiske.org>
> Sent: Saturday, May 9, 2015 7:08 PM
> To: OpenStreetMap no Brasil <mailto:talk-br@openstreetmap.org>
> Subject: Re: [Talk-br] border_type
>  
> Marcio
>  
> Eu utilizei border_type nos limites administratives no Espírito Santo, porque 
> houve 2 tipos de limites batendo no admin_level=9, os distritos e 
> subdistritos, no maioria dos casos não deu problema, município uso ou 
> distrito ou subdistrito, so encontrou problema no Vitória, que uso ambos.
>  
> Quando tudos municipios do territorio e mapeado com tudos divisões dentro os 
> municípios podemos revisar os divisões para analizar o que e necessário, que 
> e bom ter, e que e informação duplicado. Eu acho não e tempo fazer este antes 
> que território Brasileiro e completamente mapeado.
>  
> Aun Johnsen
>  
>>  
> ___
> 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] border_type

[Lists]

Marcio

Eu utilizei border_type nos limites administratives no Espírito Santo, porque 
houve 2 tipos de limites batendo no admin_level=9, os distritos e subdistritos, 
no maioria dos casos não deu problema, município uso ou distrito ou 
subdistrito, so encontrou problema no Vitória, que uso ambos.

Quando tudos municipios do territorio e mapeado com tudos divisões dentro os 
municípios podemos revisar os divisões para analizar o que e necessário, que e 
bom ter, e que e informação duplicado. Eu acho não e tempo fazer este antes que 
território Brasileiro e completamente mapeado.

Aun Johnsen

> On May 9, 2015, at 19:00,  
>  wrote:
> 
> Obrigado Aun,
> concordo com voce que essa tag border_type não impacta no mkgmap e, pelo que 
> sei e ando experimentando no Mkgmap, ele não tem configurações em seus styles 
> para reconhecer essa tag.
>  
> A minha pergunta se deu fins padronização já que me juntei ao grupo que está 
> revisando os boundarys no Brasil .
>  
> Seria interessante a padronização do emprego dessa tag (ou não) para que 
> uniformizássemos todos os ways sem tag específica e membros de relações 
> boundarys.
>  
> []s
> Marcio
>  
> From: Lists <mailto:li...@gimnechiske.org>
> Sent: Saturday, May 9, 2015 4:45 PM
> To: OpenStreetMap no Brasil <mailto:talk-br@openstreetmap.org>
> Subject: Re: [Talk-br] border_type
>  
> Marcio
>  
> border_type e usado onde e necessario denominar limites especificos e onde 
> não ha outros tags boas para fazer este denominação. Tem somente alguns 
> exemplos raros no boundary=administrativo, e em maioria dos casos pode ser 
> ignorado do consumidores (por exemplo acho não dar impacto no renderia do 
> mkgmap
>  
> Tem exemplos onde border_type tem informação importante, por exemplo nos 
> border=maritime, veja no wiki como usar.
>  
> Aun Johnsen
> ___
> 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] border_type

[Lists]

Marcio

border_type e usado onde e necessario denominar limites especificos e onde não 
ha outros tags boas para fazer este denominação. Tem somente alguns exemplos 
raros no boundary=administrativo, e em maioria dos casos pode ser ignorado do 
consumidores (por exemplo acho não dar impacto no renderia do mkgmap

Tem exemplos onde border_type tem informação importante, por exemplo nos 
border=maritime, veja no wiki como usar.

Aun Johnsen

> On May 9, 2015, at 16:38,  
>  wrote:
> 
> Amigos,
> como a maioria sabe os níveis administrativos (admin_level) vem agora sendo 
> incluídos nas relações já que um way, por vezes, é membro de inúmeras 
> relações com admin_level distintos.
>  
> Como nosso amigo Blad já postou aqui nesta lista a situação e se comprometeu 
> a revisar algumas regiões, decidi fazer parte desse trabalho em conjunto com 
> ele e os demais que vem fazendo.
>  
> A minha primeira dúvida é quanto a tag boundary=administrative inserida no 
> way.
>  
> Entendo eu que esse way, sendo membro da relação boundary=administrativo, não 
> necessita ter essa tag nele.
>  
> Revisando os limites administrativos no Brasil me deparei com uma situação 
> única, não empregada de forma geral.
>  
> É o way http://www.openstreetmap.org/way/28733364 
>  , limite marítimo de estado e que 
> recebeu a tag border_type=state
>  
> Havia eu removido essa tag, mas decidi restaurar e aqui perguntar
>  
> Observei que essa tag border_type=state esta inclusa em alguns ways membros 
> de ralações boundary=administrative de estados (level=4), entretanto, não 
> está esse way é também membro de relações boundary de outros admin=level.
>  
> Entendo que não foi incluída porque ali é múltiplo border, já que pode ser 
> border de país ou região, no caso do Brasil, mas não deixa de ser border
>  
> Existe tag border+type=multi? ou algo parecido.
>  
> []s
> Marcio
>  
>  
> ___
> 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] Mapeando ciclofaixa

[Lists]

Também existe um sintax com lanes=, principalmente util se ciclofaixa tem 
restrições, por exemplo um faixa que e exclusivamente cixlofaica nos domingos, 
mas compartilhado com carros no semana, ou se ônibus pode invadir o ciclofaixa 
no horas especificas.

Aun Johnsen

> On May 8, 2015, at 12:24, Nelson A. de Oliveira  wrote:
> 
> 2015-05-08 12:02 GMT-03:00  :
>> Se a ciclovia não ocupa faixa destinada a veículos, tenho visto e sou
>> favorável a se desenhar um way só para ela, margeando o way da via e
>> interligando as duas pontas na via de forma a se manter o roteamento de
>> bicicleta.
> 
> Apesar de alguns defenderem e desenharem desse jeito, se não há
> separação física entre a rua do carro e a faixa de bicicleta, então
> está errado fazer dessa forma.
> 
> bicycle=yes (ou bicicleta=yes no iD) só vai dizer que a via possui
> permissão de uso por bicicletas. Isso não representa se existe
> ciclovia, ciclofaixa ou qualquer outra característica específica. É
> apenas uma rua que as bicicletas podem usar.
> 
> Mapear ciclofaixa em uma rua é colocar a informação na própria rua (no
> caso adicionar cycleway
> http://wiki.openstreetmap.org/wiki/Key:cycleway).
> A página que o wille passou possui bastante exemplo sobre isso.
> 
> ___
> 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] TAGs admin_center ou capital ?

[Lists]

 deixo 
> registrado a simpatia com que eles nos receberam naquela lista e rapidamente 
> apresentaram na versão r3564 do Mkgmap um filtro que remove o ponto virtual 
> criado no centro da relação quando da existência do ponto admin_centre nessa 
> relação.
>  
> Até aí conseguimos resolver 70% do problema, entretanto nos deparamos com 
> muitos municípios sem o admin_centre na relação. estamos inserindo isso, mas 
> confessamos que é um grande trabalho se feito manualmente, sem alguma 
> automatização que facilite o trabalho.
>  
> Nos simpatizamos com o Overpass e identificamos que indiretamente ele faz o 
> mesmo processo que o renderizador Mkgmap quando no inicio de seu trabalho. O 
> Mkgmap nos apresenta um arquivo que aponta todos os boundarys e os 
> admin_centre dos que tem e dentro deles.
>  
> O grande problema não é só o admin_centre, o grande problema é que alguns 
> inexperientes alteram relações sem saberem ao certo o que estão fazendo. 
> Agora mesmo estamos tendo problema com a indexação do estado de São Paulo. 
> Observamos que a relação boundary de São Paulo (admin_level 4) foi alterada 
> recentemente e pelos menos nós não identificamos falha nessa alteração.
>  
> De tudo isso amigos, solicitamos um pouco de paciência conosco e relevem, por 
> vezes, a forma com que nos dirigimos a alguns. Estamos no mesmo barco e vamos 
> remar juntos para conduzir essa nave ao seu porto.
>  
> []s
> Marcio  
>  
> From: Lists <mailto:li...@gimnechiske.org>
> Sent: Thursday, May 7, 2015 1:41 PM
> To: OpenStreetMap no Brasil <mailto:talk-br@openstreetmap.org>
> Subject: Re: [Talk-br] TAGs admin_center ou capital ?
>  
> O problema com relações incompleta (falta admin_centre) pode acontecer no 
> pais inteiro, acho devemos montar um pesquisa overpass do relações sem 
> admin_centre, algum quer fazer? 
>  
> Eu mesmo ira fazer so que meu internet e lento demais hoje
>  
> Aun Johnsen
>  
>>  
> 
> ___ Talk-br mailing list 
> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org> 
> https://lists.openstreetmap.org/listinfo/talk-br 
> <https://lists.openstreetmap.org/listinfo/talk-br>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-br 
> <https://lists.openstreetmap.org/listinfo/talk-br>
> 
> ___ Talk-br mailing list 
> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org> 
> https://lists.openstreetmap.org/listinfo/talk-br 
> <https://lists.openstreetmap.org/listinfo/talk-br>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-br 
> <https://lists.openstreetmap.org/listinfo/talk-br>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-br 
> <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] TAGs admin_center ou capital ?

[Lists]

O problema com relações incompleta (falta admin_centre) pode acontecer no pais 
inteiro, acho devemos montar um pesquisa overpass do relações sem admin_centre, 
algum quer fazer?

Eu mesmo ira fazer so que meu internet e lento demais hoje

Aun Johnsen

> On May 7, 2015, at 13:35, Adriano Rosa  wrote:
> 
> vcs sabem dizer se esse "problema" também acontece em SC?
> 
> sou novato ainda no osm, estou tentando acompanhar os assuntos, mas alguns eu 
> fico boiando, como esse...
> 
> caso positivo, eu posso revisar/corrigir, mas vou precisar de orientação 
> sobre o melhor método de fazer.
> 
> Em qui, 7 de mai de 2015 às 13:27, Blademir Andrade de Lima 
> mailto:blademi...@hotmail.com>> escreveu:
> Muito bom esse overpass.
> Não entendo nada de códigos, xml etc, mas deu pra entender o que significam.
> Vai me ajudar muito a concluir um outro projeto de Micro e Mesorregiões.
> Att,
> BladeTC
> 
> From: alexandre@gmail.com 
> Date: Thu, 7 May 2015 03:29:03 -0300
> To: tarci...@ymail.com ; talk-br@openstreetmap.org 
> 
> 
> Subject: Re: [Talk-br] TAGs admin_center ou capital ?
> 
> Minha sugestão continua sendo compartilhar esse tipo de código por GitHub, 
> seja como projeto ou Gist.
> 
> Alexandre
> 
> Em 6 de maio de 2015 22:46, Tarcisio Oliveira  > escreveu:
> 
> Eu tava fazendo esse trabalho no país todo, parei por causa do trabalho, mas 
> era de forma automatizada e com minha supervisão relação a relação para 
> depois enviar para o osm, o problema é que consegui perder o código que fiz 
> para realizar essa tarefa, uma pena, pois dava pra fazer o estado todo em 
> alguns minutos, contando como tempo de supervisão do que foi feito.
> 
> Essa consulta pode te ajudar a fazer esse trabalho ai 
> http://overpass-turbo.eu/s/9di 
> 
> ___ Talk-br mailing list 
> Talk-br@openstreetmap.org  
> https://lists.openstreetmap.org/listinfo/talk-br 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-br 
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br

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

Re: [Talk-br] TAGs admin_center ou capital ?

[Lists]

Marcio

Como o node e ligado diretamente com o relação com o papel admin_centre, não 
mais tem necessidade de usar admin_level ou capital no node.

O que e certo e usar admin_center, e talvez também label no relação, so isso. o 
tag admin_level não faz sentido no o node, e capital e evidente por o papel 
admin_centre

Preciso ter bastante cuidado incluir o tag place nos relações de limites 
administrativos, algum deles pode ser certo combinar com place (por exemplo no 
estado) e outros não


Aun Johnsen

> On May 6, 2015, at 19:14,  
>  wrote:
> 
> Aun,
> mas qual usar?
>  
> Pergunto porque não cheguei a conclusão alguma do padrão que estamos 
> empregando no Brasil. Alguns inserem na relação boundary o admin_center, 
> outros excluem da relação e em alguns lugares nunca inseriram capital e 
> tampouco admin_centre na relação.
>  
> Aproveito para parabeniza-lo porque identifico que você formatou todos os 
> municípios do espírito santo com admin_centre nas relações boundarys, 
> entretanto ao norte, na Bahia, a maioria dos municípios tem a relação 
> boundary, mas sem o admin_centre.
>  
> A nível renderizador nos é fornecido um arquivo resultado de um 
> pré-processamento dos dados OSM extraindo dele as relações boundary com os 
> admin_center delas. Observe um corte do print dessa imagem aberta:
>  
> 
>  
> Essa imagem pega a área Norte do Espírito Santo e a Sul da Bahia.
>  
> A cor verde escura nos boudarys significa que aquele boundary não tem a TAG 
> place. A verde clara significa que tem.
>  
> As cidades que estão como admin_centre da relação boundary são estampadas na 
> cor referente ao tipo de place dela.
>  
> Tirem suas conclusões.
>  
> []s
> Marcio
>  
>  
>  
>  
> From: Lists <mailto:li...@gimnechiske.org>
> Sent: Wednesday, May 6, 2015 6:43 PM
> To: OpenStreetMap no Brasil <mailto:talk-br@openstreetmap.org>
> Subject: Re: [Talk-br] TAGs admin_center ou capital ?
>  
> Marcio
>  
> O tag capital tambem e mais antigua que relações, acho esses duas assuntos 
> pode ser levantados no tagging, mas provavelmente eles vai dizer para não 
> usar.
>  
> Aun Johnsen
>  
>>  
> ___
> 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] TAGs admin_center ou capital ?

[Lists]

Marcio

O tag capital tambem e mais antigua que relações, acho esses duas assuntos pode 
ser levantados no tagging, mas provavelmente eles vai dizer para não usar.

Aun Johnsen

> On May 6, 2015, at 18:36,  
>  wrote:
> 
> Amigos,
> qual a orientação no Brasil para configuração da cidade onde se encontra o 
> governo de um estado ou município?
>  
> Identificamos que alguns empregam a TAG capital no ponto e outros a TAG 
> admin_centre na relação.
>  
> Pelo wiki só identificamos ambos a nível proposta.
>  
> []s
> Marcio
> ___
> 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] Erros no ID

[Lists]

Isso tinha no JOSM ha muito tempo, e chama resolução do conflitos. No JOSM ate 
dar para fazer comparação do objeto local (seu) e no servidor para analizar o 
que e melhor, e salvar objeto local/remote para terminar o conflito. Acho bom 
que iD começando ser ciente isso, mas tem duvida que ele vai tratar eles bem.

Aun Johnsen

> On May 6, 2015, at 18:33, belnu...@pop.com.br wrote:
> 
> 
> 
> O ID a pelo menos 3 dias está apresentando falhas intermitentes na hora de 
> salvar . Algumas ele não salva , outras ele diz que há uma outra modificação 
> feita pelo proprio usuário no mesmo instante e pergunta o que deva ser feito .
> ___
> 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] Brasília - DF

[Lists]

Tava um discussão muito tempo atras sobre uso do admin_level no node do place, 
para identificar do o que o no e admin_center, isso fui antes do implantação do 
relações, e não mais necessário.

Aun Johnsen

> On May 6, 2015, at 18:10,  
>  wrote:
> 
> Agradeço Nelson.
> Vou retirar o admin_level=2 de lá e aguardar até amanhã para renderizar novo 
> mapa Cocar e ver se o problema da duplicação não ocorre de novo.
> 
> []s
> Marcio
> 
> -Mensagem Original- From: Nelson A. de Oliveira
> Sent: Wednesday, May 6, 2015 6:03 PM
> To: OpenStreetMap no Brasil
> Subject: Re: [Talk-br] Brasília - DF
> 
> 2015-05-06 17:54 GMT-03:00  :
>> É correto se empregar admin_level para ponto? admin_level não só é empregado
>> para relation=boundary? Ou estou completamente equivocado?
> 
> Errado não é, mas também não está 100% certo.
> Pode retirar o admin_level do nó de Brasília.
> 
> Já é a segunda vez que algum estrangeiro mexe nisso, de forma errada,
> e sem perguntar.
> 
> 
> ___
> 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] Uso Correto da Place

[Lists]

Tem algum areas com relações duplicados

Por enquanto nao ha ferramentas que pode ajudar limpar isso, e preciso ser 
concertado por mao.

Aun Johnsen

> On May 3, 2015, at 11:14, A. Carlos  wrote:
> 
> 
> Blade,
> 
> Pelo que vi, acho que fizeram um trabalho automatizado, porque praticamente a 
> região Norte toda esta "duplicada"..
> 
> Fazer/consertar isso ali " na  mão", é trabalho de formiguinha...
> 
>   
>  
>  
>  
>  
>  
>  
> 
> ___
> 
> Anor C. A. de Souza   
>Concórdia SC 
>   
> 49-8866-3290 Claro
> 49-8808-4963 Vivo
> 49-9975-2560 Tim
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> 
> 
> Date: Sun, 3 May 2015 11:05:17 -0300
> From: blademi...@hotmail.com 
> To: talk-br@openstreetmap.org 
> Subject: Re: [Talk-br] Uso Correto da Place
> 
> O OSM funciona destas duas formas,  a 'place'  e o limite administrativo 
> (boundary) como  'relation'. 
> Não se deve excluir a tag place,  e ela deve estar vinculada dentro da 
> relação como 'admin_centre',  senao o resultado sai duplicado. 
> Existem bastante exemplos,  pesquise algumas cidades do sudeste ou sul para 
> ver como funciona. 
> 
> Agora,  se a TAG 'place'  estiver duplicada,  exclua uma delas,  de 
> preferência a que nao tiver a fonte e nao estiver vinculada a relação 
> municipal. 
> 
> Att, 
> BladeTC
> 
> --- Mensagem Original ---
> 
> De: "A. Carlos" mailto:anorcar...@hotmail.com>>
> Enviado: 3 de maio de 2015 10:49
> Para: "Talk-br@openstreetmap.org " 
> mailto:talk-br@openstreetmap.org>>
> Assunto: [Talk-br] Uso Correto da Place
> 
> Pessoal, uma dúvida aqui, espero que os expertes  possam me ajudar e 
> esclarecer
> 
> Qual o uso correto e onde o usar o Place?
> 
> Explico...
> 
> Ao compilar o mapa BR, na pesquisa de cidades, tanto no GPS quanto no 
> Mapsource, centenas 
> de cidades estão parecendo na lista com nomes duplicados...
> 
> Analisando no OSM, vi que tem de centenas pra mais cidades que estão com a 
> tag Place duplicada (princiapalmente 
> Região Norte)
> 
> Estão incluíndo a tag, no (ponto) e pelo que vi (JOSM) estão incluindo ela na 
> Relação do Limite Administrativo.
> 
> Pergunto:
> 
> O que é certo? Porque ali do jeito que está fica impraticável o usuário usar 
> e fazer a pesquisa, com 2 e tem casos de até 3
> nomes na pesquisa.
> 
> Se a didática ali está correta,que extrai mapas agora precisa descobrir então 
> uma dica de como excluir via Mkgmapp esta
> segunda opção para fazer um mapa "limpo" 
> 
> Estou aceitando sugestões :) 
> 
> 
> 
> 
> 
> 
> 
> 
>   
>  
>  
>  
>  
>  
>  
> 
> ___
> 
> Anor C. A. de Souza   
>Concórdia SC 
>   
>
>  
>  
>  
>  
>  
>  
>  
> 
> ___ Talk-br mailing list 
> Talk-br@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-br
>  
> ___ Talk-br mailing list 
> Talk-br@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-br
>  
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-br 
> 
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Uso Correto da Place

[Lists]

Carlos

O resposta pode ser um pouco complicado, mas em principo a resposta e “ambos”

O nome deve ser no limite administrativo e no um no central. Porque? Porque 
algum consumidores de dados usando um e outros usando outro. Bem, tem 
consumidores que entendo e usando ambos também.

Se o problemo e que mapa compilado com mkgmap duplicando os nomes, talvez olhar 
os regras ou os stylesheets utilizados para ver se pode fazer algum coisas para 
resolver este?

Aun Johnsen

> On May 3, 2015, at 10:48, A. Carlos  wrote:
> 
> Pessoal, uma dúvida aqui, espero que os expertes  possam me ajudar e 
> esclarecer
> 
> Qual o uso correto e onde o usar o Place?
> 
> Explico...
> 
> Ao compilar o mapa BR, na pesquisa de cidades, tanto no GPS quanto no 
> Mapsource, centenas 
> de cidades estão parecendo na lista com nomes duplicados...
> 
> Analisando no OSM, vi que tem de centenas pra mais cidades que estão com a 
> tag Place duplicada (princiapalmente 
> Região Norte)
> 
> Estão incluíndo a tag, no (ponto) e pelo que vi (JOSM) estão incluindo ela na 
> Relação do Limite Administrativo.
> 
> Pergunto:
> 
> O que é certo? Porque ali do jeito que está fica impraticável o usuário usar 
> e fazer a pesquisa, com 2 e tem casos de até 3
> nomes na pesquisa.
> 
> Se a didática ali está correta,que extrai mapas agora precisa descobrir então 
> uma dica de como excluir via Mkgmapp esta
> segunda opção para fazer um mapa "limpo" 
> 
> Estou aceitando sugestões :) 
> 
> 
> 
> 
> 
> 
> 
> 
>   
>  
>  
>  
>  
>  
>  
> 
> ___
> 
> Anor C. A. de Souza   
>Concórdia SC 
>   
>
>  
>  
>  
>  
>  
>  
>  
> ___
> 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] Usuário Lucas Silvestre

[Lists]

O plugin revert, ou se e pouco objetos, undelete (funciona bem)

Aun Johnsen

> On Apr 12, 2015, at 21:03, Blademir Andrade de Lima  
> wrote:
> 
> Mandei Mensagem pelo OSM, ainda não tive retorno.
> 
> Este usuário excluiu dois bairros em minha cidade, e fez outras alterações, 
> mas suas changesets não possuem nenhum comentário ou justificativa.
> 
> O local é este http://www.openstreetmap.org/#map=17/-21.71070/-45.25166 
>  , de nome alto da 
> colina.
> 
> Não compreendi o motivo da exclusão, ja que usei fontes legítimas na época.
> 
> Att,
> BladeTC
> 
> Date: Sun, 12 Apr 2015 18:45:29 -0300
> From: tarci...@ymail.com
> To: talk-br@openstreetmap.org
> Subject: Re: [Talk-br] Usuário Lucas Silvestre
> 
> Não encontrei nenhum email dele aqui 
>  que possa parecer ser dele.
> 
> 
> On 12-04-2015 12:59, Blademir Andrade de Lima wrote:
> O Usuário Lucas Silvestre 
> https://www.openstreetmap.org/user/Lucas%20Silvestre 
>  é assinante da Lista 
> Talk-BR?
> 
> Att,
> BladeTC
> 
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-br 
> 
> 
> 
> ___ Talk-br mailing list 
> Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-br 
> 
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Perda de dados em Itabira e MG-434

[Lists]

So para voces intender, entre os dados seria reportado para o DWG e um redact 
passa muito tempo investigando os changesets em duvida. Cada um changeset 
verificada manualmente. Por isso pode demorar meses entre dados e reportado e o 
redact. Se tem mais gente que pode ajudar com analizar e investigar isso pode 
passa mais rápido. No momento Naoliv e Gerald Weber fazendo maioria desses 
investigações. - E um trabalho grande que eles fazendo, eu deveria ajuda mais, 
mas falta acesso ao dados TS para fazer comparação.

Aun Johnsen

> On Mar 1, 2015, at 18:21,  
>  wrote:
> 
> Que me recorde não aproveitei na ocasião dado que veio do Tracksource até 
> porque o indivíduo que importou não se preocupou em unir os nós e as vias por 
> ele inseridas estavam soltas, sem entroncamentos.
> 
> Acredito que alguém deve ter reportado a época a situação ao DWG e só agora 
> ele processou o reporte sem verificar que a cidade havia sido reeditada.
> 
> -Mensagem Original- From: Nelson A. de Oliveira
> Sent: Sunday, March 1, 2015 6:16 PM
> To: OpenStreetMap no Brasil
> Subject: Re: [Talk-br] Perda de dados em Itabira e MG-434
> 
> 2015-03-01 18:07 GMT-03:00  :
>> A cidade de Itabira - MG foi toda por mim redesenhada no ano passado, tendo
>> na ocasião excluído dados importados do Tracksource por outro.
> 
> Se você reaproveitou algum dado que veio do TS então também foi excluído.
> Caso alguém queira conferir, os changesets que tiveram redact:
> 
> 
> 20228047
> 20250730
> 20251873
> 20807281
> 20972925
> 20974632
> 21030344
> 21030592
> 21062554
> 21067651
> 21068496
> 21458662
> 21458768
> 21458890
> 21461025
> 22212638
> 22232758
> 22233069
> 22233203
> 22233855
> 22247970
> 22248060
> 
> E os que foram revertidos:
> 
> 20973062
> 20974012
> 20975246
> 21030469
> 21458719
> 21458898
> 21458969
> 21461107
> 22233967
> 22234020
> 22234063
> 22234392
> 22234529
> 22234853
> 22234940
> 22234965
> 22236064
> 22236194
> 22248699
> 22248849
> 22249031
> 22249146
> 22249477
> 22258398
> 22259598
> 22295643
> 22295867
> 22295919
> 22295926
> 22332067
> 22332683
> 22332713
> 22332904
> 22334168
> 22914844
> 23011120
> 23127944
> 23128272
> 23128411
> 23129003
> 
> ___
> 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] Quando usar shelter e covered

[Lists]

Nelson

De acordo com 
http://wiki.openstreetmap.org/wiki/Key:public_transport#Platform_2 
 tem os 
duas formas, “covered=yes” e “shelter=yes”

Aun Johnsen

> On Feb 26, 2015, at 13:06, Nelson A. de Oliveira  wrote:
> 
> 2015-02-26 10:43 GMT-03:00 Vitor George :
>> Aqui no Brasil nunca vi, só pontos cobertos mesmo. Acho melhor usar
>> "covered=yes".
> 
> Mas essas coberturas dos pontos é shelter.
> Tanto é que existe diferenciação de shelter no OSM:
> http://wiki.openstreetmap.org/wiki/Key:shelter_type
> Olha o "public_transport"
> 
> ___
> 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 nome de rua

[Lists]

Mapillary e um bom ferramenta para documentar este, corre as ruas gravando com 
mapillary, e se voce em pe ou bicicleta, basta fazer um giro no cada esquino 
para pega as placas identificando as ruas

Aun Johnsen

> On Feb 23, 2015, at 23:05, Arlindo Pereira  
> wrote:
> 
> As vezes acontece, por exemplo "Santana" e "Santanna", "Moraes" e "Morais", 
> etc.
> 
> Em 23/02/2015 19:19, "Thiago Jung Bauermann"  > escreveu:
> Olá Arlindo,
> 
> Tem casos de mais de uma grafia em placas na mesma rua? Vou procurar
> percorrer as ruas então, pra garantir.
> 
> --
> []'s
> Thiago Jung Bauermann
> 
> 
> Arlindo Pereira wrote:
> 
> > Nesses casos, se possível, seria interessante percorrer a rua toda e
> > verificar se não há outras placas com outras grafias, se houver pode ser
> > interessante incluir o outro nome na tag alt_name para aparecer nas
> > buscas. Em 19/02/2015 20:54, "Thiago Jung Bauermann"
> > mailto:thiago.bauerm...@gmail.com>> escreveu:
> >
> >> Aun, John,
> >>
> >> John Packer wrote:
> >> > por acaso você está usando o editor JOSM ?
> >> > Se sim, tem uma extensão muito boa para isto:
> >> > http://wiki.openstreetmap.org/wiki/JOSM/Plugins/FixAddresses 
> >> > 
> >>
> >> Obrigado por responder tão rapidamente. Estou usando o JOSM sim, vou
> >> experimentar esse plugin.
> >>
> >> --
> >> []'s
> >> Thiago Jung Bauermann
> >>
> >>
> >> ___
> >> Talk-br mailing list
> >> Talk-br@openstreetmap.org 
> >> https://lists.openstreetmap.org/listinfo/talk-br 
> >> 
> >>
> 
> 
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-br 
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br

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

Re: [Talk-br] Aplicativos navegação

[Lists]

Também uso mapas OSM no meu Garmin, mas não uso Cocardl por falta do arquivos 
.GMAP para instalação no Mac OS X com os ferramentas Garmin (eu sei que posso 
instalar no meu GPS manualmente, mas uso mesmo mapas para Garmin BaseCamp, que 
não aceito arquivos .IMG sem compilar ao .GMAP), baixando do 
http://garmin.openstreetmap.nl  que 
atualizando mais ou menus semanal. Roteamento nestes mapas do 
garmin.openstreetmap.nl  dar velocidades que e 
ilegal no Brasil, um indicativo que nosso mapa ainda falta muitos trechos com 
velocidade mapeado (maxspeed).

Aun Johnsen

> On Feb 21, 2015, at 10:00, Helio Cesar Tomio  > wrote:
> 
> Eu uso para navegação,  o Garmin com os mapas da Cocardl (que tem compilações 
> diárias ). Pode instalar o Viago no smartphone e modificar para rodar offline 
> com os mapas na memória. 
> Outro muito bom e roda em Qq sistema é o 7ways usando as personalizações do 
> fidelis.assis, no fórum da GpsPoint. 
> Ele compila mapas mensalmente.
> O 7ways tb grava rotas e pois em gpx, alertas de radares Maparadar...
> Pode ser usado no computador, simular rotas previamente ou mesmo conectar com 
> o gps do smartphone pelo bluetooth. 
> Já acho o 7ways superior ao garmin.
> 
> ___
> 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] Aplicativo recomendado

[Lists]

No iOS uso OpenMaps para visualização, e Go Map!! para edições rápidas. Ainda 
não achei um aplicativa de roteamento que vou recomendar, porque uso o telefone 
bastante no viagem, e quando não uso por email ou ligações, tirando fotos com 
Mapillary (que e outro aplicativo que recomendo)

Aun Johnsen

> On Feb 20, 2015, at 19:10, Márcio Aguiar Ribeiro  
> wrote:
> 
> Pessoal,
> 
> qual o aplicativo recomendado para iOS e Android.
> 
> Dei as boas vindas à um usuário da minha região e ele só reclamou que as ruas 
> que ele estava colocando não estava atualizando no aplicativo. Ele falou que 
> usa um tal de navigator. Qual a recomendação pra ele?
> 
> 
> Marcio Aguiar Ribeiro
> ___
> 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] Incluindo Hot Spots Wi-fi

[Lists]

Acho bom, pode incluir um note também

note=Public Hotspot


Aun Johnsen

> On Feb 19, 2015, at 15:21, Marcelo Pereira  wrote:
> 
> Srs,
> 
>A prefeitura do Recife liberou via seu portal de dados abertos uma lista 
> dos Hot Spots do Conecta Recife ( 
> http://portalconecta.recife.pe.gov.br/index.php 
>  ).
> 
> Me interessei em incluí-los no mapa do OSM já que são poucos, cerca de 70, e 
> estou tentando achar um conjunto de tags apropriado.
> 
> Até agora achei os seguintes :
> 
> internet_access:fee=no
> internet_access:operator=Conecta Recife
> internet_access:ssid=CONECTARECIFE
> internet_access=wlan
> source = Dados Abertos Prefeitura do Recife - http://goo.gl/aAluVE 
> 
> source:date=2015/02/13
> 
> Além desses, existe uma informação de que cada acesso feito por essa rede 
> será mediante cadastro no site e limitado a 1 hora de cada vez, renovável via 
> login.
> 
> Como tagear essas informações adicionais?
> 
> Além disso, esses pontos não estão associados a nenhuma amenity, por isso não 
> serão renderizadas, entendi certo ?
> 
> Agradeço a paciência.
> 
> Att,
> 
> Marcelo Pereira
> 
>  
> 
> 
> -- 
> 
> São Pedro recebe Seu Lunga no céu perguntando: 
>  "Morreu, Seu Lunga? "
> "Não, vim passar o Natal!"
> 
> ___
> 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 nome de rua

[Lists]

Tem sim, depende um pouco do como voce trabalhando, voce pode fazer um busca 
dentro o editor, ou pelo ferramentas externas como Overpass. O resposta certa 
depende disso.

Aun Johnsen

> On Feb 19, 2015, at 12:01, Thiago Jung Bauermann  
> wrote:
> 
> Olá novamente,
> 
> Encontrei dois casos em que o nome da rua no OSM está diferente do nome nas 
> placas na própria rua (erros pequenos, 'e' em vez de 'i' em um caso e um 'h' 
> a mais no outro). Gostaria de corrigir, mas fico na dúvida se tem algum node 
> ou area referenciando esse nome com addr:street para corrigir junto. Tem 
> algum jeito de verificar isso?
> 
> -- 
> []'s
> Thiago Jung Bauermann
> 
> 
> ___
> 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] roteamento na páginas principal do OSM

[Lists]

Gerald

Investigei um pouco

Primeiro precisamos um servidor que pode hospedar nosso OSRM, como o OSRM não 
aceita atualizações de crescimento precisamos um outro fonte do dados do OSM, 
por exemplo baixar Brasil como PBF do servidor do geofrabrik.de, e rodar o 
script de importação. Depende de tamanho do banco dados, mas acho que podemos 
rodar isso semanalmente.

Segundo precisamos criar perfis de roteamento, olhei um pouco no github como 
eles fiz no OSRM, cada perfil e um arquivo em formata LUA, que indicando os 
tipos de restrições, que tipo prioridade, e penalidade por vários obstáculos. 
Olhei o perfil car.lua “car (fastest)” e bicycle.lua “bicycle”. Ambos dar 
penalidade por coisas diferente, tem obstaculos que deixar passar e que 
bloquear, etc.

Com um pouco entendimento do LUA podemos criar perfis certos para nosso OSRM, 
como velocidade maxima no diferente classificações das ruas, suprefise, 
penalidade por semáforos, pare, dê preferencia, curvas fechadas e muito mais. 
Podemos sim tambem criar roteamento que evitar estradas da terra ou pedágio.

Viu que pelo github, o OSRM não faz roteamento da balsas com carro, mas faz 
para bicicleta.

Aun Johnsen

> On Feb 18, 2015, at 18:23, Gerald Weber  wrote:
> 
> Conversei la no IRC, e vi que ja tem algum países oferecendo OSRM com somente 
> dados nacionais, acho um OSRM do somente Brasil vai ser mais rápido 
> atualizar, e se ha um servidor próprio podemos ter nosso roteamento nacional.
> 
> 
> Um OSRM-BR seria algo fantástico. Atualmente o OSRM só tem um perfil "car 
> (fastest)", seria legal se tivessesmos várias opções como por exemplo para 
> evitar (ou preferir) estradas de terra.
> 
> Qual seria o caminho para se fazer isto?
> 
> A instalação do software não me pareceu complicada e editar os perfís também 
> parece bem simples. 
> 
> abraço
> 
> Gerald
> ___
> 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] junction=roundabout: uso obrigatório da tag area=no

[Lists]

O unica coisa acho estranho com essa rotativo e o renderição no iD. Acho melhor 
ai e abre um ticket no https://github.com/openstreetmap/iD/issues 

Aun Johnsen

> On Feb 18, 2015, at 15:43, Ivaldo Nunes de Magalhães  
> wrote:
> 
> Até então sim, mas recentemente tenho observado no modo edição a necessidade 
> disso... veja a imagem de uma rotatória, que coloquei no help (link abaixo). 
> Sem a tag area=no ela permanece com esse visual de área. Isso no id. Não 
> testei no P2 e não utilizo o josm.
> 
> https://help.openstreetmap.org/questions/41099/junctionroundabout-uso-obrigatorio-da-tag-areano
>  
> 
> 
> Mais um teste abaixo (id editor, modo edição), quando adiciono 
> junction=roundabout:
> http://www.openstreetmap.org/edit?editor=id&relation=334022#map=19/-20.43992/-54.62610
>  
> 
> 
> 
> 
> Ivaldo Nunes de Magalhães
> E-mail: ivald...@gmail.com 
> Blog: makermaps.blogspot.com.br 
> (67) 8108-7415 - 3431-2810
> (61) 9139-7560
> ___
> 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] junction=roundabout: uso obrigatório da tag area=no

[Lists]

Ivaldo

Outro vez parecendo que iD fazendo coisas estranho ou errado. O tag area=no não 
e necessário para rotatórias com junction=roundabout, nem no renderização nem 
no roteamento.

Aun Johnsen

> On Feb 18, 2015, at 15:18, Ivaldo Nunes de Magalhães  
> wrote:
> 
> Coloquei a dúvida abaixo no help do osm mas as vezes as respostas são lentas. 
> Se alguém aqui tiver uma resposta para sanr a minha dúvida, ficaria grato. 
> 
> Sei que este não é o canal adequado, mas o tema pode ser uma oportunidade 
> para discussão e eliminação de dúvidas também...
> 
> 
> 
> Há alguns dias percebi que o OSM (editor iD) está exigindo a tag area=no 
> quando é atribuído nas rotatórias a tag junction=roundabout.
> 
> De outro modo (sem a tag area=no) a rotatória assume o aspecto de área, com 
> pontos desconectados, que no meu entender é estranho. Antes não era assim.
> 
> Desse modo peço confirmar se realmente houve essa mudança, ou se trata se 
> algum bug na minha máquina.
> 
> 
> 
> Ivaldo Nunes de Magalhães
> E-mail: ivald...@gmail.com 
> Blog: makermaps.blogspot.com.br 
> (67) 8108-7415 - 3431-2810
> (61) 9139-7560
> ___
> 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] Quando usar shelter e covered

[Lists]

Tem um difference entre os duas, o shelter e um abrigo que dar proteção da 
vento, alas tem teto e paredes, enquanto covered somente tem teto e não dar 
proteção da vento.

Aun Johnsen

> On Feb 17, 2015, at 21:04, belnu...@pop.com.br wrote:
> 
> 
> 
> No ID aparece as etiquetas : shelter e covered para os pontos de ônibus .
> Pra mim os dois são iguais , portanto redundantes . Estou certo ?
> 
> Obrigado
> ___
> 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] roteamento na páginas principal do OSM

[Lists]

Tava olhando isso ontem, mas parecendo que o banco dados do OSRM ja tem algum 
semanas. Perguntei no IRC, e eles não pode usar os diffs minutos ou similar 
para atualizar os dados, mas depende de baixar o planeta inteiro e rodar o 
script de importação por cada atualizacao, como planet.osm e uns 3TB, este e um 
processo demorava. Infelizmente o campo do informação do idade dos dados não e 
disponível (mostrando somente “age of datas: n/a”)

Conversei la no IRC, e vi que ja tem algum países oferecendo OSRM com somente 
dados nacionais, acho um OSRM do somente Brasil vai ser mais rápido atualizar, 
e se ha um servidor próprio podemos ter nosso roteamento nacional.
 
Aun Johnsen

> On Feb 17, 2015, at 17:41, Marcelo Pereira  wrote:
> 
> Gerald,
> 
> Vi o novo roteamento, achei legal, mas fiquei com uma dúvida, qual a 
> frequência de atualização da base usada para o cálculo das rotas.
> 
> Incluí um via nova no OSM, e é claro que o roteamento não se adaptou 
> imediatamente, na verdade seria até bom ter essa diferença entre o mapa de 
> fundo e o período de atualização do roteamento explicitado, se é que já não 
> está em algum local.
> 
> Em 17 de fevereiro de 2015 17:33, Gerald Weber  > escreveu:
> Ativaram a possibilidade de fazer roteamento direto da páginas principal do 
> OSM.
> 
> https://blog.openstreetmap.org/2015/02/16/routing-on-openstreetmap-org/ 
> 
> 
> bom divertimento :)
> 
> Gerald
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-br 
> 
> 
> 
> 
> 
> -- 
> 
> São Pedro recebe Seu Lunga no céu perguntando: 
>  "Morreu, Seu Lunga? "
> "Não, vim passar o Natal!"
> 
> ___
> 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] Ruas sem nome

[Lists]

As ruas internas do condominio deve ser access=destination + 
access:destination=“Condominio Fulano de Tal”, significando que somente se voce 
vai a condominio pode entrar.

Com as nomes das ruas internas, pode ser, mas acho que “Condomínio Fulano de 
Tal” deve ser suficiente, se eles não ha nomes especificas.

Aun Johnsen

> On Feb 17, 2015, at 17:37, Marcelo Pereira  wrote:
> 
> Srs,
> 
> Agradeço pelas várias dicas.
> 
> Acabei a tarefa que estava fazendo, a de nomear as vias residenciais de 
> acordo com a Prefeitura e o IBGE.
> 
> Aproveito para perguntar algo no mesmo assunto, e quanto às vias internas de 
> condomínios e afins ? 
> 
> Tenho adicionado access=private e deixado sem nome, mas já vi casos em que 
> foi colocado "name=Rua Interna do Condomínio Fulano de Tal"
> 
> Isso é necessário e/ou recomendado ?
> 
> Att,
> 
> Marcelo Pereira


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

Re: [Talk-br] Digest Talk-br, volume 77, assunto 55

[Lists]

Concordo que o wiki nao explica bem.

o noname=yes e importante por varias motivos:
1) sinalizar para ferramentas QA como mapa noname para não mostra erro neste rua
2) ajuda nominatim e outros ferramentas de endereçamento que e um rua não 
denominada
3) aproveita um oportunidade para renderizadores da mapa coloque etiquetas 
localizadas, i.e. em Inglês voce vai quer ver “No Name”, como em Portuguese 
“Sem Nome”
4) Exclui-los do catalogação das ruas num município, para criar um index 
geográfica

Ainda pode ter mais motivos

Um valor generico como Gerald sugestionado pode também fazer mesma coisa, mas 
geralmente complicando bastante como estes ferramentas trabalhando

Valores como name=“Sem Nome” fazendo impossível criar um stylesheet do 
renderizador em idiomas específicas, quem sabe as formas certas e usados do 
“Sem Nome” em tudo idiomas e dielatas mundiais, alem no formas alternativas? 
Somente no Brasil temos pelo menus 4 formas, “Sem Nome”, “Não Denominada”, “Sem 
Denominação”, “Rua Projetada”. O etiqueta noname=yes dar este informação 
independente de como voce vai quer representar a mapa no rendericador, ou como 
voce vai quer catalogar as ruas, ou o que voce vai quer fazer com os dados.

Aun Johnsen

> On Feb 17, 2015, at 08:41, Ivaldo Nunes de Magalhães  
> wrote:
> 
> Oi João... lendo o wiki, não gostei dessa parte: 
> 
> "Um dos pontos principais deste noname=sim seria permitir que tais 
> ferramentas para excluir ruas a partir do destaque que eles realmente não têm 
> nome."
> 
> O termo excluir refere-se à pesquisa (excluir da pesquisa) ou literalmente?
>  
> Ivaldo Nunes de Magalhães
> E-mail: ivald...@gmail.com 
> Blog: makermaps.blogspot.com.br 
> (67) 8108-7415 - 3431-2810
> (61) 9139-7560
> ___
> 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] Digest Talk-br, volume 77, assunto 55

[Lists]

> On Feb 17, 2015, at 08:04, John Packer  wrote:
> 
> Aun,
> Até onde eu saiba, retornos não recebe nenhuma etiqueta ou nome adicional.
> Adicionar uma etiqueta destination=Retorno não me parece correto.

O descrição da tag destination e o informação que tem nas placas de destino. 
Como muitos retornos tem este tipo placa verde, as vezes somente com “Retorno”, 
outros com “Retorno” junto com outros destinos, eu acho certo usar este placa. 
Se não ha placa informando retorno, não deve coloque este tag destination, como 
este significar um retorno sinalizado, não somente qualquer retorno.

Onde ha mais que um destino, basta separa eles com coma virgula, como 
destination=“Retorno;Vitória”

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

Re: [Talk-br] Digest Talk-br, volume 77, assunto 55

[Lists]

> On Feb 16, 2015, at 22:34, Ivaldo Nunes de Magalhães  
> wrote:
> 
> 3. Acessos/link: sempre me deparo com esse problema e tambem fico na duvida. 
> Geralmente deixo em branco pois prefiro nao colocar informacao duvidosa ou 
> inexistente. Mas deixo uma pergunta: é correto colocar (por conta propria) os 
> termos "retorno" ou "acesso" em avenidas ou rodovias, quando sabemos que  
> realmente sao? 

Os valores “Retorno” e “Acesso” e melhor coloque no tag destination, onde ha 
placa de Retorno eu coloque “destination=Retorno”, em caso do acesso, coloque 
somente o destino como destination=“Fazenda de Tal” ou 
destination:forward=“Fazenda de Tal” sem coloque o palavra “Acesso”.___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Ruas sem nome

[Lists]

Pra a gente que usam JOSM, basta entra no configurações e ativar o validador 
Brasileiro, ele vai te avisar se não uso nomes padronizados. Se ha erros no 
validador basta abre um issue no 
https://github.com/OSMBrasil/validador-josm/issues

O Validação do JOSM e um muito bom ajuda para evitar erro nos chagesets, e o 
validador Brasileiro tem regras específicas para mapa Brasileiro, com por 
exemplo nomes das ruas, uso errado de name, formato errado no ref nas rodovias, 
palavras abreviadas no nome, uso errado do place=, e muito mais. O validador 
padrão do JOSM ja dar aviso do falta de nome, e o validador brasileiro ainda 
vai dar aviso se coloque “sem nome” como nome da rua (no este caso, se 
verificado, basta noname=yes)

Aun Johnsen

> On Feb 16, 2015, at 17:18, Blademir  wrote:
> 
> Olá, estou em Recife e Olinda pro carnaval rsrs me deparei com ruas 
> Abreviadas, favor corrija os nomes, para padronização.
> Valeu
> BladeTC

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

[Talk-br] Uso dos realações de manobra e limpeza

[Lists]

Boa tarde

depois olhando algumas trevos no Espírito Santo onde ja ha implementado 
relações de manobra ha muito tempo observando 3 assuntos diferente.

1) Relações quebrados. Tem muitos relações de manobra que falta membros, ou 
onde os membros não são ligados. Este e principalmente relações antigas, onde 
ha muitos edições desde o criação da relação. Maioria deles parecendo que fui 
criado um novo relação com mesmo papel mais recente. Tudo essas pode ser 
apagados como eles não tem funções mais, e muito trabalho concerta-los, e 
maioria ja fui substituídos com novos relações.

2) Criação da relações dis-necessarios. Viu algumas exemplos com trevos tem da 
mesmo via os sigintes, no_left_turn, no_right_turn, no_u_turn. Contando todos 
os relações me levou com somente um opção, e poderia mudar tudo para 
only_straight_on. No estes casos, o simples e o melhor, eu ja trocei alguma 
deles para somente um do only_straight_on. No criação dos relações, se não ha 
todos essas placas, cria um relação mais simples. Se tem este monte de placas, 
eu acho ainda melhor fazer o opção mais simples, mas ai tem o “on the ground 
trueth”, o que observamos e valido.

3) Tem muito relações no_u_turn que voltar no mesmo trecho (mesmo way como from 
e to). Se motivo e forcar o GPS não voltar no mesmo rua, precisamos procura um 
melhor tag. Eu suspeito que tem compiladores de mapa que ignoram estes relações 
porque e errado pelo documentação no wiki. Pelo lei do transito Brasileiro, não 
podemos fazer retorno (u_turn) ou vira esquerda onde ha faixa amarelo não 
interditada. Então uso do overtaking=no (também overtaking=forward, 
overtaking=backward) deve identificar que não pode vira esquerda ou fazer 
retorno. Se começamos utilizar este tag podemos da mesmo instrução ao 
compiladores das mapas. Em caso que tem mais que um faixa por sentido podemos 
começar com um novo tag, por exemplo noreturn=yes.

Aun Johnsen


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

Re: [Talk-br] Prioridades em rodovias com mais de uma ref=

[Lists]

Arlindo

No meu entendimento, mas nao, não perguntei os usuários, no muitos lugares as 
rodovias, principalmente federais, e conhecido como o ref. Ouvindo muito 
pessoas dizer coisas como “me pega ponto ônibus no BR-101”, ninguém que conheço 
dizendo “me pega ponto ônibus no Rodovia Governador Mário Covas”. E muito fácil 
copiar o valor do ref= para name= onde não ha nome mapeado, pelo menus parar 
dar erro no validadores e no ferramentas QA como nonamemap. Pelo meu 
conhecimento, todos os GPS veicular mostram o tag ref= (se compilado no mapa), 
então se falta ref no mapa não e falta no GPS, mas erro no compilador.

Aun Johnsen

> On Feb 15, 2015, at 10:31, Arlindo Pereira  
> wrote:
> 
> Algo que me passou na cabeça: sei que não é "nossa responsabilidade" enquanto 
> mapeadores, mas podemos investigar se quem reintroduz name=* nessas rodovias 
> o faz porque seu "cliente" de mapas (GPS veicular) não suporta a tag ref para 
> buscas ou algo do tipo.
> 
> []s
> Arlindo
> 
> Em 15/02/2015 11:25, "Gerald Weber"  > escreveu:
> 
> 
> no exempo do Gerald podemos coloque “ref=BR-367;MGC-367” + “nat_ref=BR-367” + 
> “ref_ref=MGC-367”. No verdade este e duplificacao das dados, mas acho 
> necessário porque tanto aplicativos não vai conhecer os valores nat_ref e 
> reg_ref
> 
> 
> É uma boa estratégia. Aumentando o número de nat_ref e reg_ref (6000 
> comparado com 1.2 milhão de ref) quem sabe com o tempo os renderizadores 
> passam a usar isto também. O único dilema é que na verdade a nat_ref=BR-367 é 
> que é conhecida regionalmente.
> 
>  
> Em tanto, ainda vendo muitos rodovias que tem um copia do ref no nome, este 
> não e certo. Eu não copiando refs como MGC-xxx para o ref, mas provavelmente 
> deve, mas onde ver que ref= e name= e mesmo, apagando o valor da name=
> 
> 
> Em vez de apagar eu tenho feito assim: troco "name=MGC-262"  por 
> "incorrect:name=MGC-262". Eu tenho percebido que quando apago "name=MGC-262" 
> com o tempo alguém acaba reintroduzindo. Minha frágil esperança é que 
> "incorrect:name=MGC-262" evite isto. :P
> 
> Gerald
>  
> 
> ___
> 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] Prioridades em rodovias com mais de uma ref=

[Lists]

> On Feb 15, 2015, at 10:24, Gerald Weber  wrote:
> 
> 
> 
> no exempo do Gerald podemos coloque “ref=BR-367;MGC-367” + “nat_ref=BR-367” + 
> “ref_ref=MGC-367”. No verdade este e duplificacao das dados, mas acho 
> necessário porque tanto aplicativos não vai conhecer os valores nat_ref e 
> reg_ref
> 
> 
> É uma boa estratégia. Aumentando o número de nat_ref e reg_ref (6000 
> comparado com 1.2 milhão de ref) quem sabe com o tempo os renderizadores 
> passam a usar isto também. O único dilema é que na verdade a nat_ref=BR-367 é 
> que é conhecida regionalmente.

Como criando um stylesheet, talvez deve investigar como utilizar 
nat_ref/reg_ref/loc_ref em vez de ref. Acho não pode substituir, nem agora nem 
no futuro, mas talvez pode criar um stylesheets onde ambos formas e aceito. Com 
certeza vou dar um trabalho. Por enquanto vou fazer um issue para talvez 
resolver no futuro.

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

Re: [Talk-br] Prioridades em rodovias com mais de uma ref=

[Lists]

> On Feb 15, 2015, at 09:25, Gerald Weber  wrote:
> 
>  
> O tag ref é para informações oficiais. O tag para nomes alternativos pelos 
> quais a população local conhece uma via é alt_name, loc_name ou reg_name, 
> dependendo do caso. Existe ainda a possibilidade de nat_ref, reg_ref ou 
> loc_ref. Se a preocupação é essa, talvez esse caso possa ter dois tags: 
> "ref=MGC-262" e "nat_ref=BR-262". Se for possível, é melhor evitar valores 
> múltiplos para o mesmo tag.
> 
> Hum, é uma mudança importante de opinião. Agora há pouco você considerava 
> redundante (ou seja idêntico), agora BR nem sequer é oficial para você.
> 
> BR continua sendo tão oficial quanto RSC ou MGC. Os documentos do DER-MG 
> trazem ambos os códigos. Eu agora estou revisando a MGC-367;BR-367 por onde 
> passei. Ela é administrada em todo o trecho pelo DER-MG. Ora há placas com 
> MGC ora com BR. Já as placas de direção sempre aparecem como "BR-367 a 10 
> km". 
>  

Os tags nat_ref, reg_ref, loc_ref e int_ref e pouco usado e tem poucos 
aplicativos suportando. Se voce acho que devemos começar usar estes tags, basta 
coloque todos os refs no ref=, e especificar cada deles com um *_ref tag. O 
problema e onde ha mais que um BR ou mais que um estadual no mesmo trecho, no 
tempo que importei dados DNIT viu que pode ter ate 3 BR e 2 estaduais no mesmo 
trecho. Concordo que o visualização do muitos tags pode ser um pouco poluído na 
mapa, mas melhorou bastante no mapnik principal quando mudo para o novo 
stylesheet.

no exempo do Gerald podemos coloque “ref=BR-367;MGC-367” + “nat_ref=BR-367” + 
“ref_ref=MGC-367”. No verdade este e duplificacao das dados, mas acho 
necessário porque tanto aplicativos não vai conhecer os valores nat_ref e 
reg_ref

Em tanto, ainda vendo muitos rodovias que tem um copia do ref no nome, este não 
e certo. Eu não copiando refs como MGC-xxx para o ref, mas provavelmente deve, 
mas onde ver que ref= e name= e mesmo, apagando o valor da name=


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

Re: [Talk-br] Prioridades em rodovias com mais de uma ref=

[Lists]

Carlos

Acho este e por compilador, ou por stylesheet, algum que compilando mapas para 
GPS pode confirmar isso. Também pode ser que o firmware dentro GPS cortando o 
ref, se este e caso preciso ver com o fabricante (Garmin).

Pelo o validador brasileiro do JOSM, LLL- e valido, também tem valido 
LL-NNN/NNN que dar 10 letras (este e caso no algum estaduais no SP

Para nao ha problemas aqui no Brasil, precisamos ate 10 caracteres no ref


Aun Johnsen

> On Feb 13, 2015, at 20:02, A. Carlos  wrote:
> 
> 
> Já existe Rodovias municipais hoje com 3 letras na REF e 4 digitos no 
> numeral, com o (-) são 8 Caracteres,
> 
> Não sei quanto as outras plataformas, mas nos GPS Garmin  (com o Mkgmap) não 
> sei se aceita mais que 7 caracteres.
> 
> 
>   
>  
>  
>  
>  
>  
>  
> 
> ___
> Anor C. A. de Souza   Concórdia 
> SC   
> 49-8808-4963
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> 
> 
> From: li...@gimnechiske.org
> Date: Fri, 13 Feb 2015 19:45:15 -0300
> To: talk-br@openstreetmap.org
> Subject: Re: [Talk-br] Prioridades em rodovias com mais de uma ref=
> 
> No meu opinião, o ref=RSC-xxx;BR-xxx somente se as placas no BR mesmo tem o 
> ref RSC, se as placas e com o ref BR, basta ref=BR-xxx;RSC-xxx (como e o 
> situação na minas pelo que observei e pelo que evidencias que conheço no 
> Mapillary com placas BR alas ref=BR-xxx;MGC-xxx)
> 
> Sobre nome do rodovia no trechos individuais, prefiro ter somente nome do 
> rodovia no relação, e no cada trecho usar o nome local do trecho, ou deixa 
> sem nome. Pelo que saiba não dar erro no camada noname porque nome ja tem no 
> relação. Também renderizadores e roteadores deve pega nome do relação.
> 
> Aun Johnsen
> 
> On Feb 13, 2015, at 19:24, Gerald Weber  > wrote:
> 
> 
> Os códigos das rodovias são excludentes, em cada trecho. Ou é BR ou é RSC. É 
> redundante colocar os dois códigos, pois TODAS as RSC (antigas RST) pertence 
> ao trajeto planejado da BR. Não se perde informação alguma deixando o código 
> da BR fora dos trechos da RSC, e o mapa fica mais limpo. Sempre que eu vejo 
> uma RSC, eu sei que ela faz parte do trajeto planejado de uma BR. Caso 
> contrário, seria ERS ou VRS.
> 
> Bom, se existe a possibilidade de uma BR-XXX ter um trajeto diferente de uma 
> RSC-XXX então é essencial que nos trechos em que de fato coincidam tenhamos 
> ambos as referências no trecho. 
> 
> Depois da discussão anterior fica assim para mim
> 
> ref=RSC-XXX;BR-XXX  significa que RSC-XXX segue o mesmo trajeto de BR-XXX
> 
> ref=RSC-XXX (somente) significa que a RSC-XXX segue um trajeto mas a BR-XXX 
> segue outro.
> 
> Ter ambas as referências não polui o mapa, e eu como usuário, acho 
> extremamente útil. 
> 
> Além do mais omitir informação para deixar o mapa mais limpo não é o 
> procedimento adequado, é etiquetar para o renderizador. O renderizador é que 
> decide se mostra uma, duas ou mais referências.
> 
>  
> 
> O termo "coincidente", apesar de ser a denominação oficial, pode estar 
> causando confusão. Coincidente mesmo é, por exemplo, o trecho (da BR-287) 
> entre os km 115,70 e 158,16, em que a RSC-287 coincide com os km 326,32 a 
> 368,78 da BR-153 (ou, nesse caso, RSC-153). Nesse trecho o tag correto deve 
> ser "ref=RSC-153;RSC-287". 
> 
> 
> Não. O significado é este mesmo, veja aqui
> http://www.der.mg.gov.br/saiba-sobre/rede-rodoviaria/652-rodovias-estaduais-coincidentes
>  
> 
> 
> Rodovia Coincidente, levando um "C" adicional no código, como MGC ou RSC. 
> 
> A BR-040 e a BR-262 coincidem em certos trechos no anel rodoviário de BH, mas 
> não estão relacionadas como rodovias coincidentes.
> 
>  
> Ficaria inconveniente etiquetar esse trecho como 
> "ref=BR-153;BR-287;RSC-153;RSC-287".
> 
> É o que temos feito e não vejo problema algum nisto. 
> 
> abraço
> 
> Gerald
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-br
> 
> 
> ___ Talk-br mailing list 
> Talk-br@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-br
>  
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-br 
> 
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Prioridades em rodovias com mais de uma ref=

[Lists]

No meu opinião, o ref=RSC-xxx;BR-xxx somente se as placas no BR mesmo tem o ref 
RSC, se as placas e com o ref BR, basta ref=BR-xxx;RSC-xxx (como e o situação 
na minas pelo que observei e pelo que evidencias que conheço no Mapillary com 
placas BR alas ref=BR-xxx;MGC-xxx)

Sobre nome do rodovia no trechos individuais, prefiro ter somente nome do 
rodovia no relação, e no cada trecho usar o nome local do trecho, ou deixa sem 
nome. Pelo que saiba não dar erro no camada noname porque nome ja tem no 
relação. Também renderizadores e roteadores deve pega nome do relação.

Aun Johnsen

> On Feb 13, 2015, at 19:24, Gerald Weber  wrote:
> 
> 
> Os códigos das rodovias são excludentes, em cada trecho. Ou é BR ou é RSC. É 
> redundante colocar os dois códigos, pois TODAS as RSC (antigas RST) pertence 
> ao trajeto planejado da BR. Não se perde informação alguma deixando o código 
> da BR fora dos trechos da RSC, e o mapa fica mais limpo. Sempre que eu vejo 
> uma RSC, eu sei que ela faz parte do trajeto planejado de uma BR. Caso 
> contrário, seria ERS ou VRS.
> 
> Bom, se existe a possibilidade de uma BR-XXX ter um trajeto diferente de uma 
> RSC-XXX então é essencial que nos trechos em que de fato coincidam tenhamos 
> ambos as referências no trecho. 
> 
> Depois da discussão anterior fica assim para mim
> 
> ref=RSC-XXX;BR-XXX  significa que RSC-XXX segue o mesmo trajeto de BR-XXX
> 
> ref=RSC-XXX (somente) significa que a RSC-XXX segue um trajeto mas a BR-XXX 
> segue outro.
> 
> Ter ambas as referências não polui o mapa, e eu como usuário, acho 
> extremamente útil. 
> 
> Além do mais omitir informação para deixar o mapa mais limpo não é o 
> procedimento adequado, é etiquetar para o renderizador. O renderizador é que 
> decide se mostra uma, duas ou mais referências.
> 
>  
> 
> O termo "coincidente", apesar de ser a denominação oficial, pode estar 
> causando confusão. Coincidente mesmo é, por exemplo, o trecho (da BR-287) 
> entre os km 115,70 e 158,16, em que a RSC-287 coincide com os km 326,32 a 
> 368,78 da BR-153 (ou, nesse caso, RSC-153). Nesse trecho o tag correto deve 
> ser "ref=RSC-153;RSC-287".
> 
> 
> Não. O significado é este mesmo, veja aqui
> http://www.der.mg.gov.br/saiba-sobre/rede-rodoviaria/652-rodovias-estaduais-coincidentes
>  
> 
> 
> Rodovia Coincidente, levando um "C" adicional no código, como MGC ou RSC. 
> 
> A BR-040 e a BR-262 coincidem em certos trechos no anel rodoviário de BH, mas 
> não estão relacionadas como rodovias coincidentes.
> 
>  
> Ficaria inconveniente etiquetar esse trecho como 
> "ref=BR-153;BR-287;RSC-153;RSC-287".
> 
> É o que temos feito e não vejo problema algum nisto. 
> 
> abraço
> 
> Gerald
> ___
> 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] BR-116 split and cleanup

[Lists]

Tem uns 2 ou 3 rodovias mais que teoricamente pode ser divido similares, mas 
estes passa principalmente nas areas com pouco mapeamento, e assim as trechos 
mais logos e menus atividade.

Aun Johnsen

> On Feb 12, 2015, at 23:13, Flavio Bello Fialho  > wrote:
> 
> Entendo que o histórico estava muito longo e que a rodovia tem muitos 
> segmentos. Entretanto, dividir a rodovia em relações pequenas prejudica o 
> controle. Quando eu vejo que uma rodovia ficou descontínua, eu baixo a 
> rodovia no JOSM e conserto o que ficou errado. Geralmente, aproveito para 
> corrigir a rodovia no trecho afetado, detalhando os cruzamentos e colocando 
> as restrições de conversão, de forma que a rodovia fique correta e o usuário 
> não precise mexer de novo. Assim, é bom que os trechos sejam longos, pois eu 
> verifico uma grande extensão numa tacada só. Se for para dividir, proponho 
> que seja dividido por região (Sul, Sudeste, Nordeste, Norte e Centro-Oeste). 
> Assim, a BR-116 ficaria dividida em 3 relações (NE, SE e S) e fica mais fácil 
> para as equipes de cada estado trabalharem. Dessa forma, quando eu 
> verificasse a integridade da BR-116, já o faria em 3 estados (RS, SC e PR). 
> Até agora, as únicas rodovias realmente grandes (em número de segmentos) são 
> a BR-116 e a BR-101.
> 
> 2015-02-12 22:48 GMT-02:00 Nelson A. de Oliveira  >:
> A separação que o Paul fez foi emergencial (para remover alguns dados do OSM).
> Foi caso isolado.
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-br 
> 
> 
> 
> 
> -- 
> Flávio Bello Fialho
> bello.fla...@gmail.com 
> ___
> 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] BR-116 split and cleanup

[Lists]

Eu concordo com separa os relações das rodovias maiores, o BR-116 e o BR-101 
ambos e mais que 2000 elementos, e quase 2000 versões. Mas precisamos um 
consenso em como eles deve ser divididos. Não concordo como o Paul Norman 
dividiu o BR-116.

Eu dividi o ES-060 (relação 2055019) entre o area concecionada e o area não 
concecionada (relação 3904464) com o relação 4564066 como super-relação, para 
experimentar se funciona melhor. Um motivo por isso e que area concecionada tem 
um operador próprio (RodoSol) com canal de informacao aos usuários, enquanto o 
outro parte e operado por DER-ES sem nenhuma forma de comunicação oficial.

Eu acho devemos fazer mesmo com os rodovias federais, cada conceição forma um 
relação próprio, com um super-relação juntando tudo.

Aun Johnsen

> On Feb 12, 2015, at 20:40, Flavio Bello Fialho  wrote:
> 
> Não concordo com essa quebra da BR-116. Eu uso a relação para testar a 
> integridade das rodovias e isso me atrapalhou bastante. Não consigo mais 
> checar a BR-116, cuja relação eu vinha mantendo intacta. Antes de fazer algo 
> desse tipo, devemos ter uma discussão adequada para decidir se deve ou não 
> ser feito, aviso de que isso será feito (na lista, no fórum e no wiki) e 
> tempo suficiente para que todos se manifestem. As rodovias federais do Rio 
> Grande do Sul estão listadas em 
> http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/RS/Rodovias_Federais 
>  
> (testo elas regularmente) e a lista de todas as rodovias federais está em 
> http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Rodovias_Federais 
>  . 
> Com a alteração, os links para a BR-116 não estão mais funcionando.
> 
> Em 2 de fevereiro de 2015 10:28, Nelson A. de Oliveira  > escreveu:
> Como o problema de relações de rota não está relacionado com o DWG não
> é preciso incluí-los (DWG e Paul) nas respostas.
> Também não há necessidade de continuar a discussão em inglês (já que é
> a comunidade brasileira que deve decidir qual a melhor forma de manter
> as relações).
> 
> O Paul gentilmente avisou sobre a divisão de uma rota apenas porque
> foi necessário quebrá-la para facilitar algumas reversões e remoções
> de objetos.
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-br 
> 
> 
> 
> 
> -- 
> Flávio Bello Fialho
> bello.fla...@gmail.com 
> ___
> 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] erros x relações

[Lists]

Voce pode me manda algumas pontos para eu reproduzir esses erros de roteamento? 
Eu posso testar com varias formas de roteamento com varias configurações 
habilitadas.

Aun Johnsen

> On Feb 12, 2015, at 13:04,  
>  wrote:
> 
> Intercepto a Amaral Peixoto pela Rua Professor Souza ( 
> https://www.openstreetmap.org/way/291228492 
>  ). O roteamento nessa 
> intercessão instrui a fazer curva a direita, pegar a Estrada do Palmital ( 
> https://www.openstreetmap.org/way/284244418 
>  ) e posteriormente a Via lagos 
> ( https://www.openstreetmap.org/way/326023360 
>  ). Esse roteamento é correto 
> para configuração de caminho mais rápido, entretanto não o sigo porque 
> prefiro retornar para casa pela Amaral Peixoto, pelo que o povo local chama 
> de Serrinha.
>  
> Assim, ao entrar na Amaral Peixoto sigo para esquerda contrariando o 
> roteamento.
>  
> A partir desse momento, quando o navegador identifica que não segui o 
> roteamento por ele calculado, começa a ativar o recalculo de rota e logo de 
> pronto manda eu fazer u-turn no primeiro nós de roteamento a frente que é a 
> intercessão com a via https://www.openstreetmap.org/way/278750332 
> 
>  
> Daí em seguinte ele, vendo que não fiz u-turn fica sempre recalculando 
> instruindo a retornar na próxima intercessão a frente. Essa situação fica se 
> repetindo até aproximadamente o entroncamento em 
> https://www.openstreetmap.org/way/278746258 
>  . Depois disso ele se cansa em 
> ficar recalculando e roteia normalmente pela minha rota desejada que é pela 
> Serrinha.
> 

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

Re: [Talk-br] erros x relações

[Lists]

Geraldo, isso também, se ha linha amarela completa (não interditada) e proibido 
cruzar linha e assim não pode retornar, este exemplo de noreturn=yes e onde não 
ha overtaking=no, por exemplo onde ha 2 faixas (voce pode ultrapassar) mas tem 
linha completa (voce não pode fazer u_turn). Talvez que este tag próprio pode 
crescer dados interessante na mapa, e resolver este problema no navegadores (eu 
ainda falta replicar este problema)

Aun Johnsen

> On Feb 12, 2015, at 12:37, Gerald Weber  wrote:
> 
> Enfim, como Garmin usando um arquivo proprio para roteamento, e OSM não fui 
> desenvolvido direitamente para isso, o geração da mapa Garmin e atreves um 
> compilador. Se e assim que o rodovia inteiro tem um restrição tipo 
> no_self_u_turn, talvez similante que overtaking=no e noparking=yes, podemos 
> ter noreturn=yes.
> 
> Verdade Aun, uma "relation" é para relacionar um trecho com outro. Para 
> colocar uma restrição sobre o próprio techo não há necessidade de uma 
> "relation", é completamente redundante. Mais uma razão para não usar.
> 
> Mas o que disse é que overtaking=no deveria implicar em no_self_u_turn. Você 
> não pode retornar em trechos onde é proibido ultrapassar.
> 
> No caso de rotatórias sempre é proibido ultrapassar, assim se colocar 
> overtaking=no no trecho já mataria dois coelhos com uma cajadada só. Se os 
> aplicativos reconhecessem isto eliminaria o uso de quase todas as restrições 
> de conversão em rotatórias. Simplificaria demais a nossa vida.
> 
> Gerald
> 
> ___
> 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] erros x relações

[Lists]

No Europa maioria de carros novos ja chegando com navegador próprio instalados, 
logo e somente carros velhos que não tem, por isso as vendas de aparelhos nos 
lojas eletrônicos quase sumiu. Os fabricantes, (Garmin, TomTom, GoMap, etc.) 
tem mais atenção em vender para fabricantes e importadoras de automóveis em vez 
de consumidores. Em vez disso o mercado também mudando, pessoas não quer tanto 
aparelhos instalado no veiculo, por isso prefiro navegar pelo smartphone, eles 
uso um fitnestracker (muitos deles com GPS), ou outros atividades onde outro 
tipos do gadgets seria interessante. O que voce ver no prateleira no lojas 
eletrônicos no Europa e no EUA não necessariamente significando que eles não 
vender aparelhos, so que eles não vender navegadores nos esse tipo de lojas.

Ainda ha muito produtos incluindo aplicativos, que utilizando mapas do formato 
do Garmin, TomTom, GoMap e provavelmente outros formatos, sei que ja tem GoMap 
instalado no meu smartphone, alem do ter GoMap instalado no meu carro e meu 
aparelho Garmin. Não instalei TomTom no meu smartphone porque não achei 
aplicativo gratuito.

Aun Johnsen

> On Feb 12, 2015, at 12:24, Gerald Weber  wrote:
> 
> Há alguns anos, nas lojas de eletrônicos da europa, havia setores inteiros 
> com unidades autônomas de GPS (Garmin, Tomtom etc). Da última vez que fui, em 
> julho, mal tinha uma prateleira perdida no canto da loja.

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

Re: [Talk-br] erros x relações

[Lists]

O Garmin como o navigador preferido no Carros e Caminhos declinando sim, 
justamente porque smartphones tem mapa navegáveis de alto qualidade, mas este 
não vai fundar a mercado do Garmin. Garmin usando muito energia desenvolver 
outros produtos, como fitness trackers e relógio para golfeiros entre outros. 
Algumas desses novos produtos também pode utilizar mapas do OSM. Eu acho que 
muito de nos tem um foco cego que este mapa e para roteamento, não e. No 
verdade, OSM e um “mapa de todo”, assim podemos ter roteamento, navegação 
náutica, campos de golfe, e muito mais no nosso mapa.

Enfim, como Garmin usando um arquivo proprio para roteamento, e OSM não fui 
desenvolvido direitamente para isso, o geração da mapa Garmin e atreves um 
compilador. Se e assim que o rodovia inteiro tem um restrição tipo 
no_self_u_turn, talvez similante que overtaking=no e noparking=yes, podemos ter 
noreturn=yes.

Ainda nao vi exemplos no Garmin sobre este roteamento retorno no mesmo rua que 
Marcio dizendo que tem, e tem tempo perguntando do exemplo disso para fazer 
simulação. Tem tempo usei Garmin como único navegador (meu carro tem Go Map, 
mas não confio porque ver muito trechos erradas no mapa), e regularmente 
fazendo simulações no meu computador com Garmin BaseCamp. Eu tem centenas de 
rotas de teste, ambos entre cidades perto e do longo distancia, ate um  rota do 
Chuí (RS) a Fortaleza (CE). Identifiquei varias problemas mas ainda fazendo 
testes localiza-los com mais certeza.

Meus testes no momento e com mapas gerado do banco dados OSM dia 30/12/2014, 
quando tem linha de internet melhor vou atualizar.

Aun Johnsen

> On Feb 12, 2015, at 11:22, Gerald Weber  wrote:
> 
> Aqui então vem outra pergunta que precisa ser pensada. Ainda compensa o 
> investimento em gerar mapas para o Garmin? O mercado da Garmin tem declinado 
> dramaticamente:
> http://www.technologyreview.com/news/511786/a-shrinking-garmin-navigates-the-smartphone-storm/
>  
> 
> 
> Colocando de outra maneira: compensa introduzir tantos elementos estranhos e 
> conflitantes no OSM por uma tecnologia que está aos poucos saindo do mercado?

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

Re: [Talk-br] erros x relações

[Lists]

Marcio

Voce pode me mostra onde o navegador do Garmin faz este u-turn para eu dar 
simulações? Pelo que conheço de roteamento isso não e caso. Favor manda 
informação para outro pode replicar a problema. No meu experiência o Garmin não 
quer dar curvas em cima do 100º se existe alternativas, mesmo se um pouco mais 
longe. Então entra uma rotatória o Garmin vai prefiro rodar a rotatória em vez 
de fazer u_turn no entrada da mesma.

Aun Johnsen

> On Feb 12, 2015, at 10:12, thunder...@gpsinfo.com.br wrote:
> 
> Pois é Nelson, entretanto lembro que em não existindo a restrição o Garmin 
> faz u-turn nesse nó de roteamento caso o utilizador não tenha configurado seu 
> navegador para evitar u-turn.
> 
> Lembro que estamos tratando de nó de roteamento onde existe nele mais de uma 
> opção de manobra. Não estamos tratando de nó comum, onde só existe uma opção 
> de manobra e aquele que liga simplesmente segmentos de reta em retratação de 
> curvas (sem entroncamentos).
> 
> -Mensagem Original- From: Nelson A. de Oliveira
> Sent: Thursday, February 12, 2015 11:00 AM
> To: OpenStreetMap no Brasil
> Subject: Re: [Talk-br] erros x relações
> 
> 2015-02-12 10:26 GMT-02:00 :
>> 5 - Ele aceita a implantação de restrição u-turn no nó de roteamento formado 
>> pelo entroncamento das 3 vias e defendo que essa situação é correta e 
>> testada em campo com um aparelho garmin.
> 
> Não é certo. O iD não deveria sugerir e nem permitir esse tipo de
> no_u_turn na própria rua.
> Vou ver se já existe um bug reportado, senão abrirei um.
> 
> ___
> 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] erros x relações

[Lists]

Marcio & al

Se sinto ofendido por linguagem pedir desculpa, eu não sou formado em 
Portuguese, e escreve como falho. Alexandre ja descobri este num discução no 
IRC, e o maioria das pessoas que comunicando comigo diariamente saber isso.

Eu nao o pessoa que chamando outros da bicha, ou outros ofensas, eu não 
discriminando (ou pelo menus tentando não) por sexualidade, religião, raça, 
opinião politico ou outro.

Aun Johnsen

> On Feb 11, 2015, at 21:37, Alexandre Magno Brito de Medeiros 
>  wrote:
> 
> Vamos deixando de lado a parte mais chata da discussão.
> 
> Marcio, é preciso dar um desconto. Ele não é versado em nosso idioma. Em 
> vários momentos usa o feminino para si próprio. Quero crer que com a 
> expressão "seja home" ele quis um significado mais lúdico, muito usado no 
> nordeste. Aliás, eu realmente acredito que ele não lhe se referiu à 
> sexualidade.
> 
> Alexandre Magno
> 
> Em 11 de fevereiro de 2015 21:30,  <mailto:thunder...@gpsinfo.com.br>> escreveu:
> 
> Aun Johnsen,
>  
> HOMEM EU SOU E MEÇA SUAS PALAVRAS AO SE DIRIGIR A MIM DESSA FORMA.
>  
> TENHO 64 ANOS E NÃO ADMITO ISSO.
>  
> From: Lists <mailto:li...@gimnechiske.org>
> Sent: Wednesday, February 11, 2015 6:04 PM
> To: OpenStreetMap no Brasil <mailto:talk-br@openstreetmap.org>
> Subject: Re: [Talk-br] erros x relações
>  
> Marcio
>  
> E bom voce quer ajuda melhora a mapa, mas favor seja home concertar o que 
> voce quebrando. Fiquei muito com raiva vendo que relações que fiz semana 
> passado quebrado em pouco tempo.
> 
> ___
> 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] erros x relações

[Lists]

Ah, voce pode esgotar meu contribuções porque voce e uns 25 anos mais velho que 
eu? Ou talvez eu pode dizer que meus dados e mais importante que seus porque 
tava no projeto uns 5 anos antes de voce? Ou talvez porque fiz mais edições?

Nao importa se voce e 16 ou 64 se voce preciso coloque seu edições em frente de 
outros. Eu não dar diferencia em como eu verificando mudanças na mapa, nem do 
crianças, nem adultos, nem do novetas e nem do usuários experientes. Eu sei que 
posso fazer coisas errados, também não sou perfeito. E voce pode ter certeza 
que vou olhar bastante como voce editando relações com seu atitude.

 Aun Johnsen

> On Feb 11, 2015, at 21:30,  
>  wrote:
> 
> Aun Johnsen,
>  
> HOMEM EU SOU E MEÇA SUAS PALAVRAS AO SE DIRIGIR A MIM DESSA FORMA.
>  
> TENHO 64 ANOS E NÃO ADMITO ISSO.
>  
> From: Lists <mailto:li...@gimnechiske.org>
> Sent: Wednesday, February 11, 2015 6:04 PM
> To: OpenStreetMap no Brasil <mailto:talk-br@openstreetmap.org>
> Subject: Re: [Talk-br] erros x relações
>  
> Marcio
>  
> E bom voce quer ajuda melhora a mapa, mas favor seja home concertar o que 
> voce quebrando. Fiquei muito com raiva vendo que relações que fiz semana 
> passado quebrado em pouco tempo.
>  
> ___
> 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] erros x relações

[Lists]

Me entendo certo,

Ja tem empresa, e ganho bom, se tira tudo salário de voce não me dar diferencia,

So digo isso porque tempo tem valor, e como voluntário eu investe meu tempo 
próprio sem outro compensação que receber um mapa gratuito.

Mando um valor para pessoas no OSM não tem outro significativo que mostrar o 
valor do trabalho. Sem contrato não posso juridicamente cobra este valor. Se 
poderia trabalhar 3 horas e ganha este salário com outros coisas, ou uso 3 
horas mapeando no OSM e meu escolhe, sem contrato ou sem compromisso. Se algum 
me pagasse para editar aqui eu aceito, e sei que muitos vai aceitar também, mas 
também sei que tem gente aqui que prefiro não ser pago.

Com manda valor ao pessoa quer dizer 2 coisas

1) meu tempo tem valor, este que poderia ganhar fazendo outro coisas

2) eu prefiro outros atividades no OSM que concertar erros dos outros.

Eu nao espera ver nenhuma centavo do este valor também.

Aun Johnsen

> On Feb 11, 2015, at 20:35, Alexandre Magno Brito de Medeiros 
>  wrote:
> 
> Não, isso está evidentemente errado. Todo o trabalho aqui é voluntário. Se 
> alguém tem contrato com alguma empresa, trate com ela, não com a comunidade. 
> O que vem da comunidade e o que vai para ela não é cobrado. A pessoa faz 
> porque quer e pode. Se existe lei constitucional por aqui, certamente este é 
> um dos princípios. Eu sei que está implícito, mas não vamos misturar alhos 
> com bugalhos. Se quer ganhar dinheiro, procure ou crie uma empresa.
> 
> Alexandre Magno
> 
> Em 11 de fevereiro de 2015 20:16, Lists  <mailto:li...@gimnechiske.org>> escreveu:
> 
> E como voce [Marcio Soares] editando tao muito e tanto coisas, como eu, voce 
> investindo muitos horas neste projeto. Um motivo para reverter e mostra para 
> voce que tanto tempo investido fui esgotado. Eu poderia cobra voce o tempo eu 
> uso para concerta este coisas, mas provavelmente voce não tem dinheiro paga 
> contas tao alto, profissionalmente cobrando mais por hora que maioria dos 
> Brasileiros ganha por dia.
> 
> Proximo vez que preciso concertar algum coisa de voce vou mandar um recado 
> com o valor.
> 
> 
> ___
> 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] erros x relações

[Lists]

> On Feb 11, 2015, at 20:17, Nelson A. de Oliveira  wrote:
> 
> 2015-02-11 21:14 GMT-02:00  :
>> Se ela não é para ser feita significa que a aplicação de restrição de
>> manobra pelo ID está errada? Li vários elogios a respeito quando implantaram
>> essa facilidade no ID que na minha analise é bem mais facil que pelo josm.
> 
> É mais fácil, mas ela não valida e nem impede de criar restrição incorreta.
> 
> Precisa ver se é erro no mkgmap que acaba permitindo retornar na própria rua.
> 
Eu nao sei onde voce encontro este problema, no meu Garmin Nüvi 50, não queria 
fazer um curva de 110 graus porque com 4 curvas mais suave poderia entra no 
mesmo rua. Precisava editar o trevo para concertar roteamento. Então, me mostra 
onde roteamento dar estes retornos absurdos, se eu consigo replica-los no meu 
Garmin e no BaseCamp, vou creditar em voce.


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

Re: [Talk-br] erros x relações

[Lists]

Que nao priorizando geometria e errado, mas primeiro regra editando e não 
quebra que existe. Quando ha informação de geometria melhor eu editando. Onde 
voce editou fui por mim um area onde não ha conhecimento pessoal, e sim somente 
editando pelo Bing/MapBox. Tem tempo que não editei ai, mas não lembro ver os 
rotatórias que voce falhando no Bing, então este e mais recentes que imagens 
que tem/tava no local.

O geometria eu vai entrar e o que conheço, se voce tem dados mais novas ou mais 
detalhadas que imagens de satélite, divulga com o comunidade, editar, e não 
quebra que tem.

E como voce editando tao muito e tanto coisas, como eu, voce investindo muitos 
horas neste projeto. Um motivo para reverter e mostra para voce que tanto tempo 
investido fui esgotado. Eu poderia cobra voce o tempo eu uso para concerta este 
coisas, mas provavelmente voce não tem dinheiro paga contas tao alto, 
profissionalmente cobrando mais por hora que maioria dos Brasileiros ganha por 
dia.

Proximo vez que preciso concertar algum coisa de voce vou mandar um recado com 
o valor.

Aun Johnsen

> On Feb 11, 2015, at 20:07,  
>  wrote:
> 
> Não nego que em nosso diálogo, quando disse você que iria reverter minhas 
> edições, repliquei dizendo que poderia reverter, mas que tivesse o cuidado de 
> corrigir todos os erros de geometria de rodovia por mim corrigidos.
>  
> Diferentemente de você priorizo a geometria das rodovias permitindo 
> roteamento por elas. Não tiro a importância da relação, mas a vejo em segundo 
> plano porque essa é oculta para o utilizador e não é renderizada.
>  
> Teremos mais colaboradores quando tratarmos com bondade os que estão 
> colaborando e os que ingressam.
>  
> From: Lists <mailto:li...@gimnechiske.org>
> Sent: Wednesday, February 11, 2015 8:55 PM
> To: OpenStreetMap no Brasil <mailto:talk-br@openstreetmap.org>
> Subject: Re: [Talk-br] erros x relações
>  
>  
>> On Feb 11, 2015, at 19:35, > <mailto:thunder...@gpsinfo.com.br>> > <mailto:thunder...@gpsinfo.com.br>> wrote:
>>  
>> Não tiro a importância dos “fiscais”, entretanto esses devem ser comedidos 
>> em suas interpelações e não ameaçar de reversão os dados editados sem 
>> contato com a comunidade.
> Ficou puto porque um semana trabalho esgotado, e também e cheia do coisas 
> pequenos quebrados por caso desse editor iD. Chegou um limite para mim, e 
> voce pode considerar que fui educado informando voce do problema e que 
> realmente queria reverter tudo. Admito que o linguagem no recado em si talvez 
> não muito educado, mas fiquei com raiva mesmo.
>  
> Eu poderia fica quieta e reverter tudo isso sem falhar, realmente entrou 
> contato com voce para voce resolver concertar o que fui quebrado. Voce não 
> queria olhar eles, então, eu começou preparar reverter.
>  
> Nao reverti porque chegou algum para concertar antes que tinha meu changeset 
> de reversão pronto.
>  
> Se voce pelo menus mostrou que tentaria concertar, entender o trabalho outros 
> coloque no projeto, eu poderia ajuda voce, mas como voce respondeu fiquei 
> mais com raiva.
>  
> E jogando em mim “tem monte erros para voce concertar”, quando eu vejo voce 
> como um dos criadores do erros, ficando como “favor limpa meu merda”. Eu quer 
> mesmo como voce criar um mapa melhor, mas prefiro usar meu tempo editar onde 
> falta dados, que concertando atreves outros usuários.
> 
> ___
> 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] erros x relações

[Lists]

O exemplo que voce mostrar e totalmente errado, o roteador não vai vierar voce 
neste local mesmo, eles não dar curva 180º mesmo. Tambem, tem placa no local? 
Se não tem placa, não e proibido fazer (se voce tem espaço para manobrar), e 
voce pode tentar. O “on the ground trueth” entrar aqui, tem placa, faz o 
relação, não tem placa, não faz.

Aun Johnsen

> On Feb 11, 2015, at 19:54,  
>  wrote:
> 
> Nelson,
> agora não compreendi.
>  
> Existe a restrição u-turn que impede o retorno na mesma rua.
>  
> Como citei, quando existe uma abertura de uma rua em duas, no nó de abertura 
> deve-se empregar a restrição u-turn de forma a impedir que o roteamento faça 
> u-turn naquele nó.
>  
> Vamos a um exemplo prático de uma restrição u-turn por mim implantada no nó 
> em http://www.openstreetmap.org/node/3338188908 
> 
>  
> 
>  
>  
> -Mensagem Original-
> From: Nelson A. de Oliveira
> Sent: Wednesday, February 11, 2015 8:27 PM
> To: OpenStreetMap no Brasil
> Subject: Re: [Talk-br] erros x relações
>  
> 2015-02-11 20:21 GMT-02:00  :
> > A restrição=no_u_turn é reconhecida pelo MKGMAP e deve ser aplicada sempre
> > que uma via se abre em duas. Exatamente no nó da abertura porque caso
> > contrário aquele nó é considerado um ponto de manobra para U-turn.
>  
> Os no_u_turn estão em sua maioria errados, com to (destino) e from
> (origem) sendo a mesma rua.
> Elas só estão proibindo de retornar na própria rua.
>  
> ___
> 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] erros x relações

[Lists]

> On Feb 11, 2015, at 19:35,  
>  wrote:
> 
> Não tiro a importância dos “fiscais”, entretanto esses devem ser comedidos em 
> suas interpelações e não ameaçar de reversão os dados editados sem contato 
> com a comunidade.
Ficou puto porque um semana trabalho esgotado, e também e cheia do coisas 
pequenos quebrados por caso desse editor iD. Chegou um limite para mim, e voce 
pode considerar que fui educado informando voce do problema e que realmente 
queria reverter tudo. Admito que o linguagem no recado em si talvez não muito 
educado, mas fiquei com raiva mesmo.

Eu poderia fica quieta e reverter tudo isso sem falhar, realmente entrou 
contato com voce para voce resolver concertar o que fui quebrado. Voce não 
queria olhar eles, então, eu começou preparar reverter.

Nao reverti porque chegou algum para concertar antes que tinha meu changeset de 
reversão pronto.

Se voce pelo menus mostrou que tentaria concertar, entender o trabalho outros 
coloque no projeto, eu poderia ajuda voce, mas como voce respondeu fiquei mais 
com raiva.

E jogando em mim “tem monte erros para voce concertar”, quando eu vejo voce 
como um dos criadores do erros, ficando como “favor limpa meu merda”. Eu quer 
mesmo como voce criar um mapa melhor, mas prefiro usar meu tempo editar onde 
falta dados, que concertando atreves outros usuários.___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] erros x relações

[Lists]

> On Feb 11, 2015, at 19:13,  
>  wrote:
> 
> Ainda temos um sério problema (ainda não resolvido) que é o roteamento pela 
> BR-101 para o NORTE passando por Vitória. O roteamento constatado pelo GPS e 
> também pelo OSRM abandona a BR-101 antes do trevo com a ES-060, passa pela 
> Rodovia do Sol, Vila Velha, Terceira Ponte, por dentro de Vitória para então 
> pegar novamente a BR-101 quase em Serra – ES.

Este caso que voce reclamando sobre roteamento puxando para ES-060 em vez de 
BR-101 e um coisa eu tentando investigar, como morando no local, quero que 
roteamento e certo. Infelizmente, se roteamento e cominho mais curto não dar 
evitar este problema como este trecho economiza quase 2 quilometro em 
distancia. Para concertar este precisamos entra máximo dado possível entre o 
trevo onde roteamento saindo BR-101, pelo ES-060 no Guarapari, Vila Velha e 
Vitoria, e ate trevo onde voltar no BR-101 no Serra.

Eu ja fiz muito para resolver este, mas preciso volta para casa para fazer 
levantamento no local. Eu não sei que dados falta neste regiao que pode 
resolver o roteamento, mas não aceito entra dados falso no mapa para resolver 
roteamento. Meu primeiro objetivo e entra mais detalhas nos dados existente da 
mapa. Se este não resolve precisamos olhar como os roteadores funciona.

Infelizmente, e realmente, en quanto o BR-101 ainda não e duplicado neste 
trecho acho não vai ter solução no problema do roteamento como o ES-060 tem 
velocidades de 110 e 80 entre Guarapari e Vila Velha, mas o BR-101 tem 60 e 80 
tudo trecho do estado.

Post-note: Eu deve ter mais tempo procura solução este problema de roteamento 
entre Guarapari e Vitoria se não preciso corre atras relações quebrados e 
corrige-los.___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] erros x relações

[Lists]

> On Feb 11, 2015, at 18:14,  
>  wrote:
> 
> em que pese as diferenças entre o JOSM e o ID, muitas das vezes prefiro o ID 
> dado a praticidade inserida para incluir restrições de manobra que como você 
> bem sabe poucos empregam. Prefiro o ID também para alinhar as vias.
Que pessoas nao incluindo restrições de manobra talvez não e por caso do 
editor, mas por falta do dados. Eu não faço restrições de manobra porque 
parecendo certo, eu faço porque tem evidencia de existência. Quando descobre 
que roteamento dar errado por falta do um restriction=no_left_turn eu 
inclui-lo, se roteamento dar errado por falta do oneway=yes, incluindo também. 
Falta do informação infelizmente dar falta no banco dados, e quando obter este 
informação incluímos.

Eu acho um desculpa besteiro dizer que “pode quebrar algum dados para mapa fica 
melhor”. Não devemos quebra dados, e se quebramos sem querer, concertamos. Se 
eu causando danos me ponta a onde e eu vou tenta resolver. O resposta voce me 
deu me dar raiva (meu dados mais importante que seu?) Eu postei para voce que 
voce quebrei dados que eu trabalhei uma semana fazer. Voce respondeu que 
concertar eles vai interfere com seu dia de trabalho.

Eu cansada gastar horas e horas para concertar que pessoas quebrando, e quando 
eles não mostrando nenhuma vontade corrigir o que quebrando eu ficar com 
vontade a reverter tudo eles fazendo. Talvez fui bom que for voce que botei o 
ultimo goto neste copo cheia, e não um noveta que nunca mais vai contribuir. Eu 
sei que mesmo se brigamos neste assunto voce como eu vou continuar contribuir.

Meu raiva e porque vez e vez ver muito trabalho esgotado porque pessoas 
tentando resolver um coisa sem verificar que não quebrando outro. Se a mapa 
fosse seu projeto sozinho voce poderia priorizar resolver um coisa cada vez, 
mas somos um comunidade grande.

Muito vezes quando ver estes relações restriction=no_u_turn pontando de volto 
no mesmo rua, ficando com vontade apagar todos restriction=no_u_turn, porque 
realmente e mais fácil adicionar os poucos que certo denovo que verificar cada 
um deles para apagar o que e errado, mas não faço isso por o comunidade. Em vez 
usando horas verificar cada um poderia apaga todos em 2 minutos, ne? ___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] erros x relações

[Lists]

Marcio

E bom voce quer ajuda melhora a mapa, mas favor seja home concertar o que voce 
quebrando. Fiquei muito com raiva vendo que relações que fiz semana passado 
quebrado em pouco tempo.

Eu pode mencionar que sim monitorando tudo edições no Espirito Santo, e usando 
muito tempo para verificar o que acontecendo na mapa.

Concordo que a mapa tem muito que pode melhorar, e trabalhando bastante para 
melhora-lo

Mas gastando muito do meu tempo concertar edições, principalmente relações 
criados do outros usuários, e que dar mais trabalho e um pouco usuários muito 
ativos, incluindo voce, que infelizmente introduzindo muitos relações errados.

Tudo este discussão começou quando viu meu trabalho do semana passado quebrado 
por voce e so quer que voce concerta o que quebrou

To cansada de estes poucos usuários dando tao muito problemas, e tem vontade 
reverter todos os chagastes  deles com relações.

Estes usuarios tem algum coisas em comum.

Principalmente eles editando com o editor iD, que um grande part do comunidade 
do OSM, não somente no Brasil comentando criando muitos erros e problemas com 
relações

Também um grande parte deles chegou do TrackSource, e levantando um cultura do 
objetos errados dai.

Aun Johnsen

> On Feb 11, 2015, at 16:53,  
>  wrote:
> 
> Amigos,
> nesse fim de ano rodei mais de 2000 km pelo Espírito Santo e me surpreendi 
> com a quantidade de erros que identifiquei no mapa OSM.
>  
> Fiz o seguinte trajeto cujos tracklogs já foram enviados para a base OSM:
>  
> Rio de Janeiro – RJ / Saquarema – RJ / Conceição da Barra – ES / São Mateus – 
> ES / Nova Venécia – ES / Barra de São Francisco – ES / Ecoporanga – ES / Riod 
> e Janeiro – RJ
>  
> Infelizmente o roteamento pelo Espírito Santo encontrava-se bastante 
> comprometido por desalinhamentos significativos de rodovias, sentidos de mão 
> invertidos, ausência de trevos e rotatórias, ausência de pistas duplas onde 
> essas existem, ausência de restrições de manobras, ausência de acessos, etc.
>  
> Tendo anotado todas as necessárias correções venho gradativamente corrigido o 
> mapa no Espírito Santo e estou sendo surpreendido com questionamentos sobre 
> quebra de relações com ameaça de reversão do trabalho por mim realizado.
>  
> Gostaria de saber do grupo se relações de rodovias secundárias são 
> prioritárias em se comparando com erros de percurso nessas rodovias.
>  
> []s
> Marcio
> ___
> 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] Tag para lojas de bolos

[Lists]

shop=bakery e shop=confectionary vender para leva fora, amenity=cafe ou similar 
vender para consumo no local. Se a loja somente vender para leva fora uso 
somente shop=*, se loja vender somente para consumo no local uso somente 
amenity=cafe, se a loja oferecendo os duas serviços uso ambos.

e de novo:
shop=bakery fabricando no local
shop=confectionary fabricando fora do local

Aun Johnsen

> On Feb 8, 2015, at 12:52, Alexandre Magno Brito de Medeiros 
>  wrote:
> 
> Se eu não dissesse o nome, ficaria ainda menos claro.
> 
> - Essas lojas são especializadas em bolo "popular", então não é exatamente o 
> tipo 1.
> - O bolo é fabricado lá mesmo, então não é o tipo 2.
> 
> Mas sim, é possível que existam outros produtos nas prateleiras. Só que não 
> me lembro de ter. Nem me lembro de ter cadeiras para os clientes consumirem 
> os produtos ali mesmo, na hora.
> 
> Alexandre Magno
> 
> Em 8 de fevereiro de 2015 12:29, Lists  <mailto:li...@gimnechiske.org>> escreveu:
> Alexandre: Este e um comercial?
> 
> Eu vejo duas tipas diferentes em princípio.
> 1) Um loja que também fabricando as bolos = shop=bakery
> 2) Um loja que vende bolos prefabricado (seja fabricado no outro lugar) = 
> shop=confectionary
> 
> shop=bakery nao nesesariamente vender pao, e as vezes (maioria que conheço) 
> pode ser combinado com amenity=cafe ou similar como eles tem um cafeteira ou 
> lanchonete.
> 
> Aun Johnsen
> 
>> On Feb 8, 2015, at 12:21, Alexandre Magno Brito de Medeiros 
>> mailto:alexandre@gmail.com>> wrote:
>> 
>> Aqui em Natal tem várias "Casa do Bolo". Não atentei para existência de 
>> concorrentes, ou se são de donos diferentes com um nome genérico. São bolos 
>> comuns e baratos. Sem ser confeitados ou necessariamente grandes. Pelo 
>> contrário. Não só de ovos. Tem de laranja, bolo preto, bolo da moça, bolo da 
>> moça, bolo de macaxeira, e uma infinidades de outros tipos dos quais não me 
>> lembro agora. Não acho que isso seja padaria ou confeitaria.
>> 
>> Alexandre Magno
> ___
> 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] Tag para lojas de bolos

[Lists]

Alexandre: Este e um comercial?

Eu vejo duas tipas diferentes em princípio.
1) Um loja que também fabricando as bolos = shop=bakery
2) Um loja que vende bolos prefabricado (seja fabricado no outro lugar) = 
shop=confectionary

shop=bakery nao nesesariamente vender pao, e as vezes (maioria que conheço) 
pode ser combinado com amenity=cafe ou similar como eles tem um cafeteira ou 
lanchonete.

Aun Johnsen

> On Feb 8, 2015, at 12:21, Alexandre Magno Brito de Medeiros 
>  wrote:
> 
> Aqui em Natal tem várias "Casa do Bolo". Não atentei para existência de 
> concorrentes, ou se são de donos diferentes com um nome genérico. São bolos 
> comuns e baratos. Sem ser confeitados ou necessariamente grandes. Pelo 
> contrário. Não só de ovos. Tem de laranja, bolo preto, bolo da moça, bolo da 
> moça, bolo de macaxeira, e uma infinidades de outros tipos dos quais não me 
> lembro agora. Não acho que isso seja padaria ou confeitaria.
> 
> Alexandre Magno
> 
> Em 8 de fevereiro de 2015 09:13, Gerald Weber  > escreveu:
> Eu estava usando shop=bakery, mas não é muito adequada pois não vende pão. A 
> tag shop=confectionery não é para confeitarias, mas sim loja de doces.
> 
> Da wikipedia: Baker, a person who produces baked goods
> 
> Veja que o termo não tem a ver com pão, mas sim com produzir produtos assados 
> num forno.
> 
> Bakery não é à rigor um lugar onde se faz pão, ao contrário do que implica o 
> termo padaria (ou o horroroso panificadora) em português. 
> 
> Eu deixaria bakery e colocaria uma note ou description dando mais detalhes.
> 
> abraço
> 
> Gerald
> 
> 
> ___
> 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] Metodologia de grupos de trabalho

[Lists]

Vitor,

Temos paginas das Rodovias Federais e Estaduais, os Federais tem um pagina 
principal mas um por cada estado, não sei que tanto eles preciso atualização. 
Também os Rodovias Estaduais tem um pagina por cada estado, terminei atualizar 
do Espirito Santo.

Eu acho o grupo das Rodovias preciso um pagina próprio pra grupo, estes paginas 
que tem pode ser um comunicação para o comunidade

Aun Johnsen

> On Feb 6, 2015, at 16:36, Vitor George  wrote:
> 
> Muito legal, Alexandre.
> 
> Acho que ter uma área de notícias para cada grupo vai tornar o wiki mais 
> difícil de atualizar. Penso que cada grupo poderia decidir como organizar a 
> sua informação, mas que pelo menos informe como um mapeador pode participar, 
> qual a qualidade dos dados e quando ela foi medida.
> 
> O Aun comentou do grupo de trabalho de rodovias, há alguma página do wiki 
> para isso?
> 
> 
> 2015-02-04 16:47 GMT-02:00 Alexandre Magno Brito de Medeiros 
> mailto:alexandre@gmail.com>>:
> Pronto, esta é minha proposta inicial de modelo de página de grupo de 
> trabalho: Brasil/Grupos_de_trabalho/Rascunho 
> .
> 
> Alexandre Magno
> 
> Em 4 de fevereiro de 2015 14:54, Alexandre Magno Brito de Medeiros 
> mailto:alexandre@gmail.com>> escreveu:
> O que imagino seria assim:
> Brasil/Grupos_de_trabalho/Rascunho#Mantenedores 
> 
> 
> Falta trabalhar o resto dessa proposta de modelo de página. Vou editando 
> enquanto ninguém responde. Avisarei quando tiver um todo.
> 
> Alexandre Magno
> 
> 
> ___
> 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] Situação das traduções

[Lists]

Vitor

To vendo no wiki que Merkaator e 1000% traducido, mil porcento? bom trabalho!

Aun Johnsen

> On Feb 5, 2015, at 18:58, Vitor George  wrote:
> 
> Pessoal,
> 
> Há algum tempo 
> 
>  comecei a mandar na lista de discussão talk-br 
>  informes sobre a situação 
> da tradução ao português brasileiro das ferramentas do OpenStreetMap.
> 
> Agora não consigo mais mandar estes informes com frequência, e coloquei-o no 
> wiki para que qualquer pessoa possa ajudar no monitoramento:
> 
> WikiProject_Brazil/Traduções 
> 
> Gostaria que a comunidade brasileira começasse a se organizar em grupos de 
> trabalho, que ficariam responsáveis pelas atividades mínimas de organização 
> de esforços direcionados.
> 
> Um grupo de trabalho de traduções poderia ser um primeiro passo. Caso alguém 
> se interesse manter a informação do wiki atualizada, ao menos quinzenalmente, 
> vá em frente e divulgue novidades na lista, fórum e demais canais da 
> comunidade. Eu posso ajudar.
> 
> Abraço,
> Vitor
> ___
> 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] Relation:boundary

[Lists]

admin_center pode indicar prioridade em indexar, mas não da muito diferencia 
para renderizar. Por exemplo voce quer indexar ruas num município, voce quer 
todos os ruas em ordem alfabético no cidade cede do município primeiro, depois 
cada outro cidade/vila/distrito em ordem alfabético, com os ruas em ordem 
alfabético. No este caso admin_center vai te indicar onde começar este 
registro. Sem admin_center voce pode tenta combinar pelo nome, mas este também 
pode criar duvidas, não em tudo casos o admin_center tem mesmo nome como 
município, e as vezes pode ter mais que um ocorrência da nome dentro o 
município, por exemplo pode ter distrito e subdistrito com mesmo nome.

Em caso do estado, nenhuma tem capital com mesmo nome como estado.

Aun Johnsen

> On Feb 4, 2015, at 21:12, Vítor Rodrigo Dias  wrote:
> 
> O Nelson disse que "não é obrigatório, mas é bom ter" admin_centre. Pelo que 
> entendi, o admin_centre é importante no roteamento do renderizador usado pelo 
> Marcio. Sendo assim, creio que podemos adotar oficialmente o admin_centre 
> como padrão para as relações de municípios e distritos.
> 
> Em 4 de fevereiro de 2015 21:59,  > escreveu:
> Nelson,
> sem duvida o Brasil é grande e falta muita coisa para arrumar. Até me 
> comprometo a auxiliar nessa empreitada, mas identifico de suma importância 
> que cheguemos a um consenso do que deve ser inserido e o que não deve. Com 
> isso estabelecemos um padrão a ser seguido por todos aqueles que desejarem 
> ajudar.
> 
> -Mensagem Original- From: Nelson A. de Oliveira
> Sent: Wednesday, February 4, 2015 9:46 PM
> To: OpenStreetMap no Brasil
> Subject: Re: [Talk-br] Relation:boundary
> 
> 2015-02-04 21:40 GMT-02:00   >:
> Nelson,
> agregaria para cidade o admin_centre se ela for a sede do estado ou
> município. Existem inúmeras cidades dentro de um estado e/ou município e, na
> minha opinião, tem de existir um diferenciador para elas.
> 
> Isso. Mas essa parte já faz parte dos membros da relação.
> A relação em si só precisa ter aquelas tags que eu falei anteriormente.
> 
> Nos membros da relação só é obritagatório os caminhos externos (outer).
> admin_centre não é obrigatório mas é bom ter.
> Acho que todos aqui que arrumam os limites acabam colocando o admin_centre.
> 
> O problema é que o Brasil é grande e falta muita coisa pra arrumar.
> 
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-br 
> 
> 
> 
> 
> -- 
> Vítor Rodrigo Dias
> Revisor de textos
> Tradutor port/ing/port e port/esp/port
> Telefone: (31) 7360-9421 - TIM
> ___
> 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] Relation:boundary

[Lists]

O que valor deve usar no flag=?

um base/64 do png da bandeira?

um link p commons.wikimedia.org  da bandeira em 
png ou svg?


Aun Johnsen

> On Feb 4, 2015, at 21:11, Tarcisio Oliveira  wrote:
> 
> type=boundary
> boundary=administrative
> admin_level=8
> name=Cidade
> place=city|town|village
> population=
> wikipedia=pt:
> 
> admin_center=(sobre a cidade)
> 
> 
> Esse é o conjunto de tags que costumo aplicar às relações, sendo que tem 
> outras tags que foram sugeridos pelo Fernando Trebien em uma época remota, 
> que não estão ai como:
> website=
> name:pt|en|ru|de|it
> flag=
> 
> 
> On 04-02-2015 20:59, thunder...@gpsinfo.com.br wrote:
>> Nelson,
>> sem duvida o Brasil é grande e falta muita coisa para arrumar. Até me 
>> comprometo a auxiliar nessa empreitada, mas identifico de suma importância 
>> que cheguemos a um consenso do que deve ser inserido e o que não deve. Com 
>> isso estabelecemos um padrão a ser seguido por todos aqueles que desejarem 
>> ajudar.
>> 
>> -Mensagem Original- From: Nelson A. de Oliveira
>> Sent: Wednesday, February 4, 2015 9:46 PM
>> To: OpenStreetMap no Brasil
>> Subject: Re: [Talk-br] Relation:boundary
>> 
>> 2015-02-04 21:40 GMT-02:00  :
>>> Nelson,
>>> agregaria para cidade o admin_centre se ela for a sede do estado ou
>>> município. Existem inúmeras cidades dentro de um estado e/ou município e, na
>>> minha opinião, tem de existir um diferenciador para elas.
>> 
>> Isso. Mas essa parte já faz parte dos membros da relação.
>> A relação em si só precisa ter aquelas tags que eu falei anteriormente.
>> 
>> Nos membros da relação só é obritagatório os caminhos externos (outer).
>> admin_centre não é obrigatório mas é bom ter.
>> Acho que todos aqui que arrumam os limites acabam colocando o admin_centre.
>> 
>> O problema é que o Brasil é grande e falta muita coisa pra arrumar.
>> 
>> 
>> ___
>> 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] Relation:boundary

[Lists]

> On Feb 4, 2015, at 20:40,  
>  wrote:
> Nosso amigo Aun Johnsen acabou de citar aqui:
> > Nao use ref=(UF), melhor usar short_name=(UF)
> > ref pode ser codigo IBGE do estado, ou algum coisas similar, mas realmente 
> > não faz sentido.
>  
> Só a titulo de exemplo essa TAG REF=(UF) está presente na formatação do 
> boundary do Espírito Santo em http://www.openstreetmap.org/relation/54882 
> 
>  
> É erro? Creio que não. Atribuo a isso a falta de um padrão a ser aplicado 
> para o Brasil.

Pode ser eu mesmo que coloquei neste relação, for antes que sabie uso e 
rendericao do short_name, no meu opinião, todos ocorrências de ref=(UF) pode 
ser retirado dos relações dos estados.

Aun

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

Re: [Talk-br] Relation:boundary

[Lists]

Nao use ref=(UF), melhor usar short_name=(UF)

ref pode ser codigo IBGE do estado, ou algum coisas similar, mas realmente não 
faz sentido.

Aun Johnsen

> On Feb 4, 2015, at 19:21,  
>  wrote:
> 
> Amigos,
> minha ponderação se deve ao fato de falta de um padrão a ser aplicado por 
> todos os editores que estão alterando boundarys.
>  
> As seguintes TAGs estão sendo empregadas por uns e por outros não:
>  
> place: state
> ref: (UF do estado)
> type: boundary
> boundary: administrative
> addr: state = nome do estado
> addr: state_code = UF do estado
> short_name= UF do estado
> etc
>  
> Confesso que nem sei se existe redundância no emprego dessas TAGs, entretanto 
> estão sendo empregadas aleatoriamente em muitas configurações de boundarys.
>  
> Quanto a falta do admin_centre o renderizador passou a indexar para o centro 
> geométrico do município e não para a cidade sede.
>  
> Confesso que ainda não identifiquei uma padronização a ser aplicada no 
> Brasil. A única matéria que encontrei a respeito está em 
> http://wiki.openstreetmap.org/wiki/Relation:boundary 
> 
>  
> []s
> Marcio
>  
>  
>  
>  
> From: Blademir 
> Sent: Wednesday, February 4, 2015 7:54 PM
> To: talk-br@openstreetmap.org 
> Subject: Re: [Talk-br] Relation:boundary
>  
> Estou trabalhando em algumas boundarys municipais, que estao sem a definição 
> outer na relação. E sempre adiciono a admin_centre a elas. Nas ultimas que 
> editei estao no Norte do eatado de São Paulo, e no Brasil ainda temos muitas 
> divisas para editar.
> 
> --- Mensagem Original ---
> 
> De: thunder...@gpsinfo.com.br
> Enviado: 4 de fevereiro de 2015 18:36
> Para: talk-br@openstreetmap.org
> Assunto: [Talk-br] Relation:boundary
> 
> Amigos,
> na renderização que fazemos identificamos que estamos perdendo indexações de 
> cidades porque simplesmente algumas não são indexadas para o município ou 
> para o estado.a que pertencem.
>  
> Estamos trabalhando na identificação de uma saída a nível renderizador, 
> entretanto identificamos que nos últimos meses muitos editores estão 
> alterando configurações de boundarys e não está ocorrendo um padrão nacional 
> talvez por falta desse.
>  
> A título de exemplo vejamos o município de Rio Grande, RS
>  
> https://www.openstreetmap.org/relation/242762 
> 
>  
> A cidade Rio Grande ( https://www.openstreetmap.org/node/406093463 
>  ) está sem relação 
> (admin_centre) com o boundary do município.
>  
> Esse foi só um exemplo, entretanto identificamos muitos municípios, 
> especialmente no Rio Grande do Sul, dessa forma.
>  
> []s
> Marcio
> 
> ___
> 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] Prioridades em rodovias com mais de uma ref=

[Lists]

Claiton,

Voce tem exemplo onde BR-287 não passa junto com RSC-287, ou RSC-287 não junto 
com BR-287? Pelo que eu consegui ver, os RSC e BR mesmo. Caso similar no Minas 
Gerais onde MGC e mesmo BR.

Pelo que conheço, este somente e caso nos estados Rio Grande do Sul e Minas 
Gerais.

Tem no Espirito Santo o BR-484 e o ES-484 que pelo maioria do trecho e mesmo, 
mas tem desvia diferente algum lugares, e também caso com BR-482 e ES-482. Tem 
tempo não visitei estes rodovias pessoalmente, mas se lembro certo, os placas 
tem BR-xxx, então, deve ser etiquetada com prioridade a BR, se caso contrario 
deve usar o estadual.

Aun Johnsen

> On Feb 3, 2015, at 10:21, Claiton Neisse  wrote:
> 
> Eu penso que o "que vem primeiro" deveria depender de quem administra a via. 
> Se uma rodovia federal coincide com uma rodovia administrada por um estado da 
> federação, a numeração do estado deveria vir antes. Caso contrário, a 
> numeração federal viria primeiro.
> 
> Ou seja, o primeiro da fila na tag ref, deveria ser quem administra a rodovia 
> de fato.
> 
> Eu concordo que, não é preciso colocar a tag ref em cada membro de uma 
> relação. Mas, aí surge uma dúvida.
> 
> Tomemos uma rodovia administrada por um estado e que coincida com uma rodovia 
> federal, em um determinado trecho. Cria-se uma relação para cada uma das 
> rodovias. Se, no trecho em que as rodovias coincidem, não colocarmos a tag 
> ref, como uma aplicação qualquer, que utilize os dados, vai decidir quem 
> administra o trecho coincidente? No trecho coincidente, acredito que cabe o 
> uso da ref.
> 
> Esse é o caso da rodovia RSC-287, no Rio Grande do Sul. A RSC-287 é uma 
> rodovia estadual onde toda a sua extensão coincide com parte da rodovia 
> federal BR-287. Daí, uma aplicação que renderize esse trecho como BR-287 (e 
> não como RSC-287) não é realista, porque é uma rodovia estadual e não federal.
> 
> 
> 
> Atenciosamente,
> 
> Claiton Neisse
> 55 8147 1030
> 
> Em 1 de fevereiro de 2015 23:41, Lists  <mailto:li...@gimnechiske.org>> escreveu:
> Vitor
> 
> Como os rodovias faz parte do relações, não e necessário com ref= no cada 
> trecho das rodovias. Os refs deve ser renderizados por importância nos mapas 
> direito da relação.
> 
> Em caso nao, os federais primeiro, começando com numeração menor, e depois os 
> estaduais, também começando com numeração menor.
> 
> Por exemplo (nao sei se e um exemplo verdadeiro), onde ha BR-040, BR-116 e 
> RJ-194 juntos, o ref pode ser etiquetado ref=BR-040;BR-116;RJ-194
> 
> No meu opinião, fica meia bagunçado fazendo isso no cada trecho, as vezes o 
> renderizador vai tentar render o ref no pontes pequenas sobre córregos, e a 
> mapa pode fica meia poluído com refs.
> 
> Aun Johnsen
> 
> > On Feb 1, 2015, at 21:27, Vítor Rodrigo Dias  > <mailto:vitor.d...@gmail.com>> wrote:
> >
> > Pessoal,
> >
> > Uma dúvida me veio à cabeça. Em rodovias que se sobrepõem, qual a ref= que 
> > vem antes? Tenho utilizado por padrão, em casos de rodovias de redes 
> > (network=) diferentes, a rodovia nacional primeiro, mas não tenho certeza 
> > se é o mais correto a se fazer.
> >
> > Abraços!
> > --
> > Vítor Rodrigo Dias
> > Revisor de textos
> > Tradutor port/ing/port e port/esp/port
> > Telefone: (31) 7360-9421 - TIM
> > ___
> > Talk-br mailing list
> > Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
> > https://lists.openstreetmap.org/listinfo/talk-br 
> > <https://lists.openstreetmap.org/listinfo/talk-br>
> 
> 
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org <mailto:Talk-br@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/talk-br 
> <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] BR-116 split and cleanup

[Lists]

Paul

There is another relation that have the same problem in terms of members and 
versions, that is BR-101 (http://www.openstreetmap.org/relation/53556 
). These two and many other 
Brazilian highways could be split according to operator, as many of these are 
privately maintained on contracts, where the maintaining operator have the 
right to charge toll fee.

At the moment I only have accurate information about one operator on BR-101, 
which operates on the stretch from the intersection to city of Mucuri, southern 
Bahia to the border between Espirito Santo and Rio de Janeiro.

Should one split the relation like this than one would need accurate 
information about which parts are operated by whom, and maybe even contract 
lengths.

Aun Johnsen

> On Feb 2, 2015, at 06:24, Paul Norman  wrote:
> 
> In the course of redacting some Tracksource data from the database, I came 
> across a relation for BR-116 which had about 2400 members and was version 
> 1000. A relation like this is a problem for various practical reasons such as 
> edit conflicts, getting history, and generally being impossible to work with.
> 
> I've split it up into four relations with a super-relation 
> (http://www.openstreetmap.org/relation/4551470), the standard method for 
> dealing with very long highways.
> 
> The parts are in the north (osm.org/relation/4551466), around Rio de Janerio 
> (osm.org/relation/4551467), around Sao Paulo (osm.org/relation/4551468) and 
> in the south (osm.org/relation/4551469).
> 
> The tracksource redaction is temporarily paused, but should now be much 
> faster as it doesn't have to work with that mega-relation.
> 
> Paul Norman
> For the OSMF Data Working Group
> 
> ___
> 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] Prioridades em rodovias com mais de uma ref=

[Lists]

Vitor

Como os rodovias faz parte do relações, não e necessário com ref= no cada 
trecho das rodovias. Os refs deve ser renderizados por importância nos mapas 
direito da relação.

Em caso nao, os federais primeiro, começando com numeração menor, e depois os 
estaduais, também começando com numeração menor.

Por exemplo (nao sei se e um exemplo verdadeiro), onde ha BR-040, BR-116 e 
RJ-194 juntos, o ref pode ser etiquetado ref=BR-040;BR-116;RJ-194

No meu opinião, fica meia bagunçado fazendo isso no cada trecho, as vezes o 
renderizador vai tentar render o ref no pontes pequenas sobre córregos, e a 
mapa pode fica meia poluído com refs.

Aun Johnsen

> On Feb 1, 2015, at 21:27, Vítor Rodrigo Dias  wrote:
> 
> Pessoal,
> 
> Uma dúvida me veio à cabeça. Em rodovias que se sobrepõem, qual a ref= que 
> vem antes? Tenho utilizado por padrão, em casos de rodovias de redes 
> (network=) diferentes, a rodovia nacional primeiro, mas não tenho certeza se 
> é o mais correto a se fazer.
> 
> Abraços!
> -- 
> Vítor Rodrigo Dias
> Revisor de textos
> Tradutor port/ing/port e port/esp/port
> Telefone: (31) 7360-9421 - TIM
> ___
> 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