Re: [Talk-br] Reversão Itabira - MG

[Nelson A. de Oliveira]

2014-08-02 22:27 GMT-03:00 Tarcisio Oliveira :
> Se eu não me engano, o naoliv e o jgpaker estão fazendo essa análise, vira e
> mexe eles falam disso no canal #osm-br

Eu não mexo mais com isso. É algo ingrato e estressante.

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

Re: [Talk-br] Reversão Itabira - MG

[thundercel]

Amigos,
quanto a Itabira – MG passei o dia todo de hoje editando no mapa aquela cidade, 
Acredito que já consegui corrigir uns 80% do estrago causado pelo Genulpho no 
mapa de Itabira.

Não tenho duvida que ali ele importou dados do Tracksource. Cito isso porque 
tenho bastante experiência em edições dentro de padrões Tracksource e nessas 
correções que venho fazendo do estrago dele em Itabira identifico técnicas 
empregadas no Tracksource.

Por exemplo:

No Tracksource, para não fazer “looping”, um desenho de rotatória deve ser 
particionado de forma que fique duas meia lua. Ele colocou assim em todas as 
rotatórias inseridas na cidade.

No tracksource se coloca na via POI de Lombada nomeado assim e se empregando a 
técnica de 30m para um dos lados quando pista dupla. Excluí um monte deles.

No Tracksource se nomeia os acessos, rampa, rotatória, agulhas, etc. Ele nomeou 
tudo no mapa.

etc. etc etc..

Como solicitei a reversão e ficam só debatendo sem solução, decidi editar o 
mapa e analisar manualmente os erros nele e corrigi-los. Como falta pouco para 
terminar julgo que até a semana que vem termino.

[]s
Marcio



From: John Packer 
Sent: Saturday, August 2, 2014 10:19 PM
To: OpenStreetMap no Brasil 
Subject: Re: [Talk-br] Reversão Itabira - MG

>Uma solução seria reverter TODOS os conjuntos de alteração do Genulpho, mas 
>creio que a maioria não se sinta confortável com isso, já que ele faz outras 
>contribuições.
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Reversão Itabira - MG

[Tarcisio Oliveira]

Foi mau jgpaker, eu quis escrever Skippern. (bem diferente até)

Em 02-08-2014 23:10, John Packer escreveu:
De vez em quando eu falo com o naoliv sobre coisas aleatórias, mas 
nunca entro no irc... :-P



Em 2 de agosto de 2014 22:27, Tarcisio Oliveira > escreveu:


Se eu não me engano, o naoliv e o jgpaker estão fazendo essa
análise, vira e mexe eles falam disso no canal #osm-br



Em 02-08-2014 22:19, John Packer escreveu:

Paulo,
Lembro que um tempo atrás soubemos de um grupo do Tracksource que
os dados importados pelo Genulpho não são do mesmo.
Se eu não me engano, o Genulpho pegou os dados com outro
desenvolvedor, mas não pediu permissão para importar para o OSM.

Reforçando: A questão aqui não é se esta importação deveria ser
revertida ou não. O problema é saber quais conjuntos de
alterações devem ser revertidos e quais não, pois o Genulpho
adicionou e removeu vários objetos relacionados com a importação
em outros conjuntos de alteração e só reverter os conjuntos de
alteração onde foi feita as adições em massa não é o suficiente.
Uma solução seria reverter TODOS os conjuntos de alteração do
Genulpho, mas creio que a maioria não se sinta confortável com
isso, já que ele faz outras contribuições.


Em 2 de agosto de 2014 18:34, Paulo Carvalho
mailto:paulo.r.m.carva...@gmail.com>> escreveu:

Pessoal,

  Lembrem que os dados do Tracksource não são disponíveis
para download (closed source). Ele só poderia usar os dados
"do" Tracksource caso ele tenha sido desenvolvedor do mapa em
questão no Projeto.  Temos que usar a lógica antes de
formular hipóteses, sobretudo aquelas que comprometem a
reputação de um colega.  Os mapas que ele mesmo criou
evidentemente pode compartilhar se suas fontes forem
compatíveis com o OSM.
   Agora concordo que vias duplicadas são lixo que deve ser
