Re: [Talk-br] Sobre addr:interpolation - possibilidades

[santamariense]

Penso que não existam metodologias completamente diferente entre nós.
Existem alguns pormenores em discussão, mas de modo geral a
metodologia parece ser a mesma.

Eu não tenho conhecimentos de POSTGis mas to querendo aprender. Então
se lançarem no Git beleza.

A ideia é que a metodologia seja aberta para que, quem tiver
interesse, possa contrapor, dar sugestões e entender o processo, mas
não necessariamente vai ter que aprender a fazer todo o processo do
zero.

A ideia é (passos):

1. Padronizar uma metodologia (estamos neste momento aqui);
2. Processar os dados de TODOS os municípios, já com formato *.osm
3. Criar na wiki uma tabela de todos os municípios, com um link para
download do arquivo *.OSM e um campo de assinatura. (Exemplo: Escolhi
trabalhar no município X, então baixo o arquivo e, assino meu nome de
usuário para que outra pessoa não conflite em escolher o mesmo
município para edição). Além do que, se terá controle do andamento do
trabalho em escala nacional.
4. Com o arquivo em mãos, vai se trabalhando em cima dele e salvando,
e, quando estiver pronto (todo o município) se faz o upload. Não
poderá ser baixado dados do OSM sobre o arquivo para evitar potenciais
conflitos de edição.

Como a ideia é já entregar o arquivo em formato *.osm pronto para
ajustes finais, quem não tiver interesse em entender o processo de
como se chegou a ele, não precisará aprender a fazer.

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

Re: [Talk-br] duplicidade de projetos

[Peter Krauss]

Oi gente , pelo que entendi o nome oficial ficou sendo "Muncicípios" (tem
também ~1/3 a mais de dados), assim vale fazer o merge de uma página para
outra...  Se ninguém tem ideia do que ainda tem em "CIdades" mas não tem em
"Municipios", o mais simples seria levando ambas para uma planilha, o diff
da Wiki é impossível de usar para essas coisas.



Em 5 de janeiro de 2017 21:31, Lucas Pereira 
escreveu:

> Olá Gerald, boa noite.
>
> Quando eu fiz as análises, fiz primeiramente com as cidades, estabelecendo
> um raio de 10km (se não estiver enganado) ao redor do ponto que identifica
> os agrupamentos urbanos. Como vimos que essa lista poderia não ser
> adequada, realizei outra análise, desta vez, comparando os dados com a área
> dos municípios.
>
> Assim, o projeto foi melhorado e os resultados foram adicionados na
> segunda página. Por uma razão qualquer, não modifiquei a página anterior, e
> acabei criando outra. Mesmo assim, em alguns casos aparecem nomes na lista
> de cidades que não aparecem na lista de municípios, pois haviam municípios
> que tinham vias residenciais desenhadas no interior de seu limite, mas não
> havia mapeamento em suas sedes.
>
> Atenciosamente,
> LucFreitas.
>
> Em 5 de janeiro de 2017 20:57, Gerald Weber  escreveu:
>
>> Oi Turma
>>
>> esses dois projetos na wiki me parecem bem semelhantes?
>>
>> https://wiki.openstreetmap.org/wiki/Cidades_brasileiras_com_
>> mapeamento_deficit%C3%A1rio
>>
>> https://wiki.openstreetmap.org/wiki/Munic%C3%ADpios_brasilei
>> ros_com_mapeamento_deficit%C3%A1rio
>>
>> o que vocês acham?
>>
>> Gerald
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
>>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] duplicidade de projetos

[Lucas Pereira]

Olá Gerald, boa noite.

Quando eu fiz as análises, fiz primeiramente com as cidades, estabelecendo
um raio de 10km (se não estiver enganado) ao redor do ponto que identifica
os agrupamentos urbanos. Como vimos que essa lista poderia não ser
adequada, realizei outra análise, desta vez, comparando os dados com a área
dos municípios.

Assim, o projeto foi melhorado e os resultados foram adicionados na segunda
página. Por uma razão qualquer, não modifiquei a página anterior, e acabei
criando outra. Mesmo assim, em alguns casos aparecem nomes na lista de
cidades que não aparecem na lista de municípios, pois haviam municípios que
tinham vias residenciais desenhadas no interior de seu limite, mas não
havia mapeamento em suas sedes.

Atenciosamente,
LucFreitas.

Em 5 de janeiro de 2017 20:57, Gerald Weber  escreveu:

> Oi Turma
>
> esses dois projetos na wiki me parecem bem semelhantes?
>
> https://wiki.openstreetmap.org/wiki/Cidades_brasileiras_
> com_mapeamento_deficit%C3%A1rio
>
> https://wiki.openstreetmap.org/wiki/Munic%C3%ADpios_
> brasileiros_com_mapeamento_deficit%C3%A1rio
>
> o que vocês acham?
>
> Gerald
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Sobre addr:interpolation - possibilidades

[Peter Krauss]

Oi gente, por favor preencham os links vermelhinhos ou acrescentem outros
em que estiverem trabalhando.

https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/CNEFE_2010



Em 5 de janeiro de 2017 20:10, Sérgio V.  escreveu:

