Re: [Talk-br] Dúvida na identificação de Rodovias

[thundercel]

Prezado Jairo e amigos,

uma coisa é NOME de rodovia e outra REF (sigla) de rodovia. Existem campos 
específicos para inclusão de sigla e de nome.


Não podemos e não devemos colocar no campo  a sigla da rodovia porque 
em fazendo isso causaremos duplicidade de informação uma vez que os 
renderizadores extraem os dados da via na forma REF + NAME.


[]s
Marcio

-Mensagem Original- 
From: Jairo Duarte

Sent: Saturday, February 11, 2017 4:07 PM
To: talk-br@openstreetmap.org
Subject: [Talk-br] Dúvida na identificação de Rodovias

Boa tarde Srs.

Em 2013 o Deinfra de Santa Catarina alterou a codificação das estradas
estaduais, para se adequar as normas brasileiras de identificação de
rodovias.

Recentemente trechos destas rodovias para a ser identificados com nomes
de pessoas homenageadas por políticos locais.

Estou propondo uma discussão. Proponho que se adote o código para nomear
estas rodovias no OSM, pois é desta forma que as mesmas são conhecidas
pela população.

Por exemplo: A rodovia que liga Lages a São Joaquim é codificada como
SC-114(anteriormente SC-438), composta por 2 trechos denominados por
Enedino Batista Ribeiro e Prudente Cândido da Silva Filho. A mudança de
nome ocorre no Rio Lavatudo, que divide Painel e São Joaquim.
Para a população o nome da rodovia é SC-114 e acredito que é desta forma
que devemos mapear no OSM, até para não confundir as pessoas. Se tiveres
no interior e for perguntar pela denominação, ninguém saberá informar.
Até o relatório do Deinfra com as denominações, traz a identificação
pela codificação das rodovias, para que se possa melhor entender.
http://www.deinfra.sc.gov.br/jsp/relatorios_documentos/doc_rodoviario/download/denominacao_de_trechos_por_rodovias.pdf


Ademais, o mapa rodoviário fornecido pelo Deinfra traz somente a
codificação para identificação das rodovias catarinenses.
http://www.deinfra.sc.gov.br/jsp/informacoes_sociedade/downloadMapas.jsp

Acredito que o ideal é que façamos a identicação no mapa pelo nome pelo
qual a rodovia é reconhecida. Assim a rodovia litorânea em Santa
Catarina é reconhecida por BR-101(embora tenha também o nome de Rodovia
governador Mario Covas). Já em São Paulo a BR-116 é reconhecida por
Regis Bitencourt.
Nestes casos não tenho dúvida de que uma deva ser nomeada pelo nome e
outra pelo código.

Não adianta fazermos um mapa, que não seja reconhecido pela população.
Até o google maps e o bing vão estar mais próximos da realidade.

Estou propondo esta discussão, pois alguém chamou minha atenção para
alterações que fiz na identificação de rodovias na serra catarinense.

Até

Jairo

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



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


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

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

[thundercel]

-Mensagem Original- 
From: Nelson A. de Oliveira

O Marcio vai se lembrar que eu perguntei se por acaso ele não teria um
filho ou neto, justamente pelos nomes de familiares nas ruas.
Parece bem uma coisa de criança (não no sentido de mentalidade
infantil, mas de pessoa com pouca idade mesmo).


Ele me disse por telefone que não, ninguém emprega a maquina dele e por essa 
razão que deduzi, sendo ele com pouco experiência, que o PC foi invadido.


Por telefone expliquei e foi feito por ele a troca de senha do ID.

Até prova em contrário acredito na palavra dele quanto a nunca ter editado 
qualquer coisa no estado de SP.


Por fim solicito aquele que o rotulou de sabotador em mensagem direta que 
reflita um pouco mais antes de tecer um comentário desse tipo a um usuário 
que tem boas intenções.


[]s
Marcio 



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


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

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

[thundercel]

Amigos,
conversei ainda pouco por telefone com o Gabriel Vilela e o questionei sobre a 
inclusão do POI Chácara São Judas Tadeu, na cidade de Silveiras, SP e esse me 
afirmou que não foi ele quem incluiu esse POI.
O fiz entender que o POI foi incluído com o ID dele e se não fez é porque 
alguém invadiu sua conta.
De qualquer forma o orientei a trocar a senha de login no OSM e o ensinei a 
excluir o POI, o que foi feito por ele.
Ele comentou que até então nunca fez edições em SP e que só edita nos locais 
que bem conhece como Acre, Rondônia, Minas e Região serrana do RJ.
Na imagem abaixo a foto do Gabriel Vilela que ele emprega no Whats App

[]s
Marcio


---
Este email foi escaneado pelo Avast antivírus.
https://www.avast.com/antivirus
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

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

[thundercel]

Desconheço a fonte empregada pelo Google para incluir essa Chácara como vila 
e tampouco sei a fonte empregada pelo editor Gabriel para incluir a mesma 
chácara no OSM.


Pode ser evidente para você a copia do google, mas não o é para mim. Para 
mim é prudente antes de se acusar buscar respostas quanto a fonte de 
referencia empregada. Fiquei de perguntar a ele isso, a fonte que empregou.


Como citei anteriormente experimentei o nome da minha Rua errado e igual ao 
estampado no google. Não é por isso que poderia eu concluir que o editor que 
inseriu o nome da minha rua no OSM copiou o erro do google, pois afinal a 
placa na rua esta errada e deve ter sido essa a ser empregada pelo Google e 
pelo editor.


Devemos saber distinguir prova e indicio e lembrar que indicio não constitui 
prova no ordenamento jurídico.


-Mensagem Original- 
From: santamariense

Sent: Wednesday, December 14, 2016 12:48 AM
To: talk-br@openstreetmap.org
Subject: Re: [Talk-br]Possível cópia de nomes de ruas do Google

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

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



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


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

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

[thundercel]

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


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


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


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


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


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


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

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


[]s
Marcio

-Mensagem Original- 
From: santamariense

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

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

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



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


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

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

[thundercel]

Minha opinião:

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


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


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


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


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


[]s

Marcio



-Mensagem Original- 
From: Nelson A. de Oliveira

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Estranhamente essas ruas de cima tiveram os nomes removidos hoje.

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

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

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

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

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

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

O problema é que são quase 10 mil changesets.
Não dá para verificar um por um, além de ter duas questões
importantes: quais objetos possuem d

Re: [Talk-br] Rio Olympics – Tutorial para Importação de Edificações

[thundercel]

Alexandre, 
para resumir, o que regula direito autoral no Brasil, por enquanto, é a LEI que 
citei e por essa ninguém pode reproduzir obra sem a autorização expressa do 
autor.

Volto a afirmar: - o que vale, por enquanto no Brasil, é a lei e não a Creative 
Common, apesar dessa ultima ser muito empregada aqui.

Em caso do contraditório o que prevalece é a lei e isso não sou eu quem digo e 
sim os sites jurídicos, apesar que todos devem saber disso, mesmo os não 
advogados.

Como já citei o órgão que fornece a Creative Common não é órgão publico e a lei 
bem define quais órgãos públicos fornecem licença.

O dia em que a lei for revisada e nela inserida a figura do Creative Common 
será outra estória.

Muito interessante o filme abaixo onde o advogado Renato Opice Blum, presidente 
do Conselho de Tecnologia da Informação da Fecomércio/São Paulo, diz que não há 
jurisprudência que proteja os dados pessoais no mundo móvel. Hoje, quem dita as 
regras, são os desenvolvedores de conteúdo. Para ele "Sem lei no Brasil, termo 
de uso é a única proteção do usuário".
Veja em 
https://www.youtube.com/watch?v=k8_e8RnXZFE

From: Alexandre Magno Brito de Medeiros 
Sent: Friday, July 15, 2016 3:11 AM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]Rio Olympics – Tutorial para Importação de Edificações

Onde não se permite?


Em 15 de julho de 2016 00:14,  escreveu:


  [...] existem comentários interessantes sobre o assunto e que em especial 
retransmito abaixo: 

  [...] Não é imposto ao autor reclamar contra obras derivadas, porém, 
sentindo-se este lesado, é garantido o direito de assegurar a integridade de 
sua obra (Art. 24, IV). O que não se permite é que o autor abra mão deste 
direito. [...]




___
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] Rio Olympics – Tutorial para Importação de Edificações

[thundercel]

Wille,

o Creative Common colide em certos aspectos com a lei 9610/98 que regula os 
direitos autorais no Brasil e enquanto essa não for emendada ou revogada, 
juridicamente ela que vale.

Não tenho dúvida que essa antiga lei em vigor será alterada, mas até onde sei, 
ainda não foi porque o assunto, dentre outros, está vinculado ao marco da 
internet no Brasil, ainda em debate no Congresso.

De uma olhada em 
https://www.passeidireto.com/arquivo/11057458/direito-propriedade/30 que 
existem comentários interessantes sobre o assunto e que em especial retransmito 
abaixo:

“Importante lembrar que, mesmo com a licença adaptada, alguns direitos 
opcionais continuam colidindo com a Lei dos Direitos Autorais, é o caso da 
criação de obras derivadas.
Não é imposto ao autor reclamar contra obras derivadas, porém, sentindo-se este 
lesado, é garantido o direito de assegurar a integridade de sua obra (Art. 24, 
IV). O que não se permite é que o autor abra mão deste direito.
A atuação do Creative Commons se efetiva através de uma licença pública, que, 
vinculando a obra em rede mundial (internet), torna acessível a todos à maneira 
que a mesma foi concedida. O Creative Commons não tem validade jurídica. 
Além disto, o Creative Commons se abstém da responsabilidade de qualquer dano 
surgido em conexão com sua licença126.”
[]sMarcio
From: Wille 
Sent: Thursday, July 14, 2016 11:10 PM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br] Rio Olympics – Tutorial para Importação de Edificações

Márcio,

O Creative Commons, bem como outras licenças livres usadas pelo OSM e por 
softwares livres não contrariam, mas sim utilizam a lei de direitos autorais. A 
lei de direitos autorais automaticamente protege tudo o que criamos. O que as 
licenças fazem é dar algumas permissões para que as pessoas não precisem pedir 
autorização sempre que queiram usar algo. 

É quase a mesma coisa que um termo de uso, mas como as licenças são mais 
conhecidas, a comunicação é mais fácil.

wille

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

Re: [Talk-br] Rio Olympics – Tutorial para Importação de Edificações

[thundercel]

Alexandre me atualize, por gentileza:

Qual a lei brasileira que aprovou o Creative Common?

Minha pergunta se deve ao fato que até onde pesquisei o problema, alguns anos 
atrás para o site maparadar,  a LEI Nº 9.610, DE 19 DE FEVEREIRO DE 1998 ( 
http://www.planalto.gov.br/ccivil_03/leis/L9610.htm ), que regula o direito 
autoral no Brasil, não havia sido revogada e tampouco emendada.   

Na época que pesquisei fui informado por um amigo no Planalto que o assunto 
estava parado na Casa Civil do Governo e um outro amigo da área juridica 
recomendou empregar, por enquanto, “Termo de Uso” para a obra.

[]s
Marcio

From: Alexandre Magno Brito de Medeiros 
Sent: Thursday, July 14, 2016 8:16 PM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]Rio Olympics – Tutorial para Importação de Edificações

Marcio,

Como você desconhecia ou não lembrava da CC-BY-SA, foi ético mesmo. E também 
porque o autor podia estar desconsiderando que doara o material ao wiki do 
OpenStreetMap.

Noutro caso, é irrelevante pedir a autorização. Pelo contrário, muitas vezes, 
quem formaliza com licenças CC quer justamente evitar a aporrinhação de 
analisar e distribuir autorizações particulares.


Alexandre Magno


Em 8 de julho de 2016 11:37,  escreveu:

  Agradeço Arlindo, mas somente por questão ética pedi autorização ao Sergio.

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

Re: [Talk-br] Rio Olympics – Tutorial para Importação de Edificações

[thundercel]

Agradeço Arlindo, mas somente por questão ética pedi autorização ao Sergio.

[]s
Marcio



From: Arlindo Pereira 
Sent: Friday, July 8, 2016 11:26 AM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]Rio Olympics – Tutorial para Importação de Edificações

Marcio, 

creio que você possa divulgar sem problemas independentemente de autorização, 
uma vez que a licença do wiki do OSM é Creative Commons (CC-BY-SA). Mais 
detalhes em https://wiki.openstreetmap.org/wiki/Wiki_content_license.


[]s 
Arlindo Pereira

2016-07-08 9:17 GMT-03:00 :

  Bom dia Sergio.

  Parabéns pelo Tutorial.

  Você nos autoriza a reproduzir esse tutorial em nosso site Cocar, com os 
devidos créditos?

  []s
  Marcio

  From: Sérgio V. 
  Sent: Friday, July 8, 2016 8:57 AM
  To: talk-br@openstreetmap.org 
  Subject: [Talk-br] Rio Olympics – Tutorial para Importação de Edificações

  Bom dia pessoal.



  Tutorial para a importação de prédios no Rio de Janeiro está em:



  
https://wiki.openstreetmap.org/wiki/Rio_Olympics_%E2%80%93_Tutorial_para_Importa%C3%A7%C3%A3o_de_Edifica%C3%A7%C3%B5es






  Mais informações, contatar a comunidade:



  https://wiki.openstreetmap.org/wiki/Rio_Olympics_Mapping#Contact






  Saudações,



  - - - - - - - - - - - - - - - -

  Sérgio / user:smaprs


--
  ___
  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] Rio Olympics – Tutorial para Importação de Edificações

[thundercel]

Bom dia Sergio.

Parabéns pelo Tutorial.

Você nos autoriza a reproduzir esse tutorial em nosso site Cocar, com os 
devidos créditos?

[]s
Marcio

From: Sérgio V. 
Sent: Friday, July 8, 2016 8:57 AM
To: talk-br@openstreetmap.org 
Subject: [Talk-br] Rio Olympics – Tutorial para Importação de Edificações

Bom dia pessoal.



Tutorial para a importação de prédios no Rio de Janeiro está em:



https://wiki.openstreetmap.org/wiki/Rio_Olympics_%E2%80%93_Tutorial_para_Importa%C3%A7%C3%A3o_de_Edifica%C3%A7%C3%B5es






Mais informações, contatar a comunidade:



https://wiki.openstreetmap.org/wiki/Rio_Olympics_Mapping#Contact






Saudações,



- - - - - - - - - - - - - - - -

Sérgio / user:smaprs




___
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] name=Retorno

[thundercel]

Vou abrir um chamado no grupo do Mkgmap.

Quando eles alteraram a estrutura do renderizador distribuiram a alteração 
do style que começa assim:


# which may add info to a part of these highway=*_link roads:
# motorway_link, trunk_link, primary_link, secondary_link, tertiary_link

-Mensagem Original- 
From: Nelson A. de Oliveira

Sent: Tuesday, June 14, 2016 10:49 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] name=Retorno

2016-06-14 22:48 GMT-03:00 Nelson A. de Oliveira :

Estados Unidos tem 1257:
http://overpass-turbo.eu/s/gNE

Exemplo: http://overpass-turbo.eu/s/gNE


Errei no exemplo, mas só clicar em qualquer caminho do resultado que
dá pra ver as tags.

___
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] name=Retorno

[thundercel]

Não penso assim e também não interpreto assim.

na sua frase:

"Use destination=* together with highway=* on pieces of highway after
the position of the signpost or ground writing"

Omitiu o final dela que é: For details, see also the examples.
Nos exemplos cita-se somente lanes e não a highway como um todo.

Isso de se aplicar em somente lanes faz sentido para mim. A logica está em 
um condutor, que vai a um destino, se posicionar na faixa de pista que o 
conduzirá aquele destino. Dessa situação sai a função nos navegadores 
conhecida como "lane assistance".


Esse debate sobre destination ocorreu no ano passado, no grupo de 
desenvolvedores do Mkgmap. Por nossa solicitação eles fizeram com que também 
fossem reconhecidas as tags destination aplicadas em links primary, 
secundary e terciary, antes o Mkgmap só reconhecia até em links motorway e 
trunk.


Tenho curisidade em saber se é somente o Mkgmap que tem essa restrição. 
Outro renderizador reconhece a tag destination aplicada na highway?


-Mensagem Original- 
From: Nelson A. de Oliveira

Sent: Tuesday, June 14, 2016 9:59 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] name=Retorno

2016-06-14 21:53 GMT-03:00  :

nos exemplos só é empregada em LANE de motorway e não na motorway.


É o mesmo caso, Marcio.
destination:lanes é só uma especialização de destination, da mesma
forma para destination:forward, destination:backward, etc

Mas de toda forma, não existe limitação por tipo:
https://wiki.openstreetmap.org/wiki/Key:destination#Where_to_use.3F

"Use destination=* together with highway=* on pieces of highway after
the position of the signpost or ground writing"

Qualquer highway serve.

___
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] name=Retorno

[thundercel]

Complementando...

inclusive em https://wiki.openstreetmap.org/wiki/Lanes encontramos:

destination=* destination:lanes While the road specific key 
describes the direction of the highway by using the name of the city the 
highway is heading to, the destination:lanes allows tagging of cities when 
sign-posted for individual lanes. See destination=* for examples.


-Mensagem Original- 
From: thunder...@gpsinfo.com.br

Sent: Tuesday, June 14, 2016 9:53 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] name=Retorno

Então,
nos exemplos só é empregada em LANE de motorway e não na motorway.

Observe nos dois ultimos exemplos o emprego: destination:lanes

-Mensagem Original- 
From: Nelson A. de Oliveira

Sent: Tuesday, June 14, 2016 9:45 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] name=Retorno

2016-06-14 21:42 GMT-03:00  :

Se aplicada em highway o Mkgmap não reconhece.


Mas aí é um problema/limitação do mkgmap.
No OSM pode-se utilizar destination em qualquer tipo de rua.

Pode ver inclusive nos exemplos
https://wiki.openstreetmap.org/wiki/Key:destination#Examples que tem
motorway_link e motorway apenas (sem ser _link).

___
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] name=Retorno

[thundercel]

Então,
nos exemplos só é empregada em LANE de motorway e não na motorway.

Observe nos dois ultimos exemplos o emprego: destination:lanes

-Mensagem Original- 
From: Nelson A. de Oliveira

Sent: Tuesday, June 14, 2016 9:45 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] name=Retorno

2016-06-14 21:42 GMT-03:00  :

Se aplicada em highway o Mkgmap não reconhece.


Mas aí é um problema/limitação do mkgmap.
No OSM pode-se utilizar destination em qualquer tipo de rua.

Pode ver inclusive nos exemplos
https://wiki.openstreetmap.org/wiki/Key:destination#Examples que tem
motorway_link e motorway apenas (sem ser _link).

___
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] name=Retorno

[thundercel]

Nelson,
pelo que compreendi no grupo de desenvolvimento do Mkgmap ela só é suportada 
quando empregada em classe link_ e por isso que foi alterado o Mkgmap e o 
style para isso.


Em http://wiki.openstreetmap.org/wiki/Key:destination , nos exemplos podemos 
identificar que só é aplicada em links_  e também em lanes, pelo menos na 
Alemanha.


Se aplicada em highway o Mkgmap não reconhece.



-Mensagem Original- 
From: Nelson A. de Oliveira

Sent: Tuesday, June 14, 2016 9:28 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] name=Retorno

2016-06-14 20:53 GMT-03:00  :

Lembro que essa tag destination só pode ser implantada em vias de classe
link_*


Não.
"destination" pode ser usado em qualquer tipo de via.

___
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] name=Retorno

[thundercel]

Roger,
como ja citado anteriormente o retorno não deve ser incluído no campo name.

Solicitamos que, na medida do possível, abra para a via de retorno a tag 
destination e nela inclua retorno


Essa ação facilitará os renderizadores que reconhecem a tag destination e 
utilizam o nela escrito para instrução em voz de manobra nos navegadores.


Lembro que essa tag destination só pode ser implantada em vias de classe 
link_*


[]s
Marcio

-Mensagem Original- 
From: Roger C. Soares

Sent: Tuesday, June 14, 2016 6:37 PM
To: OSM talk-br
Subject: [Talk-br] name=Retorno

Só para confirmar, no OSM agente não nomeia retornos, acessos, etc,
certo? Posso remover names do tipo:
http://www.openstreetmap.org/way/214229462

Outra dúvida, para que serve colocar addr:street com o mesmo valor da
tag name em highways? Por exemplo:
http://www.openstreetmap.org/way/171470967

Atenciosamente,
Roger.


___
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] Votação: uso de boundary=administrative para meso/micro-regiões do IBGE

[thundercel]

CONCORDO

Concordo porque compreendo que limite administrativo (divisão 
administrativa) requer uma administração central e por essa razão não 
deveria ser empregado no Brasil para outros fins como os idealizados pelo 
IBGE.


A divisão do Brasil por regiões serve para outros fins estatísticos e não 
administrativos.


Antigamente, na divisão administrativa do Brasil, tínhamos a figura do 
território que foram incorporados a administração de estados. Hoje só temos 
o distrito federal, os estados, os municípios e os distritos.



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

Re: [Talk-br] Ruas sem nome

[thundercel]

Na minha opinião devemos sempre administrar nosso esforço analisando e 
empregando o binômio eficiência eficácia. Sabendo bem diferenciar o ótimo do 
bom.

De nada adianta a um piloto fazer excelentes pousos (eficiente) no aeródromo 
errado (ineficaz).

Defendo que o prioritário é o desenho da malha viária de forma a permitir que 
outros que não saibam desenhar possam agregar valor aquele desenho incluindo 
“alegorias e adereços”.

Se um utilizador sabe onde se encontra o ponto de partida, a ele vejo como mais 
importante conhecer como chegar ao destino e não a nomenclatura das vias que o 
levarão aquele destino.

O desenhando a via (BOM) deve ser sempre prioridade e a inclusão de 
nomenclatura das vias desenhadas (ÓTIMO) deve ser feito a posteriori e com 
tempo.

Voltaire disse:

O ótimo sempre foi inimigo do bom 

Avaliando o que isso quer dizer, poderíamos deduzir que qualquer coisa serve. 
Mas, não é isso. ‘Feito é melhor do que perfeito’ se encaixa  no mesmo conceito 
de  ‘O ótimo é inimigo do bom’.  Não quer dizer que a gente pode fazer as 
coisas de qualquer jeito, sem vontade e empenho em melhorar. Não é isso, 
definitivamente.

[]s
Marcio

From: Tarcisio Oliveira 
Sent: Wednesday, April 6, 2016 3:40 PM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br] Ruas sem nome

Pra mim depende de tempo e paciência que estou no momento.
Várias vezes quero fazer uma rua apenas e mas não estou com paciência, mas as 
vezes faço cidades inteiras, assim como as vezes coloco nome em uma rua ou 
outra, posso não colocar nome em nenhuma rua.
Penso que deixando a rua com o nós correto, sem zig-zag e sem nome já vai 
ajudar o próximo editor a colocar o nome na rua, assim como já vai ajudar o 
próximo editor a colocar a superfície da via e por aí vai.




Em 06-04-2016 15:27, Arlindo Pereira escreveu:

  Discordo porque tem que ficar alternando entre as camadas de satélite e do 