revertido.

[]s

PC


Em 30 de julho de 2014 20:36, Tarcisio Oliveira
mailto:tarci...@ymail.com>> escreveu:

/"Como citei anteriormente, na minha opinião, se um
usuário faz uma importação dessa forma, descumprindo
todas recomendações e nem se dá o luxo de verificar o
resultado da importação, não merece que aquele trabalho,
mesmo que tenha algo de útil nele, seja aprovado e
mantido.//"

/
Concordo, se o usuário não se deu ao trabalho de abrir a
região que acabou de modificar, e notar que causou um
estrago, no mais deve ser notoficado que fez coisa errada
e o changeset revertido.

Em 30-07-2014 17:33, thunder...@gpsinfo.com.br
 escreveu:

A minha duvida do porque não se reverte está concentrado
para o município de Itabira - MG onde, pelo conjunto de
alterações

http://www.openstreetmap.org/changeset/22233203#map=11/-19.5932/-43.3170
, importou os dados sobre os dados existentes duplicando
quase toda a cidade de Itabira - MG.

Como citei anteriormente, na minha opinião, se um
usuário faz uma importação dessa forma, descumprindo
todas recomendações e nem se dá o luxo de verificar o
resultado da importação, não merece que aquele trabalho,
mesmo que tenha algo de útil nele, seja aprovado e mantido.

Se ele quer ajudar que assim seja, mas não destrua o
trabalho dos demais.

Na minha opinião é reversão imediata e envio de mensagem
a ele informando que importe novamente, mas cumprindo as
recomendações para isso e verificando se o resultado da
importação causou danos ao trabalhos dos demais.

Perdoem, mas minha formação e educação militar me fez,
por vezes, ser mais rígido e severo quando do
descumprimento de normas e recomendações.


-Mensagem Original- From: Nelson A. de Oliveira
Sent: Wednesday, July 30, 2014 3:02 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] Reversão Itabira - MG

Para quem quiser olhar os changesets do Genulpho:
http://naoliv.iq.unesp.br/osm/genulpho/

Os links dos changesets são para o OSMHV (então a
primeira vez que
acessar pode ter uma página em branco ou dizendo que
está na fila; é
só atualizar o endereço depois)

Os que ele editou com o JOSM eu destaquei (porque muito
provavelmente
foram importações).
Também precisa verificar todos os changesets onde há
dados apagados,
porque mesmo depois de parar com as importações, ainda
tem edições
ond

Re: [Talk-br] Reversão Itabira - MG

[John Packer]

De vez em quando eu falo com o naoliv sobre coisas aleatórias, mas nunca
entro no irc... :-P


Em 2 de agosto de 2014 22:27, Tarcisio Oliveira 
escreveu:

>  Se eu não me engano, o naoliv e o jgpaker estão fazendo essa análise,
> vira e mexe eles falam disso no canal #osm-br
>
>
>
> Em 02-08-2014 22:19, John Packer escreveu:
>
>  Paulo,
> Lembro que um tempo atrás soubemos de um grupo do Tracksource que os dados
> importados pelo Genulpho não são do mesmo.
> Se eu não me engano, o Genulpho pegou os dados com outro desenvolvedor,
> mas não pediu permissão para importar para o OSM.
>
>  Reforçando: A questão aqui não é se esta importação deveria ser revertida
> ou não. O problema é saber quais conjuntos de alterações devem ser
> revertidos e quais não, pois o Genulpho adicionou e removeu vários objetos
> relacionados com a importação em outros conjuntos de alteração e só
> reverter os conjuntos de alteração onde foi feita as adições em massa não é
> o suficiente.
> Uma solução seria reverter TODOS os conjuntos de alteração do Genulpho,
> mas creio que a maioria não se sinta confortável com isso, já que ele faz
> outras contribuições.
>
>
>  Em 2 de agosto de 2014 18:34, Paulo Carvalho <
> paulo.r.m.carva...@gmail.com> escreveu:
>
>> Pessoal,
>>
>>Lembrem que os dados do Tracksource não são disponíveis para download
>> (closed source). Ele só poderia usar os dados "do" Tracksource caso ele
>> tenha sido desenvolvedor do mapa em questão no Projeto.  Temos que usar a
>> lógica antes de formular hipóteses, sobretudo aquelas que comprometem a
>> reputação de um colega.  Os mapas que ele mesmo criou evidentemente pode
>> compartilhar se suas fontes forem compatíveis com o OSM.
>>Agora concordo que vias duplicadas são lixo que deve ser revertido.
>>
>>  []s
>>
>>  PC
>>
>>
>> Em 30 de julho de 2014 20:36, Tarcisio Oliveira 
>> escreveu:
>>
>>   *"Como citei anteriormente, na minha opinião, se um usuário faz uma
>>> importação dessa forma, descumprindo todas recomendações e nem se dá o luxo
>>> de verificar o resultado da importação, não merece que aquele trabalho,
>>> mesmo que tenha algo de útil nele, seja aprovado e mantido.*
>>>
>>> *" *
>>> Concordo, se o usuário não se deu ao trabalho de abrir a região que
>>> acabou de modificar, e notar que causou um estrago, no mais deve ser
>>> notoficado que fez coisa errada e o changeset revertido.
>>>
>>> Em 30-07-2014 17:33, thunder...@gpsinfo.com.br escreveu:
>>>
>>> A minha duvida do porque não se reverte está concentrado para o
>>> município de Itabira - MG onde, pelo conjunto de alterações
>>> http://www.openstreetmap.org/changeset/22233203#map=11/-19.5932/-43.3170
>>> , importou os dados sobre os dados existentes duplicando quase toda a
>>> cidade de Itabira - MG.
>>>
>>> Como citei anteriormente, na minha opinião, se um usuário faz uma
>>> importação dessa forma, descumprindo todas recomendações e nem se dá o luxo
>>> de verificar o resultado da importação, não merece que aquele trabalho,
>>> mesmo que tenha algo de útil nele, seja aprovado e mantido.
>>>
>>> Se ele quer ajudar que assim seja, mas não destrua o trabalho dos
>>> demais.
>>>
>>> Na minha opinião é reversão imediata e envio de mensagem a ele
>>> informando que importe novamente, mas cumprindo as recomendações para isso
>>> e verificando se o resultado da importação causou danos ao trabalhos dos
>>> demais.
>>>
>>> Perdoem, mas minha formação e educação militar me fez, por vezes, ser
>>> mais rígido e severo quando do descumprimento de normas e recomendações.
>>>
>>>
>>> -Mensagem Original- From: Nelson A. de Oliveira
>>> Sent: Wednesday, July 30, 2014 3:02 PM
>>> To: OpenStreetMap no Brasil
>>> Subject: Re: [Talk-br] Reversão Itabira - MG
>>>
>>> Para quem quiser olhar os changesets do Genulpho:
>>> http://naoliv.iq.unesp.br/osm/genulpho/
>>>
>>> Os links dos changesets são para o OSMHV (então a primeira vez que
>>> acessar pode ter uma página em branco ou dizendo que está na fila; é
>>> só atualizar o endereço depois)
>>>
>>> Os que ele editou com o JOSM eu destaquei (porque muito provavelmente
>>> foram importações).
>>> Também precisa verificar todos os changesets onde há dados apagados,
>>> porque mesmo depois de parar com as importações, ainda tem edições
>>> onde ele apaga dados antigos de outros usuários (por exemplo,
>>> http://osm.mapki.com/history/way.php?id=288678930, apagado no começo
>>> do mês)
>>>
>>> Acho que isso deve dar uma noção da dificuldade e responder uma parte
>>> das dúvidas sobre "porque não reverte as coisas dele?"
>>>
>>> ___
>>> 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
>>

Re: [Talk-br] Reversão Itabira - MG

[Tarcisio Oliveira]