> Penso que seria útil se os que já tem uma metodologia em andamento,
>  se pudesse ir começando uma wiki comum (tipo "Proposta de importação de
> endereços no Brasil - CNEFE 2010 ") e descrevendo ali a metodologia
> pensada (mesmo que certamente vá sendo mudada e aprimorada no andar dos
> estudos e experimentos; e por experimentos entendo inicialmente "fora" do
> OSM, para que todos possam ver antes se tá funcionando suficientemente bem,
> e aprovar o uso no Brasil todo).
>
> Poderia ser em tópicos nesta wiki:
>
> -metodologia proposta por santamariense;
>
> -metodologia proposta por papibarrígafo;...
>
> -problemas identificados;
>
> -objeções;
>
> -preferências da comunidade;...
>
>
> Por exemplo, pode-se colocar na wiki também imagens dos resultados para
> que mesmo quem não entende de programação possa acompanhar.
>
> E em passo-a-passo, para mesmo quem não entende muito de programação ou
> processamentoem QGIS.
>
> Eu pessoalmente sou muito limitado em entender de programação.
>
> Assim todos podem enxergar melhor o que uns e outros estão propondo.
>
> Por exemplo, talvez seria útil colocar figuras do QGIS das tags com
> "labels", nas faces, tal como ficaria para importar.
>
> (pensei nisto na questão do Augusto sobre se  < pelo recenseador sempre em ordem de numeração crescente? Digamos, face 001,
> face 002, face 003, etc?>>).
>
> Aí se enxerga a coisa.
>
> Mas acho que tá indo bem a coisa, estamos próximos de chegar lá.
>
>
> Parabéns aos que tão metendo a mão no bagulho.
>
> Eu percebo minhas limitações em programação e processamento.
>
> Mas assim que entender o método, pego e executo.
>
>
> - - - - - - - - - - - - - - - -
>
> Sérgio - http://www.openstreetmap.org/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] duplicidade de projetos

[Gerald Weber]

Oi Turma

esses dois projetos na wiki me parecem bem semelhantes?

https://wiki.openstreetmap.org/wiki/Cidades_brasileiras_com_mapeamento_deficit%C3%A1rio

https://wiki.openstreetmap.org/wiki/Munic%C3%ADpios_brasileiros_com_mapeamento_deficit%C3%A1rio

o que vocês acham?

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

[Talk-br] Sobre addr:interpolation - possibilidades

[Sérgio V .]

Penso que seria útil se os que já tem uma metodologia em andamento,  se pudesse 
ir começando uma wiki comum (tipo "Proposta de importação de endereços no 
Brasil - CNEFE 2010 ") e descrevendo ali a metodologia pensada (mesmo que 
certamente vá sendo mudada e aprimorada no andar dos estudos e experimentos; e 
por experimentos entendo inicialmente "fora" do OSM, para que todos possam ver 
antes se tá funcionando suficientemente bem, e aprovar o uso no Brasil todo).

Poderia ser em tópicos nesta wiki:

-metodologia proposta por santamariense;

-metodologia proposta por papibarrígafo;...

-problemas identificados;

-objeções;

-preferências da comunidade;...


Por exemplo, pode-se colocar na wiki também imagens dos resultados para que 
mesmo quem não entende de programação possa acompanhar.

E em passo-a-passo, para mesmo quem não entende muito de programação ou 
processamentoem QGIS.

Eu pessoalmente sou muito limitado em entender de programação.

Assim todos podem enxergar melhor o que uns e outros estão propondo.

Por exemplo, talvez seria útil colocar figuras do QGIS das tags com "labels", 
nas faces, tal como ficaria para importar.

(pensei nisto na questão do Augusto sobre se  <>).

Aí se enxerga a coisa.

Mas acho que tá indo bem a coisa, estamos próximos de chegar lá.


Parabéns aos que tão metendo a mão no bagulho.

Eu percebo minhas limitações em programação e processamento.

Mas assim que entender o método, pego e executo.


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

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Sobre addr:interpolation - possibilidades

[Papibaquígrafo]

VItor, só pra confirmar, precisamos saber algo sobre a metodologia de numeração 
das faces:

Seria verdade que, dentro de cada quadra, as faces são percorridas pelo 
recenseador sempre em ordem de numeração crescente? Digamos, face 001, face 
002, face 003, etc?

Se for o caso, tá matada a charada.
Em Quinta-feira, 5 de Janeiro de 2017 20:03, Vítor Rodrigo Dias 
 escreveu:
 

 

Ainda: os recenseadores (e antes, os agentes censitários, na pré-coleta) são 
instruídos a coletar os dados de uma determinada quadra em sentido horário - ou 
seja, sempre com o imóvel à direita do recenseador.
Em qui, 5 de jan de 2017 às 17:00, Vítor Rodrigo Dias  
escreveu:

@santamariense, só pra confirmar que a probabilidade do txt refletir a ordem 
real das casas é de 99% Trabalhei no Censo 2010 e os recenseadores foram 
instruídos a respeitar a ordem das casas.
Em qui, 5 de jan de 2017 às 16:27, Peter Krauss  escreveu:

@santamariense,   eu não sou contra a interpolação, acho inclusive que, por ser 
um atributo distinto da numeração praticada (zero risco de adulteração pelo que 
entendi), é sempre lucro em relação ao "NADA" usual.  A demanda pelo Github é 
quanto à  reprodutibilidade da sua metodologia: não dá para ficar batendo papo 
aqui, é preciso mão-na-massa, pelo menos uma amostrinha, e de preferência 
(ajudo a traduzir passos QGis para PostGIS) com código-fonte do processo.
PS1: alguém mais aqui usa PostGIS?  Possso fornecer temporariamente um ssh para 
todos fazerem seus testes no mesmo ambiente, sem precisar ficar montando cada 
um a sua base.
PS2: o Lucas iniciou um trabalho parecido exatamente 1 ano atrás em Janeiro de 
2015, mas não tinha gente para colaborar como agora.  
https://github.com/lucasmation/osm_cnefe_import



 

Em 5 de janeiro de 2017 15:35, santamariense  escreveu:

@Peter, teremos que documentar tudo. Você quer dizer usar o Git como
repositório de arquivos? A documentação mesmo terá que ser no wiki.

Eu pessoalmente sou a favor do uso das linhas de interpolação também
no sentido de manter uma organização dos pontos. Os números de casas
avulsos no mapa me preocupam. Digamos que tenhamos invertido a ordem
dos números de uma esquina a outra (achar que uma rua inicia numa
ponta, quando na verdade iniciava em outra). Se isso acontecer fica
muito simples identificar quais números de casas são do CNEFE, pegar a
linha mestre e girar.

Claro, isso é questão de opinião (há pontos favoráveis e
desfavoráveis). Há a possibilidade de se usar linha mestre apenas em
ruas de uma quadra só (e não se sabe o sentido da numeração das casas
daquela cidade) - não necessariamente como addr:interpolation. Talvez
uma fixme.

@Papibaquígrafo, Resposta sobre "Além disso, notei que no TXT às vezes
aparece um endereço S/N entre dois que tem número. Nesse caso, dá pra
ter certeza que a ordem dos elementos no TXT corresponde à ordem real
dos prédios?"  > Isso é muito interessante. Já havia observado em
leitura manual dos dados. Creio que realmente seja a ordem real. O
problema é que essa informação se perde pela metodologia que estamos
astuciando. E fica realmente complicado um ser humano ler aquele monte
de linhas com caracteres esparsos quando se quer realizar um trabalho
a nível nacional.


Estando a source no changeset, é possível fazer uma query no overpass
com base nas tags da changeset, mesmo um objeto já não estando mais em
sua version=1???

___
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] Sobre addr:interpolation - possibilidades

[Vítor Rodrigo Dias]

Ainda: os recenseadores (e antes, os agentes censitários, na pré-coleta)
são instruídos a coletar os dados de uma determinada quadra em sentido
horário - ou seja, sempre com o imóvel à direita do recenseador.

Em qui, 5 de jan de 2017 às 17:00, Vítor Rodrigo Dias 
escreveu:

> @santamariense, só pra confirmar que a probabilidade do txt refletir a
> ordem real das casas é de 99% Trabalhei no Censo 2010 e os recenseadores
> foram instruídos a respeitar a ordem das casas.
>
> Em qui, 5 de jan de 2017 às 16:27, Peter Krauss 
> escreveu:
>
> @santamariense,   eu não sou contra a interpolação, acho inclusive que,
> por ser um atributo distinto da numeração praticada (zero risco de
> adulteração pelo que entendi), é sempre lucro em relação ao "NADA" usual.
> A demanda pelo Github é quanto à  reprodutibilidade
>  da sua metodologia: não
> dá para ficar batendo papo aqui, é preciso mão-na-massa, pelo menos uma
> amostrinha, e de preferência (ajudo a traduzir passos QGis para *PostGIS*)
> com código-fonte do processo.
>
> PS1: alguém mais aqui usa PostGIS?  Possso fornecer temporariamente um ssh
> para todos fazerem seus testes no mesmo ambiente, sem precisar ficar
> montando cada um a sua base.
>
> PS2: o Lucas iniciou um trabalho parecido exatamente 1 ano atrás em
> Janeiro de 2015, mas não tinha gente para colaborar como agora.
> https://github.com/lucasmation/osm_cnefe_import
>
>
>
>
>
>
>
> Em 5 de janeiro de 2017 15:35, santamariense 
> escreveu:
>
> @Peter, teremos que documentar tudo. Você quer dizer usar o Git como
> repositório de arquivos? A documentação mesmo terá que ser no wiki.
>
> Eu pessoalmente sou a favor do uso das linhas de interpolação também
> no sentido de manter uma organização dos pontos. Os números de casas
> avulsos no mapa me preocupam. Digamos que tenhamos invertido a ordem
> dos números de uma esquina a outra (achar que uma rua inicia numa
> ponta, quando na verdade iniciava em outra). Se isso acontecer fica
> muito simples identificar quais números de casas são do CNEFE, pegar a
> linha mestre e girar.
>
> Claro, isso é questão de opinião (há pontos favoráveis e
> desfavoráveis). Há a possibilidade de se usar linha mestre apenas em
> ruas de uma quadra só (e não se sabe o sentido da numeração das casas
> daquela cidade) - não necessariamente como addr:interpolation. Talvez
> uma fixme.
>
> @Papibaquígrafo, Resposta sobre "Além disso, notei que no TXT às vezes
> aparece um endereço S/N entre dois que tem número. Nesse caso, dá pra
> ter certeza que a ordem dos elementos no TXT corresponde à ordem real
> dos prédios?"  > Isso é muito interessante. Já havia observado em
> leitura manual dos dados. Creio que realmente seja a ordem real. O
> problema é que essa informação se perde pela metodologia que estamos
> astuciando. E fica realmente complicado um ser humano ler aquele monte
> de linhas com caracteres esparsos quando se quer realizar um trabalho
> a nível nacional.
>
>
> Estando a source no changeset, é possível fazer uma query no overpass
> com base nas tags da changeset, mesmo um objeto já não estando mais em
> sua version=1???
>
> ___
> 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] Sobre addr:interpolation - possibilidades

[Vítor Rodrigo Dias]

@santamariense, só pra confirmar que a probabilidade do txt refletir a
ordem real das casas é de 99% Trabalhei no Censo 2010 e os recenseadores
foram instruídos a respeitar a ordem das casas.

Em qui, 5 de jan de 2017 às 16:27, Peter Krauss 
escreveu:

> @santamariense,   eu não sou contra a interpolação, acho inclusive que,
> por ser um atributo distinto da numeração praticada (zero risco de
> adulteração pelo que entendi), é sempre lucro em relação ao "NADA" usual.
> A demanda pelo Github é quanto à  reprodutibilidade
>  da sua metodologia: não
> dá para ficar batendo papo aqui, é preciso mão-na-massa, pelo menos uma
> amostrinha, e de preferência (ajudo a traduzir passos QGis para *PostGIS*)
> com código-fonte do processo.
>
> PS1: alguém mais aqui usa PostGIS?  Possso fornecer temporariamente um ssh
> para todos fazerem seus testes no mesmo ambiente, sem precisar ficar
> montando cada um a sua base.
>
> PS2: o Lucas iniciou um trabalho parecido exatamente 1 ano atrás em
> Janeiro de 2015, mas não tinha gente para colaborar como agora.
> https://github.com/lucasmation/osm_cnefe_import
>
>
>
>
>
>
>
> Em 5 de janeiro de 2017 15:35, santamariense 
> escreveu:
>
> @Peter, teremos que documentar tudo. Você quer dizer usar o Git como
> repositório de arquivos? A documentação mesmo terá que ser no wiki.
>
> Eu pessoalmente sou a favor do uso das linhas de interpolação também
> no sentido de manter uma organização dos pontos. Os números de casas
> avulsos no mapa me preocupam. Digamos que tenhamos invertido a ordem
> dos números de uma esquina a outra (achar que uma rua inicia numa
> ponta, quando na verdade iniciava em outra). Se isso acontecer fica
> muito simples identificar quais números de casas são do CNEFE, pegar a
> linha mestre e girar.
>
> Claro, isso é questão de opinião (há pontos favoráveis e
> desfavoráveis). Há a possibilidade de se usar linha mestre apenas em
> ruas de uma quadra só (e não se sabe o sentido da numeração das casas
> daquela cidade) - não necessariamente como addr:interpolation. Talvez
> uma fixme.
>
> @Papibaquígrafo, Resposta sobre "Além disso, notei que no TXT às vezes
> aparece um endereço S/N entre dois que tem número. Nesse caso, dá pra
> ter certeza que a ordem dos elementos no TXT corresponde à ordem real
> dos prédios?"  > Isso é muito interessante. Já havia observado em
> leitura manual dos dados. Creio que realmente seja a ordem real. O
> problema é que essa informação se perde pela metodologia que estamos
> astuciando. E fica realmente complicado um ser humano ler aquele monte
> de linhas com caracteres esparsos quando se quer realizar um trabalho
> a nível nacional.
>
>
> Estando a source no changeset, é possível fazer uma query no overpass
> com base nas tags da changeset, mesmo um objeto já não estando mais em
> sua version=1???
>
> ___
> 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] Sobre addr:interpolation - possibilidades

[Peter Krauss]

@santamariense,   eu não sou contra a interpolação, acho inclusive que, por
ser um atributo distinto da numeração praticada (zero risco de adulteração
pelo que entendi), é sempre lucro em relação ao "NADA" usual.
A demanda pelo Github é quanto à  reprodutibilidade
 da sua metodologia: não dá
para ficar batendo papo aqui, é preciso mão-na-massa, pelo menos uma
amostrinha, e de preferência (ajudo a traduzir passos QGis para *PostGIS*)
com código-fonte do processo.

PS1: alguém mais aqui usa PostGIS?  Possso fornecer temporariamente um ssh
para todos fazerem seus testes no mesmo ambiente, sem precisar ficar
montando cada um a sua base.

PS2: o Lucas iniciou um trabalho parecido exatamente 1 ano atrás em Janeiro
de 2015, mas não tinha gente para colaborar como agora.
https://github.com/lucasmation/osm_cnefe_import







Em 5 de janeiro de 2017 15:35, santamariense 
escreveu:

> @Peter, teremos que documentar tudo. Você quer dizer usar o Git como
> repositório de arquivos? A documentação mesmo terá que ser no wiki.
>
> Eu pessoalmente sou a favor do uso das linhas de interpolação também
> no sentido de manter uma organização dos pontos. Os números de casas
> avulsos no mapa me preocupam. Digamos que tenhamos invertido a ordem
> dos números de uma esquina a outra (achar que uma rua inicia numa
> ponta, quando na verdade iniciava em outra). Se isso acontecer fica
> muito simples identificar quais números de casas são do CNEFE, pegar a
> linha mestre e girar.
>
> Claro, isso é questão de opinião (há pontos favoráveis e
> desfavoráveis). Há a possibilidade de se usar linha mestre apenas em
> ruas de uma quadra só (e não se sabe o sentido da numeração das casas
> daquela cidade) - não necessariamente como addr:interpolation. Talvez
> uma fixme.
>
> @Papibaquígrafo, Resposta sobre "Além disso, notei que no TXT às vezes
> aparece um endereço S/N entre dois que tem número. Nesse caso, dá pra
> ter certeza que a ordem dos elementos no TXT corresponde à ordem real
> dos prédios?"  > Isso é muito interessante. Já havia observado em
> leitura manual dos dados. Creio que realmente seja a ordem real. O
> problema é que essa informação se perde pela metodologia que estamos
> astuciando. E fica realmente complicado um ser humano ler aquele monte
> de linhas com caracteres esparsos quando se quer realizar um trabalho
> a nível nacional.
>
>
> Estando a source no changeset, é possível fazer uma query no overpass
> com base nas tags da changeset, mesmo um objeto já não estando mais em
> sua version=1???
>
> ___
> 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] Sobre addr:interpolation - possibilidades

[santamariense]

@Peter, teremos que documentar tudo. Você quer dizer usar o Git como
repositório de arquivos? A documentação mesmo terá que ser no wiki.

Eu pessoalmente sou a favor do uso das linhas de interpolação também
no sentido de manter uma organização dos pontos. Os números de casas
avulsos no mapa me preocupam. Digamos que tenhamos invertido a ordem
dos números de uma esquina a outra (achar que uma rua inicia numa
ponta, quando na verdade iniciava em outra). Se isso acontecer fica
muito simples identificar quais números de casas são do CNEFE, pegar a
linha mestre e girar.

Claro, isso é questão de opinião (há pontos favoráveis e
desfavoráveis). Há a possibilidade de se usar linha mestre apenas em
ruas de uma quadra só (e não se sabe o sentido da numeração das casas
daquela cidade) - não necessariamente como addr:interpolation. Talvez
uma fixme.

@Papibaquígrafo, Resposta sobre "Além disso, notei que no TXT às vezes
aparece um endereço S/N entre dois que tem número. Nesse caso, dá pra
ter certeza que a ordem dos elementos no TXT corresponde à ordem real
dos prédios?"  > Isso é muito interessante. Já havia observado em
leitura manual dos dados. Creio que realmente seja a ordem real. O
problema é que essa informação se perde pela metodologia que estamos
astuciando. E fica realmente complicado um ser humano ler aquele monte
de linhas com caracteres esparsos quando se quer realizar um trabalho
a nível nacional.


Estando a source no changeset, é possível fazer uma query no overpass
com base nas tags da changeset, mesmo um objeto já não estando mais em
sua version=1???

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

Re: [Talk-br] RES: Sobre addr:interpolation - possibilidades

[Papibaquígrafo]

A resposta à minha pergunta anterior — se é possível determinar o sentido da 
numeração de uma rua usando o CNEFE — está na página 83 deste documento:
https://international.ipums.org/international/resources/enum_materials_pdf/enum_instruct_br2010a.pdf
Pra resumir: em tese, é possível deduzir o sentido da numeração a partir do TXT 
e dos shapefiles. Se o resultado é confiável são outros quinhentos...


 

Em Quinta-feira, 5 de Janeiro de 2017 16:00, Papibaquígrafo 
 escreveu:
 

 Está claro que a direção das linhas nos shapefiles de face de quadra é 
completamente aleatória, não indicando nem numeração crescente nem 
descrescente. Pois agora eu notei que nos TXTs do CNEFE os numeros de uma mesma 
face às vezes vem em ordem crescente, às vezes decrescente.
Alguém checou se por acaso as duas coisas se compensam? Ou seja, distribuindo 
os números na ordem do TXT ao longo da face na direção que consta no shp, 
obtemos sempre a ordem real dos prédios?

Além disso, notei que no TXT às vezes aparece um endereço S/N entre dois que 
tem número. Nesse caso, dá pra ter certeza que a ordem dos elementos no TXT 
corresponde à ordem real dos prédios?
 

Em Quinta-feira, 5 de Janeiro de 2017 13:45, Peter Krauss 
 escreveu:
 

 Oi gente, que tal consolidar as discussões e decisões de projeto?É impossível 
acompanhar e tirar alguma conclusão mais séria aqui em meio a tantos e-mails 
dispersos e tantos tópicos discutidos pela metade.
Para mim está claro que é um experimento sério de consolidação global de dados, 
e que portanto requer antes um preparo, reprodutível por exemplo com PostGIS, 
para experts em processamento de dados poderem conferir e "assinarem embaixo" 
(eu me incluo nos voluntários), bem como emitirem relatórios mostrando os rumos 
da coisa antes de alterar a base OSM.  O uso dos dados do CNEF e o cruzamento 
com dados do CRP são dos mais relevantes (!), são dados oficiais e atualizados. 
Talvez o mais importante não seja a interpolação (num país onde ainda tem gente 
adotando numeração predial por Numerologia), mas o destaque das inconsistências 
e o registro confiável e definitivo dos dados relativos a faces de quadra.
Se todos aqui são "meio nerd", pode ser direto no Github, 
   https://github.com/OSMBrasil/_NOME_DO_PROJETO_
Qual nome será dado a esse projeto?  (ex. CNEFE2010)





Em 5 de janeiro de 2017 09:35, Reinaldo Neves  escreveu:

Também acredito que interpolação pelos dados do CNEFE vai trazer mais problemas 
que solução. Apenas a título de informação em São Paulo nas cidades que compõem 
a região metropolitana, a capital inclusive, o cep se inicia por zero,  
acredito que seja por isso que observou registros com 7 digítos.   Evidente que 
o problema ocorre na definição do campo CEP com sendo int e não char como é o 
correto.  No arquivo do CNEFE original a informação está correta. 
__ _Reinaldo Neves☎: (11) 3221-3722✉: 
rne...@equacao.com.brhttp://br.linkedin.com/in/ 
rrneveshttps://medium.com/Reinaldo_ Neves De: Papibaquígrafo 
[mailto:agostinho741-1@yahoo. com.br] 
Enviada em: quinta-feira, 5 de janeiro de 2017 07:49
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Sobre addr:interpolation - possibilidades Santamariense, 
Sobre o ponto 1: O trabalho do recenseador não é muito diferente do nosso como 
colaboradores do OSM: você vai a campo e coleta os números da fachada das 
casas. Se falta o número de uma casa, então para todos os efeitos práticos esse 
número não existe: este é o princípio da verificabilidade do OSM ("the truth is 
on the ground"). Portanto, não há nada de errado em pular os endereços que 
constam como S/N no CNEFE. Pode-se até deixar uma nota dizendo "faltam N 
números nesta face" para posterior verificação. Por outro lado, ao adicionar 
interpolações, nós estamos "especulando" a respeito da numeração, o que de 
certa forma até fere o princípio da verificabilidade. E isso pode até mesmo 
introduzir erros e inconsistências. Se o número faltante é o da esquina, a 
interpolação não vai deixar de ser incompleta. Pior que isso, é sabido que 
existem quebras na sequencialidade dos números (acontece na rua em que cresci 
em Porto Alegre). Imagine se você usar um desses números "anômalos" (ou mesmo 
um dado incorreto, algo que há de existir no CNEFE) como base da interpolação!! 
(Note também que as tags para numeração interpolada foram pensadas para o 
sistema europeu, de números sequenciais. No Brasil, onde a numeração é por 
metro, mais de 9 em cada 10 números gerados serão inexistentes! Em uma mapa 
completo, a não existência de um número é uma informação tão importante quando 
o da existência de um número) Em suma, vamos tirar do CNEFE o que o CNEFE nos 
dá, sem especular em cima. Agora, sobre pontos menos importantes: a) Será 
preciso realinhar os shapes do IBGE com o OSM. Eu queria pedir que se mantenha 
um registro desses deslocamentos, para uso futuro. O workflow 