IBGE. Pode-se fazer por regiões pequenas, como bairros, primeiro traçar todas 
as vias, depois aplicar os nomes (ainda que no mesmo changeset). 

  []s
  Arlindo


  2016-04-06 15:16 GMT-03:00 Helio Cesar Tomio :

Lucas e Anor, muito obrigado. 
Vou rodar aqui e ver os resultados. 

Alexandre, respeito sua opinião em implementar aos poucos, mas discordo de 
deixar o nome pra depois qdo tem -se a informação do IBGE.
Pode ser feito junto com a edição da via, sem qq problema. 
Talvez pela minha formação de eng, não consigo conceber de outra forma. 
Um projeto de uma casa com apenas as linhas,  sem outras informações, ao 
meu ver é apenas um monte de rabiscos de nenhuma utilidade.
Assim penso de um mapa com apenas as linhas. 
Talvez seja um vício profissional.


___
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] O que houve com Fernando Trebien?

[thundercel]

Foi comigo também e o ultimo desentendimento que tive com ele se referia a 
minha edição do novo trevo em Porto Velho – RO quando tive a oportunidade de 
apresentar imagens extraídas por um helicóptero da FAB no novo Trevo 
comprovando que minha edição estava correta.

Depois que apresentei as fotos ele nada mais comentou e nunca mais o vi por 
aqui.

[]s
Marcio

From: Alexandre Magno Brito de Medeiros 
Sent: Sunday, December 13, 2015 10:45 PM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br] O que houve com Fernando Trebien?

Em 13 de dezembro de 2015 10:49, Arlindo Pereira 
 escreveu:

  Desistiu do projeto depois de discussões improdutivas na lista com outro 
mapeador aqui do Rio.



Não foi um mapeador do Rio de Janeiro. Foi comigo.


Em 13 de dezembro de 2015 10:54, Erick de Oliveira Leal 
 escreveu:

  Poxa, uma pena. Ele foi o que mais me ajudou quando entrei aqui.



A mim também. É uma pena que uma cabeça daquelas tenha resolvido uma coisa 
dessas.

2015-12-13 11:12 GMT-03:00 Arlindo Pereira :

  Também acho uma lástima. :(


Acreditem ou não: eu também!


Quem pesquisar, verá que foi ele quem me ensinou quase tudo que eu possa ter 
aprendido sobre mapeamento.


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] Issue no Github para o iD exibir mensagem alertando usuários de nomes copiados do Google

[thundercel]

Estamos aqui debatendo sobre “nomenclatura de vias” e não o desenho dessas.

Me alinho aqueles que aqui defendem que nomenclatura de via é de domínio 
público porque em não sendo não podemos nem extrair o nome da placa existente 
na esquina que é de propriedade da Prefeitura.

Me perdoe Magno, mas pelo menos no ordenamento jurídico brasileiro e 
internacional se faz necessário provar que foi copiado para que uma ação penal 
siga em frente. Coincidência de grafia em determinado nome de rua cria um 
indício, mas para que esse indício seja pesado se faz necessário a existência 
de outros no mesmo sentido.
Recentemente muito foi debatido nesse sentido na ação penal do mensalão e agora 
do petrolão.

Na minha interpretação indício isolado não caracteriza prova.

“Posto que os indícios não se pesam, e não se contam, não basta que apareçam em 
número plural; é indispensável que, examinados em conjunto, produzam a certeza 
moral sobre o fato investigado. Para tanto, devem ser graves, precisos, e 
concorrerem, harmonicamente, a indicar o mesmo fato” (Moura, Maria Thereza 
Rocha de Assis. A prova por indícios no processo penal. São Paulo: Saraiva, 
1994. p. 91).

Concordo que devemos defender o Projeto, mas na minha opinião devemos ter o 
cuidado para não permitir que ações restritivas, sejam novas ou reafirmação de 
antigas, acabem produzindo descontentamentos e evasão de colaboradores. Sem 
colaboradores o Projeto não tem futuro.

Como citei anteriormente, infelizmente estamos perdendo colaboradores devido a 
insistente fiscalização e interpelação de alguns a esses.

[]s
Marcio
From: Alexandre Magno Brito de Medeiros 
Sent: Friday, December 11, 2015 6:56 AM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]Issue no Github para o iD exibir mensagem alertando 
usuários de nomes copiados do Google

Entendo que não é necessário "provar" que foi copiado.

O OpenStreetMap não tem como defender-se judicialmente. Então é bem razoável 
adotar políticas de afastamento das "inseguranças". Assim, a mera "suspeita", 
corroborada por "indícios", torna-se suficiente.


O futuro de um projeto dessa dimensão não deve ser tratado como um rolar de 
dados. Se uma decisão judicial obrigar a lançar no esgoto um monte de 
contribuições válidas, ficamos todos como PALHAÇOS, tenhamos contribuído pouco 
ou muito. E mais uma vez "a gente egoísta" terá material para chamar de tolos 
aqueles que gratuitamente colaboram.


Alexandre Magno


Em 11 de dezembro de 2015 05:33, Peter Krauss  escreveu:



  Bom dia Marcio e Nelson,  
  exemplos são ótimos para todos aqui na Lista falarem a mesma língua ;-) 

  Por hora parece bom o  exemplo, mas ainda está  meio difícil de entender o 
que se passou: alguém poderia explicar quais são os "Redact Google-sourced 
names" deste exemplo?
  Qual o critério que se usa para taxar de "foi copiado" e, independente de 
cópia, porque haveria algum direito autorial envolvido nisso?


  PS: se falam em DWG, seriam não nomes mas linhas e polígonos copiados de uma 
base alheia... Se for isso, não parece ter nada haver com "copiar nomes"...

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

Re: [Talk-br] Issue no Github para o iD exibir mensagem alertando usuários de nomes copiados do Google

[thundercel]

Arlindo,

não sou contra o aviso proposto por você. Sou favorável a analisarmos melhor o 
objetivo, abrangência e operacionalidade.

Para alguns o aviso repetitivo pode incomodar, como já comentado aqui, e por 
isso seria interessante a aplicação de uma quantidade de edições por usuário 
onde ele não mais apareceria.

Outra situação é quanto ao editor, pelo que interpretei ele está sendo proposto 
para ser inserido no ID. E os outros editores? Muitos já se simpatizam mais com 
o JOSM.

Sem duvida devemos reafirmar a orientação de emprego das nomenclaturas tendo 
como referência os dados do IBGE com especial atenção aos dados por ele 
fornecidos pois algumas informações estão desatualizadas.

Quanto ao Google Maps nem considero porque a experiência já nos demonstrou que 
ele contem muito mais erros que o IBGE. Temos identificado isso diariamente 
plotando radares em nosso território empregando a API do Google.

[]s
Marcio

From: Arlindo Pereira 
Sent: Friday, December 11, 2015 10:00 AM
To: OSM talk-br 
Subject: Re: [Talk-br]Issue no Github para o iD exibir mensagem alertando 
usuários de nomes copiados do Google

Marcio,

de fato, nomes de ruas não são passíveis de copyright, mas o mapa de terceiros 
o é. De fato, uma única grafia copiada seria um indício muito leve, mais 
provável coincidência, mas com dezenas, centenas, milhares de dados com a 
grafia errada inseridos tanto no nosso mapa, quanto no de terceiros, já fica 
mais difícil de justificar.

E, de novo, não há mais motivo para se copiar nomes de ruas do Google Maps ou 
de onde seja quando podemos copiar nomes de ruas do mapa do IBGE, que inclusive 
já fica embutido nos editores. Precisamos apenas comunicar isso melhor, pois 
não é um fato que fique evidente para os editores novatos (assim como diversas 
outras questões).

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

Re: [Talk-br] Importação de aeródromos - ANAC

[thundercel]

Na minha opinião SIM uma vez que o Diário Oficial reproduz a portaria. 

O Diário Oficial é público e até onde sei não existe restrição a reprodução 
parcial ou total dos dados nele contidos.
. 
From: Alexandre Magno Brito de Medeiros 
Sent: Friday, December 11, 2015 2:34 PM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]Importação de aeródromos - ANAC

Obrigado.


Já que o ROTAER não pode, esses documentos de portarias poderiam ser fontes de 
dados lícitas?


Alexandre Magno

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

Re: [Talk-br] Importação de aeródromos - ANAC

[thundercel]

A permissão de uso dos dados contidos no ROTAER está explícita em sua 
introdução:

É PROIBIDA A REPRODUÇÃO PARCIAL OU TOTAL DESTA PUBLICAÇÃO.

Creio que não existe duvida quanto a reprodução dos dados nele contidos.

O diário oficial não publica algumas informações de aeródromos constantes no 
ROTAER. 

Enquanto eu trabalhava na área somente a Jeppesen era credenciada a digitalizar 
e divulgar todas as informações contidas no ROTAER. Acredito que continua assim 
uma vez que desconheço outra empresa que divulgue informações aeronáuticas 
digitalizadas.

Sempre fui muito crítico a essa situação de dependência tecnológica. As 
empresas que operam aviões modernos ficam (ou ficavam se mudou) dependentes da 
Jeppesen porque só ela fornece (ou fornecia) os cartões a serem inseridos no 
sistema do avião.

Já chegou ao meu conhecimento que ilegalmente estão produzindo mapas para serem 
empregados no aerodesporto com aparelhos GNSS não aeronáuticos. Até a aviação 
privada que emprega aeronaves menores estão empregando.

Um dia o autor desses mapas leva uma pedrada indenizatória. Só espero que o OSM 
não auxilie o trabalho dele.

From: Alexandre Magno Brito de Medeiros 
Sent: Friday, December 11, 2015 12:42 PM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]Importação de aeródromos - ANAC

Então quer dizer que no Diário Oficial sai apenas um subconjunto do ROTAER...

Sendo assim, não podemos inferir pelo Diário Oficial a permissão de uso para 
todo o ROTAER.


Em 11 de dezembro de 2015 11:37,  escreveu:


  Na minha opinião podemos divulgar a existência do aeródromo como divulgado no 
Diário Oficial, mas outras informações a respeito dele devemos melhor analisar 
quais divulgar de forma que evitemos o emprego do OSM por pilotos que 
descumprem as regras internacionais de navegação aérea.

  Um dado inserido de forma errada pode ser um fator contribuinte de um 
acidente aéreo e causar problemas para o OSM.

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

Re: [Talk-br] Importação de aeródromos - ANAC

[thundercel]

http://www2.anac.gov.br/biblioteca/portarias/2015/PA2015-0168.pdf

From: Alexandre Magno Brito de Medeiros 
Sent: Friday, December 11, 2015 2:00 PM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]Importação de aeródromos - ANAC

Alguém tem exemplo de um Diário Oficial com informação aeródromo?


Alexandre Magno

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

Re: [Talk-br] Importação de aeródromos - ANAC

[thundercel]

Alexandre,
o único dado da portaria que não é citado no diário oficial são as coordenadas 
geográficas do aeródromo.

Essas coordenadas, apesar de não citadas, correspondem ao centro geométrico da 
pista de movimentos e não as instalações do aeródromo.

Coordenadas se extraem em qualquer referência lícita e por isso não considero 
que as existentes na portaria não sejam de domínio público e nem tem sentido 
ser já que em qualquer imagem satélite se pode extraí-las.

Em uma analise rápida acredito que o descrito em 
http://wiki.openstreetmap.org/wiki/Aviation é válido.

Devemos ter especial atenção ao ali descrito que se segue:

Things Not to Map
We do not map things that are not observable on the ground. For example: 

  a.. VFR aerodrome traffic patterns 
  b.. SIDs and STARs (departure and arrival patterns for IFR) 
  c.. airspace (control zones, no-fly zones, TMZes, airspaces A-G, FIRs, 
MATZes, restricted/prohibited/danger areas) 
  d.. airways, flight paths, and flight routes 
  e.. reporting points with no visible ground reference
Mapping these objects is strongly discouraged, and it is well possible that 
they are removed by other mappers. 

Pelo visto o OSM já se resguardou a respeito.

[]s
Marcio

..

From: Alexandre Magno Brito de Medeiros 
Sent: Friday, December 11, 2015 8:05 PM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]Importação de aeródromos - ANAC

Na verdade, o DOU não reproduz a portaria. Ele apenas a referencia.


Vejamos o que acontece num exemplo específico:

PORTARIA Nº 2899/SIA 26/12/2012 / DOU Nº 250, S/1, p.27  28/12/2012


Naquele DOU:


  SUPERINTENDÊNCIA DE INFRAESTRUTURA
  A E R O P O RT U Á R I A
  GERÊNCIA DE ENGENHARIA DE
  INFRAESTRUTURA AEROPORTUÁRIA

  PORTARIAS DE 26 DE DEZEMBRO DE 2012

  O GERENTE DE ENGENHARIA DE INFRAESTRU-
  TURA   AEROPORTUÁRIA   DA AGÊNCIA   NACIONAL   DE
  AVIAÇÃO  CIVIL -  ANAC, no  uso de  suas atribuições  outorgadas
  pelo  artigo 1º,  inciso IV  da  Portaria nº  2304  de 17  de dezembro  de
  2010, pelo que consta no artigo 41, incisos VIII e X da Resolução Nº
  110, de 15 de setembro de 2009, nos termos do disposto na Resolução
  nº 158, de 13 de julho de 2010, com fundamento na Lei nº 7.565, de
  19 de dezembro de 1986, que dispõe sobre o Código Brasileiro de
  Aeronáutica, resolve:

  [...]

  No - 2.899  - Inscrever o aeródromo  Campo Grande (SJYU),  em Pa-
  caraima (RR); validade de 10 (dez) anos.



  O inteiro teor das Portarias acima encontra-se disponível no
  sítio da   ANAC na rede   mundial de computadores   - endereço
  h t t p : / / w w w. a n a c . g o v. b r.

  TÁRIK PEREIRA DE SOUZA



E é só isso! O Diário Oficial não tem dados além de nome do aeródromo, código e 
nome do lugar.


Então a questão continua:


Os textos e dados contidos nas portarias podem ser usados no OSM?


Alexandre Magno


PS.:

URLs para os PDFs de diários são assim:

http://pesquisa.in.gov.br/imprensa/jsp/visualiza/index.jsp?data=28/12/2012=1=27


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

Re: [Talk-br] Issue no Github para o iD exibir mensagem alertando usuários de nomes copiados do Google

[thundercel]

Volto a comentar que não tiro a importância da fiscalização, porém já observo 
que o numero de edições de alguns fiscais está muito aquém da do fiscalizado.

Não sou contra a iniciativa do Arlindo e até me alinho com ela porque não é 
demais alertar, em especial para aqueles que estão ingressando agora no 
Projeto. Só espero que ela não alimente ao fiscal ficar perguntando ao editor 
que não empregou o source=survey a se explicar de onde extraiu a nomenclatura.

Aproveitei a ocasião para desabafar e citar dos fiscais.

Quando cito fiscais me refiro aqueles que, em especial, andam fiscalizando 
minhas edições e até vídeos tutoriais sobre o OSM que posto no youtube. Esses 
constantemente me obrigam, por mensagens internas, a parar e justificar meus 
atos. Perco muito tempo justificando e buscando provas que suportem minhas 
edições.

Os de mais tempo devem se recordar do caloroso debate que tivemos aqui nesta 
lista sobre uma edição que fiz em um novo trevo em Porto Velho – RO por 
orientação de um residente amigo meu. Ali fui fiscalizado, interpolado e acabei 
sendo obrigado a solicitar a um outro amigo de lá a extrair por helicóptero 
imagens fotográficas do novo trevo e apresentar aqui as fotos que comprovavam 
minha edição.

Compreendam que quando ingressei no OSM decidi participar e ajudar a divulgar o 
Projeto nos sites que administro. O meu desabafo quanto a fiscais não está 
dirigido somente aqueles que estão me fiscalizando, está dirigido a todos que 
em vez de contribuir com edições passam a maior parte do tempo fiscalizando as 
edições dos outros. Não são poucas as críticas a esse respeito que venho 
recebendo daqueles que frequentam nossos sites e se dispuseram a contribuir. 
Estou fazendo o papel de porta voz deles.

Infelizmente alguns foram desmotivados, pararam de contribuir e passaram a 
fazer propaganda negativa do Projeto.

[]s
Marcio

From: Gerald Weber 
Sent: Thursday, December 10, 2015 5:31 PM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]Issue no Github para o iD exibir mensagem alertando 
usuários de nomes copiados do Google

  Não tiro a importância da fiscalização, mas me preocupa a inversão de valores 
onde começam a existir mais fiscais do que editores. Seria interessante que 
esses fiscais também se debruçassem na edição uma vez que no OSM ainda faltam 
inúmeras informações de nomenclaturas de vias, sem contar falta de arruamento 
de inúmeros municípios.

A iniciativa do Arlindo é precisamente para diminuir a necessidade da 
fiscalização e podermos concentrar naquilo que nós gostamos de fazer.

abraço


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

Re: [Talk-br] Issue no Github para o iD exibir mensagem alertando usuários de nomes copiados do Google

[thundercel]

Sou de mesma opinião do Peter já que nome de logradouro é público. Incluir no 
OSM um nome com o mesmo erro de grafia do Bing ou Google é outra estória e que 
caracteriza indícios de cópia, o que não é aceitável no OSM.

Eu mesmo sou um que nos últimos dias tenho incluído inúmeras nomenclaturas de 
vias advindas de colaborações recebidas de utilizadores do mapa Cocar.

Não faz muito tempo produzi, a pedido de alguns interessados, um vídeo tutorial 
orientando a forma de inclusão de nomenclatura de via no OSM. Na ocasião fui 
interpolado pelo Nelson que solicitou que eu no vídeo deixasse bem claro a 
situação de copyright e assim fiz. Alguns estão se cadastrando no OSM e eles 
mesmos incluindo as nomenclaturas na região que residem e bem conhecem. Outros, 
por motivos pessoais, estão nos alimentando com a informação e nós mesmos temos 
incluído.

Não tiro a importância da fiscalização, mas me preocupa a inversão de valores 
onde começam a existir mais fiscais do que editores. Seria interessante que 
esses fiscais também se debruçassem na edição uma vez que no OSM ainda faltam 
inúmeras informações de nomenclaturas de vias, sem contar falta de arruamento 
de inúmeros municípios.

[]s
Marcio 



From: Peter Krauss 
Sent: Thursday, December 10, 2015 4:18 PM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]Issue no Github para o iD exibir mensagem alertando 
usuários de nomes copiados do Google

Cuidado, não faz o menor sentido atribuir copyright ao nome de logradouro, é 
público (!!). ___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Issue no Github para o iD exibir mensagem alertando usuários de nomes copiados do Google

[thundercel]

Concordo Arlindo até porque trabalhando no Maparadar com a API do Google 
identificamos a infinidade de erros de nomenclatura de vias nele.

Infelizmente temos identificado também erros no IBGE nos obrigando a pesquisa 
apurada sobre o correto.

Compreendo a dificuldade enfrentada pelo IBGE em se manter atualizado já que em 
nosso país, as Câmaras para mostrarem serviço, alteram frequentemente nomes no 
sistema viário.

Só para terem noção do problema vejam comentário deste ano de 2015, da Câmara 
Municipal de SP, em 
http://noticias.band.uol.com.br/brasil/noticia/10764816/criar-festas-e-dar-nome-a-rua-sao-o-foco-da-camara-de-sp.html
 , em especial o citado:
“Balanço da Casa aponta que, de 118 textos aprovados e transformados em leis 
entre janeiro e 23 de julho, 73 (61,8%) tratavam de iniciativas para 
denominação de ruas e praças e de inclusão de datas festivas no calendário 
oficial. 
[]s
Marcio
From: Arlindo Pereira 
Sent: Thursday, December 10, 2015 7:51 PM
To: OSM talk-br 
Subject: Re: [Talk-br]Issue no Github para o iD exibir mensagem alertando 
usuários de nomes copiados do Google
Não há porque copiar dados do Google Maps ou o que seja quando temos a camada 
com o arruamento do IBGE direto no iD. ___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Issue no Github para o iD exibir mensagem alertando usuários de nomes copiados do Google

[thundercel]

Nelson,
tenho o vídeo original aqui onde cito o emprego do Bing para alinhamento de 
vias e o emprego do IBGE para nomenclaturas. No vídeo até explico como estampar 
a imagem do IBGE e dela extrair a nomenclatura das vias.

É fato que nesse vídeo original não deixei explícito que do Bing só se poderia 
empregar a imagem para alinhamentos. NO vídeo só mostrei um alinhamento 
empregando a imagem do Bing.

Conversei isso com você e mesmo convicto que o emprego do Bing para 
nomenclatura de via ficava para interpretação de qualquer um, decidi refazer o 
vídeo deixando explícito que não se pode empregar o Bing para nomenclatura.

Volto a comentar que os "fiscais" devem, na minha opinião, ter sensibilidade 
quando do "approach" a um colaborador.

No link apontado, logo de inicio observamos:

"Comentário de naoliv 22 dias atrás
Esses dados vão ter que ser removidos do mapa. Nenhum deles permite o uso ou 
cópia das informações.
Comentário de santos02 22 dias atrás
Como assim, as informações estão corretas, e de algum lugar tem que sair as 
informações."

Convém lembrar que esse usuário Santos02 interpelado é um dos que motivamos a 
colaborar com o OSM. Ele reside nessa pequena cidade de Boituva - SP editada.

Julgo valido um fiscal interpelar um colaborador quando identificar algum erro 
de grafia que possa criar algum indício de cópia de fonte não aceita, em que 
pese ser muito difícil provar isso por grafia errada semelhante. Isso não 
constitui prova e sim indício.

Interpelar tão somente porque o colaborador nomeou uma quantidade significativa 
de vias não sou favorável. Isso desmotiva quem entra para ajudar e vem 
desmotivando muita gente pela quantidade de fiscais interpelando colaboradores.

Só eu sei a quantidade de ponderações que venho recebendo a respeito e talvez 
seja mais recomendável traze-las aqui para essa lista para que todos tenham 
noção da quantidade e tirem suas próprias conclusões.

[]s
Marcio


-Mensagem Original- 
From: Nelson A. de Oliveira 
Sent: Thursday, December 10, 2015 6:20 PM 
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]Issue no Github para o iD exibir mensagem alertando 
usuários de nomes copiados do Google 

2015-12-10 18:10 GMT-02:00  :
> Quando cito fiscais me refiro aqueles que, em especial, andam fiscalizando
> minhas edições e até vídeos tutoriais sobre o OSM que posto no youtube.

Se for o meu caso, espero que leiam, por exemplo, a discussão em
http://www.openstreetmap.org/changeset/35388654

O aviso serve justamente para evitar tais cópias de dados (o que anda
ocorrendo muito recentemente).
Não existe terrorismo e muito menos perseguição com qualquer pessoa.
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Issue no Github para o iD exibir mensagem alertando usuários de nomes copiados do Google

[thundercel]

Prezado Gerald,

até onde sei os “redactions” que ocorreram até então se deram por “importações 
em massa” de dados. Um desses “redactions” destruiu um trabalho meu em Itabira 
– MG porque um “colaborador”, que vou chamar de “destruidor”, importou dados do 
município da base do Tracksource, o que sabemos não é permitido.