Se eu não me engano, o naoliv e o jgpaker estão fazendo essa análise, 
vira e mexe eles falam disso no canal #osm-br




Em 02-08-2014 22:19, John Packer escreveu:

Paulo,
Lembro que um tempo atrás soubemos de um grupo do Tracksource que os 
dados importados pelo Genulpho não são do mesmo.
Se eu não me engano, o Genulpho pegou os dados com outro 
desenvolvedor, mas não pediu permissão para importar para o OSM.


Reforçando: A questão aqui não é se esta importação deveria ser 
revertida ou não. O problema é saber quais conjuntos de alterações 
devem ser revertidos e quais não, pois o Genulpho adicionou e removeu 
vários objetos relacionados com a importação em outros conjuntos de 
alteração e só reverter os conjuntos de alteração onde foi feita as 
adições em massa não é o suficiente.
Uma solução seria reverter TODOS os conjuntos de alteração do 
Genulpho, mas creio que a maioria não se sinta confortável com isso, 
já que ele faz outras contribuições.



Em 2 de agosto de 2014 18:34, Paulo Carvalho 
mailto:paulo.r.m.carva...@gmail.com>> 
escreveu:


Pessoal,

  Lembrem que os dados do Tracksource não são disponíveis para
download (closed source). Ele só poderia usar os dados "do"
Tracksource caso ele tenha sido desenvolvedor do mapa em questão
no Projeto.  Temos que usar a lógica antes de formular hipóteses,
sobretudo aquelas que comprometem a reputação de um colega.  Os
mapas que ele mesmo criou evidentemente pode compartilhar se suas
fontes forem compatíveis com o OSM.
   Agora concordo que vias duplicadas são lixo que deve ser revertido.

[]s

PC


Em 30 de julho de 2014 20:36, Tarcisio Oliveira
mailto:tarci...@ymail.com>> escreveu:

/"Como citei anteriormente, na minha opinião, se um usuário
faz uma importação dessa forma, descumprindo todas
recomendações e nem se dá o luxo de verificar o resultado da
importação, não merece que aquele trabalho, mesmo que tenha
algo de útil nele, seja aprovado e mantido.//"

/
Concordo, se o usuário não se deu ao trabalho de abrir a
região que acabou de modificar, e notar que causou um estrago,
no mais deve ser notoficado que fez coisa errada e o changeset
revertido.

Em 30-07-2014 17:33, thunder...@gpsinfo.com.br
 escreveu:

A minha duvida do porque não se reverte está concentrado para
o município de Itabira - MG onde, pelo conjunto de alterações
http://www.openstreetmap.org/changeset/22233203#map=11/-19.5932/-43.3170
, importou os dados sobre os dados existentes duplicando
quase toda a cidade de Itabira - MG.

Como citei anteriormente, na minha opinião, se um usuário faz
uma importação dessa forma, descumprindo todas recomendações
e nem se dá o luxo de verificar o resultado da importação,
não merece que aquele trabalho, mesmo que tenha algo de útil
nele, seja aprovado e mantido.

Se ele quer ajudar que assim seja, mas não destrua o trabalho
dos demais.

Na minha opinião é reversão imediata e envio de mensagem a
ele informando que importe novamente, mas cumprindo as
recomendações para isso e verificando se o resultado da
importação causou danos ao trabalhos dos demais.

Perdoem, mas minha formação e educação militar me fez, por
vezes, ser mais rígido e severo quando do descumprimento de
normas e recomendações.


-Mensagem Original- From: Nelson A. de Oliveira
Sent: Wednesday, July 30, 2014 3:02 PM
To: OpenStreetMap no Brasil
Subject: Re: [Talk-br] Reversão Itabira - MG

Para quem quiser olhar os changesets do Genulpho:
http://naoliv.iq.unesp.br/osm/genulpho/

Os links dos changesets são para o OSMHV (então a primeira
vez que
acessar pode ter uma página em branco ou dizendo que está na
fila; é
só atualizar o endereço depois)