Re: [Talk-br] RES: Sobre addr:interpolation - possibilidades

[Papibaquígrafo]

Está claro que a direção das linhas nos shapefiles de face de quadra é 
completamente aleatória, não indicando nem numeração crescente nem 
descrescente. Pois agora eu notei que nos TXTs do CNEFE os numeros de uma mesma 
face às vezes vem em ordem crescente, às vezes decrescente.
Alguém checou se por acaso as duas coisas se compensam? Ou seja, distribuindo 
os números na ordem do TXT ao longo da face na direção que consta no shp, 
obtemos sempre a ordem real dos prédios?

Além disso, notei que no TXT às vezes aparece um endereço S/N entre dois que 
tem número. Nesse caso, dá pra ter certeza que a ordem dos elementos no TXT 
corresponde à ordem real dos prédios?
 

Em Quinta-feira, 5 de Janeiro de 2017 13:45, Peter Krauss 
 escreveu:
 

 Oi gente, que tal consolidar as discussões e decisões de projeto?É impossível 
acompanhar e tirar alguma conclusão mais séria aqui em meio a tantos e-mails 
dispersos e tantos tópicos discutidos pela metade.
Para mim está claro que é um experimento sério de consolidação global de dados, 
e que portanto requer antes um preparo, reprodutível por exemplo com PostGIS, 
para experts em processamento de dados poderem conferir e "assinarem embaixo" 
(eu me incluo nos voluntários), bem como emitirem relatórios mostrando os rumos 
da coisa antes de alterar a base OSM.  O uso dos dados do CNEF e o cruzamento 
com dados do CRP são dos mais relevantes (!), são dados oficiais e atualizados. 
Talvez o mais importante não seja a interpolação (num país onde ainda tem gente 
adotando numeração predial por Numerologia), mas o destaque das inconsistências 
e o registro confiável e definitivo dos dados relativos a faces de quadra.
Se todos aqui são "meio nerd", pode ser direto no Github, 
   https://github.com/OSMBrasil/_NOME_DO_PROJETO_
Qual nome será dado a esse projeto?  (ex. CNEFE2010)





Em 5 de janeiro de 2017 09:35, Reinaldo Neves  escreveu:

Também acredito que interpolação pelos dados do CNEFE vai trazer mais problemas 
que solução. Apenas a título de informação em São Paulo nas cidades que compõem 
a região metropolitana, a capital inclusive, o cep se inicia por zero,  
acredito que seja por isso que observou registros com 7 digítos.   Evidente que 
o problema ocorre na definição do campo CEP com sendo int e não char como é o 
correto.  No arquivo do CNEFE original a informação está correta. 
__ _Reinaldo Neves☎: (11) 3221-3722✉: 
rne...@equacao.com.brhttp://br.linkedin.com/in/ 
rrneveshttps://medium.com/Reinaldo_ Neves De: Papibaquígrafo 
[mailto:agostinho741-1@yahoo. com.br] 
Enviada em: quinta-feira, 5 de janeiro de 2017 07:49
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Sobre addr:interpolation - possibilidades Santamariense, 
Sobre o ponto 1: O trabalho do recenseador não é muito diferente do nosso como 
colaboradores do OSM: você vai a campo e coleta os números da fachada das 
casas. Se falta o número de uma casa, então para todos os efeitos práticos esse 
número não existe: este é o princípio da verificabilidade do OSM ("the truth is 
on the ground"). Portanto, não há nada de errado em pular os endereços que 
constam como S/N no CNEFE. Pode-se até deixar uma nota dizendo "faltam N 
números nesta face" para posterior verificação. Por outro lado, ao adicionar 
interpolações, nós estamos "especulando" a respeito da numeração, o que de 
certa forma até fere o princípio da verificabilidade. E isso pode até mesmo 
introduzir erros e inconsistências. Se o número faltante é o da esquina, a 
interpolação não vai deixar de ser incompleta. Pior que isso, é sabido que 
existem quebras na sequencialidade dos números (acontece na rua em que cresci 
em Porto Alegre). Imagine se você usar um desses números "anômalos" (ou mesmo 
um dado incorreto, algo que há de existir no CNEFE) como base da interpolação!! 
(Note também que as tags para numeração interpolada foram pensadas para o 
sistema europeu, de números sequenciais. No Brasil, onde a numeração é por 
metro, mais de 9 em cada 10 números gerados serão inexistentes! Em uma mapa 
completo, a não existência de um número é uma informação tão importante quando 
o da existência de um número) Em suma, vamos tirar do CNEFE o que o CNEFE nos 
dá, sem especular em cima. Agora, sobre pontos menos importantes: a) Será 
preciso realinhar os shapes do IBGE com o OSM. Eu queria pedir que se mantenha 
um registro desses deslocamentos, para uso futuro. O workflow poderia ser o 
seguinte: 1. abrir o shp no JOSM e traçar algumas linhas entre uma esquina do 
shp e a correspondente esquina no OSM; 2. salvar essas geometrias em um 
arquivo; 3. usar a média aritmética das linhas para realinhar o shp; 4. 
arquivar o deslocamento usado em cada setor censitário nalgum lugar da wiki.b) 
Notei que há muitas inconsistências no campo CEP. Em São Paulo, por exemplo, 
eles tem só 7 digitios, o erro parece ser que falta o "1" no início.c) Sobre a 
tag source, veja exemplos mais recentes. 

Re: [Talk-br] RES: Sobre addr:interpolation - possibilidades

[Peter Krauss]

Oi gente, que tal *consolidar *as discussões e decisões de projeto*?*
É impossível acompanhar e tirar alguma conclusão mais séria aqui em meio a
tantos e-mails dispersos e tantos tópicos discutidos pela metade.

Para mim está claro que é um experimento sério de consolidação global de
dados, e que portanto requer antes um preparo, reprodutível por exemplo com
PostGIS, para *experts* em processamento de dados poderem conferir e
"assinarem embaixo" (eu me incluo nos voluntários), bem como emitirem
relatórios mostrando os rumos da coisa antes de alterar a base OSM.