Até onde acompanhei estamos aqui nos referindo a nomenclaturas de vias feitas 
manualmente e não por importação massiva de dados.

Acredito que o colega A.Carlos se referiu a essa situação.

[]s
Marcio


From: Gerald Weber 
Sent: Thursday, December 10, 2015 8:34 PM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]Issue no Github para o iD exibir mensagem alertando 
usuários de nomes copiados do Google

Prezado Colega


2015-12-10 20:06 GMT-02:00 A. Carlos :

  Parece que aqui está prevalecendo a tecnocracia, do que o bom senso em 
desenhar
  e deixar um mapa mais plausível á realidade..

  Fiscalizar se uma rua é ou não copiada, seja google ou qualquer outra fonte, 
francamente...


Você provavelmente não acompanhou, mas tivemos um "redaction" (eliminação 
completa da base) na região de Pouso Alegre que deixou um buraco monstruoso no 
mapa há alguns anos atrás. Foram dados inseridos ilegalmente e que ficaram no 
mapa por 5 anos. O DWG (Data Working Group) um belo dia descrobriu e removeu 
não apenas os dados inseridos mas tudo que foi feito em cima disto. O prejuízo 
foi enorme. Muita gente perdeu trabalho legítimo, eu inclusive, por causa de 
dados problemáticos. Até hoje há cidades no sul de Minas incompletas por causa 
disto.

Este ano tivemos pelo menos 2 redactions no Brasil, que eu saiba, um bem grande 
na região de Itabira.

Lembre-se que o OSM é um projeto internacional, com sede no Reino Unido. Um 
único processo judicial de copyright custaria milhões para defender e 
arruinaria tudo que foi feito. Por isto o OSM é mais realista que o rei e dados 
suspeitos são simplesmente eliminados (sim, basta que haja suspeita).

O objetivo de colocar avisos é tentar evitar todo este problema. Só isto.


abraço

Gerald

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

Re: [Talk-br] Issue no Github para o iD exibir mensagem alertando usuários de nomes copiados do Google

[thundercel]

Por gentileza, cite um exemplo de um redact ocorrido nos dados do Brasil por 
emprego de nome de rua.


Nos exemplos apontados só identifiquei redact devido importação de dados.

Cópia do Google: https://www.openstreetmap.org/redactions/6
o usuário colocou source=google
Caso do Eduardo: https://www.openstreetmap.org/redactions/16
o usuário fez importação de dados do Tracksource/google
Cópia do Tracksource: https://www.openstreetmap.org/redactions/18
Esse estava eu já no OSM e trata-se de um redact em Itabira - MG por 
importação de dados do Tracksource e que criou um grande buraco.


Reverter changset é outra estória e diferente do redact que cria o buraco ao 
apagar todos os dados na área.



-Mensagem Original- 
From: Nelson A. de Oliveira

Sent: Thursday, December 10, 2015 9:39 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br]Issue no Github para o iD exibir mensagem alertando 
usuários de nomes copiados do Google


2015-12-10 21:28 GMT-02:00 A. Carlos :

Claro que seu argumento do redaction está correto, mas sei que redaction
atua quando existiu alguma importação em massa.


Redaction é nada mais do que remover as informações do banco de dados,
geralmente por envolver fontes que o projeto não possui permissão de
uso.

Mesmo que a pessoa tenha copiado manualmente o nome de algum lugar, é
caracterizado da mesma forma como uso indevido.
Não são apenas processos automáticos que são removidos.

Processos automatizados e que não são ilegais são apenas revertidos, e
não removidos do OSM.

Exemplos de motivos que geram redact:

Cópia do Google: https://www.openstreetmap.org/redactions/6
Caso do Eduardo: https://www.openstreetmap.org/redactions/16
Cópia do TrackSource: https://www.openstreetmap.org/redactions/18


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

Re: [Talk-br] Issue no Github para o iD exibir mensagem alertando usuários de nomes copiados do Google

[thundercel]

Pelo que analisei esse "redaction revert" se deu pelo emprego de dados do 
Google pelo usuário Tauranis.


Pergunto:

- Que prova motivou o "redaction revert"? Não encontrei.

Engraçado que no http://www.openstreetmap.org/changeset/32806066 dele tem o 
seguinte debate:


Comentário de Skippern 5 meses atrás
O nome do "Rua Manuel A. T. Uso" tem cheiro do easter egg. Existe algum 
fontes que podemos confiar que confirma esse nome?


Comentário de Tauranis 5 meses atrás
IBGE - Mapas de setores urbanos

Teria sido alguma denuncia?

-Mensagem Original- 
From: Nelson A. de Oliveira

Sent: Thursday, December 10, 2015 10:13 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br]Issue no Github para o iD exibir mensagem alertando 
usuários de nomes copiados do Google


2015-12-10 22:08 GMT-02:00  :
Por gentileza, cite um exemplo de um redact ocorrido nos dados do Brasil 
por

emprego de nome de rua.


http://www.openstreetmap.org/changeset/32838078


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

Re: [Talk-br] Issue no Github para o iD exibir mensagem alertando usuários de nomes copiados do Google

[thundercel]

Uma coisa é o usuário ficar em dúvida e outra ter eu no video comentado que 
poderia empregar os dados de nomes de rua do Bing. No video comentei e 
ensinei a empregar os dados de nomes do IBGE.


Uma coisa é comentar com o usuário que os dados "precisam" ser retirados e 
outra que os dados "vão ter"  de ser removidos. Apesar de aparentemente 
semelhantes, a primeira abre o debate e a segunda não dá chance a esse.


Quanto ao procedimento adotado por voce para fiscalização insto a gastar um 
pouco desse tempo disponivel editando o mapa. Pelo tempo de OSM julgo que 
1.239 edições é pouco em comparação as 6.037 que já tenho em muito menos 
tempo de Projeto.


Me tire uma duvida, por gentileza:

- O que significa aquele icone medalha no seu perfil que diz: USUÁRIO MAIS 
ODIADO DA COMUNIDADE BRASILEIRA.


Isso é glória?


-Mensagem Original- 
From: Nelson A. de Oliveira

Sent: Thursday, December 10, 2015 9:24 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br]Issue no Github para o iD exibir mensagem alertando 
usuários de nomes copiados do Google


2015-12-10 20:17 GMT-02:00  :

Conversei isso com você e mesmo convicto que o emprego do Bing para
nomenclatura de via ficava para interpretação de qualquer um, decidi 
refazer

o vídeo deixando explícito que não se pode empregar o Bing para
nomenclatura.


Sim, nós conversamos sobre o vídeo.
Em momento algum eu disse que ele estava errado ou reclamei quanto a
isto. Apenas disse que a parte do Bing estava ambígua e dando a
entender que poderia copiar os nomes das ruas dele.
Tanto é que o usuário ficou com esta dúvida e me apontou o vídeo.



"Comentário de naoliv 22 dias atrás
Esses dados vão ter que ser removidos do mapa. Nenhum deles permite o uso 
ou

cópia das informações.
Comentário de santos02 22 dias atrás
Como assim, as informações estão corretas, e de algum lugar tem que sair 
as

informações."


Posso não ser o melhor diplomata, mas não falei nenhuma mentira (que
os dados precisam ser removidos) e também apontei caminhos de onde ele
poderia obter os nomes de forma lícita.
Inclusive me ofereci a colocar os nomes do IBGE.



Interpelar tão somente porque o colaborador nomeou uma quantidade
significativa de vias não sou favorável. Isso desmotiva quem entra para
ajudar e vem desmotivando muita gente pela quantidade de fiscais
interpelando colaboradores.


Vou falar por mim: quando vejo algo estranho eu olho o histórico do
objeto, o changeset e também as outras modificações do usuário.
Comparo, na medida do possível, com mapas do IBGE, da prefeitura e
também com mapas comerciais (Google, Bing, Here, etc).

Pode ter certeza que eu não pergunto a ninguém de onde a pessoa está
retirando os dados se eu vejo que os nomes batem com o IBGE, por
exemplo.
Mas se aparecem várias palavras com grafia diferente e que batem com
algum mapa comercial apenas, aí sim, eu pergunto de onde a pessoa
retirou as informações.


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

Re: [Talk-br] Issue no Github para o iD exibir mensagem alertando usuários de nomes copiados do Google

[thundercel]

Já supunha isso, que alguém havia acionado o DWG.

É muito dificil e complicado afirmar que houve cópia de fonte não permitida. 
Indício não constitui prova.


Se o colaborador assim declarou é outra estória.

-Mensagem Original- 
From: Nelson A. de Oliveira

Sent: Thursday, December 10, 2015 10:52 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br]Issue no Github para o iD exibir mensagem alertando 
usuários de nomes copiados do Google


2015-12-10 22:43 GMT-02:00  :

- Que prova motivou o "redaction revert"? Não encontrei.


Fui eu que pedi ao DWG a remoção dos nomes.


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

Re: [Talk-br] RES: Classificação de vias (agora com 50km/hora), como fica? Tarcisio Oliveira

[thundercel]

Não emprego navegação pelo smartphone e até onde sei o Osmand não foi 
desenvolvido para navegadores GNSS automotivos. Pelo que sei ele é um APP 
para smartphone.


De qualquer forma espero que os utilizadores do Osmand estejam acostumados 
com os inúmeros erros existentes no OSM, contidos nas tag maxspeed de 
algumas vias.


Seriam interessante alguém de São Paulo atualizar essa tag nas principais 
vias da cidade que são as marginais, sem considerar as de menor importância 
que também tiveram recentemente alterações na velocidade máxima.


-Mensagem Original- 
From: Nelson A. de Oliveira

Sent: Wednesday, September 30, 2015 2:30 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br]RES: Classificação de vias (agora com 50km/hora), como 
fica? Tarcisio Oliveira


2015-09-30 14:25 GMT-03:00  :

Dentro do GNSS, qual aplicativo que emprega dados OSM tem alerta de
velocidade para o usuário?


O osmand é um dos que utiliza, tanto para cálculo do tempo estimado da
viagem, exibição da velocidade máxima da via e também aviso de excesso
de velocidade.


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

Re: [Talk-br] RES: Classificação de vias (agora com 50km/hora), como fica? Tarcisio Oliveira

[thundercel]

 

From: Gerald Weber 

> É uma pena. Como usuário do OSM para mim estas são informações importantes. 
> Especialmente quando há grande variação nas velocidades, se eu puder usar o 
> GPS como recurso para me alertar destas variações seria muito valioso.


Tenho lido algumas colocações como essa, desculpem a minha ignorância em 
perguntar:

Dentro do GNSS, qual aplicativo que emprega dados OSM tem alerta de velocidade 
para o usuário?

Os navegadores Garmin tem quando empregados dados compilados em NT, o que não é 
o caso, por enquanto, do Mkgmap.

Recentemente essa necessidade foi tratada na lista de desenvolvimento do 
Mkgmap, quando um usuário citou uma possibilidade de na compilação se extrair 
os dados da TAG maxspeed e estampa-los no GPS junto e após o nome da via, na 
caixa de texto desse nome, mas essa solução foi descartada porque não gera 
alerta e é contra recomendações de segurança quanto a não se ficar olhando para 
o display do GPS quando em navegação.

Até onde acompanho nos sites de GPS que administramos, esse assunto de alerta 
de velocidade máxima no aparelho é desejado por todos aqueles que empregam 
mapas com dados OSM, entretanto não é ainda do meu conhecimento solução para se 
atingir esse objetivo. Se alguém souber, por gentileza nos informe para que 
possamos melhorar o mapa Cocar.

Quanto aos provedores que compilam em NT e fornecem esse tipo de alerta, a 
Nokia (provedora do mapa City Navigator) e a Multispectral (provedora do mapa 
AutoGuia) estão descontinuando essa prática porque elas tem recebido mais 
críticas do que elogios, devido as inumeras incorreções contidas na informação. 
Essas incorreções ocorrem devido as constantes alterações de velocidades nas 
vias efetuadas pelas autoridades competentes em tempo superior a capacidade 
deles em mante-las atualizadas nos alertas.

[]s
Marcio

From: Reinaldo Neves 
Sent: Wednesday, September 30, 2015 12:57 PM
To: 'OpenStreetMap no Brasil' 
Subject: [Talk-br] RES: Classificação de vias (agora com 50km/hora), como fica? 
Tarcisio Oliveira

Indo mais longe Marcio/Gerald,

 

Não podemos comparar nem vias, nem políticos e nem mesmo motoristas, apesar de 
concordar com a restrição de velocidade em alguns locais é notório que no 
Brasil algumas dessas intervenções nas vias públicas tem objetivo de favorecer 
arrecadação ou coisa pior, e o argumento da segurança é apenas cortina de 
fumaça.

 

Para ficarmos apenas no exemplo de São Paulo qualquer esforço em sinalizar 
velocidade máxima será perdido em breve, já que nosso dileto alcaide deixou 
claro que novas alterações estão programadas para o curto prazo, e digo mais 
caso ele não se reeleja o próximo pode desfazer um mundo dessas alterações.

 

Abraços

___

Reinaldo Neves

Equação Informática

(11) 3221-3722
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Classificação de vias (agora com 50km/hora), como fica?

[thundercel]

Complementando o citado pelo Arlindo, devemos ter especial atenção na 
classificação de vias e o que isso acarreta no roteamento na região.

Em termos de roteamento as classes motorway e trunk exercem um poder muito 
forte puxando para elas o roteamento em cruzamento da região onde elas se 
encontram.

Como exemplo cito a ES-060 Rodovia do Sol, no ES formatada na classe TRUNK ( 
http://www.openstreetmap.org/way/293885854 ).

A BR-101 ( http://www.openstreetmap.org/way/317662876 ) que seria a rota 
recomendada para cruzamento do ES está sendo desconsiderada no roteamento 
porque se encontra na classe PRIMARY.

Assim sendo recomendo o emprego do OSRM para identificar o roteamento na região 
antes de fazer qualquer alteração.

[]s
Marcio

From: Arlindo Pereira 
Sent: Tuesday, September 29, 2015 11:12 AM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]Classificação de vias (agora com 50km/hora), como fica?

Acho que mais importante do que a velocidade máxima são os acessos. 
Autoestradas, marginais etc. via de regra não tem semáforos ou vias 
transversais, geralmente tem acessos em rampa etc. Por outro lado, as vias 
laterais das marginais, quando existem, geralmente permitem acesso lindeiro ou 
a transversais, ainda que não (necessariamente) tenham sinais ou outras 
interrupções. 

Dessa forma, o recomendado seja marcar as pistas expressas como motorway e as 
locais como trunk. 

Exemplo no Rio de Janeiro: Avenida Brasil 
http://www.openstreetmap.org/#map=16/-22.8861/-43.2260

[]s
Arlindo

2015-09-28 23:14 GMT-03:00 Ivaldo Nunes de Magalhães :

  É incrível como esse assunto sempre volta - por ser complexo, creio. Mas 
principalmente porque leigos teimosos (como eu) insistem em fazer certo.

  Pessoal como fica a questão das vias expressas com a redução do limite de 
velocidade em vias importantes (como exemplo mais recente em SP, marginais...)? 
Que aliás estão classificadas como autoestradas (azuzinhas), cuja velocidade 
anterior era 90km max e agora estão com 70km max.

  Pergunto porque aqui em Campo Grande/MS tem algumas vias com as mesmas 
características estruturais - evidente que com menor tráfego - mas com 
50km/hora max (duplicada, com acostamento, 2 ou mais faixas, mas 50km/h). Posso 
classificar como expressa?


  Ivaldo 


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

Re: [Talk-br] Classificação de vias (agora com 50km/hora), como fica? Tarcisio Oliveira

[thundercel]

Ivaldo,
confesso que não é do meu costume aplicar a tag maxspeed em vias porque 
infelizmente estamos em um país onde a engenharia de tráfego não demonstra que 
entende de tráfego.

Conduzi carro lá fora com grande tranquilidade porque experimentei velocidades 
máximas permitidas constantes nas vias. Aqui no Brasil não é assim. À frente no 
site http://maparadar.com me impressiona as variações de velocidade máxima 
permitida em trechos de vias, e o pior, com sensores de velocidade que 
arrecadam recursos oriundos das multas.

Pasmo estou com a quantidade de radares que foram implantados no Brasil nestes 
meses de agosto e setembro. Isso está me levando a deduzir que os governos 
estão buscando outras fontes de renda para diminuir o rombo nos cofres públicos.
Vejam matéria em 
http://g1.globo.com/sao-paulo/noticia/2015/08/multas-aplicadas-em-sp-sobem-22-no-1-semestre-deste-ano-diz-cet.html

Quando incluímos a tag maxspeed em uma via devemos ter em mente que as 
constantes variações  de velocidade máxima impostas pelos órgãos de trânsito 
irão nos obrigar a alterar aquela tag.

Veja exemplo recente na cidade de São Paulo onde foram reduzidas todas as 
velocidades das principais vias da cidade. 

Como exemplo, observe a Marginal Tietê em 
http://www.openstreetmap.org/way/4614918

Essa via teve sua velocidade máxima permitida alterada de 90 para 70 km/h. A 
auxiliar de 70 para 60 km/h. Ambas não foram ainda alteradas no OSM, mas de 
qualquer forma não acredito que velocidades nessas vias, em horários diurnos, 
permitam se atingir essas velocidades.

Outra situação que devemos levar em consideração em termos de roteamento é que 
a tag maxspeed se sobrepõe a tag highway.

[]s
Marcio




From: Ivaldo Nunes de Magalhães 
Sent: Tuesday, September 29, 2015 5:04 PM
To: talk-br@openstreetmap.org 
Subject: [Talk-br] Classificação de vias (agora com 50km/hora), como fica? 
Tarcisio Oliveira

Tarcísio, concordo também com esse ponto, mas no "intrincado" organograma (de 
classificação de vias 
(http://wiki.openstreetmap.org/w/images/1/12/Br-classification-flowchart-pt.png)
 - onde sempre que há alguma dúvida sobre esse tema aqui alguém remete para ele 
 [inclusive eu agora... rsrsrs] cita como pré-condição exatamente a velocidade 
(<= 80km/hora).

Nesse ponto, entendo que os atributos estruturais (nº de faixas, duplicada, 
acostamento, canteiro central...) deveriam se sobrepor à velocidade.


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

Re: [Talk-br] Classificação de vias (agora com 50km/hora), como fica? Tarcisio Oliveira

[thundercel]

EM OFF também.

Alexandre,
o problema é mais sério.
Veja matéria recente em 
http://www.afam.com.br/noticia/policia-civil-vai-apurar-gastos-da-cet-com-troca-de-placas/28727
Se comprovada a denuncia não desejam só abastecer os cofres públicos.

From: Alexandre Magno Brito de Medeiros 
Sent: Tuesday, September 29, 2015 6:08 PM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]Classificação de vias (agora com 50km/hora), como fica? 
Tarcisio Oliveira

Não resisti... OFF:

Em 29 de setembro de 2015 17:58,  escreveu:


  Pasmo estou com a quantidade de radares que foram implantados no Brasil 
nestes meses de agosto e setembro. Isso está me levando a deduzir que os 
governos estão buscando outras fontes de renda para diminuir o rombo nos cofres 
públicos.

  Vejam matéria em Multas aplicadas em SP sobem 22% no 1º semestre deste ano, 
diz CET


Cunha ironiza legalização de jogos [de azar]: “Vamos depender da sorte dos 
outros” 


Se bem que pardal já é joguinho...


Alexandre

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

Re: [Talk-br] Classificação de vias (agora com 50km/hora), como fica?

[thundercel]

Complementando...
em 
http://map.project-osrm.org/?z=9=-20.414143%2C-40.028687=-20.907569%2C-41.066895=-19.471771%2C-40.113831=en
 podem observar o roteamento cruzando o Espírito Santo, de sul para norte.

A rota deveria prosseguir pela BR-101, que mesmo com velocidade máxima inferior 
a ES-060, evita o cruzamento por dentro de Vila Velha e Vitória onde existem 
inúmeros semáforos e pesado trânsito.

Esse situação ocorre simplesmente porque a ES-060 está como TRUNK e a BR-101 
como PRIMARY.

Alterações em classes de vias alteram o roteamento.

From: thunder...@gpsinfo.com.br 
Sent: Tuesday, September 29, 2015 1:17 PM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]Classificação de vias (agora com 50km/hora), como fica?

Complementando o citado pelo Arlindo, devemos ter especial atenção na 
classificação de vias e o que isso acarreta no roteamento na região.

Em termos de roteamento as classes motorway e trunk exercem um poder muito 
forte puxando para elas o roteamento em cruzamento da região onde elas se 
encontram.

Como exemplo cito a ES-060 Rodovia do Sol, no ES formatada na classe TRUNK ( 
http://www.openstreetmap.org/way/293885854 ).

A BR-101 ( http://www.openstreetmap.org/way/317662876 ) que seria a rota 
recomendada para cruzamento do ES está sendo desconsiderada no roteamento 
porque se encontra na classe PRIMARY.

Assim sendo recomendo o emprego do OSRM para identificar o roteamento na região 
antes de fazer qualquer alteração.

[]s
Marcio

From: Arlindo Pereira 
Sent: Tuesday, September 29, 2015 11:12 AM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]Classificação de vias (agora com 50km/hora), como fica?

Acho que mais importante do que a velocidade máxima são os acessos. 
Autoestradas, marginais etc. via de regra não tem semáforos ou vias 
transversais, geralmente tem acessos em rampa etc. Por outro lado, as vias 
laterais das marginais, quando existem, geralmente permitem acesso lindeiro ou 
a transversais, ainda que não (necessariamente) tenham sinais ou outras 
interrupções. 

Dessa forma, o recomendado seja marcar as pistas expressas como motorway e as 
locais como trunk. 

Exemplo no Rio de Janeiro: Avenida Brasil 
http://www.openstreetmap.org/#map=16/-22.8861/-43.2260

[]s
Arlindo

2015-09-28 23:14 GMT-03:00 Ivaldo Nunes de Magalhães :

  É incrível como esse assunto sempre volta - por ser complexo, creio. Mas 
principalmente porque leigos teimosos (como eu) insistem em fazer certo.

  Pessoal como fica a questão das vias expressas com a redução do limite de 
velocidade em vias importantes (como exemplo mais recente em SP, marginais...)? 
Que aliás estão classificadas como autoestradas (azuzinhas), cuja velocidade 
anterior era 90km max e agora estão com 70km max.

  Pergunto porque aqui em Campo Grande/MS tem algumas vias com as mesmas 
características estruturais - evidente que com menor tráfego - mas com 
50km/hora max (duplicada, com acostamento, 2 ou mais faixas, mas 50km/h). Posso 
classificar como expressa?


  Ivaldo 






___
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 Baía de Guanabara X Ilha do Governador

[thundercel]

Thiago,
desconheço a politica de arquivamento de tracklogs na base OSM, mas desde que 
ingressei no projeto fiz upload para aquela base do banco de tracklogs que 
tenho em meu PC (mais de 80 MB de arquivos)..

Não tenho tracklogs  só por mim levantados, em função de administrar sites 
dirigidos a usuários de GPS, recebo muitos tracklogs de usuários até porque no 
site http://maparadar.com/ por vezes somos obrigados a alinhar o radar 
cadastrado por informação de tracklog.

De qualquer forma extraí do banco que tenho os tracklogs da Ilha do Governador 
e os disponibilizei em http://cocardl.com.br/pv/ilha.rar

Quanto aos mapas do Cocar continuamos disponibilizando gratuitamente esses 
mapas com frequência mensal, mas nada impede que o utilizador sozinho compile o 
mapa a qualquer tempo empregando os KITs de compilação que disponibilizamos no 
site Cocar em http://cocardl.com.br/viewforum.php?f=70

Decidimos criar o Cocar porque não existia no Brasil provedor de mapa para GPS 
Garmin empregando os dados OSM. Com essa decisão acreditamos que, além de 
divulgar o OSM, angariamos mais colaboradores para o projeto.

O pessoal que emprega o mapa Cocar e tem auxiliado nas edições tem se dedicado 
mais a editar objetos que afetam diretamente roteamentos. Os que não sabem 
ainda editar estão abrindo notas no mapa ou nos comunicando necessidade de 
alterações por meio dos foruns dos sites por nós administrados e onde 
divulgamos o OSM e Cocar.

Em que pese o emprego dos dados OSM para um aplicativo específico, o mapa Cocar 
e seu emprego em muito nos tem auxiliado na identificação de necessidade de 
alterações.

[]s e mais uma vez parabéns pelo trabalho do grupo de inclusão de bairros.

Marcio

From: Thiago Vieira 
Sent: Thursday, September 24, 2015 2:37 PM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]Relação Baía de Guanabara X Ilha do Governador

Certo Marcio, eu já sabia que você é morador da Ilha, sei que se empenha na 
exportação dos mapas do Cocar para os aparelhos de GPS Garmin, etc, e assim 
como a todos os demais mapeadores OSM, tenho profundo respeito. Acredito que 
você possua dados precisos de tracklogs da região, acontece que eu, por ter 
realizado o trabalho de inclusão das divisas dos bairros na Ilha, tomei a 
responsabilidade de efetuar a correção dos problemas apontados das ruas que 
estavam no mar, que conforme eu mostrei no email anterior nem fui eu que 
causei, sem problema algum, eu me disponho a efetuar qualquer correção que me 
apresentarem, não necessariamente tendo sido causados por mim, isso é o que me 
dá prazer no OSM, ver os mapas cada vez melhores. 

Na verdade os bairros da Cacuia e Ribeira não ficaram "desalinhados" a partir 
do trabalho dos bairros mas ficaram desta forma atual após ter sido reportado o 
problema das ruas no mar. Para realizar esse trabalho eu ativei a camada de 
dados de tracklogs no Josm, no entanto pouquíssima coisa foi carregada, não sei 
se esses seus dados estão nas bases do OSM. Logo tive que adotar um critério 
para realizar o trabalho e o mais adequado que considerei foi usar as próprias 
ruas mapeadas para obter o melhor offset para o mapa base, então percebi que o 
offset -50;-60 da ortofoto 2012 do IPP aparentava ser suficientemente alinhado, 
percebi inclusive que esse offset tem um alinhamento praticamente exato com o 
mapa Bing, veja as imagens a seguir.___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Relação Baía de Guanabara X Ilha do Governador

[thundercel]

Sim Arlindo, a Ilha do Governador não está mais sendo encoberta pelas águas da 
Baía, entretanto é visível no mapa o desvio da linha da costa, em especial na 
parte sul da Ilha onde ela está bastante desalinhada. 

Surgiu também um novo problema, agora no multipoligono do Aeroporto 
Internacional, onde os objetos internos deixaram de ser vistos no mapa, 
entretanto estamos, o Nelson e eu, identificando a solução. è problema de inner 
e outer que foi alterado.

[]s
Marcio

From: Arlindo Pereira 
Sent: Wednesday, September 23, 2015 11:47 AM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]Relação Baía de Guanabara X Ilha do Governador