Os que ele editou com o JOSM eu destaquei (porque muito
provavelmente
foram importações).
Também precisa verificar todos os changesets onde há dados
apagados,
porque mesmo depois de parar com as importações, ainda tem
edições
onde ele apaga dados antigos de outros usuários (por exemplo,
http://osm.mapki.com/history/way.php?id=288678930, apagado no
começo
do mês)

Acho que isso deve dar uma noção da dificuldade e responder
uma parte
das dúvidas sobre "porque não reverte as coisas dele?"

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

___
Talk-br mailing list
Talk-br@openstreetmap.org 

Re: [Talk-br] Reversão Itabira - MG

[John Packer]

Paulo,
Lembro que um tempo atrás soubemos de um grupo do Tracksource que os dados
importados pelo Genulpho não são do mesmo.
Se eu não me engano, o Genulpho pegou os dados com outro desenvolvedor, mas
não pediu permissão para importar para o OSM.

Reforçando: A questão aqui não é se esta importação deveria ser revertida
ou não. O problema é saber quais conjuntos de alterações devem ser
revertidos e quais não, pois o Genulpho adicionou e removeu vários objetos
relacionados com a importação em outros conjuntos de alteração e só
reverter os conjuntos de alteração onde foi feita as adições em massa não é
o suficiente.
Uma solução seria reverter TODOS os conjuntos de alteração do Genulpho, mas
creio que a maioria não se sinta confortável com isso, já que ele faz
outras contribuições.


Em 2 de agosto de 2014 18:34, Paulo Carvalho 
escreveu:

> Pessoal,
>
>   Lembrem que os dados do Tracksource não são disponíveis para download
> (closed source). Ele só poderia usar os dados "do" Tracksource caso ele
> tenha sido desenvolvedor do mapa em questão no Projeto.  Temos que usar a
> lógica antes de formular hipóteses, sobretudo aquelas que comprometem a
> reputação de um colega.  Os mapas que ele mesmo criou evidentemente pode
> compartilhar se suas fontes forem compatíveis com o OSM.
>Agora concordo que vias duplicadas são lixo que deve ser revertido.
>
> []s
>
> PC
>
>
> Em 30 de julho de 2014 20:36, Tarcisio Oliveira 
> escreveu:
>
>  *"Como citei anteriormente, na minha opinião, se um usuário faz uma
>> importação dessa forma, descumprindo todas recomendações e nem se dá o luxo
>> de verificar o resultado da importação, não merece que aquele trabalho,
>> mesmo que tenha algo de útil nele, seja aprovado e mantido.*
>>
>> *" *
>> Concordo, se o usuário não se deu ao trabalho de abrir a região que
>> acabou de modificar, e notar que causou um estrago, no mais deve ser
>> notoficado que fez coisa errada e o changeset revertido.
>>
>> Em 30-07-2014 17:33, thunder...@gpsinfo.com.br escreveu:
>>
>> A minha duvida do porque não se reverte está concentrado para o município
>> de Itabira - MG onde, pelo conjunto de alterações
>> http://www.openstreetmap.org/changeset/22233203#map=11/-19.5932/-43.3170
>> , importou os dados sobre os dados existentes duplicando quase toda a
>> cidade de Itabira - MG.
>>
>> Como citei anteriormente, na minha opinião, se um usuário faz uma
>> importação dessa forma, descumprindo todas recomendações e nem se dá o luxo
>> de verificar o resultado da importação, não merece que aquele trabalho,
>> mesmo que tenha algo de útil nele, seja aprovado e mantido.
>>
>> Se ele quer ajudar que assim seja, mas não destrua o trabalho dos demais.
>>
>> Na minha opinião é reversão imediata e envio de mensagem a ele informando
>> que importe novamente, mas cumprindo as recomendações para isso e
>> verificando se o resultado da importação causou danos ao trabalhos dos
>> demais.
>>
>> Perdoem, mas minha formação e educação militar me fez, por vezes, ser
>> mais rígido e severo quando do descumprimento de normas e recomendações.
>>
>>
>> -Mensagem Original- From: Nelson A. de Oliveira
>> Sent: Wednesday, July 30, 2014 3:02 PM
>> To: OpenStreetMap no Brasil
>> Subject: Re: [Talk-br] Reversão Itabira - MG
>>
>> Para quem quiser olhar os changesets do Genulpho:
>> http://naoliv.iq.unesp.br/osm/genulpho/
>>
>> Os links dos changesets são para o OSMHV (então a primeira vez que
>> acessar pode ter uma página em branco ou dizendo que está na fila; é
>> só atualizar o endereço depois)
>>
>> Os que ele editou com o JOSM eu destaquei (porque muito provavelmente
>> foram importações).
>> Também precisa verificar todos os changesets onde há dados apagados,
>> porque mesmo depois de parar com as importações, ainda tem edições
>> onde ele apaga dados antigos de outros usuários (por exemplo,
>> http://osm.mapki.com/history/way.php?id=288678930, apagado no começo
>> do mês)
>>
>> Acho que isso deve dar uma noção da dificuldade e responder uma parte
>> das dúvidas sobre "porque não reverte as coisas dele?"
>>
>> ___
>> 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
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Reversão Itabira - MG