O uso dos dados do CNEF e o cruzamento com dados do CRP
 são dos mais relevantes (!),
são dados oficiais e atualizados.
Talvez o mais importante não seja a interpolação (num país onde ainda tem
gente adotando numeração predial por Numerologia), mas o destaque das
inconsistências e o registro confiável e definitivo dos dados
relativos a *faces
de quadra*.

Se todos aqui são "meio nerd", pode ser direto no Github,

   https://github.com/*OSMBrasil* /
*_NOME_DO_PROJETO_*

*Qual nome será dado a esse projeto?*  (ex. *CNEFE2010*)






Em 5 de janeiro de 2017 09:35, Reinaldo Neves 
escreveu:

> Também acredito que interpolação pelos dados do CNEFE vai trazer mais
> problemas que solução.
>
>
>
> Apenas a título de informação em São Paulo nas cidades que compõem a
> região metropolitana, a capital inclusive, o cep se inicia por zero,
> acredito que seja por isso que observou registros com 7 digítos.
>
>
>
> Evidente que o problema ocorre na definição do campo CEP com sendo int e
> não char como é o correto.  No arquivo do CNEFE original a informação está
> correta.
>
>
>
> ___
>
> Reinaldo Neves
>
> ☎: (11) 3221-3722
>
> ✉: rne...@equacao.com.br
>
> http://br.linkedin.com/in/rrneves
>
> https://medium.com/Reinaldo_Neves 
>
>
>
> *De:* Papibaquígrafo [mailto:agostinho74...@yahoo.com.br]
> *Enviada em:* quinta-feira, 5 de janeiro de 2017 07:49
> *Para:* OpenStreetMap no Brasil
> *Assunto:* Re: [Talk-br] Sobre addr:interpolation - possibilidades
>
>
>
> Santamariense,
>
>
>
> Sobre o ponto 1:
>
>
>
> O trabalho do recenseador não é muito diferente do nosso como
> colaboradores do OSM: você vai a campo e coleta os números da fachada das
> casas. Se falta o número de uma casa, então para todos os efeitos práticos
> esse número não existe: este é o princípio da verificabilidade do OSM ("the
> truth is on the ground"). Portanto, não há nada de errado em pular os
> endereços que constam como S/N no CNEFE. Pode-se até deixar uma nota
> dizendo "faltam N números nesta face" para posterior verificação.
>
>
>
> Por outro lado, ao adicionar interpolações, nós estamos "especulando" a
> respeito da numeração, o que de certa forma até fere o princípio da
> verificabilidade. E isso pode até mesmo introduzir erros e inconsistências.
> Se o número faltante é o da esquina, a interpolação não vai deixar de ser
> incompleta. Pior que isso, é sabido que existem quebras na sequencialidade
> dos números (acontece na rua em que cresci em Porto Alegre). Imagine se
> você usar um desses números "anômalos" (ou mesmo um dado incorreto, algo
> que há de existir no CNEFE) como base da interpolação!!
>
>
>
> (Note também que as tags para numeração interpolada foram pensadas para o
> sistema europeu, de números sequenciais. No Brasil, onde a numeração é por
> metro, mais de 9 em cada 10 números gerados serão inexistentes! Em uma mapa
> completo, a *não existência* de um número é uma informação tão importante
> quando o da *existência* de um número)
>
>
>
> Em suma, vamos tirar do CNEFE o que o CNEFE nos dá, sem especular em cima.
>
>
>
> Agora, sobre pontos menos importantes:
>
>
>
> a) Será preciso realinhar os shapes do IBGE com o OSM. Eu queria pedir que
> se mantenha um registro desses deslocamentos, para uso futuro. O workflow
> poderia ser o seguinte: 1. abrir o shp no JOSM e traçar algumas linhas
> entre uma esquina do shp e a correspondente esquina no OSM; 2. salvar essas
> geometrias em um arquivo; 3. usar a média aritmética das linhas para
> realinhar o shp; 4. *arquivar* o deslocamento usado em cada setor
> censitário nalgum lugar da wiki.
>
> b) Notei que há muitas inconsistências no campo CEP. Em São Paulo, por
> exemplo, eles tem só 7 digitios, o erro parece ser que falta o "1" no
> início.
>
> c) Sobre a tag source, veja exemplos mais recentes. Na importação de Nova
> York, não há source nos objetos. Note que ninguém jamais atualiza o source
> ao fazer uma edição, logo você precisa ir no histórico de qualquer forma
> para saber algo com convicção.
>
>
>
> E, pra finalizar, queria dizer que essa é uma ótima iniciativa. Parabéns!
>
>
>
> Em Quarta-feira, 4 de Janeiro de 2017 23:30, santamariense <
> imagens...@gmail.com> escreveu:
>
>
>
> @Papibaquígrafo,
>
> 1. A questão é que existem muitos SN (sem número) cadastrados entre

Re: [Talk-br] strava

[Arlindo Pereira]

Complementando: o Strava disponibiliza camadas heatmap (mapas de calor) com
as trilhas de seus usuários, anonimizadas. É possível escolher entre
somente ciclismo, somente corrida ou os dois juntos, em diferentes estilos
de coloração.


[]s
Arlindo Pereira

Em 5 de janeiro de 2017 10:22, Helio Cesar Tomio 
escreveu:

> Complementando o que o Roger muito bem explanou, a camada do strava pode
> ser aberta também no editor iD.
>
> Existe tb um editor iD modificado pela Strava, para auxiliar nas edições :
> https://strava.github.io/iD/
>
> Em 05/01/2017 07:52, "Gerald Weber"  escreveu:
>
>> Oi Turma
>>
>>
>> eu vejo muitas menções ao strava nas discussões aqui e no telegram, já vi
>> até edições com gente se referindo ao strava.
>>
>>
>> Eu só não entendi muito bem como nós podemos usar os dados do strava.
>> Lendo a wiki do OSM eu fiquei na mesma.
>>
>>
>> Entendi que se trata de um aplicativo onde se registra caminhadas,
>> corridas etc. Uma amiga minha até me mostrou a trilha gps que ela gravou de
>> bicicleta.
>>
>>
>> Mas onde entramos nisto? A gente tem acesso a estas trilhas gps? como?
>>
>>
>> qualquer dica será muito bem vinda
>>
>>
>> abraço
>>
>>
>> Gerald
>>
>>
>>
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
>>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] strava

[Helio Cesar Tomio]

Complementando o que o Roger muito bem explanou, a camada do strava pode
ser aberta também no editor iD.

Existe tb um editor iD modificado pela Strava, para auxiliar nas edições :
https://strava.github.io/iD/

Em 05/01/2017 07:52, "Gerald Weber"  escreveu:

> Oi Turma
>
>
> eu vejo muitas menções ao strava nas discussões aqui e no telegram, já vi
> até edições com gente se referindo ao strava.
>
>
> Eu só não entendi muito bem como nós podemos usar os dados do strava.
> Lendo a wiki do OSM eu fiquei na mesma.
>
>
> Entendi que se trata de um aplicativo onde se registra caminhadas,
> corridas etc. Uma amiga minha até me mostrou a trilha gps que ela gravou de
> bicicleta.
>
>
> Mas onde entramos nisto? A gente tem acesso a estas trilhas gps? como?
>
>
> qualquer dica será muito bem vinda
>
>
> abraço
>
>
> Gerald
>
>
>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] RES: Sobre addr:interpolation - possibilidades