Marcio, 

a compilação do Cocar com os dados de hoje ocorreu de forma correta?

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

Re: [Talk-br] Relação Baía de Guanabara X Ilha do Governador

[thundercel]

Thiago,
lembro que resido na Ilha do Governador, no Bairro Jardim Guanabara, e por ela 
trafego diariamente. Foi nela que nasci e é nela que espero ir.

Como edito mapa há bastante tempo não são poucos os tracklogs por mim 
levantados com GPS, em especial na Ilha. A quase totalidade desses se encontram 
na base OSM.

As imagens satélites por vezes não estão satisfatoriamente bem 
georreferenciadas em algumas áreas, mas esse não é o caso da Ilha do Governador 
que por meio dos tracklogs afirmo que a imagem do Bing de hoje se encontra 
satisfatoriamente georreferenciada podendo tranquilamente ser empregada para 
alinhamentos sem necessidade de ajustes pelo editor do mapa..

Isso tudo me habilita a citar que a linha da costa, em especial dos Bairros do 
Cacuia e Ribeira, ficaram bastante desalinhadas após o changeset de inclusão de 
bairros.

A referencia que empregamos para identificar necessidades de alterações é o 
mapa COCAR BR ( http://cocardl.com.br/ ) que diariamente compilamos para uso 
próprio e mensalmente disponibilizamos gratuitamente para usuários de GPS 
Garmin.  

A compilação desse mapa emprega os dados OSM disponibilizados no formato PBF em 
http://download.geofabrik.de/south-america/brazil.html .Esses dados são 
diariamente atualizados por volta das 21:00 hs contemplando “TODAS” as 
alterações na base OSM até as 18:00 hs do dia. Por aí compreenda que não existe 
situação que alguma alteração realizada na base OSM não seja contemplada no 
arquivo PBF. Não existe, nesse caso, necessidade de se aguardar para verificar 
no mapnik qualquer alteração. 

Observo que a linha da costa já foi corrigida hoje e essa correção já estará 
estampada no mapa COCAR BR que hoje a noite compilaremos.

Finalizo parabenizando a você e demais participantes do grupo criado pelo 
Arlindo, pelo excelente trabalho de inclusão de bairros no Rio de Janeiro. Até 
então, na Ilha do Governador, só existia um bairro incluído que era o que onde 
resido, o Jardim Guanabara. Agora todos os bairros dela já estão no mapa.

[]s
Marcio



From: Thiago Vieira 
Sent: Wednesday, September 23, 2015 3:02 PM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]Relação Baía de Guanabara X Ilha do Governador

Marcio, 

"entretanto é visível no mapa o desvio da linha da costa, em especial na parte 
sul da Ilha onde ela está bastante desalinhada."


Onde ocorre isso? Se estiver se referindo ao litoral nos bairros da Ribeira e 
Cacuia, na verdade agora o litoral está mais próximo do correto, tanto que a 
foto de satélite usada pra mapear foi a mesma que no resto da ilha e só ali 
apareceu essa diferença pois aparentemente foi mapeada anteriormente em 
separado com alguma foto com um offset alto com relação ao correto. Não se 
preocupe com o desvio percebido no mapnik, como eu disse no email anterior, irá 
levar um tempo até que as modificações na coastline se reflitam ali.

Em 23 de setembro de 2015 13:24,  escreveu:

  Sim Arlindo, a Ilha do Governador não está mais sendo encoberta pelas águas 
da Baía, entretanto é visível no mapa o desvio da linha da costa, em especial 
na parte sul da Ilha onde ela está bastante desalinhada. 

  Surgiu também um novo problema, agora no multipoligono do Aeroporto 
Internacional, onde os objetos internos deixaram de ser vistos no mapa, 
entretanto estamos, o Nelson e eu, identificando a solução. è problema de inner 
e outer que foi alterado.

  []s
  Marcio

--

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

Re: [Talk-br] Relação Baía de Guanabara X Ilha do Governador

[thundercel]

Marcio,
pela nossa experiência, em nossas compilações, não havíamos até então 
identificado problema por estarem ways membros de relação fora de ordem, 
entretanto vamos testar a correção.

O nosso teste só poderá ser feito após as 21:00 hs de hoje, quando o geofabrik, 
em http://download.geofabrik.de/south-america/brazil.html , disponibiliza os 
dados OSM do Brasil, em formato PBF.a.

Para voce e os demais, disponibilizamos a imagem da Ilha do Governador no mapa 
Cocar compilado em 20 SET 2015. Podem ver em http://cocardl.com.br/pv/1.jpg

Quando compilamos o mapa na manhã de hoje encontramos a Ilha do Governador 
vista em print em http://cocardl.com.br/pv/2.jpg

Até podemos a nível Mkgmap tentar incluir algo que descarte o problema, 
entretanto não sabemos ainda onde foi alterado no OSM que causou isso.

Caso o problema fosse no Mkgmap as demais ilhas da Baía de Guanabara também 
seriam encobertas por ela, o que não ocorre.


From: Márcio Aguiar Ribeiro 
Sent: Tuesday, September 22, 2015 2:02 PM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]Relação Baía de Guanabara X Ilha do Governador

A relação da Baia da Guanabara estava com os ways fora de ordem. Verifica se a 
correção fez efeito.

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

Re: [Talk-br] Relação Baía de Guanabara X Ilha do Governador

[thundercel]

Na minha opinião não tem sentido se colocar a tag coastline nos caminhos 
membros de uma relação se na própria relação pode-se colocar isso uma única 
vez. Essa situação reduz sobremaneira a possibilidade de erro de não se 
colocar a tag em um dos caminhos.


A relação da Ilha do Governador é composta de inúmeros caminhos membros e 
esses caminhos estão sendo tratados pelo grupo de trabalho de bairros uma 
vez que a Ilha não é um bairro. Nela existem inúmeros bairros do Rio de 
Janeiro.


Onde é citado que é errado colocar coastline na relação?

-Mensagem Original- 
From: Nelson A. de Oliveira

Sent: Tuesday, September 22, 2015 3:43 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br]Relação Baía de Guanabara X Ilha do Governador

2015-09-22 15:39 GMT-03:00  :

É bem provável que tenha sido isso da retirada da TAG coastline que
acarretou o problema. Estamos inserindo essa tag na relação e iremos
compilar novo mapa a noite para identificar se o problema foi corrigido.


Não, está errado colocar coastline na relação.
Ela já faz parte dos caminhos que compõem a relação.
Por exemplo:

https://www.openstreetmap.org/way/252992140

___
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 Baía de Guanabara X Ilha do Governador

[thundercel]

Vitor,
como citei somente a Ilha do Governador. Todas as demais ilhas na baía de 
Guanabara, como do Fundão, Paquetá, do Boqueirão, etc,  permanecem normais.



From: Vítor Rodrigo Dias 
Sent: Tuesday, September 22, 2015 2:00 PM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]Relação Baía de Guanabara X Ilha do Governador

Marcio, 

Acontece somente na Ilha do Governador ou em alguma outra?___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Relação Baía de Guanabara X Ilha do Governador

[thundercel]

Agradeço a informação Arlindo e se não é o problema da coastline onde será que 
está o erro que fez com que a Baía tampasse a Ilha?

Voltei a estaca zero na pesquisa.

From: Arlindo Pereira 
Sent: Tuesday, September 22, 2015 4:44 PM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]Relação Baía de Guanabara X Ilha do Governador

É isso mesmo: "Do not tag nodes or relations with natural=coastline." 
http://wiki.openstreetmap.org/wiki/Tag:natural%3Dcoastline 

O wiki menciona ainda que "Tagging the coastline is a bit different than with 
all other features in OSM and you should be careful to get this right."

Vou editar a wiki para deixar mais claro que o tagueamento deve estar na linha, 
e não como relação.

[]s

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

Re: [Talk-br] Relação Baía de Guanabara X Ilha do Governador

[thundercel]

Arlindo,
o problema é maior e não creio que será corrigido no próximo pbf.

Analisando os dados da Ilha do Governador no OSM, constatamos que esse usuário 
alemão, de nome aportuguesado André68, pelo changeset 
https://www.openstreetmap.org/changeset/34188829 não só incluiu o coastline nos 
ways como também alterou os limites da Ilha do Governador.

Essa alteração feita por ele acarretou ficarem ruas dentro da Baía de Guanabara 
e inúmeros outros erros de menor significância.

Observe que o trecho https://www.openstreetmap.org/way/371670281 por ele 
alterado fez com que a rua https://www.openstreetmap.org/way/49804715 
entroncasse a rua https://www.openstreetmap.org/way/49712023 dentro d'água.

Observe também como ficou o pier https://www.openstreetmap.org/way/71756434 que 
agora não chega mais à terra. Pier flutuante?

Observe o way https://www.openstreetmap.org/way/71756436 que passou também a 
ser pier flutuante. Olhe onde o pier termina na terra e onde está a linha da 
costa;

Se ele foi corrigir uma coisa estragou inumeras outras. 



From: Arlindo Pereira 
Sent: Tuesday, September 22, 2015 6:12 PM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]Relação Baía de Guanabara X Ilha do Governador

Então, o problema é justamente que a tag natural=coastline não pode ficar na 
relação; ela tem de ficar nas vias (mesmo que as outras tags, que definem a 
ilha, nome, etc etc fiquem na relação). 

O usuário alemão corrigiu o problema, mas somente depois da geração do pbf.

Acredito que no próximo pbf gerado o problema já esteja corrigido, portanto.

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

Re: [Talk-br] Relação Baía de Guanabara X Ilha do Governador

[thundercel]

Nelson,
saberia então informar quem alterou a linha da costa na Ilha?

-Mensagem Original- 
From: Nelson A. de Oliveira

Sent: Tuesday, September 22, 2015 6:56 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br]Relação Baía de Guanabara X Ilha do Governador

2015-09-22 18:48 GMT-03:00  :

Analisando os dados da Ilha do Governador no OSM, constatamos que esse
usuário alemão, de nome aportuguesado André68, pelo changeset
https://www.openstreetmap.org/changeset/34188829 não só incluiu o 
coastline

nos ways como também alterou os limites da Ilha do Governador.


Ele não alterou geometria.
Só corrigiu o coastline.
Não tem alteração em http://nrenner.github.io/achavi/?changeset=34188829


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

[Talk-br] Relação Baía de Guanabara X Ilha do Governador

[thundercel]

Amigos,
ao compilarmos o mapa Cocar na data de hoje identificamos que a Ilha do 
Governador – RJ foi encoberta pela Baía de Guanabara. Estranhamos que somente a 
Ilha do Governador foi encoberta, as demais ilhas da baía de Guanabara e que 
constam da relação da Baía como membros inner não o foram.

Na tentativa de identificação do problema constatamos que o grupo criado e 
informado em http://www.openstreetmap.org/user/Nighto/diary/35888 está 
executando um excelente trabalho de importação de dados de bairro do Rio de 
Janeiro, entretanto acreditamos que a alteração feita em 
http://www.openstreetmap.org/relation/1964267 acarretou um problema,na Ilha do 
Governador de ser encoberta pelas aguas da Baía de Guanabara e somente ela 
porque as demais ilhas não foram.

Identificamos que a Ilha do Governador está formatada como multipoligono em 
http://www.openstreetmap.org/relation/5519132#map=14/-22.8049/-43.2109 e que 
seus membros outer estão incluídos como inner na relação da Baía de Guanabara, 
o que na nossa opinião é normal.

Estamos quebrando a cabeça e ainda não identificamos onde está o problema. 
Alguém poderia nos auxiliar?

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

Re: [Talk-br] boundary Estados Rio de Janeiro e Minas Gerais

[thundercel]

Agradecemos Nelson.

Aguardaremos o geofabrik disponibilizar hoje a noite o PBF com essas 
alterações para compilarmos e disponibilizarmos novo mapa Cocar.


[]s
Marcio

-Mensagem Original- 
From: Nelson A. de Oliveira

Sent: Saturday, August 1, 2015 10:50 AM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] boundary Estados Rio de Janeiro e Minas Gerais

Arrumei essa área.
Se tiver mais alguma coisa depois eu vejo na segunda.


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

Re: [Talk-br] boundary Estados Rio de Janeiro e Minas Gerais

[thundercel]

Agradecemos Nelson,
até analisamos a possibilidade de corrigirmos, mas é um longo trecho de 
fronteira.

Pelo que identificamos o changeset mexeu no Rio Preto (  
https://www.openstreetmap.org/way/30639074 ) que é membro de inumeras relações 
boundary, entretanto foi deixado o https://www.openstreetmap.org/way/30638691 
que também é membro dessas mesmas relações acarretando uma duplicidade de 
boundarys na região, por vezes se cruzando e outras não fechando o 
multipolígono.

[]s
Marcio 




-Mensagem Original- 
From: Nelson A. de Oliveira 
Sent: Saturday, August 1, 2015 8:41 AM 
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br] boundary Estados Rio de Janeiro e Minas Gerais 

2015-08-01 1:55 GMT-03:00  thunder...@gpsinfo.com.br:
 Seria o caso de reverter?

Reverter não.
Vou dar uma olhada.
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] boundary Estados Rio de Janeiro e Minas Gerais

[thundercel]

Amigos,
quando da compilação do mapa Cocar os estados do Rio de Janeiro e Minas gerais 
deixaram de ser indexados.

Analisando o motivo identificamos que ao Norte do estado do Rio de Janeiro e 
Sul de Minas Gerais as fronteiras estão duplicadas e se cruzando.

Observem em http://www.openstreetmap.org/way/84101046 

Aparentemente isso foi ocasionado pelo changeset 
http://www.openstreetmap.org/changeset/32811458

Seria o caso de reverter?

[]s
Marcio___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] tag ref

[thundercel]

Amigos,
mais uma vez o Aun e eu estamos discordando em changeset feito por mim ontem a 
noite após ter identificado a tarde erros em dois trevos da BR-101 ao trafegar 
do Rio de Janeiro – RJ para Barra de São Francisco – ES, onde me encontro no 
momento.

O erro identificado por mim era, quando do cruzamento, roteamento indevido 
pelos acessos do trevo e não pela rodovia.

Ao chegar em Barra de São Francisco – ES decidi de imediato entrar no OSM para 
tentar identificar a razão daqueles roteamentos indevidos e de imediato 
identifiquei que os acessos se encontravam com a classe primary e não _link 
como recomendado. Identifiquei também que existiam restrições de manobra 
incorretas impedindo o roteamento pela rodovia em cruzamento do trevo.

Durante o desgastante debate entre ele e eu foi por ele citado:

“ Todos os rodovias ES e em conforma dados do DER-ES e IJSN, o ref=* estou nas 
relações e não preciso ser inserido no cada trecho da rodovia.”

Quer dizer que o ref, estando na relação rota, não precisa estar na etiqueta 
ref da via:? Isso é novidade para mim.

Onde está isso definido?

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

Re: [Talk-br] tag ref

[thundercel]

Explico.

Até onde sei a tag surface, quando não definida, é assumido paved pelo 
sistema e comprovado por mim quando em roteamento por vias pavimentadas. Se 
é assumido pelo sistema não perco tempo em inserir nas inúmeras vias 
pavimentadas que tenho desenhado.


Agora aponte alguma unpaved não inserida por mim. Para essas me preocupo em 
inserir porque afetam diretamente o roteamento.


A tag ref não afeta o calculo de rota em si, mas facilita a navegação visual 
porque a sigla da rodovia é estampada na caixa hbox (highway-symbol:hbox) do 
mapa e ainda aparece nas instruções em texto das manobras quando da 
navegação GNSS.



-Mensagem Original- 
From: Aun Johnsen

Sent: Saturday, July 18, 2015 4:12 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] tag ref

Voce dizendo que eu não valorizo as vias desenhado, e que voce
valorizando eles tao muito.

Me esplica porque eu ainda não vi voce adicionar o tag surface? Desde
que viu o importância desse tag por roteamento eu sempre tentando
adiciona-lo onde ha dados pra identificar se e pavimentada
(surface=paved) ou não pavimentada (surface=unpaved). Se voce olhando,
maioria dos ways editado por mim os últimos 6 meses tem algum tag de
surface.

Eu deu tag ref=* menus prioridade, porque eles vai ser inseridos por
projetos que trabalho, e não afetando roteamento.


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

Re: [Talk-br] Esqueleto de projeto para classificação de vias urbanas

[thundercel]

Gerald,
mesmo existindo um padrão, sou de opinião que devemos revisa-lo, indentificando 
se algo nele requer melhoramento.

Como a maioria sabe nos dedicamos a disponibilização do mapa Cocar que é 
produzido pela extração da base OSM os dados importantes para navegação GNSS 
automotiva.

O roteamento provido pelos dados é por nós considerado como importante e por 
isso constantemente temos identificado falhas de roteamento devido a 
classificações indevidas de vias urbanas no OSM.

Já identificamos que em roteamento os aplicativos levam em consideração 
diversos fatores, entretanto o mais importante e de peso maior entre eles é a 
classe de via seguida da velocidade configurada.

Na página 
http://wiki.openstreetmap.org/wiki/Pt-br:How_to_map_a#Recomenda.C3.A7.C3.A3o_atual_.28esquema_br2013.29
 apresentada identificamos propostas e não um padrão definido para o Brasil que 
tem a malha viária com características diferentes de muitos outros países.

Está sendo comum identificarmos falhas de roteamento simplesmente porque o 
editor configurou a via em uma classe elevada, porém formatou a velocidade dela 
bem abaixo de uma esperada para aquele tipo de via.

Sou de opinião que deveríamos explorar mais esse assunto na tentativa de um 
padrão que mais se assemelhe a realidade brasileira, sabendo que dificilmente 
se poderá estabelecer um padrão que permita retratar a realidade e o perfeito 
funcionamento dos inúmeros aplicativos que irão se valer daquele padrão.

[]s
Marcio




From: Gerald Weber 
Sent: Monday, July 13, 2015 2:22 PM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br] Esqueleto de projeto para classificação de vias urbanas

Oi Ivaldo 

já temos um padrão:
http://wiki.openstreetmap.org/wiki/Pt-br:How_to_map_a#Recomenda.C3.A7.C3.A3o_atual_.28esquema_br2013.29


o que falta?

abraço

Gerald

2015-07-12 19:19 GMT-03:00 Ivaldo Nunes de Magalhães ivald...@gmail.com:

  Saudações a todos. Apesar de não estar com muito tempo, gostaria de iniciar 
uma discussão sobre classificação de vias urbanas (tema espinhoso, mas 
urgentemente necessário, devido falta de um padrão). Isso porque estou 
trabalhando na delimitação dos bairros de Campo Grande/MS - cidade onde resido 
- e já me deparei até com Auto Estrada no meio da cidade, quando sabemos que 
isso não existe. Tenho corrigido algumas coisas, mas é complicado trabalhar sem 
parâmetros.

  Além de correções e classificação de vias não ser o meu foco no osm, as vezes 
acabo fazendo (como agora) porque no andamento de um projeto não dá para se 
omitir ao ver algo incorreto ou fora do padrão, embora ele ainda não esteja 
definido. 

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

Re: [Talk-br] Roteamento urbano, falta do etiquetas e soluções.

[thundercel]

Aun,
infelizmente meu tempo anda escasso devido aos preparativos para uma longa 
viagem que farei pelo Espirito Santo, com estimada de saída na próxima 
quarta-feira, mesmo assim não poderia deixar de responder e opinar  sobre 
sua mensagem.