[Paulo Carvalho]

Pessoal,

  Lembrem que os dados do Tracksource não são disponíveis para download
(closed source). Ele só poderia usar os dados "do" Tracksource caso ele
tenha sido desenvolvedor do mapa em questão no Projeto.  Temos que usar a
lógica antes de formular hipóteses, sobretudo aquelas que comprometem a
reputação de um colega.  Os mapas que ele mesmo criou evidentemente pode
compartilhar se suas fontes forem compatíveis com o OSM.
   Agora concordo que vias duplicadas são lixo que deve ser revertido.

[]s

PC


Em 30 de julho de 2014 20:36, Tarcisio Oliveira 
escreveu:

>  *"Como citei anteriormente, na minha opinião, se um usuário faz uma
> importação dessa forma, descumprindo todas recomendações e nem se dá o luxo
> de verificar o resultado da importação, não merece que aquele trabalho,
> mesmo que tenha algo de útil nele, seja aprovado e mantido.*
>
> *" *
> Concordo, se o usuário não se deu ao trabalho de abrir a região que acabou
> de modificar, e notar que causou um estrago, no mais deve ser notoficado
> que fez coisa errada e o changeset revertido.
>
> Em 30-07-2014 17:33, thunder...@gpsinfo.com.br escreveu:
>
> A minha duvida do porque não se reverte está concentrado para o município
> de Itabira - MG onde, pelo conjunto de alterações
> http://www.openstreetmap.org/changeset/22233203#map=11/-19.5932/-43.3170
> , importou os dados sobre os dados existentes duplicando quase toda a
> cidade de Itabira - MG.
>
> Como citei anteriormente, na minha opinião, se um usuário faz uma
> importação dessa forma, descumprindo todas recomendações e nem se dá o luxo
> de verificar o resultado da importação, não merece que aquele trabalho,
> mesmo que tenha algo de útil nele, seja aprovado e mantido.
>
> Se ele quer ajudar que assim seja, mas não destrua o trabalho dos demais.
>
> Na minha opinião é reversão imediata e envio de mensagem a ele informando
> que importe novamente, mas cumprindo as recomendações para isso e
> verificando se o resultado da importação causou danos ao trabalhos dos
> demais.
>
> Perdoem, mas minha formação e educação militar me fez, por vezes, ser mais
> rígido e severo quando do descumprimento de normas e recomendações.
>
>
> -Mensagem Original- From: Nelson A. de Oliveira
> Sent: Wednesday, July 30, 2014 3:02 PM
> To: OpenStreetMap no Brasil
> Subject: Re: [Talk-br] Reversão Itabira - MG
>
> Para quem quiser olhar os changesets do Genulpho:
> http://naoliv.iq.unesp.br/osm/genulpho/
>
> Os links dos changesets são para o OSMHV (então a primeira vez que
> acessar pode ter uma página em branco ou dizendo que está na fila; é
> só atualizar o endereço depois)
>
> Os que ele editou com o JOSM eu destaquei (porque muito provavelmente
> foram importações).
> Também precisa verificar todos os changesets onde há dados apagados,
> porque mesmo depois de parar com as importações, ainda tem edições
> onde ele apaga dados antigos de outros usuários (por exemplo,
> http://osm.mapki.com/history/way.php?id=288678930, apagado no começo
> do mês)
>
> Acho que isso deve dar uma noção da dificuldade e responder uma parte
> das dúvidas sobre "porque não reverte as coisas dele?"
>
> ___
> 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] Comemoração de 10 anos do OSM