[Reinaldo Neves]

Também acredito que interpolação pelos dados do CNEFE vai trazer mais problemas 
que solução.

 

Apenas a título de informação em São Paulo nas cidades que compõem a região 
metropolitana, a capital inclusive, o cep se inicia por zero,  acredito que 
seja por isso que observou registros com 7 digítos.  

 

Evidente que o problema ocorre na definição do campo CEP com sendo int e não 
char como é o correto.  No arquivo do CNEFE original a informação está correta.

 

___

Reinaldo Neves

☎: (11) 3221-3722

✉:   rne...@equacao.com.br

  http://br.linkedin.com/in/rrneves

  https://medium.com/Reinaldo_Neves

 

De: Papibaquígrafo [mailto:agostinho74...@yahoo.com.br] 
Enviada em: quinta-feira, 5 de janeiro de 2017 07:49
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Sobre addr:interpolation - possibilidades

 

Santamariense,

 

Sobre o ponto 1:

 

O trabalho do recenseador não é muito diferente do nosso como colaboradores do 
OSM: você vai a campo e coleta os números da fachada das casas. Se falta o 
número de uma casa, então para todos os efeitos práticos esse número não 
existe: este é o princípio da verificabilidade do OSM ("the truth is on the 
ground"). Portanto, não há nada de errado em pular os endereços que constam 
como S/N no CNEFE. Pode-se até deixar uma nota dizendo "faltam N números nesta 
face" para posterior verificação.

 

Por outro lado, ao adicionar interpolações, nós estamos "especulando" a 
respeito da numeração, o que de certa forma até fere o princípio da 
verificabilidade. E isso pode até mesmo introduzir erros e inconsistências. Se 
o número faltante é o da esquina, a interpolação não vai deixar de ser 
incompleta. Pior que isso, é sabido que existem quebras na sequencialidade dos 
números (acontece na rua em que cresci em Porto Alegre). Imagine se você usar 
um desses números "anômalos" (ou mesmo um dado incorreto, algo que há de 
existir no CNEFE) como base da interpolação!!

 

(Note também que as tags para numeração interpolada foram pensadas para o 
sistema europeu, de números sequenciais. No Brasil, onde a numeração é por 
metro, mais de 9 em cada 10 números gerados serão inexistentes! Em uma mapa 
completo, a não existência de um número é uma informação tão importante quando 
o da existência de um número)

 

Em suma, vamos tirar do CNEFE o que o CNEFE nos dá, sem especular em cima.

 

Agora, sobre pontos menos importantes:

 

a) Será preciso realinhar os shapes do IBGE com o OSM. Eu queria pedir que se 
mantenha um registro desses deslocamentos, para uso futuro. O workflow poderia 
ser o seguinte: 1. abrir o shp no JOSM e traçar algumas linhas entre uma 
esquina do shp e a correspondente esquina no OSM; 2. salvar essas geometrias em 
um arquivo; 3. usar a média aritmética das linhas para realinhar o shp; 4. 
arquivar o deslocamento usado em cada setor censitário nalgum lugar da wiki.

b) Notei que há muitas inconsistências no campo CEP. Em São Paulo, por exemplo, 
eles tem só 7 digitios, o erro parece ser que falta o "1" no início.

c) Sobre a tag source, veja exemplos mais recentes. Na importação de Nova York, 
não há source nos objetos. Note que ninguém jamais atualiza o source ao fazer 
uma edição, logo você precisa ir no histórico de qualquer forma para saber algo 
com convicção.

 

E, pra finalizar, queria dizer que essa é uma ótima iniciativa. Parabéns!

 

Em Quarta-feira, 4 de Janeiro de 2017 23:30, santamariense 
 escreveu:

 

@Papibaquígrafo,

1. A questão é que existem muitos SN (sem número) cadastrados entre
casas que já tem número. E as linhas ajudam a tapar este buraco,
interpolando numerações intermediárias que possam existir. Do meu
ponto de vista todo o material é provisório, pois na maioria dos casos
o ponto será apagado porque vai para a building quando se tiver a
certeza de qual building é. E a linha será apagada quando todas as
casas de uma face da quadra tiver os números corretos na building
correta.

2. Interessante. Não tinha pensado nisso. Mesmo assim me pergunto se
não seria melhor nos objetos para ser mais prático, quando futuramente
alguém for contribuir, buscar a fonte em históricos de changesets é
não-prático. Em Paris, tudo indica que se adicionou source a todos os
objetos (http://overpass-turbo.eu/s/l3J)

3. Isso são pormenores, mas que são sim muito relevantes. Eu proponho
que numa primeira fase, se faça testes em alguns municípios e que a
gente (cada um) faça relatório concomitantemente ao trabalho, a fim de
anotar todos os problemas/dúvidas enfrentados.

___
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] strava

[Roger C. Soares]

  
  
No josm tem várias camadas do strava,
  vc pode escolher entre cycling, running ou a combinação das duas.
  No labs não sei qual eles usam...
  
  Atenciosamente,
  Roger.
  
  --
  Em 05-01-2017 08:21, Gerald Weber escreveu:


  
Oi Roger


Ah, entendi, obrigado. Tem como saber que tipo de trilhas são?
Para mim faz muita diferença saber se é de caminhada ou
bicicleta.


abraço


Gerald
  
2017-01-05 8:08 GMT-02:00 Roger C.
  Soares :
  

  Adiciona
a camada do strava no josm, é só ir nas
preferencias, clicar no icone "WMS/TMS" e ativar a
camada. Eles geram um heatmap a partir das trilhas
enviadas.

As vezes eu tb dou uma olhada no routing errors em:
http://labs.strava.com/routing-errors/#250/4/-97.42000/39.25000

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] strava

[Gerald Weber]

Oi Roger

Ah, entendi, obrigado. Tem como saber que tipo de trilhas são? Para mim faz
muita diferença saber se é de caminhada ou bicicleta.

abraço

Gerald

2017-01-05 8:08 GMT-02:00 Roger C. Soares :

> Adiciona a camada do strava no josm, é só ir nas preferencias, clicar no
> icone "WMS/TMS" e ativar a camada. Eles geram um heatmap a partir das
> trilhas enviadas.
>
> As vezes eu tb dou uma olhada no routing errors em:
> http://labs.strava.com/routing-errors/#250/4/-97.42000/39.25000
>
> Atenciosamente,
> Roger.
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] strava

[Roger C. Soares]

  
  
Inclusive, outro dia eu passei nesse
  trecho e tem uma pista nova, mas eu não marquei os detalhes do
  trecho todo... se alguém conhecer melhor, o strava pode dar uma
  ajudada:
  
  http://labs.strava.com/routing-errors/#250/16/-47.00407/-22.44771
  
  
  Atenciosamente,
  Roger.
  
  --
  Em 05-01-2017 08:08, Roger C. Soares escreveu:


  
  Adiciona a camada do strava no josm,