Sabemos que o roteamento leva em consideração diversos, fatores entretanto 
não podemos deixar de considerar que dentre esses fatores o mais importante 
é a classe da via quando não configurada com velocidade máxima. Não 
configurada com velocidade o sistema emprega a default para aquela classe e, 
consequentemente, o roteamento opta pela via de classe mais elevada.


Na minha opinião um editor não deve somente levar em consideração o padrão 
quando esse bem conhece a região que está mapeando. O bom senso deve atuar 
na classificação da vias.


Bem sabemos que a rota de Iconha para Serra, ou vice versa, é mais rápida em 
se trafegando pela BR-101 até porque construíram a BR-101 Estrada do 
Contorno para desafogar o transito de cruzamento por dentro de Vila Velha e 
da grande Vitória.


Não podemos e não devemos analisar friamente os resultados de diferença de 
tempo trafegando pela BR-101 ou pelas vias urbanas de Vitória e Vila Velha. 
O volume de tráfego, semáforos e outros limitadores de velocidade nunca 
permitirão o desenvolvimento da velocidade máxima permitida na via. Não 
podemos também deixar de levar em consideração que uma é rodovia e as outras 
são vias urbanas.


[]s
Marcio



-Mensagem Original- 
From: Aun Johnsen

Sent: Sunday, July 12, 2015 5:47 PM
To: OSM talk-br
Subject: [Talk-br] Roteamento urbano, falta do etiquetas e soluções.

Eu postando isso porque um assunto um bom tempo atras onde o Marcio
(Thundercel) reclamou sobre problemas de roteamento no Espírito Santo,
principalmente trecho BR-101 Guarapari - Serra, onde roteamento sair
do BR e passa ES-060 no municípios Gurapari - Vila Velha - Vitória.

Desde o discussão anterior eu tentei investigar isso, esse mensagem
pode vira TL;DR, mas se voce ha problemas de roteamento
(principalmente urbano) deve continuar ler aqui.

Em abril eu passei os trechos mencionados various vezes e gravou para
analise. Esse fim de semana eu passei fazer analise dos trechos
siguntes: BR-101 Trevo Guarapari - ES-060 Contorno Guarapari - Pedágio
Guarapari/VV - Terceira Ponte VV/VIX, e Contorno Guarapari sentido
Anchieta. Resultado esse analize: 3 radares adicionado (2 de 80km/h
localiçado entre Guarapari e VV, e um de 60km/h a frente do presidio
no Contorno Guarapari sentido Anchieta), adicionou trecho do
velocidade reducido a frente posto Policia Militar Galpao do Transito
nº 13 em Barra do Jucu/Vila Velha, 150 metros de 40km/h em acordo com
dados recolidos no Mapillary, e uns 10-15 semáforos

Quando o assunto fui levantado primeira vez, o diferencia em distance
e tempo no um rota do teste entre Iconha e Serra [0] deu trecho urbano
2km mais curto e 5 minutos mais rápido. Ontem testei mesmo trecho de
novo (antes do mandar os últimos mudanças) e ha 2km e 3 minutos
diferencia entre os dois. Meu calculo baseado por conhecimento do
perfil de roteamento do OSRM [1] indicando que aumento ~60 segundos o
tempo passa o setor urbano, então credito que o OSRM ainda vai me
manda pelo ES-060.

Tentei investigar como o roteamento funciona dentro aparelhos
(prioridade das estradas, penalidade do obstáculos e trevos entre
outro), isso e um segredo bem guardado, mas pelo quem uso aparelhos do
Garmin com mapas do OpenStreetMap, maioria desses e criados por
aplicativo mkgmap [2], e segundo documentação mkgmap traduzindo nossos
etiquetas para os etiquetas road_class e road_speed, ambos usando
numero decimais entre 0 e 7. Para mkgmap não dar diferencia se o
velocidade da estrada e 60km/h ou 50km/h, e conhecendo esse eu entendo
um pouco mais sobre roteamento no aparelho.

Pelo perfil do OSRM e muito mais fácil arrumar problemos, porque os
valores e em aberto. OSRM usando um formula para achar o velocidade
certo. Se não ha maxspeed, ele divinando um valor baseado por tipo
highway, depois reduzindo isso baseado por tipo de superfície e
smoothness. No Garmin pelo que entendo o road_class e road_speed
junto com um bandeira se e pavimentado ou não. Parecendo que o valor
padrão do pavimentação e pavimentada, assim para pode utilizar o opção
evitar estradas de terra no aparelho e muito importante que o
etiquete surface= tem valor, unpaved/paved e suficiente, e no verdade
fora desses valores somente sett ou cobblestone faz sentido nas
estradas.

Eu nao conseguindo achar penalidade do semáforos, placas de para, e
outros obstáculos de transito no Garmin, no OSRM ha 2 segundos
penalidade por semáforos. Pelo que intendo o mkgmap somente ligando o
etiqueta highway=traffic_signal com o simbolo do semaforo, e depende
do aparelho para dar o penalidade.

Para melhorar o roteamento e importante tenta entender o que símbolos
que dar penalidade, e identificar o que etiqueta no OSM representando
esse símbolo. Esses símbolos pode ou não ser gráficos. Não

Re: [Talk-br] Roteamento urbano, falta do etiquetas e soluções.

[thundercel]

Aun,
na minha opinião o que está penalizando o roteamento são as classes de vias 
urbanas e as velocidades.


Cito isso porque no mapa Cocar o roteamento está semelhante ao visto pelo 
OSRM e nele não compilamos semáforos porque para navegação automotiva Garmin 
esses não são úteis. São úteis os semáforos com câmera, os que tem sensor de 
avanço.


Com isso posso deduzir que os semáforos, pelo menos para roteamento Garmin, 
não influenciam porque em nosso mapa Cocar eles não existem e, 
consequentemente, o roteamento não os considera empregando esse mapa no GPS.


-Mensagem Original- 
From: Aun Johnsen

Sent: Tuesday, July 14, 2015 1:09 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br]Roteamento urbano, falta do etiquetas e soluções.

Marcio

Ja vendo no OSRM que ha algum coisas ajudando, por exemplo ele não
mais sair no estrada do chão para o ES-060, mas continua no BR-101 ate
o Trevo do Guarapari, também chegando Vitoria ele não mais utilizando
Reta da Penha (Avenida N.S. da Penha), mas pego o Avenida Dante
Michelini ate Avenida Norte - Sul. Isso indicando que aumentar as
semáforos no Reta da Penha deu certo, agora preciso fazer levantamento
nos avenidas NS dos Navegantes, Dante Michelini e Norte-Sul para
adicionar os semáforos ali

Alem disso, o discussão no meu issue do OSRM [0] deu ideia do
penalizar vias urbanas, por exemplo redução do velocidade onde passa
pelo landuse=residential. Isso não vai resolve roteamento nos
aparelhos mas pode ajuda em planejamento antes de viagem.

Tambem mandou emails para o grupo de cartografia Garmin para tenta
entender roteamento nos aparelhos. Se ha algum coisas que pode fazer
no stylesheets ou nos dados para melhorar isso. Ainda não ha resposta
do Garmin.

Se pode ajudar com roteamento, precisamos um etiqueta de garafamento,
o 3° Ponte geralmente tem garafamento pelo manha e tarde, em ambos
sentidos, e deve ser evitado menus por roteamento entre VV/VIX.

Mesmo precisamos mais levantamento/dados para resolver isso.

[0] https://github.com/Project-OSRM/osrm-backend/issues/1414

On 7/14/15, thunder...@gpsinfo.com.br thunder...@gpsinfo.com.br wrote:

Aun,
infelizmente meu tempo anda escasso devido aos preparativos para uma longa
viagem que farei pelo Espirito Santo, com estimada de saída na próxima
quarta-feira, mesmo assim não poderia deixar de responder e opinar  sobre
sua mensagem.

Sabemos que o roteamento leva em consideração diversos, fatores entretanto
não podemos deixar de considerar que dentre esses fatores o mais 
importante

é a classe da via quando não configurada com velocidade máxima. Não
configurada com velocidade o sistema emprega a default para aquela classe 
e,

consequentemente, o roteamento opta pela via de classe mais elevada.

Na minha opinião um editor não deve somente levar em consideração o padrão
quando esse bem conhece a região que está mapeando. O bom senso deve atuar
na classificação da vias.

Bem sabemos que a rota de Iconha para Serra, ou vice versa, é mais rápida 
em

se trafegando pela BR-101 até porque construíram a BR-101 Estrada do
Contorno para desafogar o transito de cruzamento por dentro de Vila Velha 
e

da grande Vitória.

Não podemos e não devemos analisar friamente os resultados de diferença de
tempo trafegando pela BR-101 ou pelas vias urbanas de Vitória e Vila 
Velha.

O volume de tráfego, semáforos e outros limitadores de velocidade nunca
permitirão o desenvolvimento da velocidade máxima permitida na via. Não
podemos também deixar de levar em consideração que uma é rodovia e as 
outras

são vias urbanas.

[]s
Marcio



-Mensagem Original-
From: Aun Johnsen
Sent: Sunday, July 12, 2015 5:47 PM
To: OSM talk-br
Subject: [Talk-br] Roteamento urbano, falta do etiquetas e soluções.

Eu postando isso porque um assunto um bom tempo atras onde o Marcio
(Thundercel) reclamou sobre problemas de roteamento no Espírito Santo,
principalmente trecho BR-101 Guarapari - Serra, onde roteamento sair
do BR e passa ES-060 no municípios Gurapari - Vila Velha - Vitória.

Desde o discussão anterior eu tentei investigar isso, esse mensagem
pode vira TL;DR, mas se voce ha problemas de roteamento
(principalmente urbano) deve continuar ler aqui.

Em abril eu passei os trechos mencionados various vezes e gravou para
analise. Esse fim de semana eu passei fazer analise dos trechos
siguntes: BR-101 Trevo Guarapari - ES-060 Contorno Guarapari - Pedágio
Guarapari/VV - Terceira Ponte VV/VIX, e Contorno Guarapari sentido
Anchieta. Resultado esse analize: 3 radares adicionado (2 de 80km/h
localiçado entre Guarapari e VV, e um de 60km/h a frente do presidio
no Contorno Guarapari sentido Anchieta), adicionou trecho do
velocidade reducido a frente posto Policia Militar Galpao do Transito
nº 13 em Barra do Jucu/Vila Velha, 150 metros de 40km/h em acordo com
dados recolidos no Mapillary, e uns 10-15 semáforos

Quando o assunto fui levantado primeira vez, o diferencia em distance
e tempo no um rota do teste entre Iconha e Serra [0] deu trecho

Re: [Talk-br] Opinando 2

[thundercel]

Tarcísio,
não divulguei nada a respeito do colaborador inicial que motivou minha 
edição no Trevo porque esse exerce um importante cargo público em Roraima, 
não quer ser identificado e tampouco tem disponibilidade de tempo para 
qualquer atividade extra.


Ele é meu amigo pessoal e nos conhecemos fora desse mundo do GNSS.

Quanto a pescar e ensinar temos feito isso constantemente nos sites que 
administramos e também nos vídeos tutoriais que temos feito para orientar 
aqueles que tem algum tempo para nos ajudar.


[]s
Marcio

-Mensagem Original- 
From: Tarcisio Oliveira

Sent: Wednesday, July 8, 2015 1:25 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] Opinando 2
Thunder, thunder, thundercel acho uma boa você tentar fazer com que o
mapeador que te deu as coordenadas iniciar a mapear, pois ele poderá
consertar esse trecho futuramente quando as modificações forem sendo
feitas no trecho físico, aquela velha história do ensinar a pescar, e
também ele poderá inserir diversas outras coisas no seu bairro e também
na cidade.

Tarcisio
___


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

Re: [Talk-br] Opinando 2

[thundercel]

Obrigado Hélio,
espere também na resposta a existência do acesso em 
https://www.openstreetmap.org/way/358575744 que foi desenhado por mim 
recentemente e etiquetado em construção. Segundo a mídia esse acesso foi aberto 
ao tráfego no ano passado. Veja em 
http://newsrondonia.com.br/noticias/transito+der+abre+passagens+sob+a+br+364+na+regiao+do+trevo+do+roque/42394

Desenhei esse acesso de forma improvisada porque dele não tenho tracklog e 
tampouco imagem atualizada para referência. Quando retirado da etiqueta em 
construção é bem provável que requeira alinhamento.e por isso é bem provável 
que requeira alinhamento.

Segundo informações que tenho esse acesso foi aberto de forma prematura devido 
as inumeras ponderações dos habitantes de Porto Velho que saiam da cidade com 
destino a BR-364 sentido SW. 

Segundo notícias na mídia ele já se encontra aberto ao tráfego, mas decidi 
mante-lo com a etiqueta em construção para confirmar se está mesmo operacional 
e seu real traçado. Também enviei email ao Comandante da Base Aérea de Porto 
Velho perguntando sobre isso.

Interessante que a fonte ilícita (Google Maps) já estampa esse acesso.

Incrível a velocidade de atualização do Google nesse trevo. 
Veja em 
https://www.google.com.br/maps/place/Porto+Velho+-+RO/@-8.7714573,-63.8826919,19z/data=!4m2!3m1!1s0x92325b665998520b:0x75d0f25ad2c5198b

From: Helio Cesar Tomio 
Sent: Tuesday, July 7, 2015 1:15 PM
To: talk-br@openstreetmap.org 
Subject: [Talk-br] Opinando 2

Concordo com os comentários do Márcio Vinicius Pinheiro. 
Como resolver todo este debate e por um fim nestas discussões pouco produtivas?
Tomei a liberdade de enviar email para a Polícia Rodoviária, com print da tela 
com o trevo.
Se responderem, ponto final para o debate.
Quem tiver interesse, pode fazer o mesmo enviando para a prefeitura, 
departamento municipal de transportes,  bombeiro, ...
Faço isto não por que duvide do mapeador, muito pelo contrário, porque sempre 
foi uma pessoa empenhada no OSM, assim como todos que participam desta 
comunidade. 
Faço em defesa deste Fórum e da harmonia entre seus pares.
Debates, diferenças, são sempre bem vindos. Mas que sejam positivos e que 
resultem em campo fértil para que o OSM cresça e frutifique no nosso país.

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

Re: [Talk-br] Opinando

[thundercel]

Interessante sua resposta.

Quando você erra a culpa é do outro que lhe induziu ao erro.

Você aqui defendeu o mapeador local e naquela ocasião distorceu a edição feita 
pelo mapeador local mesmo estando em contato com ele na lista Cocar se valendo 
de imagens satélite desatualizadas e não confiando na informação do editor que 
reside no local (eu).

Já citei que não vou repassar a mensagem de colaboração que recebi sobre o 
Trevo de Porto Velho e tampouco o tracklog porque não gostei das mensagens 
iniciais questionando minha palavra.

Como informei fui questionado no changeset sobre a alteração e respondi a fonte 
LÍCITA que me fez editar. Mesmo tendo informado a fonte me solicitaram provas e 
isso, pelo menos para mim, é duvidar da minha integridade o que não aceito em 
qualquer fórum.

Se você aceita duvidarem da sua palavra é outra estória e não entro no mérito 
de caráter de quem quer que seja. Você construiu e tem o seu, eu o meu.

Não conheço o Marcio Vinicius Pinheiro que acabou de enviar mensagem para esta 
lista emitindo sua opinião, mas deixo registrado que ele já conta com minha 
admiração e respeito pelo que citou e que concordo com todas as palavras dele.

Como já tivemos, você e eu, sérios desentendimentos na lista Cocar agora quem 
vai se calar aqui serei eu e só responderei sobre qualquer fato relacionado com 
este assunto aqueles que respeitam os demais que voluntariamente contribuem com 
o OSM.

Não comentarei mais suas colocações e todos sabem que recentemente outro 
importante colaborador adotou também aqui essa postura com você.

From: Fernando Trebien 
Sent: Tuesday, July 7, 2015 11:33 AM
To: OSM talk-br 
Subject: Re: [Talk-br] Opinando

Com respostas desse tamanho não pode reclamar de TL;DR.

Naquela ocasião você me induziu ao erro com imagens que não representavam 
adequadamente o local. Com informação errada, eu só podia deduzir que você 
tinha se confundido. Você me informou corretamente muito depois da minha 
alteração, e eu então aceitei o que você fez, mas você não entendeu que me 
confundiu e desde então tenta dar a entender que estraguei o mapa 
intencionalmente, distorcendo completamente a situação. Deve ser a décima vez 
que você traz essa história à tona e que eu tenho que explicar exatamente a 
mesma coisa.

Na ocasião atual, uma edição num local onde você não esteve recentemente, só 
falta você copiar a mensagem do seu informante para resolver o impasse. Você 
diz que tem, mas nega compartilhá-la devido a questões morais pessoais. Se é 
assim posso inventar questões morais a torto e direito para defender qualquer 
coisa que eu faça também.
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Opinando 2

[thundercel]

Amigos,
acabei de receber as imagens aéreas do Trevo do Roque extraídas agora a tarde e 
desejaria compartilhar essas imagens com a comunidade.

Poderia eu fazer upload delas em um dos sites que administro, entretanto 
gostaria de compartilha-las no repositório do OSM, mas não sei como fazer.

Alguém poderia me dar uma dica?

Marcio.


From: Helio Cesar Tomio 
Sent: Tuesday, July 7, 2015 1:15 PM
To: talk-br@openstreetmap.org 
Subject: [Talk-br] Opinando 2

Concordo com os comentários do Márcio Vinicius Pinheiro. 
Como resolver todo este debate e por um fim nestas discussões pouco produtivas?
Tomei a liberdade de enviar email para a Polícia Rodoviária, com print da tela 
com o trevo.
Se responderem, ponto final para o debate.
Quem tiver interesse, pode fazer o mesmo enviando para a prefeitura, 
departamento municipal de transportes,  bombeiro, ...
Faço isto não por que duvide do mapeador, muito pelo contrário, porque sempre 
foi uma pessoa empenhada no OSM, assim como todos que participam desta 
comunidade. 
Faço em defesa deste Fórum e da harmonia entre seus pares.
Debates, diferenças, são sempre bem vindos. Mas que sejam positivos e que 
resultem em campo fértil para que o OSM cresça e frutifique no nosso país.




___
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] Opinando 2

[thundercel]

Aun,
não estão georreferenciadas.

Foram extraídas por um helicóptero da FAB agora a tarde e mostram como está 
a situação do Trevo hoje. Pelo menos elas refletem a situação atual de 
transito nele.


Por elas se pode identificar que meus desenhos estavam corretos e que 
refleti exatamente o que me foi passado pelo colaborador lá residente.

Os acessos por você incluídos não realmente existem.

O Trevo do Roque se encontra exatamente na zona de tráfego do aeroporto de 
Porto Velho e por isso o pessoal da Base Aérea de Porto Velho, a meu pedido 
e em aproveitamento dos vôos estão me ajudando.


Ainda irei receber outras imagens, mas dessa vez extraídas com avião.



-Mensagem Original- 
From: Aun Johnsen

Sent: Tuesday, July 7, 2015 7:15 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] Opinando 2

Marcio

Acho isso muito bom, se as imagens e georeferenciadas o melhor seria
compartilha-los pelo Mapillary [0] que tem plugins que mostrar as
imagens no JOSM e iD editoras.


[0] http://www.mapillary.com

On 7/7/15, thunder...@gpsinfo.com.br thunder...@gpsinfo.com.br wrote:

Amigos,
acabei de receber as imagens aéreas do Trevo do Roque extraídas agora a
tarde e desejaria compartilhar essas imagens com a comunidade.

Poderia eu fazer upload delas em um dos sites que administro, entretanto
gostaria de compartilha-las no repositório do OSM, mas não sei como fazer.

Alguém poderia me dar uma dica?

Marcio.


From: Helio Cesar Tomio
Sent: Tuesday, July 7, 2015 1:15 PM
To: talk-br@openstreetmap.org
Subject: [Talk-br] Opinando 2

Concordo com os comentários do Márcio Vinicius Pinheiro.
Como resolver todo este debate e por um fim nestas discussões pouco
produtivas?
Tomei a liberdade de enviar email para a Polícia Rodoviária, com print da
tela com o trevo.
Se responderem, ponto final para o debate.
Quem tiver interesse, pode fazer o mesmo enviando para a prefeitura,
departamento municipal de transportes,  bombeiro, ...
Faço isto não por que duvide do mapeador, muito pelo contrário, porque
sempre foi uma pessoa empenhada no OSM, assim como todos que participam
desta comunidade.
Faço em defesa deste Fórum e da harmonia entre seus pares.
Debates, diferenças, são sempre bem vindos. Mas que sejam positivos e que
resultem em campo fértil para que o OSM cresça e frutifique no nosso país.




___
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

[thundercel]

Não é esse debate que me referi e sim o que travamos na lista CocarDL no ano 
passado


-Mensagem Original- 
From: Fernando Trebien

Sent: Tuesday, July 7, 2015 3:17 AM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] Necessidade de intermediação

2015-07-07 2:32 GMT-03:00  thunder...@gpsinfo.com.br:

Não conhece!
As que conhece foram as apresentadas por mim e ligadas tão somente a
navegação GNSS em réplica a você por ter apresentado as suas e querendo se
prevalecer delas no debate.
Esqueceu?
Se necessário reproduzo aqui copia do debate.


Respondo apenas para o leitor casual tirar suas próprias conclusões.
Prefiro reproduzir links para discussões completas, não extratos
descontextualizados.

10º parágrafo: 
https://lists.openstreetmap.org/pipermail/talk-br/2014-January/005052.html

1ª parágrafo de resposta:
https://lists.openstreetmap.org/pipermail/talk-br/2015-July/010307.html
14º comentário do changeset (8º do usuário Thundercel):
http://www.openstreetmap.org/changeset/30210630


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

Re: [Talk-br] Opinando 2

[thundercel]

Aun,
atendendo minha solicitação as fotos aéreas foram extraídas a bordo de um 
helicóptero da FAB, na tarde de hoje, pilotado pelo Major Romulo Amaral.

Elas foram a mim encaminhadas conforme email recebido:

Cel Soares
Enviei o link das fotos no dropbox para o Sr
Aqui da BAPV não estou conseguindo enviar todas devido a velocidade da rede.
Assim que eu chegar em casa envio o resto das fotos.

Rômulo Amaral  Maj Av
Chefe da Seção de Operações do 2º/8º GAV 
Tel.: (69) 3211-9971 Cel.: (69) 9238-7999
28gavs3@bapv.intraer / 28ga...@fae2.aer.mil.br

Não existe imagem aérea do Trevo do Roque disponível na praça mais atualizada 
do que essas depositadas em http://cocardl.com.br/pv/

Quanto aos amigos da FAB ajudarem até podem, entretanto lembro que eles não 
devem criar missão para nos atender. Eles aproveitam a passagem sobre a área 
desejada quando em missão deles.

No caso do Trevo do Roque em Porto Velho se tornou fácil porque esse Trevo se 
encontra na área de tráfego do aeródromo de Porto Velho e por isso, qualquer 
aeronave militar da base Aérea de Porto Velho, chegando ou saindo, passa pelo 
trevo e não custa nada alguém a bordo tirar a fotografia do local.

O comandante da base aérea, Coronel Jean Carlo, irá fazer uma missão amanhã e 
também se comprometeu comigo a fazer novas tomadas aéreas do Trevo e me enviar. 
No caso dele será avião e não helicóptero.