[Lists]

Eu quero um meetup ou similar no Espírito Santo - Algum que interessa?

Vitória, Vila Velha, Guarapari?

Aun Johnsen

On Aug 2, 2014, at 18:21, Wille  wrote:

> Olá,
> 
> No dia 09 de agosto (próximo sábado) o OpenStreetMap completa 10 anos!
> 
> http://wiki.openstreetmap.org/wiki/OpenStreetMap_10th_Anniversary_Birthday_party
> 
> Seria legal ter eventos de comemoração ou pelo menos uma mapatona online... 
> quem se anima?
> 
> Galera de Brasília, estou indo morar aí a partir de amanhã, podemos marcar 
> uma comemoração presencial!
> 
> abraços,
> 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

[Talk-br] Comemoração de 10 anos do OSM

[Wille]

Olá,

No dia 09 de agosto (próximo sábado) o OpenStreetMap completa 10 anos!

http://wiki.openstreetmap.org/wiki/OpenStreetMap_10th_Anniversary_Birthday_party

Seria legal ter eventos de comemoração ou pelo menos uma mapatona 
online... quem se anima?


Galera de Brasília, estou indo morar aí a partir de amanhã, podemos 
marcar uma comemoração presencial!


abraços,
wille



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

Re: [Talk-br] A importância de não quebrar a hierarquia das vias dentro de cidades.

[Paulo Carvalho]

Pessoal,

  Durante essa semana estive em PoA (trouxe uns surveys na mala!),
trabalhando com um professor da U. de Alberta (Canadá) e não pude dar
atenção a este assunto.  Tive que aproveitar o tempo precioso dele aqui.

   Aun, obrigado pelo interesse em testar os mapas na plataforma Garmin.
 Como as rotas funcionam em outros engines, as hipóteses a investigar são,
por ordem decrescente de probabilidade:
1) Quebra da rede de alta hierarquia (motorway, trunk, primary) em alguma
cidade ao longo dos eixos rodoviários;
2) Proporção de classes inadequada;
3) Configuração errada do compilador, principalmente os arquivos do styles,
quebrando o mapa;
4) Limitações do mapa gerado pelo mkgmap.

  Em relação ao item 2), desconheço um estudo estatístico no sentido de
equilibrar a proporção das classes das vias em termos de percentual da
quilometragem total (para um mapa completo).  Tipo:

motorway: 2%
trunk: 5%
primary: 8%
secondary: 15%
tertiary: 30%
residential: 45%

   O cuidado com proporção de classes é uma prática no Tracksource, por
recomendação do Stan, autor do cGPSmapper.  Acredito que haja uma
recomendação de proporção de classes no mundo OSM.  Já vi no OSM mapas
visivelmente enviesados para determinada classe, por exemplo, vias
secondary.
A proporção inadequada de classes pode prejudicar o roteamento e
algoritmos que fazem otimização de memória com base nas classes assim como
outros ambientes, por exemplo, algoritmos de renderização podem
sobrecarregar *tiles* de níveis de zoom afastados por excesso de vias de
alta classe.

att,

Paulo


Em 1 de agosto de 2014 15:28, Lists  escreveu:

> Pessoal
>
> Finalmente testei este roteamento no meu Garmin Nüvi 50 com mapas do
> garmin.openstreetmap.nl compilado dia 22/7
>
> Dos cidades em baixo:
> 1 - 2: OK
> 2 - 3: OK
> 3 - 4: Falhe
> 4 - 5: Falhe
> 5 - 6: OK
> 6 - 7: OK
> 7 - 8: OK
> 8 - 9: OK
> 9 - 10: Falhe
>
> Os testes fui feito usando BaseCamp no Mac, pode puxar os waypoints para
> meu Garmin para fazer um simulação, mas provavelmente vai ter mesmo
> resultado
>
> Pode me manda mais waypoints por volta do Atibaia SP e Fortaleza CE para
> ver onde o rota quebrando
>
> Aun Johnsen
>
> On Jul 20, 2014, at 22:00, Fernando Trebien 
> wrote:
>
> > Pessoal,
> >
> > O Aun se ofereceu pra ajudar testando com a compilação da
> > garmin.openstreetmap.nl e pediu pra eu passar alguns endereços (pra
> > ficar fácil de testar). Vou postar alguém aqui também caso queiram
> > testar com outras compilações.
> >
> > Cruzamentos (requisito do geocoding do Garmin):
> > 1. Chuí, RS: Rua Chile X Rua Palestina
> > 2. Osório, RS: Rua Garibaldi X Rua Melvin Jones
> > 3. Joinville, SC: Rua Nazareno X Rua Benjamin Constant
> > 4. Atibaia, SP: Rua Belvedere X Rua Presidente Dutra
> > 5. Belo Horizonte, MG: Rua Tom Jobim X Fua Ferreira
> > 6. Teófilo Otoni, MG: Rua Coronel Ramos X Rua Dom Felipe
> > 7. Vitória da Conquista, BA: Rua Nova X Rua Deusdete Amaral
> > 8. Feira de Santana, BA: Rua Brumado X Rua Juazeiro
> > 9. Brejo Santo, CE: Rua Marcelino Costa X Rua Joaquim Nicodemos
> > 10. Fortaleza, CE: Rua Pentecoste X Rua Costa Barros
> >
> > Procedimento sugerido pra economizar trabalho testando:
> > - testar rota de [1] a [10]; se funcionar é porque há algum problema
> > com a compilação do mapa que não há na compilação do osm.nl
> > - testar [1] a [6]; se não funcionar, testar [1] a [2], [2] a [3], etc.
> > - se funcionar, testar [6] a [10]; se não funcionar, testar [6] a [7],
> > [7] a [8], etc.
> >
> > Se identificarem o trecho em que o roteamento falha, me avisem que eu
> > mando o próximo conjunto de pontos (que então deve nos levar ao ponto
> > exato do problema). Não mandei agora porque senão teria que sugerir
> > 100 pontos.
> >
> > 2014-07-20 20:05 GMT-03:00 Paulo Carvalho  >:
> >> Ok, entendido.  Obrigado pelas sugestões.
> >>
> >> []s
> >>
> >> Paulo
> >>
> >>
> >> Em 20 de julho de 2014 15:17, Fernando Trebien <
> fernando.treb...@gmail.com>
> >> escreveu:
> >>
> >>> "Acho razoável se basear na rota do OSRM
> >>> pra elencar um ponto mais ou menos" > mais ou menos no meio
> >>>
> >>> 2014-07-20 15:16 GMT-03:00 Fernando Trebien <
> fernando.treb...@gmail.com>:
>  Uma sugestão para diminuir o espaço de busca: dividir para conquistar.
> 
>  Ao invés de calcular uma rota tão longa, tente calcular a rota até
>  metade do caminho, e depois da metade até o destino. (Não precisa ser
>  exatamente a metade, qualquer ponto mais ou menos no meio serve.) O
>  problema vai estar no trecho em que esse teste falhar.
> 
>  Daí você pega o trecho problemático e repete: testa a primeira metade
>  dele, depois a segunda metade. Cada vez que você repete você diminui o
>  espaço de busca. São 3000km, dividindo por 2 a cada vez você
>  provavelmente vai chegar à raiz exata do problema em menos de 20
>  tentativas.
> 
>  Como saber onde fica a metade? Acho razoável se basear na rota do OSRM
>  pra elencar um ponto mais ou menos: htt