é só ir nas preferencias, clicar no icone "WMS/TMS" e ativar a
camada. Eles geram um heatmap a partir das trilhas enviadas.

As vezes eu tb dou uma olhada no routing errors em:
http://labs.strava.com/routing-errors/#250/4/-97.42000/39.25000

Atenciosamente,
Roger.

--
Em 05-01-2017 07:51, Gerald Weber escreveu:
  
  

  

  

  

  Oi
Turma
  
  
  eu
vejo muitas menções ao strava nas discussões
aqui e no telegram, já vi até edições com gente
se referindo ao strava. 
  
  
  Eu
só não entendi muito bem como nós podemos usar
os dados do strava. Lendo a wiki do OSM eu
fiquei na mesma.
  
  
  Entendi
que se trata de um aplicativo onde se registra
caminhadas, corridas etc. Uma amiga minha até me
mostrou a trilha gps que ela gravou de
bicicleta. 
  
  
  Mas
onde entramos nisto? A gente tem acesso a estas
trilhas gps? como?
  
  
  qualquer
dica será muito bem vinda
  
  
  abraço
  
  
  Gerald
  
  
  
  

  

  

  




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

  
  


  


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

Re: [Talk-br] strava

[Roger C. Soares]

  
  
Adiciona a camada do strava no josm, é
  só ir nas preferencias, clicar no icone "WMS/TMS" e ativar a
  camada. Eles geram um heatmap a partir das trilhas enviadas.
  
  As vezes eu tb dou uma olhada no routing errors em:
  http://labs.strava.com/routing-errors/#250/4/-97.42000/39.25000
  
  Atenciosamente,
  Roger.
  
  --
  Em 05-01-2017 07:51, Gerald Weber escreveu:


  

  

  

  
Oi
  Turma


eu
  vejo muitas menções ao strava nas discussões aqui
  e no telegram, já vi até edições com gente se
  referindo ao strava. 


Eu
  só não entendi muito bem como nós podemos usar os
  dados do strava. Lendo a wiki do OSM eu fiquei na
  mesma.


Entendi
  que se trata de um aplicativo onde se registra
  caminhadas, corridas etc. Uma amiga minha até me
  mostrou a trilha gps que ela gravou de bicicleta. 


Mas
  onde entramos nisto? A gente tem acesso a estas
  trilhas gps? como?


qualquer
  dica será muito bem vinda


abraço


Gerald




  

  

  

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



  


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

Re: [Talk-br] Sobre addr:interpolation - possibilidades

[Papibaquígrafo]

Santamariense,
Sobre o ponto 1:
O trabalho do recenseador não é muito diferente do nosso como colaboradores do 
OSM: você vai a campo e coleta os números da fachada das casas. Se falta o 
número de uma casa, então para todos os efeitos práticos esse número não 
existe: este é o princípio da verificabilidade do OSM ("the truth is on the 
ground"). Portanto, não há nada de errado em pular os endereços que constam 
como S/N no CNEFE. Pode-se até deixar uma nota dizendo "faltam N números nesta 
face" para posterior verificação.

Por outro lado, ao adicionar interpolações, nós estamos "especulando" a 
respeito da numeração, o que de certa forma até fere o princípio da 
verificabilidade. E isso pode até mesmo introduzir erros e inconsistências. Se 
o número faltante é o da esquina, a interpolação não vai deixar de ser 
incompleta. Pior que isso, é sabido que existem quebras na sequencialidade dos 
números (acontece na rua em que cresci em Porto Alegre). Imagine se você usar 
um desses números "anômalos" (ou mesmo um dado incorreto, algo que há de 
existir no CNEFE) como base da interpolação!!

(Note também que as tags para numeração interpolada foram pensadas para o 
sistema europeu, de números sequenciais. No Brasil, onde a numeração é por 
metro, mais de 9 em cada 10 números gerados serão inexistentes! Em uma mapa 
completo, a não existência de um número é uma informação tão importante quando 
o da existência de um número)

Em suma, vamos tirar do CNEFE o que o CNEFE nos dá, sem especular em cima.
Agora, sobre pontos menos importantes:
a) Será preciso realinhar os shapes do IBGE com o OSM. Eu queria pedir que se 
mantenha um registro desses deslocamentos, para uso futuro. O workflow poderia 
ser o seguinte: 1. abrir o shp no JOSM e traçar algumas linhas entre uma 
esquina do shp e a correspondente esquina no OSM; 2. salvar essas geometrias em 
um arquivo; 3. usar a média aritmética das linhas para realinhar o shp; 4. 
arquivar o deslocamento usado em cada setor censitário nalgum lugar da wiki.
b) Notei que há muitas inconsistências no campo CEP. Em São Paulo, por exemplo, 
eles tem só 7 digitios, o erro parece ser que falta o "1" no início.c) Sobre a 
tag source, veja exemplos mais recentes. Na importação de Nova York, não há 
source nos objetos. Note que ninguém jamais atualiza o source ao fazer uma 
edição, logo você precisa ir no histórico de qualquer forma para saber algo com 
convicção.
E, pra finalizar, queria dizer que essa é uma ótima iniciativa. Parabéns!
 

Em Quarta-feira, 4 de Janeiro de 2017 23:30, santamariense 
 escreveu:
 

 @Papibaquígrafo,

1. A questão é que existem muitos SN (sem número) cadastrados entre
casas que já tem número. E as linhas ajudam a tapar este buraco,
interpolando numerações intermediárias que possam existir. Do meu
ponto de vista todo o material é provisório, pois na maioria dos casos
o ponto será apagado porque vai para a building quando se tiver a
certeza de qual building é. E a linha será apagada quando todas as
casas de uma face da quadra tiver os números corretos na building
correta.

2. Interessante. Não tinha pensado nisso. Mesmo assim me pergunto se
não seria melhor nos objetos para ser mais prático, quando futuramente
alguém for contribuir, buscar a fonte em históricos de changesets é
não-prático. Em Paris, tudo indica que se adicionou source a todos os
objetos (http://overpass-turbo.eu/s/l3J)

3. Isso são pormenores, mas que são sim muito relevantes. Eu proponho
que numa primeira fase, se faça testes em alguns municípios e que a
gente (cada um) faça relatório concomitantemente ao trabalho, a fim de
anotar todos os problemas/dúvidas enfrentados.

___
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] strava

[Gerald Weber]

Oi Turma


eu vejo muitas menções ao strava nas discussões aqui e no telegram, já vi
até edições com gente se referindo ao strava.


Eu só não entendi muito bem como nós podemos usar os dados do strava. Lendo
a wiki do OSM eu fiquei na mesma.


Entendi que se trata de um aplicativo onde se registra caminhadas, corridas
etc. Uma amiga minha até me mostrou a trilha gps que ela gravou de
bicicleta.


Mas onde entramos nisto? A gente tem acesso a estas trilhas gps? como?


qualquer dica será muito bem vinda


abraço


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