-Mensagem Original- 
From: Aun Johnsen 
Sent: Tuesday, July 7, 2015 7:50 PM 
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br] Opinando 2 

Marcio

O Nelson tava me perguntando no IRC ha pouco tempo sobre onde voce
arrumou isso. Nos temos ferramentas para converter imagens verticais
(aéreas) para dados TMS em formato z/x/y.png que podemos utilizar como
camada no JOSM e outros editores, so que faltamos hospede para esses
imagens. Podemos ajuda em converter se voce pode hospeda-los.

Seus amigos no FAB pode ajuda fecha outros buracos nas imagens no
território Brasileira?

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

Re: [Talk-br] Opinando 2

[thundercel]

Aun,
com sua autorização então vou excluir os 3 acessos que não existem.

Esse Trevo ainda sofrerá muitas alterações porque irão construir ali 2 
viadutos. O DNIT, com recursos do Governo Federal, assumiu a gerencia da 
obra cuja conclusão está prevista para o primeiro trimestre de 2016.


Ficaram de me enviar o Projeto do Trevo e acredito que por ele poderemos 
muito melhorar ali o desenho.


[]s
Marcio

-Mensagem Original- 
From: Aun Johnsen

Sent: Wednesday, July 8, 2015 12:27 AM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] Opinando 2

Marcio

Obrigado pelo bela fotos, eles são contem muito informação valioso,
alem do trevo. Eles não e vertical que seria muito bom, mas ainda e
bem util.

Primeiro vou dizer que não vou editar o trevo, mas não e porque não
aceito que meu edição era errado, mas por caso do trabalho. Tenho um
conflito entre um empresa Francesa e outro empresa Cingapuriano, e
1200 toneladas de aço a cuidar, e não sei quando vai ha tempo. Marcio,
se voce editando trevo ser livre apagar os links que entrei
erradamente.

Com isso, eu ainda to opinião que não fui errado questionar o edição,
olhando perto dos imagens parecendo que trevo tive 2 ou 3 desenhos
diferente os ultimo 6 meses, ainda ha sombras onde passava veículos
antes que trecho atual fui pavimentada. Também consegui ver no um dos
fotos o retorno atual para eles que chegando BR-364 NO para SO.

Espero que quando vai ter tempo editar com foco de novo, que o trevo e
concertado ao forma atual, e eu pode adicionar os outros coisas que
vendo nas fotos, como outro posto gasolina, algum oficinas e
borracharias, um locadora, e um vendedor do veículos, se não algum
entrando isso antes. Eu não vai reclamar se isso ser inserido antes
que ter tempo.

Nota final, por caso desse obra infinito, seria bom deixar nota nos
objetos avisar outros mapeadoras sobre o status, que as imagens
verticais pode ser muito desatualizado, que o trevo mudar trecho
frequentemente, e talvez ate link para os fotos. Deixaria também um
arquivo LEIAME.txt ou similar juntos com os fotos explicando origem
das fotos e um declaração que nos podemos utiliza-los para o fins do
OpenStreetMap.

On 7/7/15, thunder...@gpsinfo.com.br thunder...@gpsinfo.com.br wrote:

Obrigado While,
a desconfiança de alguns estava me incomodando.

Essas imagens do local extraídas hoje comprovam que meu desenho, muito
questionado, feito de boa fé por orientação de um colaborador residente,
retratava e continua retratando a realidade de hoje no Trevo do Roque.

Só espero agora que o Aun exclua os 3 acessos por ele incluídos tendo como
referencia o Strava. Conforme havia eu informado antes, agora comprovado
pelas imagens aéreas de hoje, podemos observar que esses acessos realmente
não existem.

[]s
Marcio


From: Wille
Sent: Tuesday, July 7, 2015 10:45 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] Opinando 2

Oi, Márcio

Parabéns pelos contatos e pela mobilização para sanar esse problema!

abçs,
wille



___
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

[thundercel]

Adriano,

A existência de tracvklog na base oSM já foi citado por mim antes, mas o 
Fernando só le o que interessa a ele devido a sua “expertise”.

Depois eu que levo a exaustão. Também pudera se o interlocutor não le o que 
voce escreve.

From: Adriano Rosa 
Sent: Monday, July 6, 2015 12:14 PM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br] Necessidade de intermediação

uma ressalva quanto ao último parágrafo da mensagem do fernando: 
Outra saída para essa situação toda é aceitar que o que foi feito por

você é indefensável e portanto é mais seguro que seja revertido, pelo
bem da comunidade. Alguém com melhores condições de demonstrar a
licitude do método vai corrigir quando chegar a hora.
mesmo que o marcio não mostre o tracklog que ele recebeu, acho que não precisa 
reverter a edição, pois há tracklogs já incluídos que, ao menos, parcialmente 
demonstram o percurso atual no trevo.

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

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

[thundercel]

From: Fernando Trebien 
 Aí você que entra na minha área de expertise como se soubesse mais. Sou 
 mestre em computação, li várias versões desses algoritmos.

 O nó a que me refiro é o do grafo de roteamento. Não é o nó do mapa (com 
 coordenadas e tal). O nó do grafo de roteamento sequer tem coordenadas, 
 possui apenas propriedades abstratas como o tempo para atravessar uma linha 
 de uma ponta à outra, e a referência a essa linha daí sim  no mapa 
 geográfico.

Em momento algum entrei em sua área de “exertise”. Comentei que a teoria nem 
sempre é comprovada na prática.

Em se tratando de prática (testes de roteamento)  você está entrando em minha 
área de expertise, como se soubesse mais. Respeito sua “expertise e, por favor, 
respeite a minha.

Estamos em uma lista onde nem todos tem a sua expertise e por isso não cito 
nela “grafo”. A grande maioria o conhece como nó de roteamento e é assim que 
continuarei a denomina-lo em se tratando de uma lista com esta. 




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

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

[thundercel]

-Mensagem Original- 
From: Fernando Trebien

Sent: Tuesday, July 7, 2015 12:15 AM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] Necessidade de intermediação


Como disse, essa conversa é longa demais (TL;DR). É um esforço incomum
alguém TENTAR lê-la e intermediá-la. Em boa parte porque os
participantes não são concisos na forma de se expressar. Se perdi
algum pedaço, sou humano, nunca disse o contrário.


Pois é, perdeu o pedaço em que citei que já existe um tracklog na base OSM 
que retrata uma das novas vias no trevo e de acordo com o desenho que fiz.

Mesmo sendo humano, por que perdeu esse que é importante?


Agora, não omita informação para parecer mais correto do que é. Li que
esse tracklog disponível estava desatualizado e que era considerado
pouco útil devido às alterações recentes no local.


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.


Em momento algum questionei sua habilidade com testes de roteamento.
Mas sua interpretação do algoritmo estava claramente errada. De
qualquer forma, ambos os assuntos fogem ao foco principal do OSM.


Não sou programador e por isso não emprego, como você, termos técnicos.
Não considero que minha interpretação do algoritmo esteja errada. Interpreto 
o algoritmo de acordo com as observações que fazemos nos testes em campo.



Quanto ao comentário sobre expertise - como se sentiu com uma pessoa
argumentando com base em credenciais? Reflita. Acho que não gostou.
Não faça aos outros o que não querem que façam com você. Não aceito
alfinetadas gratuitas.


Credenciais?
Você nem conhece as minhas para falar isso. Talvez se surpreenda ao 
conhecer.




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

Re: [Talk-br] Opinando

[thundercel]

Interessante quando o Fernando, em resposta, cita:  Isso vale amplamente para 
o mapeador local .

Acredito que ele deve ter esquecido nosso primeiro entrave no OSM e que tenho, 
como administrador da lista Cocar, todo ele arquivado no servidor.

Quando ingressei no OSM, minhas primeiras edições ocorreram no bairro em que 
resido aqui na Ilha do Governador - RJ, ou seja, edições de um mapeador local.

Duas edições minhas, feitas no meu bairro, foram alteradas por ele e quando 
questionado por mim disse que eu estava errado em minhas edições. Que se 
registre que ele não conhecia e acredito, nem conhece o local por onde continuo 
trafegando diariamente.

Uma edição tratava-se da inclusão de uma rotatória onde insistia ele em dizer 
que não existia e a outra tratava de uma via de pedestre que corrigi porque 
passava por barreiras que impediam o transito de pedestre.

Foi exaustivo e desgastante o debate que tive com ele, mesmo indo eu aos locais 
e tirado as devidas fotografias.

Ambas edições foram alteradas por ele sem qualquer consulta a mim que as fiz.

A grande maioria aqui sabe e é constantemente relembrado aqui nesta lista que 
devemos resguardar o OSM, só permitindo que edições nele feitas tenham 
referência de fontes lícitas. Pelo menos para mim e a grande maioria dos 
responsáveis aqui nesta lista isso não precisa ser relembrado.

Devemos ter muito tato ao questionar um editor quanto a fonte empregada, ter a 
resposta e solicitar provas desse do que ele respondeu.

Infelizmente as atualizações das imagens do Bing e Mapbox não sofrem 
atualizações constantes na região do Brasil.

Infelizmente o IBGE não atualiza com frequência seus mapas.

Assim, muitas vezes, só nos resta contar com o extraído em tracklogs ou até 
extraído pela memória visual de um colaborador, ou nossa mesmo.

Se ficarmos presos ao que vemos no Bing ou outra fonte de referência 
desatualizada, teremos sempre um mapa desatualizado e acredito que não queremos 
isso.

Se observarem minhas edições, a grande maioria delas trata de sentidos de vias 
e nomenclaturas. Isso se deve porque os usuários do mapa Cocar nos enviam 
mensagens com colaborações a esse respeito. 

Cito um exemplo prático ocorrido comigo na ultima sexta-feira.
Aqui na Ilha do Governador - RJ, onde resido, criaram um enorme posto do DETRAN 
e o denominaram Posto Tubiacanga ( 
http://oglobo.globo.com/rio/detran-rj-inaugura-nesta-quarta-feira-maior-pista-de-treinamento-de-direcao-do-pais-14094831
 )
Quando lá fui para fazer vistoria em meu veículo, infelizmente não estava eu 
com o GPS e tampouco com meu celular que tira foto, mas mesmo assim, ao voltar 
para casa decidi desenhar a área do posto de acordo com minha memória visual 
pelo entendimento que mais vale uma importante área dessas no mapa do que nada 
ali.
Podem ver o desenho que fiz por memória visual e anotações em 
http://www.openstreetmap.org/way/358278962
Sem duvida essa área do posto aparecerá nas imagens satélites lícitas algum dia 
e entendo que quando aparecer qualquer um poderá corrigir as falhas existentes 
em meu desenho.

Como citei anteriormente esse novo trevo em Porto Velho me foi informado por um 
residente que gentilmente, a meu pedido, me passou um tracklog extraído por 
ele, ainda inexperiente em extração de tracklogs. Esse track foi gravado por um 
Garmin, no modo registro de viagem, que não é adequado para emprego, mas que 
serviu como referência do que a memória visual dele reportou.

Como ali estava desenhado no mapa uma grande rotatória que não existe mais, 
decidi editar desenhando a circulação pelo que me foi passado pela memória 
visual do colaborador e pelas inumeras reportagens que existem na NET sobre 
esse Trevo do Roque em Porto Velho.

Uma das vias desenhadas por mim no novo Trevo teve como referencia um tracklog 
já constante da base OSM e as demais as fiz de forma aproximada conforme me foi 
passado verbalmente.

Em paralelo decidi também pesquisar como esse trevo estava retratado nas fontes 
ilícitas e nelas identifiquei que o Waze e o Here já retratam o novo Trevo. 

[]s
Marcio


 

[]s
Marcio

-Mensagem Original- 
From: Fernando Trebien 
Sent: Monday, July 6, 2015 11:52 PM 
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br] Opinando 

2015-07-06 17:22 GMT-03:00 Helio Cesar Tomio hcto...@gmail.com:
 Assim,  entendo que a atitude correta é aceitar e manter a verdade do
 mapeador.

Isso vale amplamente para o mapeador local (só não vale se for pego no
ato plagiando uma fonte de dados), mas as coisas mudam de figura para
o mapeador remoto. Nesse caso, isso vale se não houver risco quanto à
legalidade do método pelo qual a informação foi obtida. Eu não quero
citar nomes (porque o tratamento seria igual independente da pessoa),
mas no debate recente o problema é que, não havendo registro da
comunicação boca-a-boca, sobraram só imagens de fontes cuja
legitimidade legal não foi demonstrada. Eu não tenho dúvidas de que o
autor agiu de boa fé, mas a verdade do mapeador  

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

[thundercel]

-Mensagem Original- 
From: Fernando Trebien

Sent: Tuesday, July 7, 2015 1:39 AM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] Necessidade de intermediação


Mas estava errada. Seus testes lhe apresentam um comportamento
observável, não verdades matemáticas. Você quer ter o direito de dizer
que estou errado, mas nunca aceita o direito dos outros dizerem que
você está errado quando foge à esfera do seu conhecimento.


Quer dizer que o raciocínio lógico matemático não pode ter argumentos 
equivocados?


A esfera do meu conhecimento no algoritmo Garmin se deve as observações 
feitas nos exaustivos testes realizados em campo de acordo com a s inumeras 
variáveis inseridas no mapa para observar o comportamento do navegador 
quando do roteamento.


Não disse em momento algum que você está errado, disso que você se prende a 
teoria e eu a pratica. Disse que minha experiência é prática e a sua 
teórica.



Conheço, você fez questão de apresentá-las logo que entrou no OSM. E
as repetiu diversas vezes desde então, inclusive nesta discussão. Não
demora a apresentá-las quando duvidam de algo que diz.


Não conhece!
As que conhece foram as apresentadas por mim e ligadas tão somente a 
navegação GNSS em réplica a você por ter apresentado as suas e querendo se 
prevalecer delas no debate.

Esqueceu?
Se necessário reproduzo aqui copia do debate.

Marcio 



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

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

[Marcio - Thundercel]

Uma coisa é o esperado de acordo com a teoria e outra o observado na pratica 
em exaustivos testes.



A criação do nó em si não interfere, a princípio, com o algoritmo.
Será um nó a mais a ser visitado enquanto o grafo é explorado pelo
algoritmo de roteamento.


O algoritmo, dentre outros, trata os nós e é por eles que ele traça a rota.

Já fizemos inúmeros testes de roteamento e identificamos que o roteamento, 
entre duas vias iguais, ele opta pela que tem menos nós.


Faça o teste chegando em um nó onde se abrem duas vias e que se fecham lá na 
frente, como um losango.

Divida um segmento de reta de uma das vias inserindo um nó nela.
Identificará que o roteamento se dá pela via que não tem o nó inserido.
Foi assim que nos testes constatamos a influência de partições de via em um 
roteamento.


-Mensagem Original- 
From: Fernando Trebien

Sent: Sunday, July 5, 2015 4:52 AM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] Necessidade de intermediação

2015-07-05 1:40 GMT-03:00 Marcio - Thundercel thunder...@gpsinfo.com.br:
Por outro lado lembro que classificação de vias e de velocidades 
interferem
no roteamento e, infelizmente, não dominamos ainda o algoritmo garmin. O 
que

sabemos sobre ele advém de exaustivos testes realizados.
Não estamos debatendo tempo e sim roteamento e tudo que interfere nele.
Como bem deve saber você o roteamento leva em consideração, além de 
outros,
a quantidade de nós empregados para unir os segmentos de reta na 
retratação

da via.
Ao se reduzir a velocidade de um trecho de via o editor é obrigado a 
dividir
a via de forma a poder no trecho dividido estabelecer a velocidade. Isso 
por

si só já afeta o calculo de rota por aquele trecho.


Afeta, mas muito pouco, pelo menos na minha compreensão de algoritmos
de roteamento.

O que acontece é que ele cria um novo nó no grafo de roteamento para
representar o trecho. O nó contem o tempo total para percorrer o
trecho, calculado dividindo distância por velocidade. (há variações em
que o nó contem ambas velocidade e distância e o cálculo do tempo é
feito durante o processamento, mas elas são matematicamente
equivalentes)

A criação do nó em si não interfere, a princípio, com o algoritmo.
Será um nó a mais a ser visitado enquanto o grafo é explorado pelo
algoritmo de roteamento.

O que acontece é que algoritmos diferentes usam heurísticas
diferentes. Algumas dessas heurísticas decidem descartar alguns nós
que eles acham que têm pouca chance de conduzir à melhor rota.
Heurística é um método matematicamente impreciso para chegar a uma
solução sub-ótima mais rapidamente. Se é impreciso, há heurísticas
melhores e piores. Uma heurística comum é visitar primeiro os nós
relativos às vias de maior classificação. Nesse caso, como a
classificação não foi alterada, o nó seria visitado mesmo tendo uma
velocidade mais baixa. Mas o Garmin pode usar alguma outra heurística
que eu desconheço.

Outro insight: explorar o gráfico requer somar esses tempos, trecho
por trecho. São milhares de operação de soma. Se o programa não for
bem construído, ele pode acumular erros numéricos ao somar milhares de
números. O OSRM me parece particularmente sensível a esses erros. O
Garmin geralmente opera num hardware limitado e talvez também seja
sensível (tratar desses erros numéricos requer usar mais memória).

Mais um insight: classificação interfere com esses algoritmos mais
simples que usam heurísticas. A classificação das vias não
interfere em nada com o algoritmo A* (a-estrela) puro, nem com o
algoritmo do OSRM. Por isso, classificações não devem ser alteradas
com vistas ao roteamento. No entanto, um bom método de classificação
serve bem a praticamente qualquer algoritmo de roteamento, não por ser
o objetivo da classificação, mas por ser efeito colateral dela.

Se, numa rota com vários quilômetros, a escolha de uma alternativa ou
outra depender de um trecho tão curto quanto o mencionado, é bem
provável que alguma dessas características esteja inteferindo no
resultado. Mas os mapeadores do OSM não podem fazer nada, e talvez nem
os desenvolvedores da aplicação sem ter que reescrevê-la por completo
para resolver algum problema mais profundo.

O que os roteadores prometem não é encontrar a melhor rota, mas uma
rota sub-ótima. Quanto mais longa a distância, maior o efeito desses
dois fatores (erro numérico e qualidade da heurística). Até mesmo o
Waze às vezes faz bobagem na tentativa de encontrar a melhor rota.

--
Fernando Trebien
+55 (51) 9962-5409

Nullius in verba.

___
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

[Marcio - Thundercel]

From: Fernando Trebien
Sent: Sunday, July 5, 2015 3:47 AM


Sem problemas. Caso você não tenha mais a cópia da trilha, seria
possível o residente contribuir essa trilha para o OSM pelo mecanismo
padrão de submissão das trilhas? Acho que isso sana todas as dúvidas.


Me perdoe, mas a partir do momento que minha edição foi questionada e minha 
palavra foi posta em duvida, não solicitarei e tampouco apresentarei 
qualquer tracklog do local. As provas de que fiz o correto virão com as 
atualizações das imagens satélites.
Se desejarem voltar o desenho para o estampado no Bing desatualizado, sem 
problema.
Já me desgastei muito com essa situação e perdi muito tempo justificando uma 
edição.
O mais interessante é que ficam se prendendo a detalhes e deixam de corrigir 
a ponte sobre o Rio Madeita ( BR-319 ) que se encontrava com etiqueta em 
construção e esqueceram de verificar que essa ponte já consta das fontes 
ilícitas e que foi inaugurada em 15/09/2014
conforme noticiado em 
http://g1.globo.com/ro/rondonia/noticia/2014/09/inaugurada-ponte-que-liga-rondonia-ao-amazonas-em-porto-velho.html
Corrigido o erro em http://www.openstreetmap.org/way/243298056 e só espero 
que eu não seja novamente questionado por ter editado e colocado a ponte em 
operação.



Sei que dá mais trabalho, mas para não ter que arquivar, e não ter que
se preocupar com as justificativas posteriores, poderia submeter as
trilhas ao OSM. Não precisa ser todas, só aquelas que podem esclarecer
polêmicas. Acredito que poucas das trilhas coletadas divergem da
imagem de satélite atual (as coisas mudam, mas geralmente só perto das
vias principais), então seriam poucas trilhas a submeter ao OSM.


Se observou atentamente já existe trilha de trecho desse novo trevo 
arquivada no OSM por alguém, mas de qualquer forma não é do meu feitio ficar 
arquivando dados para comprovar minha palavra. Poso errar sim, mas erro 
porque edito. Seria facil passar de editor para fiscal e talvez essa seja a 
melhor situação no OSM Brasil.




Também poderia não submeter, apenas guardá-las, e compartilhá-las em
caso de questionamento.

Guardo o que me interessa para futuras referencias.
Tenho auxiliado ao OSM por prazer e não tenciono começar a guardar provas 
das minhas edições porque deixa de ser prazer e passa a ser obrigação.



As etiquetas dos changesets são, a princípio, apenas informativas. O
objetivo da informação é permitir que outros mapeadores verifiquem a
informação que foi editada. Se você declara que fez survey, outro
mapeador pode lhe solicitar o tracklog ou fotos ou qualquer informação
que você tenha levantado, ou pelo menos entender que precisa confirmar
a informação em campo (ou seja, entender que ela não veio da imagem de
satélite).


A partir do momento que um mapeador declara em sua edição GPS;survey 
acredito nele e nunca pedirei comprovação do que ele editou. Quem ganha é o 
OSM porquemais um colaborador, voluntariamente, atuou no mapa.



Da mesma forma, se sua informação viesse de uma prefeitura, você
colocaria a prefeitura na etiqueta source. Isso informaria os outros
mapeadores onde procurar a informação para confirmar:
- sua veracidade; e
- sua correção


Dados obtidos em prefeituras, IBGE, Bing, mapbox, não pode ser comparado com 
survey.



Note que nem sempre questionar significa não acreditar em você. Ás
vezes o outro mapeador só quer saber se você transcreveu a informação
corretamente. Como disse, todos somos passíveis de erro, então o
questionamento é válido.


Creio que voce não atingiu minha ponderação.
Não sou contra questionamento, sou contra questionamento seguido de 
exp0licação e replicado com solicitação de prova em se tratando de 
GPS;survey.



Esse é o mesmo princípio pelo qual funciona a Wikipédia: nenhuma
informação fica lá sem que uma fonte seja citada para verificação. Se
a fonte não for fornecida, a informação pode ser removida por falta de
neutralidade. O OSM é a Wikipédia dos mapas - inclusive é assim que se
apresenta aos novos usuários. Tudo deve ser verificável, não somente
sob o ponto de vista da idoneidade, mas também do ponto de vista da
correção.


Não tem relação com survey.

Perfeito. Então o maxspeed no OSM está todo correto, mas o roteamento
dá uma rota inadequada. Curiosidade minha: é realmente inadequada, se
segue por um caminho mais rápido? (teoricamente, desconsiderando o
tráfego)

Sim, é inadequada porque transita por área urbana.
Gastaram muito dinheiro para fazer a BR-101 Estrada do Contorno.
Por ela que o roteamento deve passar.

Entendo. Poderia nos copiar a mensagem que ele lhe enviou, mesmo que
seja uma declaração dizendo tá igual à [fonte X]? Acho que basta.

Não.
Minha palavra nesse caso basta.


Daí o que eu faria é acrescentar uma etiqueta note na linha contendo
o link para a mensagem dele que você encaminhou pra cá. Dessa forma,
outros mapeadores podem verificar a informação. Note que eu colocaria
isso em note (um comentário informal) e não em source (a fonte
usada para verificar com certeza 

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

[Marcio - Thundercel]

From: Fernando Trebien
Sent: Sunday, July 5, 2015 4:31 AM


Todas não. Apenas as potencialmente polêmicas. A comunidade pode sim
julgar e discordar.
Não tenho duvida que a comunidade pode julgar e discordar de alguma edição, 
entretanto essa deve discordar pautada em alguma regra no OSM que foi 
descumprida pelo editor e não reverter os dados porque o editor deixou de 
apresentar tracklog de sua edição.



Dependendo do que chamas de análise, talvez não. Elas são, no
máximo, fontes de inspiração para que se priorize sua verificação
através de fontes lícitas.


As fontes lícitas são sempre empregadas, mas nada impede que o editor 
consulte como andam as fontes ilícitas.



Quando questionado, precisa. Espera-se isso de todos.


Me exclua desse todos,
Se isso for padrão OSM paro aqui minhas edições e vou desfrutar da minha 
aposentadoria e finalizar o projeto Cocar. 



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

[Talk-br] Necessidade de intermediação

[Marcio - Thundercel]

Amigos,
me perdoem, mas enquanto alguns discordam de um lado outros discordam de outro.

Alguém poderia intermediar o debate em 
http://www.openstreetmap.org/changeset/30210630 ?

Se torna muito difícil fazermos edições no mapa pautados em colaborações 
recebidas de outros e termos que ainda ficar justificando essas edições porque 
as fontes normais de emprego ainda não retratam as alterações feitas na malha 
viária.

Acreditava eu que quando se colocava o source:GPS;survey já se tornava 
implícito que não foi empregado o Bing, MapBox, IBGE ou outra fonte aceita pelo 
OSM.

Obrigado.

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

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

[Marcio - Thundercel]

Venho recebendo muitas informações de erros nessa área que comprometem o 
roteamento e aos poucos, com tempo, irei corrigir, se outro não o fizer antes.

Por exemplo:

A Avenida das Nações Unidas ( https://www.openstreetmap.org/way/358400706 ) é 
uma via de pista dupla e não pista simples de sentido duplo. Esse erro 
compromete o roteamento de todas as vias que nela se entronca pelo norte ou 
pelo sul.

A Avenida Raimundo Cantuária ( https://www.openstreetmap.org/way/338488263 ) só 
tem sentido único, de leste para oeste, até a Avenida das Nações Unidas, dela 
para oeste é via de mão dupla.

Para quem não sabe, a construção desse Trevo do Roque (nome dele) se arrasta há 
mais de 10 anos e foi até parar na justiça. Existe muita matéria na NET sobre 
ele.

A administração atual decidiu dar continuidade as obras e a circulação na área 
tem sido modificada constantemente devido as obras. Recentemente a Prefeitura 
abriu ao tráfego um novo acesso a BR-364 para quem trafega pela BR, sentido NW 
e deseja pega-la no sentido SW. Esse acesso passa por baixo dos viadutos.

Acabaram de incluir ali um acesso ( https://www.openstreetmap.org/way/358538171 
) que segundo informação que tenho ele não existe. Acredito que aquele que 
incluiu tenha certeza de que ele existe e não vou questionar se existe, ou não.

[]s
Marcio

-Mensagem Original- 
From: Aun Johnsen 
Sent: Saturday, July 4, 2015 4:18 PM 
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br] Necessidade de intermediação 

Marcio, lista talk-br

Primeiro meu pergunta e motivo para avisar no changeset fui duvida
sobre se roteamento realmente era possível, e vi Marcio tinha editado
no local. Eu poderia perguntar algum outros dos mapeadoras que
ideintificei como dbusse, mas como saber ele e alemão de armchair
mapping não poderia espera resposta inteligente dele.

No mesmo tempo que vi a problema de roteamento vi que tracklogs GPS
compartilhado no OSM não bati com Bing, significando que ha alterações
no local. Com isso eu vi que precisava melhor informação antes do
mexer, eu poderia rever pra situacao do Bing, que também e mesmo no
MapBox, mas com o evidencia do OSM-GPS isso seria ação errado e mais
conhecimento necessário, outro motivo para enviar mensagens para
Marcio.

Alem isso, eu confirei com o camada do Strava Heatmap também mostrou
falta do various partes nesse trevo, independente se for versão Bing
ou versão OSM-GPX ou como desenhado pelo Marcio. Para quem não
conhecer o Strava, muitos trackers esportivas, relógios, e similares
gravando pontos onde voce correr, passiando bicicletas e outros
atividades, e esses logs e visualicado nesse camada. Para uso aqui no
Brasil, muito pessoas usando esses aplicativas errados, e com isso dar
para identificar estradas também.

Depois muito discussão, e o Marcio resolvendo algum dos erros e faltas
que identifiquei, ainda ovei algumas erros, que tentei corrigir aqui
https://www.openstreetmap.org/changeset/32412378

Marcio, favor entra em contato com seus fontes no Porto Velho, para
eles verificar se meus edições e certo. Tudo esse seus discussão nesse
changeset seu for por caso do um pergunta sobre roteamento duvidoso.

Para volta ao assunto do do informação usado e compartilhado: No meu
opinião, tracklogs utilizado para atualizar a mapa sempre deve ser
compartilhados. Se não pode compartilhar o tracklog por motivos de
copyright não podemos utiliza-los para corrigir o mapa, em conforme da
licenciamento ODbL.

Para tira duvida sobre imagens Bing, MapBox ou outros imagens
verticais, que sempre pode ser desatualizados, sempre usando mais
camadas para compartilhar meu decisão a trazer ruas e estradas. Sempre
usando Bing e MapBox em conjunto, não confie totalmente em nenhuma
deles. Geralmente também tem OSM-GPX e Strava as overlay junto com
esses imagens verticais, e quando procurando problemas especificas de
roteamento também OSMI Routing.

As camadas IBGE eu uso quando procura informação especifica do que
pode tirar deles.

Nao sei se iD pode ter mais que um camada ativa, sei que Potlatch no
versão 1 não poderia e provavelmente também não em versão 2. Por isso
o único editor da mapa considerado para uso e o JOSM.
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

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

[Marcio - Thundercel]

Nelson,
com assessoramento de um residente editei esse novo trevo há 3 meses atrás.

De lá para cá a edição que fiz sofreu alterações inclusive com a inclusão de 
acessos inexistentes e acessos impróprios não permitindo inclusive o acesso 
citado que não permitia roteamento correto. Simplesmente editei toda a área 
novamente corrigindo a situação por mim deixada 3 meses atrás.


Nesses casos seria interessante identificar os autores de changeset e 
questionar a eles.


De qualquer forma não considero pertinente dar prosseguimento a pergunta e 
ainda duvidar da palavra do editor quando esse insere source:gps;survey, 
inclusive questionando a esse editor porque não foi compartilhado os 
tracklogs recebidos. Até onde sei compartilhar tracklog é recomendado, mas 
não obrigatório.


Apontar erros em uma edição é normal, mas não existindo erro, apontar que a 
edição não confere com as referencias satélite não concordo uma vez que o 
source inserido foi gps e survey e essa informação, até onde sei, supera 
qualquer outra fonte satélite de referência disponível.


-Mensagem Original- 
From: Nelson A. de Oliveira

Sent: Saturday, July 4, 2015 3:02 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] Necessidade de intermediação

2015-07-04 14:34 GMT-03:00 Marcio - Thundercel thunder...@gpsinfo.com.br:

Alguém poderia intermediar o debate em
http://www.openstreetmap.org/changeset/30210630 ?


Ele queria saber sobre essa situação do trevo:
http://i.imgur.com/RWtGdON.png

Que depois foi corrigido para isso:
http://i.imgur.com/nzQ6O1t.png

Antes de ser corrigido, o estado anterior dele estava bem errado (não
permitia roteamento corretamente).
Repare que quem vinha da rodovia primary não conseguia seguir para o
lado direito na trunk.

A dúvida dele era justamente sobre aquela situação inicial, se aquilo
estava realmente correto.


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

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

[Marcio - Thundercel]

Conforme já citei a você anteriormente e somente a titulo de ilustração porque 
as fontes não podem ser empregadas no OSM:

Tracklogs atualizados no trevo:

http://gpsinfo.com.br/images/portovelho2.jpg

Mapa Waze atualizado segundo informação do residente local:

http://gpsinfo.com.br/images/portovelho.jpg

Mapa Here atualizado no trevo também segundo informação desse mesmo residente:

https://www.here.com/?map=-8.77122,-63.88256,18,normalx=ep

Compreenda que esse Trevo vem sofrendo inúmeras alterações devido as obras e um 
histórico que se arrasta por anos. O DNIT assumiu as obras desse trevo depois 
que a Prefeitura não foi capaz de conduzi-las. Veja histórico disso em 
http://blogdocarloscaldeira.blogspot.com.br/2015/01/conheca-toda-historia-dos-viadutos-de.html

Compreenda também que estamos tratando de vias automotivas e não vias para 
bicicletas e tampouco tracklogs desatualizados extraídos por bicicletas podem 
valer de referência para se desenhar vias ou links automotivos.

O desenho que havia eu feito refletia as informações recebidas por mim de um 
residente local e você as está alterando por deduções e não vejo isso como 
correto.

Agora mesmo solicitei ao colaborador que lá reside o tracklog do acesso 
passando por baixo do viaduto que foi aberto ao tráfego na semana passada. 
Estou aguardando ele me retornar.

Se você cita que faço edições que não concorda também não concordo com muitas 
que você faz e nem por isso vou a você questionar a fonte de referencia 
empregada e mesmo informando eu replicar que não é verdade.

Creio que essas discussões também não levam a nada e como você citou, se 
pararmos para ficar debatendo essas pequenas situações deixaremos de corrigir 
os inúmeros erros ainda existentes no mapa. Como você também não vou questionar 
seus erros, vou corrigi-los diretamente, mas continuo aguardando a correção do 
roteamento incorreto pela ES-060 que você se prontificou a corrigir. Creio que 
pelo visto serei obrigado a corrigir as velocidades incorretamente incluídas em 
trecho da rodovia. 



-Mensagem Original- 
From: Aun Johnsen 
Sent: Saturday, July 4, 2015 6:48 PM 
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br] Necessidade de intermediação 

 Acabaram de incluir ali um acesso ( 
 https://www.openstreetmap.org/way/358538171 ) que segundo informação que 
 tenho ele não existe. Acredito que aquele que incluiu tenha certeza de que 
 ele existe e não vou questionar se existe, ou não.

Eu tentei mostra para voce tudo evidencia que esse link existe, como
voce não quer compartilhar seus fontes, e nem olhando o informação que
eu tentando mostra para voce, eu precisava editar o trevo para mostra
a voce.

Segundo Strava tem muito fluxo nesse link, e não credito que isso e
pessoas correndo ou pedalando.

Voce for la ver mesmo que esse link não existe? Eu procurando
Mapillary e outros fontes e não vejo nada contrario.

Sim, vejo ainda que tem muito dados para melhorar no local, mas voce
não queria acertar quando primeiro perguntou voce sobre problemas de
roteamento, independente se for voce ou outros pessoas quebrando, so
depois muito discussão voce editou. A mapa e cheia do erros e
problemas e em vez acertar algum coisa quando alertada voce decide
começar um guerra contra o pessoa que voce mostrando isso?

Muitos vezes eu vi voce fazer edicoes que não concordo, ou que acho
errado, e cada vez apontando algum coisa a voce sair com mesmo tipo
resposta.

Bom, as fontes voce tem talvez tem melhor conhecimento local, mas eu
adicionei esse link por causa do evidencia de fluxo no local. Se voce
não passou esse trevo mesmo, e não pode compartilhar dados provando o
existência ou falta do existência esse link eu não tem outro escola em
creditar que o evidencia que tem do fluxo dos veicules e valido.

Se cada vez eu apontando um erro a voce eu vou peder 2 dias com
discussão ate voce decide jogou na lista eu vou parar de apontar ao
voce os erros na mapa e somente concerta-los como acho certo, sem
avisar a voce. Eu poderia resolver esse situação rapidamente sem
gastar tudo esse tempo.


On 7/4/15, Marcio - Thundercel thunder...@gpsinfo.com.br wrote:
 Venho recebendo muitas informações de erros nessa área que comprometem o
 roteamento e aos poucos, com tempo, irei corrigir, se outro não o fizer
 antes.

 Por exemplo:

 A Avenida das Nações Unidas ( https://www.openstreetmap.org/way/358400706 )
 é uma via de pista dupla e não pista simples de sentido duplo. Esse erro
 compromete o roteamento de todas as vias que nela se entronca pelo norte ou
 pelo sul.

 A Avenida Raimundo Cantuária ( https://www.openstreetmap.org/way/338488263 )
 só tem sentido único, de leste para oeste, até a Avenida das Nações Unidas,
 dela para oeste é via de mão dupla.

 Para quem não sabe, a construção desse Trevo do Roque (nome dele) se arrasta
 há mais de 10 anos e foi até parar na justiça. Existe muita matéria na NET
 sobre ele.

 A administração atual decidiu dar continuidade as obras e a circulação na
 área

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

[Marcio - Thundercel]

Paciência tem limite.

Infelizmente não é a você que são dirigidos os erros do mapa.

Quer dizer que o emprego do gps survey só é válido se existir o 
compartilhamento do tracklog no OSM? Novidade para mim.

Quer dizer que outras fontes de referencia não licenciadas no OSM não podem 
servir ao editor como fonte alternativa e secundária de análise? Novidade para 
mim.

Se o HERE, WAZE, YAHOO e outras fontes de analise não podem ser empregadas por 
mim como consulta não sei o que estou fazendo aqui e porque estou debatendo 
esse assunto.

Quem citou Tracksource aqui? Não emprego e nunca empreguei o Tracksource como 
fonte  de consulta para minhas edições até porque ele contem mais erros que o 
OSM.

Sei muito bem que todas essas fontes citadas e não licenciadas no OSM não podem 
ser empregadas na etiqueta source, mas citar, desconsiderar e descartar 
consulta a elas para sanar duvidas é um procedimento seu, não meu.
Não descarto nenhuma delas quando faço analise de determinada área ou região. 
Se você descarta e não as considera, paciência.

Por gentileza e em prol dos demais exclua os acessos que incluiu no trevo por 
dedução sua e que não existem.

Se desejamos ter um mapa atualizado e confiável devemos primeiramente confiar 
naqueles que ainda estão se empenhando em ajudar ao OSM no Brasil.

Finalizo plagiando o dito pelo Blad em sua ultima postagem e que reflete também 
meu pensar:

Considero que toda pessoa que mapea age de boa fé, sem necessidade de 
questionamento, exceto em casos explícitos de vandalismo.
Atenciosamente,
Blademir Andrade - BladeTC



-Mensagem Original- 
From: Aun Johnsen 
Sent: Saturday, July 4, 2015 7:35 PM 
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br] Necessidade de intermediação 

On 7/4/15, Marcio - Thundercel thunder...@gpsinfo.com.br wrote:
 Conforme já citei a você anteriormente e somente a titulo de ilustração
 porque as fontes não podem ser empregadas no OSM:

 Tracklogs atualizados no trevo:

 http://gpsinfo.com.br/images/portovelho2.jpg

Vejo que spread e muito grande nesses tracklogs, mas pode ser por
ferramenta do visualização, esses tracklogs pode ser compartilhadas
para o OSM? do onde eles são disponíveis?
 Mapa Waze atualizado segundo informação do residente local:

 http://gpsinfo.com.br/images/portovelho.jpg

Nao conheco esse feramenta do visualisazao, os dados não e do OSM,
isso e do TrackSource? Acho que e do um projeto ou  outro de mapas
crowdsource com licença não compatível com OSM, não confia muito isso
porque pode ha mesmo erros de falta do levantamento. Que a link não
existe no TS ou outros fontes similares não significa que não existe.
 Mapa Here atualizado no trevo também segundo informação desse mesmo
 residente:

 https://www.here.com/?map=-8.77122,-63.88256,18,normalx=ep
Mapas Here também tem mesmo problema, mapas crowdsource sobre licença
não compativel mesmo não confiável

 Compreenda que esse Trevo vem sofrendo inúmeras alterações devido as obras e
 um histórico que se arrasta por anos. O DNIT assumiu as obras desse trevo
 depois que a Prefeitura não foi capaz de conduzi-las. Veja histórico disso
 em
 http://blogdocarloscaldeira.blogspot.com.br/2015/01/conheca-toda-historia-dos-viadutos-de.html

Isso e informação novo para mim, porque voce não divulgou isso
primeira vez? Blog do um politico aparentemente do Porto Velho, que
quer usar o problemas de terminar obras nesse trevo para fim deles,
esse pode dar mais luz sobre situação admito.
 Compreenda também que estamos tratando de vias automotivas e não vias para
 bicicletas e tampouco tracklogs desatualizados extraídos por bicicletas
 podem valer de referência para se desenhar vias ou links automotivos.

 O desenho que havia eu feito refletia as informações recebidas por mim de um
 residente local e você as está alterando por deduções e não vejo isso como
 correto.

 Agora mesmo solicitei ao colaborador que lá reside o tracklog do acesso
 passando por baixo do viaduto que foi aberto ao tráfego na semana passada.
 Estou aguardando ele me retornar.

Espero retorna dele, e se for posivel compartilhar os tracklogs dele
com o comunidade, vai ser muito util em disputas como esse, e talvez
podemos descobrir mais problemas do roteamento com isso?
 Se você cita que faço edições que não concorda também não concordo com
 muitas que você faz e nem por isso vou a você questionar a fonte de
 referencia empregada e mesmo informando eu replicar que não é verdade.

 Creio que essas discussões também não levam a nada e como você citou, se
 pararmos para ficar debatendo essas pequenas situações deixaremos de
 corrigir os inúmeros erros ainda existentes no mapa. Como você também não
 vou questionar seus erros, vou corrigi-los diretamente, mas continuo
 aguardando a correção do roteamento incorreto pela ES-060 que você se
 prontificou a corrigir. Creio que pelo visto serei obrigado a corrigir as
 velocidades incorretamente incluídas em trecho da rodovia.

Pelo roteamento do ES-060 e BR-101 entre Guarapari

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

[Marcio - Thundercel]

-Mensagem Original- 
From: Aun Johnsen 
Sent: Sunday, July 5, 2015 12:11 AM 

 So para dar um dica que muito vezes passa no meu trabalho: se não ha 
 evidencia, não existe”

Não sei se é questão de idioma, mas evidencie no inglês é prova que por sua 
vez não é evidência no idioma português.
'Evidência', em português, significa aquilo que é claro, inequívoco, muito 
visível, incontestável.
Apresentei  três evidências, não evidences, e mesmo assim decidiu você se 
valer de sua “evidência” deduzindo o que viu no Strava. O pior, editou se 
valendo dele. 

 To vendo que dados do este fonte que voce citando e mais certa que os fontes 
 que eu mostrando, voce comentou que um dos links que eu inseri não existe, 
 mas segundo Strava ha muito fluxo nesse link. como esse e meia do um trevo 
 onde ha obras eu não posso creditar esse e tao   muitos pedestres. 
 Obviamente os dados do Strava não tem valor, porque seu fonte, que voce não 
 pode compartilhar, sabe melhor.

Um dos links não. Você inclui os seguintes trechos que segundo informação por 
mim recebida não existem:
- https://www.openstreetmap.org/way/358538171
- https://www.openstreetmap.org/way/358538169
- https://www.openstreetmap.org/way/358538166

Inclusive esse terceiro já está errado porque é um trecho de sentido duplo 
conectando um trecho de sentido único.

 Eu tenho mesmo motivos para desconfiar em WAZE e HERE como TS

Desconfiar do TS também desconfio até porque conheço os inúmeros erros dele, 
mas desconfiar da minha edição pautada em informações de residente, do Waze e 
Here, quando esses apontam para a mesma situação, é outra estória. Prefere você 
desconfiar de todos esses e incluir acessos pautados em sua dedução do que vê 
no Strava. Interessante essa ação.

 Bom voce conheço esse trecho pelo seu amigo morando em Vila Velha, que voce 
 visitando regularmente, so em caso voce tem duvida, eu moro no Guarapari e 
 viaje muito, e por acaso esse trecho e entre meu casa e o aeroporto.

Sim e você sabe disso porque recentemente editei uma Rua em Vila velha que 
estava com nomenclatura incorreta e como fiscaliza todas as edições também no 
changeset dessa edição comentou e tive a oportunidade de ali informar que 
trafeguei pela rua no fim de semana e identifiquei o erro.

 Se 150 metros de 40km/h vai fazer muito diferencia pelo tempo? Acho que não. 
 Se o posto e do PM ou PRE e muito fácil verificar, como esse trecho em ambos 
 sentidos e documentado pelo Mapillary

Lembro ao nobre amigo que não são 150m e sim 500m a sinalização vertical para 
redução de velocidade para passagem a frente de posto policial rodoviário.
Por outro lado lembro que classificação de vias e de velocidades interferem no 
roteamento e, infelizmente, não dominamos ainda o algoritmo garmin. O que 
sabemos sobre ele advém de exaustivos testes realizados.
Não estamos debatendo tempo e sim roteamento e tudo que interfere nele.
Como bem deve saber você o roteamento leva em consideração, além de outros, a 
quantidade de nós empregados para unir os segmentos de reta na retratação da 
via. 
Ao se reduzir a velocidade de um trecho de via o editor é obrigado a dividir a 
via de forma a poder no trecho dividido estabelecer a velocidade. Isso por si 
só já afeta o calculo de rota por aquele trecho. 

 Quantos veze eu preciso esplicar, eu colhendo dados para melhorar o 
 roteamento urbano, com esse eu espero que resolver varias dos problemas que 
 dando roteamento pelo zona urbano nas gps do Garmin. Eu tentando também busca 
 informação sobre que tags que tem influencia
 desse roteamento para pode inserir dados certo na mapa. Os dados preciso ser 
 certas e adequadas.

Sim, já compreendemos isso, entretanto essa situação foi identificada em 
dezembro de 2014 e até o presente momento não identificamos solução a nível 
OSM. A nível renderizador já corrigimos, mas continuamos preocupados com os 
demais aplicativos que empregam roteamento.

On 7/4/15, Aun Johnsen li...@gimnechiske.org wrote:
 On 7/4/15, Marcio - Thundercel thunder...@gpsinfo.com.br wrote:
 -Mensagem Original-
 From: Aun Johnsen
 Sent: Saturday, July 4, 2015 9:56 PM
 To: OpenStreetMap no Brasil
 Subject: Re: [Talk-br] Necessidade de intermediação

Se voce quer entra em briga com pessoas sobre como voce mapeando, voce
pode manter seus tracklogs no seu computador ou ate apaga-los sem
compartilhar, mas esse so vai beneficiar seu ego do brigar, e não o
projeto ou comunidade. Eu compartilhando meus trilhos, e ativo no
Mapillary, e outros coisas que pode ajudar a comunidade em geral.
Provavelmente voce não vai ver as tracklogs que compartilho porque
publica-los como trackable, significando que eles são organizados
mas meu identificadora e segredo. Voce pode compartilhar assim, e isso
vai deixar tudo mundo acesso dos dados sem identificar voce
pessoalmente.

 É a sua opinião e respeito, entretanto minha formação é militar e por
 meio
 dela aprendi a sempre agir com lealdade e confiabilidade. Acredito no
 próximo

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

[Marcio - Thundercel]

Creio que você inverteu a ordem ao citar:

Lembro que no passado eu desfiz um trabalho seu, agindo de boa fé, e você me 
questionou até a exaustão. 


Tenho todo nosso debate aqui arquivado para relembrar se for necessário.

Vou desfez, sem qualquer consulta a mim,  uma edição que fiz em uma via do 
bairro onde resido e por onde trafego diariamente.


Questionei e você em replica disse que eu estava errado.

Apresentei fotos do local, legislação e tudo mais para poder lhe provar que 
o certo era eu.


Ali foi você que me questionou até a exaustão.

O caso do Aun é bem semelhante e esse questiona até a exaustão e o pior, 
põe em duvida a palavra do editor, o que para mim é inaceitável quando, não 
tendo eu mais o tracklog recebido, aponto fontes ilícitas de consulta. 
Ilícitas, ou não, não deixam de ser fontes de consulta que comprovam a 
veracidade dos fatos.


Por fim lembro que estamos aqui para colaborar voluntariamente com o OSM 
editando os erros existentes no mapa (que não são poucos) e ninguém gosta de 
ficar sendo questionado insistentemente por edições. Ser questionado é 
aceitável, mas duvidarem da palavra e das justificativas, não aceito.


Como tenho realizado muitas edições devido aos inúmeros reportes que recebo 
nos sites que administro e também por email, não são poucas as interpelações 
que recebo de edições feitas. Me parece até que o OSM Brasil tem mais 
fiscais do que editores. Será?


-Mensagem Original- 
From: Fernando Trebien

Sent: Saturday, July 4, 2015 8:44 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] Necessidade de intermediação

2015-07-04 20:04 GMT-03:00 Marcio - Thundercel thunder...@gpsinfo.com.br:

Paciência tem limite.


Verdade.


Finalizo plagiando o dito pelo Blad em sua ultima postagem e que reflete
também meu pensar:

Considero que toda pessoa que mapea age de boa fé, sem necessidade de
questionamento, exceto em casos explícitos de vandalismo.
Atenciosamente,
Blademir Andrade - BladeTC


Lembro que no passado eu desfiz um trabalho seu, agindo de boa fé, e
você me questionou até a exaustão. O Aun desfez um trabalho seu,
também agindo de boa fé, e você está fazendo o mesmo com ele. Me
parece conveniente essa interpretação seletiva dessa filosofia.

Sejamos colegas. Questionamentos são sempre bem-vindos, a quem quer
que seja. Precisamos ter o material para defender nossos mapeamentos
quando não está claro o que estamos fazendo (por exemplo, quando
diverge da imagem de satélite). Todos nós, sem exceção. Títulos e
honrarias não conferem autorização automática a todas as ações. Isso é
trabalhar em comunidade, sem hierarquias.

O questionamento só não faz sentido depois que o material já foi 
apresentado.


--
Fernando Trebien
+55 (51) 9962-5409

Nullius in verba.



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

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

[Marcio - Thundercel]

 encontra o Posto da Policia Rodoviária estadual ( 
http://www.openstreetmap.org/way/88221928 ) é de 40 km/h e não 80 km/h. O 
operador desse posto (sem etiqueta de operador) é a Policia Militar do 
Espírito Santo.



Para o BR-101, o velocidade variando entre 80 e 60, eu ainda preciso
analisar meus dados melhor para ter certeza que as trechos certos tem
80 e 60, mas não deve mudar muito, fora do um parte no Viana e
Cariacica esse trecho não tem semáforos, quase não ha radares.



Pegando um ponto no BR-101 na Serra e outro na Iconha, deveria no
ambos sentidos passa somente pelo BR-101, mas mesmo no modo mais curto
e mais rápido saindo do BR-101 por altura do Guarapari e passo pelo
ES-060, porque esse distancia e 2 quilômetros mais curto, e dar um
economia do tempo de quase 2 minutos (1m10s a 1m55s depende do
roteador), para resolver esse diferencia o BR-101 preciso ter um
velocidade maxima do mais que 180km/h ou o ES-060 menus que 40km/h ou
um coisa entre esses valores e o verdade.



Esse pode ser resolvido parcialmente com penalidade de roteamento, mas
pra isso precisamos entender esse assunto que e muito complicado.


Não é bem assim.
O roteamento está passando pelas vias urbanas de Vila Velha e pela grande 
Vitória.
Sabemos que as vias urbanas por onde ele está passando são congestionadas e 
intrafegáveis nas velocidades máximas estabelecidas.
Pela nossa analise corrigimos o problema a nível renderizador excluindo o 
trecho da ES-060 onde foi inserida a velocidade de 110 km/h ( 
http://www.openstreetmap.org/way/186840962 )
Essa inclusão não está errada, entretanto o algoritmo garmin interpreta esse 
trecho com velocidade elevada como melhor caminho para cruzamento de Vitória 
abandonando a BR-101. Ele não analisa que o roteamento prossegue pelas vias 
urbanas.
Lógico e não é necessário se repetir que o OSM serve para multi aplicações e 
que não se deve ele ser editado de acordo com as necessidades de roteamento 
de uma única aplicação (roteamento gps). Por essa razão que resolvemos o 
problema dropando a nível renderizador (não no OSM)a velocidade de 110 km/h 
desse trecho da ES-080.



On 7/4/15, Fernando Trebien fernando.treb...@gmail.com wrote:
2015-07-04 20:04 GMT-03:00 Marcio - Thundercel 
thunder...@gpsinfo.com.br:

Paciência tem limite.


Verdade.


Finalizo plagiando o dito pelo Blad em sua ultima postagem e que reflete
também meu pensar:

Considero que toda pessoa que mapea age de boa fé, sem necessidade de
questionamento, exceto em casos explícitos de vandalismo.
Atenciosamente,
Blademir Andrade - BladeTC


Lembro que no passado eu desfiz um trabalho seu, agindo de boa fé, e
você me questionou até a exaustão. O Aun desfez um trabalho seu,
também agindo de boa fé, e você está fazendo o mesmo com ele. Me
parece conveniente essa interpretação seletiva dessa filosofia.

Sejamos colegas. Questionamentos são sempre bem-vindos, a quem quer
que seja. Precisamos ter o material para defender nossos mapeamentos
quando não está claro o que estamos fazendo (por exemplo, quando
diverge da imagem de satélite). Todos nós, sem exceção. Títulos e
honrarias não conferem autorização automática a todas as ações. Isso é
trabalhar em comunidade, sem hierarquias.

O questionamento só não faz sentido depois que o material já foi
apresentado.

--
Fernando Trebien
+55 (51) 9962-5409

Nullius in verba.

___
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] classificação de subprefeituras.

[Marcio - Thundercel]

Ainda não tenho opinião formada a respeito até porque os aplicativos que 
conhecemos não descem a nível subdistrito.

Existe um debate interessante a respeito em  
http://forum.openstreetmap.org/viewtopic.php?id=26430 . Ele foi iniciado, mas 
não concluído.


-Mensagem Original- 
From: Nelson A. de Oliveira 
Sent: Sunday, June 14, 2015 1:21 AM 
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br]classificação de subprefeituras. 

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

Re: [Talk-br] Relação Cidade

[Marcio - Thundercel]

Aun Johnsen,
a relação admin_level=10 também deve ter um nó com papel label.

Marcio

-Mensagem Original- 
From: Lists

Sent: Saturday, June 13, 2015 10:05 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] Relação Cidade

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


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

Re: [Talk-br] Relação Cidade

[Marcio - Thundercel]

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

Re: [Talk-br] Relação Cidade

[Marcio - Thundercel]

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

Re: [Talk-br] Relação Cidade

[Marcio - Thundercel]

Blad, não compreendi.

A definição de Distrito é válida para todo o Brasil:

*
Significado de Distrito
s.m. Divisão administrativa e territorial de um município que pode conter um ou 
vários bairros.



*


Em http://produtos.seade.gov.br/produtos/500anos/index.php?tip=defi podemos 
identificar:



Distrito 
Divisão territorial e administrativa em que certa autoridade administrativa, 
judicial ou fiscal exerce sua jurisdição.

**



Um Distrito tem um administrador subordinado ao Prefeito do Municipio.



Um conjunto de bairros level 10 formando uma área suburbana e que não tenha 
administrador não caracteriza Distrito. 







From: Blademir Andrade de Lima 
Sent: Saturday, June 13, 2015 11:58 PM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br] Relação Cidade

É 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
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

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

[Marcio - Thundercel]

Aun Johnsen,
infelizmente não pode ver o vídeo. Nele mostro os problemas existentes no mapa 
do Brasil fornecido pelo http://garmin.openstreetmap.nl/

Os problemas existentes e ali mostrados são facilmente tratados a nível Mkgmap, 
em seus styles, o que infelizmente o mapa NL não faz, pelo menos para o Brasil.

Está você testando a indexação por Rua, entretanto o problema ocorre na 
indexação por cidade / estado e não por Rua.

Problemas de indexação por tipo de via ( Rua, Avenida, estrada, etc) são 
facilmente corrigidos pelo Mkgmap com o comando “x-split-name-index”. 
Renderizado com esse comando a busca por endereço se torna fácil sem a 
necessidade de se buscar digitando o tipo de via a frente do nome. Ele indexa 
com somente a digitação do nome, sem o tipo.

De qualquer forma volto a solicitar que seja padronizado o emprego de tags nas 
relações boundary e nos POI de city, town, etc.

Não existindo uma padronização se torna complicado a qualquer renderizador 
extrair dos dados alguma tag que vá refletir aquele objeto.

Para terem noção do problema cito como exemplo o emprego do admin_centre na 
relação boundary. 

Os desenvolvedores do Mkgmap, por nossa solicitação, criaram uma regra nele de 
quando da existência do admin_centre na relação boundary, que a função 
add-poi-to-area não criasse um POI virtual no centro geométrico da área. 

Com essa ação passamos a não mais ter o POI da cidade duplicado no mapa, 
entretanto em alguns lugares do Brasil continua essa duplicação simplesmente 
porque o membro admin_centre não está incluído em algumas relações boundary, em 
especial do estado de São Paulo.

Pelo que já lemos relação boundary no OSM é um fato relativamente recente em se 
comparando as outras funções. Talvez por isso o mapa para o Brasil ainda não 
foi totalmente ajustado as novas regras.

Outra situação foi a apresentada para São Carlos – SP e outras cidades do 
estado.

Muitos renderizadores ainda não tratam relações boundarys. Eles tratam os POI, 
os place=city, town, etc.

Se observarmos a maioria das cidades do estado de São Paulo estão vinculadas as 
correspondentes relações boundary como admin_centre, entretanto não existe o 
POI da cidade tratado isoladamente, fora da relação, como é tratado o POI de 
Concórdia – SC citado. Nele, se observarem, existe como resultado da busca a 
relação boundary e o POI city.

Vão dizer que o renderizador tem de se adaptar aos dados OSM e até concordo com 
essa ponderação, mas convenhamos que em não existindo um padrão fica difícil ao 
desenvolvedor do renderizador estabelecer uma regra para dos dados extrair o 
que é desejado.

Se desejamos alavancar o OSM no Brasil sou de opinião que devemos nos esforçar 
em padronizar o emprego de tags e identificar erros grosseiros existentes no 
mapa.

Felizmente mais utilizadores estão empregando o mapa COCAR 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

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 
Sent: Saturday, June 13, 2015 9:02 AM
To: OpenStreetMap no Brasil 
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, 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 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 

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

[Marcio - Thundercel]

Tarcísio,
parabéns pelo seu trabalho no Nordeste.

Até agora não recebemos nenhuma crítica e tampouco identificamos problemas 
de indexação por lá.


Já quanto a roteamento, que não tem relação com relação boundary, para o 
Nordeste recebemos críticas para a cidade de São Luis - MA. No mapa 
identificamos que o editor não se preocupou com sentidos (mão única), 
terminando a mesma via em sentido único e dando continuidade a ela em 
sentido duplo, sem nenhum acesso que permitisse ao condutor sair da via que 
terminava em sentido único contrário. Aos poucos estamos corrigindo os erros 
encontrados na cidade e incrementando com dados faltantes.


Sem empregar o overpass-turbo já havíamos identificado a falta ou exagero de 
algumas tags nas relações boundary, em especial do estado de São Paulo e é 
essa padronização que estamos aqui solicitando.


Gostei do dividir para conquistar.

[]s
Marcio



-Mensagem Original- 
From: Tarcisio Oliveira

Sent: Saturday, June 13, 2015 9:36 AM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] São Carlos, SP

thundercel se possível verifique a mesma situação com os estados do 
Nordeste, menos a Bahia(não editei por lá), pois verifiquei que quase todo o 
estado de são paulo falta algumas tags nas relações o que deve estar gerando 
esses erros.
Algumas cidades que podem estar corretas, Jundiaí, Itatiba, Itupeva e outras 
que podem estar errado Valinhos, Vinhedo e Louveira.
Se for isso mesmo, pode consertar o Estado todo com essa consulta 
http://overpass-turbo.eu/s/4li até mesmo os outros Estados ou então pegar 
todas as relações que apontaram esse problema no osmose 
https://etherpad.mozilla.org/9s9Xov2u2R e mesmo se não for esse o
problema, estão todos convidados a consertar essas relações, dividir para 
conquistar né?


Tarcisio Oliveira
___


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

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

[Marcio - Thundercel]

Aun Johnsen,

volto a comentar que no exemplo de Concordia – SC podemos observar no OSM que a 
cidade de Concordia é indexada isoladamente da relação boundary de Concordia.
Ali identificamos 2 indexações:
1 – Limite de Município tendo a cidade como admin_centre devido a relação 
boundary dela.
2 – somente a cidade devido ao place=town dela



Já para São Carlos e outras cidades do estado de São Paulo só existe indexação 
dos Limites administrativos. Não existe indexação das cidades isoladamente.

No vídeo que apresentei mostro o mapa do Brasil renderizado em 10/06/2015 e 
disponível em http://garmin.openstreetmap.nl/

Independente de empregar uma versão Mkgmap antiga o 
http://garmin.openstreetmap.nl/ não tem regra específica para o Brasil. Para o 
Brasil ele emprega os styles default do Mkgmap que por não serem 
personalizados, indexam as cidades (admin_level=8) dentro das Mesorregiões 
(admin_level=5), ou Regiões Metropolitanas (admin_level=6), ou Microrregiões 
(admin_level=7).

Como nos GPS não empregamos essas regiões, no mapa cocar comandamos no Mkgmap o 
“drop admin_level=5 =6 =7” dos dados baixados do OSM. Com isso a cidade é 
indexada dentro do estado e não da região admin_level mais próximo a abaixo 8.

Infelizmente não sou programador, sou aviador. Assim que aprendermos a 
renderizar um mapa para MAC forneceremos esse mapa para essa plataforma.

O importante é que estamos personalizando para o Brasil os styles do Mkgmap de 
forma a extrair e renderizar somente os dados empregados em GPS Garmin, 
entretanto está sendo difícil personalizar os styles se os dados existentes, em 
especial nas relações boundary, não estiverem padronizados.

[]s
Marcio

From: Lists 
Sent: Saturday, June 13, 2015 10:35 AM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br] São Carlos, SP

Marcio 

Concordo que precisamos padronizar

No seu exemplo de indexação do Concordia SC, bem no meu mapa do 29-03-2015 
também parecendo indexado similante como São Carlos SP. Credito que o solução 
do mkgmap não duplicar o POI do relação e mais recente que o versão mkgmap 
utilizado por garmin.openstreetmap.nl p gerar as mapas fim do marco.

Como infelizmente nao dar atualizar meus mapas, que com os argumentos agora 
seria bem interessante, não tem como ver se isso fui resolvido, e se o 
garmin.openstreetmap.nl continuaram usar um mkgmap antiga ou se eles resolvi 
atualizar também.

E bom que utilizadores do COCAR dar feedback para pode melhorar a mapa, mas 
falto um ferramenta global para isso, tem muitos contribuintes que poderia 
ajudar se for gerenciado num maneira próprio. Temos muitos atividades que 
poderia ser melhorado com um task-manager, mas por enquanto precisamos 
gerenciar tarefas entre nos mesmo.

Como ja disse muitos vezes, quando voce ha problemas com Garmin por um motivo 
ou outro, compartilhar informação sobre o que dar errado e o que voce esperava, 
para outros tenta reproduzir mesma, também como utilizador do Garmin quero mapa 
melhor. Eu não utilizando mapa COCAR por falta do arquivos em formato .gmap, 
que pode gerenciar diretamente entre meu computador (Mac) e meu aparelho GPS 
(Garmin Nüvi).

Em quanto voce nao adicionar esse opção .gmap voce pode passa qualquer 
propaganda sobre mapa COCAR e eu ainda não vai utilizar, e mesmo eu vou 
continuar adicionar dados no OSM em forma que opticimando meu uso do 
garmin.openstreetmap.nl 

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

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

[thundercel]

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/ ou 
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 onde 
nele aponto o problema empregando o mapa do Brasil renderizado no dia 
10/06/2015 pelo http://garmin.openstreetmap.nl/

[]s
Marcio

From: Lists 
Sent: Friday, June 12, 2015 8:32 PM
To: OpenStreetMap no Brasil 
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 compilado 29-03-2015, reproducido 
no BaseCamp e no meu Garmin Nüvi 50

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

Aun Johnsen

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

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

[thundercel]

Aun Johnsen,

quando identificamos o problema verificamos que as edições do POI e relação 
eram muito antigas.

[]s
Marcio


From: Lists 
Sent: Friday, June 12, 2015 4:44 PM
To: OpenStreetMap no Brasil 
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, thunder...@gpsinfo.com.br 
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 ) 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
a.. Limite de Município Concórdia, Microrregião de Concórdia, Mesorregião 
do Oeste Catarinense, Santa Catarina, Região Sul, Brasil
b.. 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
a.. 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
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

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

[thundercel]

Nelson,
já que reverteu a edição que fiz no POI de São Carlos solicito que corrija a 
posição do POI uma vez que o marco zero da Cidade de São Carlos - SP se 
encontra na Praça Dom José Marcondes Homem de Meloda, onde se encontra a 
Catedral de São Carlos Borromeu e não no quarteirão adjacente, onde foi 
recolocado.


[]s
Marcio

-Mensagem Original- 
From: Nelson A. de Oliveira

Sent: Friday, June 12, 2015 4:45 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] São Carlos, SP

2015-06-12 16:36 GMT-03:00  thunder...@gpsinfo.com.br:

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.


Márcio, mais uma vez: se está acontecendo algum problema no mkgmap,
pergunte antes de editar os dados no OSM.
A grande parte dos problemas anteriores não se encontrava no OSM.

Se o problema acontece no nominatim, da mesma forma, não mexa nos dados do 
OSM.

Teste com cidades perto de São Carlos (Araraquara, Ribeirão Preto,
etc) e verá que o resultado é exatamente o mesmo: apenas um resultado
é retornado.

O estado de SP inteiro não é indexado por acaso no mkgmap?
De várias cidades que testei todas retornam apenas 1 objeto no nominatim.

___
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

[thundercel]

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 
Sent: Friday, June 12, 2015 5:20 PM
To: OpenStreetMap no Brasil 
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 ?

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

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

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

ou aqui http://osmose.openstreetmap.fr/en/map/ ?


Aun Johnsen

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

[Talk-br] São Carlos, SP

[thundercel]

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
  a.. Limite de Município Concórdia, Microrregião de Concórdia, Mesorregião do 
Oeste Catarinense, Santa Catarina, Região Sul, Brasil

  b.. 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
  a.. 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

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

[thundercel]

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/ ) e ES ( 
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 
Sent: Friday, June 12, 2015 5:52 PM
To: OpenStreetMap no Brasil 
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 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

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

[thundercel]

Não compreendi.

A POI de Concordia –SC está assim formatado:

IBGE:GEOCODIGO420430105
addr:postcode8970
is_in:state_codeSC
nameConcórdia
placetown
population70720
sourceIBGE

A relação de Concordia _ SC assim está formatada:

IBGE:GEOCODIGO4204301
admin_level8
boundaryadministrative
nameConcórdia
sourceIBGE
typeboundary
wikipediapt:Concórdia

Essas formatações foram revisadas há 1 mes, tempo suficiente de propagação para 
o nominatim.

Onde se encontra a duplicação com place city e town? Não identifiquei nas 
formatações dos dois objetos.

De qualquer forma vamos mais uma vez acionar a lista Mkgmap para solucionar o 
problema de não indexação do POI contendo o place=city quando esse POI só está 
contido como membro admin_centre da relação boundary.

[]s
Marcio



-Mensagem Original- 
From: Nelson A. de Oliveira 
Sent: Friday, June 12, 2015 5:15 PM 
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br] São Carlos, SP 

2015-06-12 17:02 GMT-03:00  thunder...@gpsinfo.com.br:
 Diz você que testou várias cidades, mas não testou a apresentada por mim que
 é Concórdia - SC.

Testei.
Existe duplicação no nomimatim:
http://nominatim.openstreetmap.org/search.php?q=concórdia%2C+santa+catarina

Repare que está indexado como city e town (talvez porque 1 mês atrás
vocês estavam adicionando addr:place=city no nó da cidade que já
possuía place=town).
Essas adições de is_in, addr:place e outras coisas para indexar em uma
aplicação específica não é o caminho certo.

Peguemos Ribeirão Preto:
http://nominatim.openstreetmap.org/search.php?q=ribeirão+preto
Apenas 1 resultado do nominatim (os outros dos são córregos)

Ribeirão Preto também não é indexado no mkgmap?
Nenhuma cidade de SP é indexada no mkgmap?

 Infelizmente, mais uma vez, nos deparamos com configurações diferentes para
 objetos semelhantes. Falta de padronização?

Por mais distintas que estejam, nenhuma está errada.
Muitos aplicativos entendem corretamente as relações que já existem.
Único lugar que vejo apresentando problema é no mkgmap.

Sinceramente não entendo como que acontece tanto problema de indexação
no mkgmap.

___
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

[thundercel]

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] Cruzamento de fronteiras

[thundercel]

Amigos,
em nosso mapa começou a surgir falta de indexação de Aceguá – RS.

Fomo tentar identificar o motivo e constatamos que o way 
https://www.openstreetmap.org/way/344183463 , inserido recentemente, está 
acarretando isso. Ele foi inserido no changeset 
https://www.openstreetmap.org/changeset/30980118

O limite administrativo ali do Brasil é o Rio Negro e o way inserido como 
limite ficou fora dele e acabou ficando dois limites, um no Rio Negro e outro 
no way inserido.

Alguém com mais experiência do que eu em limites poderia corrigir isso ou até 
reverter esse changeset já que naquela área estava tudo correto?

Antecipadamente agradeço.

[]s
Marcio

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