Re: [Talk-br] Nova proposta de classificação viária - Votação encerrada

[santamariense]

> Eu gostaria de sugerir que aqueles que fizeram apontamentos nos seus
> votos abram discussão a respeito deles na página de discussão da
> proposta. [1] Lá é o lugar ideal para discutir e depois votar
> alterações e refinamentos na proposta.

> Acho que já existe um consenso substancial de que a regionalização por
> RGInts (parte da regra 2.2) e talvez também por RGIs (parte da regra
> 3.1) não seria a mais adequada. Alguns colegas propuseram e começaram
> a explorar os resultados de regionalizar usando as categorias das
> REGICs para adicionar alguns pólos ao conjunto considerado. As rotas
> preliminares que foram apresentadas por eles no Telegram fazem um
> certo sentido para mim, então, havendo interesse de outros colegas,
> não me oponho à substituição. As que foram apresentadas produzem um
> resultado melhor do que as RGInts, no sentido de identificarem melhor
> os eixos indutores do desenvolvimento regional.

Concordo. Poderíamos já votar sobre a supressão delas no texto uma vez
que são poucas cidades, e poderiam ser tratadas como exceção e também
porque em tais cidades o pessoal pareceu não se importar com a falta
de conexão trunk a elas. Acho que poderia ser aberto uma seção
"votação" na página de discussão e sub-seção para cada ponto a ser
votado. Cada um dá o seu voto e a sua motivação (se achar necessário)
porém para não poluir a página sugiro que discussões continuem se
dando nos canais oficiais e no Telegram. Por fim creio que uma votação
para cada um dos tipos de regiões geográficas fica mais adequado.

> Apesar disso, o número de diferenças em relação ao resultado final das
> demais regras tem se mostrado relativamente pequeno, de forma que
> essas rotas adicionais poderiam ser tratadas na lista de exceções
> junto com outras exceções que possam ser levantadas, por exemplo, como
> já foi citado por colegas diferentes algumas vezes, os acessos a
> grandes portos e aeroportos. Ou seja, é necessário mais estudo e
> comparação dos casos particulares.

Positivo.

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

Re: [Talk-br] Nova proposta de classificação viária - Votação encerrada

[santamariense]

A proposta está recebendo novas propostas de variáveis as quais
precisarão passar por novas votações, quer pontualmente, quer em
conjuntos. Várias observações foram feitas, muitas poderão ser votadas
em breve e outras tantas poderão ser votadas com o amadurecimento da
implantação em mapa do que está sendo proposto.

Como já foi falado em várias ocasiões, a discussão não acaba aqui, mas
sim evolui com o andar do mapeamento. Vou declarar a proposta
aprovada, uma vez que há a aprovação da maioria dos que votaram e por
respeito a quem dedicou o tempo que tinha para estudar a proposta e
dar seu voto. E para que possamos virar a página e a partir desse
momento votar casos pontuais conforme forem surgindo, bem como ajustes
no texto da proposta que se julgar necessário.

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

Re: [Talk-br] Nova proposta de classificação viária - Votação encerrada

[santamariense]

> Acho que a proposta base pode ser considerada aprovada e os questionamentos
> levantados devem ser discutidos e votados separadamente. Alguns itens da
> proposta também precisa de ajustes na terminologia (que não mudam o sentido
> da proposta, mas deixam ela mais uniforme):

Acho que é um bom caminho. Dar como aprovado e passar a discutir e
votar os pormenores para então consolidar.

> "se a proposta obteve apoio suficiente, seu status pode ser alterado para
> aprovada. Uma regra geral para 'apoio suficiente' é 8 votos unânimes de
> aprovação ou pelo menos 10 votos com mais de 74% de aprovação" (tradução
> livre).

Ele também diz que outros fatores podem ser considerados como no caso
de uma feature já estar em uso, o que é o nosso caso. A gente não está
criando uma nova tag, apenas está ajustando o conceito de tags já
existentes de modo a seguir uma padronização internacional. Ao meu
ver, mesmo quem votou contra a proposta ainda assim está seguindo por
este caminho, apesar de discordar em algumas questões pontuais, que os
levaram a discordar do todo.

> No artigo sobre o processo de votação também diz: "todas as sugestões
> devem ser levadas em consideração antes de uma proposta ser aprovada
> ou rejeitada, a fim de resolver quaisquer deficiências na proposta
> original (se houver)." Eu acho que isso que pode estar faltando nesse
> caso.

Concordo. E na verdade a discussão sempre seguirá conforme for se
observando pequenas peculiaridades/controvérsias ao mapear.

> No mesmo artigo, há uma seção para o período "pós-voto" (post-vote). O
> template Proposal Page, [3] usado na maioria dos artigos anglófonos de
> propostas, suporta o valor "Post-Vote" para o campo status. Se vocês
> procurarem no wiki por "Post-Vote," vão encontrar vários artigos de
> propostas com uma seção "Post-Vote" onde são discutidos os próximos
> passos, onde se discute como tratar dos apontamentos feitos por quem
> votou. Me parece que estamos exatamente nesta fase.

Concordo.

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

Re: [Talk-br] Nova proposta de classificação viária - Votação encerrada

[santamariense]

Encerrado o processo de votação, alguém se opõe em declarar a proposta
aprovada? O próximo passo é atualizar textos da Wiki, que tratam sobre
o assunto. Passarei aqui as correções a serem feitas para apreciação
da comunidade. Também há uma orientação em manter a página de votação
onde está, a qual pode ser usada de referência e ser linkada por
outras páginas.


> Registro aqui o encerramento da votação da nova proposta de
> classificação viária o qual ocorreu na data de 29/05/2020, às
> 23:59:59, horário de Rio Branco/AC.
>
> Foram um total de 11 votos, onde 7 concordaram, 3 discordaram e 1 absteve.
>
> Existem alguns pontos que foram levantados por colegas e poderão
> entrar na proposta passando por nova votação, como de costume.
>
> Também existem páginas da wiki que precisariam ser revisadas, conforme
> citei no email [1] que enviei no encerramento da votação, antes do
> pedido de prorrogação.
>
> [1] - https://lists.openstreetmap.org/pipermail/talk-br/2020-May/012834.html
>
> Alguma sugestão?

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

[Talk-br] Nova proposta de classificação viária - Votação encerrada

[santamariense]

Registro aqui o encerramento da votação da nova proposta de
classificação viária o qual ocorreu na data de 29/05/2020, às
23:59:59, horário de Rio Branco/AC.

Foram um total de 11 votos, onde 7 concordaram, 3 discordaram e 1 absteve.

Existem alguns pontos que foram levantados por colegas e poderão
entrar na proposta passando por nova votação, como de costume.

Também existem páginas da wiki que precisariam ser revisadas, conforme
citei no email [1] que enviei no encerramento da votação, antes do
pedido de prorrogação.

[1] - https://lists.openstreetmap.org/pipermail/talk-br/2020-May/012834.html

Alguma sugestão?

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

Re: [Talk-br] Nova proposta de classificação viária - Explanação

[santamariense]

A questão é que sempre haverão exceções por mais que se tente prever
elas. Daí vem uma pergunta: O que faz com que essas exceções surjam e
o que as fazem configurar como exceções? O que as fazem existir é o
ponto de vista de um mapeador, que a vê como algo que deveria ser
corrigido, e se for de comum acordo dos interessados que votarem, se
aplica e aí sim passa a ser considerada uma exceção.

As exceções que tem surgido, que são poucas e de casos muito
específicos não tem costumado ser idênticas a outras que se tenha
conhecimento a ponto de se pôr mais regras na proposta. E também se
for, se adiciona a qualquer momento no futuro, mesmo após aprovação.
Até porque estamos estagnados nesse ponto de se encontrar uma regra
perfeita há anos, só que nesse meio tempo pessoas continuam a usar
produtos baseados em OSM, direta ou indiretamente, cujos dados tem
sempre inconsistências porque sempre tem mapeador que leva ao pé da
letra o que lê na wiki o instruindo na forma de mapear, como por
exemplo, modificar trechos de rodovias quando há a mudança de sua
velocidade, se tiver ou não acostamento, entre outras variáveis da
proposta atual que causam essas inconsistências no mapa.

É muito mais simples votar algo pontual, que não tenha sido
contemplado com a proposta do que divagar a ideia tentando prever cada
uma das candidatas a exceções elencadas por cada um dos mapeadores
interessados.

Que tal tentarmos levar este assunto pro grupo RJ e dialogar com a
comunidade sobre a aplicação nesse exato estado? Inclusive vou retomar
esse assunto lá. Eu entendo seu ponto de vista que deveria haver
participação de todos os estados, mas a realidade é bem diferente,
acredite, passei por todos os grupos estaduais tentando obter feedback
do pessoal local, e tentando trazer o pessoal para a discussão de modo
a obter deles o que eles teriam de melhor a oferecer, que é o
conhecimento local, contudo a maioria não quer participar, seja por
não se importar com o tema, seja por não querer ter atritos com outros
mapeadores ou com a comunidade, ou seja por simplesmente não ter
opinião formada sobre o assunto a ponto de querer participar. Por fim,
por menos que tu tenha participado, ainda assim tu foi um dos, ou O,
que mais participou a exceção do pessoal que discute ativamente. Logo,
ter grupos discutindo aplicação da regra em cada estado é uma utopia.

Também, como já falei no grupo de Classificação viária no Telegram,
existe uma questão maior, se a comunidade deseja ainda manter a
classificação viária de 2013, ou por mais que do seu ponto de vista a
nova proposta não seja perfeita, ainda assim seria melhor nós
redirecionarmos o mapeamento para o conceito de sua funcionalidade,
dado as lacunas que a aplicação do schema2013 deixa no mapa.

Vejo que você elencou alguns problemas. O que acha de, uma vez que
você discorda da proposta por não te agradar em pontos muitos
específicos nos resultados, trazer sugestões diretas de melhoria no
texto da proposta? Mesmo depois de aprovada a discussão continua,
então sempre é tempo.

Também há a questão do limiar populacional, como dito, algum precisava
ser establecido, porque quanto mais populosa for uma cidade, em
teoria, maior sua importância, e esse é o ponto, "importância", teria
algo para acrescentar na proposta de modo a melhor definir a
importância dos lugares?

Ainda sobre a importância de uma cidade, se alguém considerar que
alguma cidade tenha uma extraordinária importância a ponto de uma
estrada que leve a ela dever ter classificação maior, por exemplo,
bastará trazer o assunto para a apreciação da comunidade, a qual será
votada.

Não importa quão perfeita/completa seja uma proposta de classificação
viária, sempre haverá pontos a serem discutidos porque um ou outro
mapeador não gostou de algum resultado específico. Agora, se faz ou
não sentido, cabe ao coletivo interessado da comunidade decidir. No
final das contas seja para votar uma proposta inteira ou seja para
votar casos especiais, sempre passará por processo de votação.

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

[Talk-br] Nova proposta de classificação viária - Explanação

[santamariense]

Como o voto de um colega traz a tona uma interpretação mal-entendida
sobre o que está sendo votado, e já explanando para outros colegas que
não acompanharam por completo as discussões até o presente momento,
comento aqui uma argumentação de voto.

Antes de mais nada obrigado por se manifestar, pois a dúvida que um
tem, outros podem também ter, por isso é importante o diálogo e que a
comundade se envolva na discussão.

> Minha opinião está baseada no arquivo .osm que foi distribuído nos grupos do 
> Telegram. Ao abri-lo eu pude observar como seria a classificação caso esta 
> proposta fosse aprovada, e notei algumas questões que me incomodaram. 
> Partirei delas para construir meu argumento:
>

Gostaria de informar que os arquivos com rascunhos de como ficaria a
malha viária são meramente ilustrativos. O que estamos propondo aqui é
a regra de mapeamento e não a interpretação dela, que foi o que eu fiz
ao apresentar os mapas, e como dito no e-mail no qual eu enviei a
lista Talk-BR ao chamar a comunidade a votar, eles ficam como sugestão
de aplicação, e não como obrigatoriedade de aplicação do mapa. O que
defendemos sim é que as comunidades locais possam ir trazendo à
discussão sua malha viária e construindo ela, norteado pela proposta
que estamos apresentando. Além do mais, o arquivo com a malha trunk
apresentado contém parte da totalidade do que será a malha trunk. Veja
bem, o arquivo com a malha trunk contém as conexões entre cidades ou
aglomerações de cidades com mais de 200 mil habitantes e ainda não
levou em consideração as interligações entre as cidades desse porte
que ficam dentro dessas aglomerações e nem dessas com aquelas que
ficam dentro de outras aglomerações. No mapa ilustrativo ainda não foi
levado em consideração as cidades-polos de regiões geográficas
intermediárias na construção da malha trunk, porém a maior parte delas
já estariam inclusas por tabela, cabendo apenas averiguar. Na ocasião
cheguei a averiguar e compartilhar no grupo de classificação viária do
telegram um mapa com as cidades-polos que faltariam ser conectadas, e
se bem me recordo eram em número de 17.

> O litoral do estado de São Paulo não é alcançado por nenhuma rodovia trunk, 
> mesmo já havendo três vias com classificação motorway na região (Imigrantes, 
> Anchieta e Tamoios). Eu entendo que a proposta não considera a mera condição 
> física da via, e concordo com esta abordagem. Por outro lado, o fato de 
> nenhuma das três vias ter sido incluída me causa dúvidas sobre a pertinência 
> dos critérios no mundo real.

O litoral de São Paulo provavelmente é o melhor exemplo do que
comentei recém, ainda não se levou em conta as cidades da aglomeração
urbana da cidade de São Paulo, que consta no IBGE Censo 2010 como área
urbana contínua. Em outras palavras não se levou ainda em consideração
as cidades do litoral com mais de 200 mil habitantes. Mas pela regra
que apresentamos, toda cidade com mais de 200 mil habitantes deve ter
uma ligação trunk no mínimo. Enfim, para saber se haverá conexão entre
2 cidades, deverá se analisar assim: Obtenha a população da menor
entre as duas cidades, extraia a raiz quadrada da população dela para
saber se ela alcança a cidade maior, se sim, verifica seu porte
(2k|20k|200k) para saber o tipo de conexão que deverá haver entre
elas, sempre lembrando que se trechos dessa conexão já estiverem com
classificação de highway maior por interconectar cidades maiores, os
mesmos deverão ser mantidos. Da mesma maneira ainda há a possibilidade
de conectar o litoral de São Paulo com Angra dos Reis e Rio de
Janeiro, com base na proposta apresentada.

> Do mesmo modo, no estado do Rio de Janeiro, a RJ-124 (atualmente motorway), 
> que liga a capital à Região dos Lagos não entrou no corte da proposta. A 
> Rodovia Amaral Peixoto se encaixa no mesmo caso. Ainda no Rio de Janeiro, a 
> RJ-116, que é uma importante ligação da capital com a cidade de Nova Friburgo 
> e parte significativa do interior do estado (volto neste ponto em breve) 
> também não alcançou os critérios.

Pela proposta se uma rodovia apresenta todos os critérios para ser
motorway, os quais estão descritos na proposta, elas serão motorways.
Antes de qualquer argumentação que apresentarei doravante, é preciso
esclarecer que ajustes podem serem feitos na malha viária, pois é
sabido que exceções existirão e é impossível prever todas elas. Então,
se após aplicada a metodologia, a comunidade local perceber que falta
algum trecho ou rodovia que deveria estar numa certa classificação, e
de comum acordo dos interessados na questão decidirem fazer esses
ajustes, os ajustes podem serem feitos. No RS teve casos assim.

Bem, vamos ao caso da RJ-124... segundo o IBGE, Cabo Frio teria hoje
219,863 habitantes, logo, deve sim ser ligada por trunk, e
adicionalmente a isso, Macaé-Rio das Ostras-Cabo Frio são
cidades-polos integrantes de uma Região Geográfica Intermediária,
ficando sugerido que poderia haver conexões estratégicas naquela
região, as quais podem ser a

Re: [Talk-br] Nova proposta de classificação viária - Votação encerrada

[santamariense]

> Quando você iniciou a votação, você citou as regras do seguinte artigo
> em inglês como norteadoras do processo, em particular em relação ao
> período da votação (2 semanas):
> https://wiki.openstreetmap.org/wiki/Proposal_process

Sim, busquei alguma diretriz de votação que já estivesse em uso no
OSM, e foi ela que encontrei para usar como norteadora do processo.

> Neste mesmo artigo, diz que a proposta deve ter no mínimo 8 votos
> unânimes a favor para ser considerada aprovada, ou 10 com pelo menos
> 74% de aprovação, e que se isso não for atingido no período de 2
> semanas, o período de votação deveria ser estendido. Essas regras
> também vão valer? Me parece que o ideal seria estender o período de
> votação para tentar obter mais votos.
>

Esse processo no qual me baseei parece ser usado para tomada de
decisão acerca da criação de novas tags a nível mundial. Imagino que
como a nossa votação é a nível nacional, a quantidade mínima de votos
exigidos poderia ser menor. A mesma passagem do texto cita algo como
que outros fatores poderiam ser considerados, como o fato de já estar
em uso, o que não deixa de ser o caso em parte do que já está
classificado.

Penso ainda que essa exigência de mínimo de quorum seja para evitar
que grupos isolados criem tags por conta própria sem que outros tomem
conhecimento, o que eu concordo que deva ocorrer. No nosso caso de
votação da classificação viária, ela foi amplamente divulgada,
inclusive em grupos do Telegram, onde o pessoal parece se concentrar
tanto a nível nacional como a nível estadual. Logo, divulgado foi, e
portanto a maior parte do pessoal na verdade se abstém, só que sem
registrar votos.

Fica mais coerente com a realidade sobre que está sendo votado que,
para a aprovação, a maioria simples decida, já que é uma discussão a
respeito do que já está em uso e que sempre foi um assunto polêmico.

Mas enfim, acho justo que o prazo seja prorrogado por uma vez já que
foi pedido por membro diretamente envolvido nas discussões. A pedido e
para tentar obter mais votos, sugiro uma prorrogação de prazo por mais
2 semanas, encerrando o prorrogação de prazo em 29 de maio de 2020.
Nesse meio tempo o pessoal pode continuar a sugerir mudanças no texto,
bem como fazer seus testes aplicando a metodologia para tomar a
decisão do seu voto.

Creio que a maioria conheça o grupo de classificação de vias, mas caso
não conheça, junte-se a nós em
https://telegram.me/osm_classificacao_vias para debater o assunto.

O que acha(m)?

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

[Talk-br] Nova proposta de classificação viária - Votação encerrada

[santamariense]

Registro aqui a finalização do período de votação da nova proposta de
classificação viária. Votaram 5 mapeadores, onde 3 concordaram, sendo
que 1 fez algumas ressalvas; 1 discordou da proposta, fazendo alguns
apontamentos, ainda dentro do conceito funcional da rodovia, os quais
podem ir sendo explorados e discutidos; E 1 se absteve na votação,
embora também concorde com o conceito funcional. Dos que votaram,
portanto, mais de 50% concorda com a proposta apresentada, sendo
considerada aprovada.

Alguns comentários foram feitos que poderiam levar a votar casos
pontuais da proposta, e não ficou claro para mim se teria algo a ser
votado desde já. se você tiver algo pontual a ser votado, manifeste-se
a qualquer momento pois ... Não menos importante, lembro aqui que o
texto da regra pode ir sendo modificado no avançar do mapeamento
conforme algumas questões pontuais forem surgindo, sendo discutidas e
votadas como de praxe.

Com a aprovação dessa proposta, a mesma terá seu texto ajustado para
excluir o que está tachado (foi excluido do texto original ao longo da
discussão), excluir a cor verde de parte do texto (foi incluido), e
modificar parte do texto de "proposta" para "regra", ou outra sugestão
que queiram dar.

Também serão atualizadas paginas relacionadas a classificação viária
que tratarem sobre o tema, na maior parte dos casos apenas com a
inclusão de uma nota no topo da página, e sempre que possível linkando
a página da atual regra de mapeamento. Paginas a serem atualizadas:

A - 
https://wiki.openstreetmap.org/wiki/Pt:How_to_map_a#Classifica.C3.A7.C3.A3o_de_vias
B - https://wiki.openstreetmap.org/wiki/Brazil/Classifica%C3%A7%C3%A3o_de_vias
C - https://wiki.openstreetmap.org/wiki/Proposta_Top_05_BR_%2B_1
D - https://wiki.openstreetmap.org/wiki/Pt:Key:highway
E - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dmotorway
F - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dtrunk
G - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dprimary
H - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dsecondary
I - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dtertiary
J - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dunclassified
K - https://wiki.openstreetmap.org/wiki/Pt:Tag:highway%3Dresidential
L - https://wiki.openstreetmap.org/wiki/Pt:Highway:International_equivalence
M - https://wiki.openstreetmap.org/wiki/Highway:International_equivalence

Assim que as modificações forem feitas, a diferença entre antes e
depois será apresentada num próximo e-mail, por meio de link para wiki
contendo o que foi modificado.

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

[Talk-br] Nova proposta de classificação viária - Solicitação de Votação

[santamariense]

Olá pessoal,

Há 3 meses  foi apresentada a nova proposta de classificação viária
para o Brasil, e já há um bom tempo que não há observações novas a
serem discutidas. Já houve algumas discussões a respeito, e nesse
interim novas observações foram feitas de modo que foi atualizada a
proposta para contemplá-las. Também foi apresentado um mapa com a
malha trunk e outro com a malha motorway para traduzir em mapas o que
esteve sendo apresentado na teoria. Os mapas gerados da malha trunk e
motorway ficam como sugestão para serem aplicados, deixando que as
comunidades locais e/ou a comunidade nacional possam ir discutindo as
melhores rotas e que a nova classificação possa vir naturalmente
conforme os mapeadores forem corrigindo/atualizando a malha viária do
país. O mapa gerado não deve ser tido como algo imutável, pois sabemos
que a dinâmica espacial não pára ao longo do tempo e isso precisa ser
refletido/atualizado no mapa.

As wikis das respectivas highways serão atualizadas após a aprovação
desta proposta.

A proposta está disponível em
https://wiki.openstreetmap.org/wiki/Brazil/Classifica%C3%A7%C3%A3o_das_rodovias_do_Brasil
, com as modificações destacadas conforme padrão descrito no topo da
página.

Seguindo o padrão adotado na tagging-list, a proposta fica aberta para
votação por 15 dias, encerrando, portanto, no dia 13 de maio de 2020.
Instruções para votação encontram-se no próprio texto da proposta, na
última de suas seções.

santamariense

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

Re: [Talk-br] Localização Indevida de um propriedade

[santamariense]

Augusto, estive verificando e não encontrei a marcação do local no
OpenStreetMap (vide [1]). Imagino que tu tenha sido redirecionado para
cá por engano. Para tratar sobre esses assuntos, favor contactar o
próprio Facebook, pois parece que eles estão localizando erroneamente
sua empresa.

[1] - https://www.openstreetmap.org/search?query=Cachoeira%20Sonho%20Meu%20DF

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

[Talk-br] Comitê para votação de disputas em Classificação de Vias

[santamariense]

Em conversa no grupo Classificação de Vias no Telegram, foi levantado
a necessidade/possibilidade de criação de um comitê para votar
questões referentes à classificação de vias quando houver disputas
entre mapeadores ou comunidades locais nos casos de empate, bem como
decidir novas modificações a serem feitas na malha viária que vierem a
divergir da REGRA GERAL QUE FOR VIGENTE.

Se por um lado os grupos no Telegram estão crescendo, por outro, a
participação em discussões vem diminuindo, e isso tenho percebido
pelas várias perguntas sem respostas ou feedback por lá, ou pelo menos
não com a mesma intensidade que se via há um ou mais anos atrás.
Imagino que o pessoal de uma forma geral vem se cansando de longas
discussões, e isso vem gerando uma falta de quórum para tratar
assuntos ou disputas em locais específicos do país, ou até mesmo a
nível nacional.

Então, para mediar estas disputas que estiverem estagnadas devido a
empate, proponho a criação de um comitê, onde os membros não precisam
discutir se não quiserem, bastando apenas votar por essa ou aquela
decisão. Poderiam votar no comitê qualquer mapeador e/ou membro das
comunidades locais e nacionais que tiverem interesse no assunto, que é
o que acontece atualmente, mais um time de membros fixos que devem
ficam comprometidos a votar.

A maior questão é: Quem deveria ficar comprometido a fazer parte do
time de membros fixos? E eu não tenho resposta pronta para isso, porém
acredito que em primeiro lugar fariam parte desse time aqueles que se
dispuserem para tal, seguidos de administradores de grupos de Telegram
baseados no Brasil e mapeadores que em algum momento já se envolveram
em discussões a respeito, baseando-se em "se o mapeador tem interesse
na classificação viária de um local especfíco a ponto de discutí-lo,
deve ao menos votar nos casos em que não estiver diretamente
interessado."

Também estive olhando como deve funcionar as fases das propostas. Em
[1], que trata sobre propostas de novas tags, define "At least two
weeks after the Request For Comments, and once problems brought up in
discussion have been resolved by modifying the proposal, send out a
Request for Voting to the tagging mailing list" cuja tradução seria
algo como "Pelo menos duas semanas após a Solicitação de Comentários,
e depois que os problemas levantados na discussão forem resolvidos com
a modificação da proposta, envie uma Solicitação de Voto para a lista
de discussão". Tal trecho poderia ser adaptado para o nosso caso como
"Uma vez estabelecida uma disputa que não puder ser resolvida
localmente, seja por empate ou pela simples insatisfação de algum dos
envolvidos, qualquer um pode acionar o comitê e dar início ao processo
de desempate, então ambas as partes diretamente envolvidas na disputa
devem apresentar seus argumentos, em seguida outros interessados podem
entrar na discussão se desejarem, e após 15 dias da disputa ser
apresentada, encerram-se as discussões e inicia-se o processo de
votação, onde os membros do Comitê são intimados a votar, sendo que no
30º dia encerram-se as votações e a decisão pode ser imediatamente
aplicada."

O que acham?


[1] - https://wiki.openstreetmap.org/wiki/Proposal_process

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

Re: [Talk-br] Nova proposta de classificação viária

[santamariense]

> Olhei (...), mas ajustes são necessários.

Fato. Convergência de conhecimentos de diferentes locais do país
advindas de diferentes mapeadores com certeza são essenciais para uma
melhor qualidade nos resultados. Vou a partir de hoje conversar sobre
os resultados locais em diferentes grupos para obter um feedback.

> Um critério fundamental para o Brasil é que todas as trunk devem ser 
> pavimentadas. Em outros países,
> pode ser aceitável uma trunk não pavimentada, como no caso do Canadá, onde
> boa parte do ano a estrada está coberta de neve, mas no Brasil a erosão das
> chuvas deixa várias estradas não-pavimentadas inviáveis (às vezes até as
> pavimentadas).

Creio que nesta situação se enquadram alguns casos bem específicos,
provavelmente exclusivas da região norte.

> Um exemplo é a rota entre Boa Vista e Georgetown, que não é
> pavimentada no lado da Guyana. Faria mais sentido, ao invés dessa rota,
> classificar como trunk a rota entre Boa Vista e Ciudad Guayana, na
> Venezuela, que é pavimentada e imagino que tenha um fluxo de veículos bem
> maior.

A possibilidade de selecionar caminhos alternativos de modo a não ter
ilhas e manter a continuidade parece ser uma boa saída para ponderar
entre as opiniões divergentes.

> Acho que o trabalho ficou bom como exemplo ilustrativo, mas as rotas
> devem ser discutidas com calma, talvez focando em um estado de cada vez. É
> importante também incluir critérios físicos, como foi feito no RS (rodovias
> duplicadas com mais de 10 km de extensão são trunk). Se a rodovia foi
> duplicada é porque ela tem importância. É muito caro duplicar uma rodovia.
> Parabéns pelo trabalho.

Vou estar dialogando com comunidades locais. Quanto ao caso das
duplicadas, vai ser um trabalho a parte, o qual será concatenado ao
arquivo de rotas ideais. Existem os parâmetros "discutíveis" entre
decidir se serão trunk ou motorway nestes casos. Então, podemos até
certo ponto tratar como objetos diferentes e concatenar mais adiante
os resultados.

> Vou ver isso assim que possível. Espero que vocês compreendam que (1)
> a maioria está tendo que se adaptar ao surto de coronavírus e (2) no
> RS houve um período de 10 meses para que alguns membros podessem
> analisar a proposta em detalhes antes de se convencerem de que era
> boa. O Brasil tem 26 estados e alguns deles maiores que o RS.

Certamente. Acima da pressa há a necessidade de se obter os melhores
resultados, o qual é nosso objetivo, portanto não adianta atropelar e
obter resultados não tão satisfatórios.

> À primeira vista, a densidade está dentro do esperado, exceto na
> região Norte, onde as conexões entre as capitais dos estados
> adjacentes não foram incluídas na malha, mesmo quando pavimentadas.
> Achei especialmente interessante o tratamento dado às balsas, algo que
> não chegou a ser discutido a fundo pela comunidade brasileira.

O resultado apresentado até o presente momento são exclusivamente as
rotas ideais entre cidades interconectáveis, nada além disso.
Parece-me coerente ir além e interconectar com trunk as capitais da
região norte dentro do possível.


> Já gostaria de te perguntar de antemão:
>
> 1. Como você gerou as rotas? Sua planilha tem 6 mil rotas. Você
> produziu elas manualmente ou de forma automatizada? Se foi de forma
> automatizada, qual foi o procedimento? Sabendo do procedimento, seria
> possível agilizar a revisão.

Não contei exatamente quantas foram, sei que no meio dessas 6 mil há
várias primaries e secondaries também, então foram menos rotas
calculadas que 6 mil certamente. As tabelas foram produzidas de forma
manual, bem como as rotas no mapa. Algumas pequenas adequações nas
rotas foram feitas de modo a, dentro do possível, aproveitar rotas
ideais já existentes.

> 2. Por que há diferenças com a proposta já aprovada no RS?

Também me fiz a mesma pergunta. É preciso comparar um com outro
resultado para poder discutir os pontos específicos. Creio que o
fbello pode melhor contra argumentar nas rotas divergentes no nosso
estado. Cabe ainda lembrar/salientar que o mapa dos resultados
apresentados está ainda aquém dos resultados obtidos no mapa do RS.

> 3. Recentemente, eu apontei para você, em conversa particular, que a
> rota que está marcada como Passo Fundo - Pelotas não preenche os
> critérios definidos para o RS e que portanto seria um erro ou uma
> escolha por consenso sem justificativa adequada. O único sistema de
> roteamento comercial que escolhe essa rota é o Google Maps. Por outro
> lado, o único sistema que escolhe a rota Porto Alegre - Santiago
> anotada no mapa é o Here.com.

Notei no decorrer das estimativas de rotas ideais que algumas rodovias
tem mais densidade de rotas ideais que outras. Quanto menor a
densidade, maior a possibilidade de haver rotas melhores naquele
local. Quanto maior a distância entre duas cidades, maiores as
possibilidades de rotas entre elas, sendo que dentro de um certo
limiar, é possível "atalhar" menos, de modo a ir "pulando" de cidade a
cidade aproveitando rotas

Re: [Talk-br] Nova proposta de classificação viária

[santamariense]

Compartilho com vocês o resultado [1] da interconexão de rotas entre
as cidades com mais de 200 mil habitantes, as quais deverão ser parte
da malha trunk do nosso país. Todos os trechos tem quais rotas passam
por ele com a tag R*. A mesma relação de rotas é possível ser
encontrada na tabela que também está contida no arquivo zip a ser
baixado. É ainda possível averiguar uma rota completa, com todos os
trechos selecionados, selecionando um dos trechos, selecionando nas
tags a rota desejada, clicando com o botão direito e selecionando a
opção 'buscar chave/valor', ou algo parecido. Em caso de divergência
entre a tabela e o mapa, a rota da última deve prevalecer.

Conurbações foram consideradas como sendo apenas uma cidade, logo, as
cidades conurbadas devem ter sua malha urbana pensa em conjunto, e,
por conseguinte, trunks adicionais podem existir dentro dessas áreas
conurbadas.

As conexões que passam a fronteira do Brasil são meramente
ilustrativas da rota completa entre cidades interconectáveis. Porém é
importante lembrar que a classificação fora do território brasileiro
não será modificada sem diálogo com os nossos vizinhos.

Divergências dos resultados podem ser discutidas pontualmente de modo
a se adicionar ou excluir trechos, bem como modificar as rotas.

[1] - 
https://github.com/santamariense/ClassViarBR/raw/master/Mapa%20e%20tabela%20trunk%20v20200313.zip

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

Re: [Talk-br] Nova proposta de classificação viária

[santamariense]

> Por outro lado o algorítmo falhou em "capturar" a BR-262 entre Betim e
> Uberaba, que eu conheço bem, é uma estrada pedagiada e claramente exerce
> papel de trunk, parte dela é motorway inclusive.

O algorítimo detecta cidade interconectáveis, não as rotas. O Linhares
deu o parecer dele sobre as rotas entre as cidades. Outros usuários
podem divergir um pouco do resultado, como tu está  fazendo com base
em seus conhecimentos e pareceres da região. O importante é que o
resultado final convirja ao máximo a um consenso ao menos da maioria.

Vamos construir o mapa em conjunto com a comunidade. O problema que
vejo nos teus contrapontos e visão de classificação é que ela tende a
ter descontinuidades topológicas, quando para mapear se olha
estritamente para um trecho de via observando exclusivamente suas
características físicas. A nossa proposta também considera que se
possível, as maiores classificações terão as melhores características
físicas, mas na falta dela em alguns trechos, não afeta a
continuidade.

> Eu também entendo que o "algoritmo" proposto (que eu sempre chamei de
> "metodologia") não deve ser levado sempre ao pé da letra sempre, alguma
> dose de ponderação e interpretação deve ser permitida para tratar de casos
> limítrofes pelo consenso. A "metodologia" é pra ajudar a orientar o
> trabalho de classificação e eliminar da discussão a grande maioria dos
> casos principais.

Isso. O algorítimo é norteador, mas se houver consenso sobre alguns
pontos divergentes do algorítimo, a gente discute e documenta as
exceções.

> No RS, a única restrição aplicada à malha primária é que elas deveriam ser 
> pavimentadas.

Em contato com o DEER MG, fui informado que apenas duas cidades não
tem acesso asfáltico. Elas tem menos de 6 mil habitantes, logo não
parece haver também neste estado a necessidade de primary ou trunk sem
pavimentação.

Sou da mesma opinião de "uma dor de cabeça por vez". Vamos discutir
cada "rota ideal" entre par de cidades por vez.

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

Re: [Talk-br] Nova proposta de classificação viária

[santamariense]

> Eu fiz uma interpretação empírica do método "começar pelo par cuja
> população somada for maior" utilizando o mspaint 😁

hahaha. Ótimo. Valeu! No sul o fbello e/ou o ftrebien já tem pronto,
agora você fez pro sudeste :). Vou (continuar a) documentar cada
trecho de trunk e quais cidades conectam. É importante para quando
alguém bater o olho e perguntar futuramente o porquê está aquela
classificação.

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

Re: [Talk-br] Nova proposta de classificação viária

[santamariense]

Olá pessoal,

Dando prosseguimento a nova proposta de classificação viária, gostaria
de compartilhar com vocês a lista de cidades interconectáveis em forma
de tabela e de mapa esquemático. Neste material já estão consideradas
as cidades conurbadas como sendo apenas uma, bem como também já está
considerado o esquema das conexões internacionais. Gostaria que
analisassem o material pois ele norteará o mapa com a nova
classificação que criaremos em conjunto com a comunidade.

Há uma alta taxa de potenciais trunks na região sudeste. Vale lembrar
ainda que temos alguns pontos que deverão ser discutidos à parte, os
quais estão relacionados em seção específica da wiki da proposta [1].
Esses pontos são os que forem elencados no decorrer da proposta e dela
divergir pontualmente, mas não da ideia geral.

Quanto ao método a adotar para mapear as interconexões, uma
possibilidade é começar pelo par cuja população somada for maior e ir
até a menor. Quanto mais se avançar na tabela, maior a probabilidade
das conexões entre cidades convergirem para conexões existentes
maiores.

Os arquivos estão disponíveis para download em [2]

Como utilizar no JOSM:

1 - Ativar a janela filtro no menu janelas
2 - Botão "+" para adicionar filtros
3 - Exemplo. Para ver todas as interconexões highway=trunk, adicione
novo filtro, onde deve ter ativado o E, H e I
4 - Para ver quantas conexões desse tipo tem uma cidade, selecione-a e
tecle "shift+E" para selecionar as conexões ou "E" para selecionar as
cidades interconectadas (estará selecionada todas as cidades incluido
a primeira).


[1] - 
https://wiki.openstreetmap.org/wiki/Brazil/Classifica%C3%A7%C3%A3o_das_rodovias_do_Brasil

[2] - 
https://github.com/santamariense/ClassViarBR/blob/master/Mapa%20esquem%C3%A1tico%20e%20Tabela%20v20200212.zip

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

Re: [Talk-br] Nova proposta de classificação viária

[santamariense]

> Vi as suas alterações lá. Acho que seria interessante termos um
> glossário, pra que as definições dos termos estejam bem claras. Eu
> acho interessante adotarmos as definições do CTB e do DNIT, que são do
> conhecimento de muitos, e esclarecer onde for necessário divergir
> delas por alguma razão específica do OSM. Se quiser, eu mesmo posso
> acrescentar o glossário.

Pode adicionar o glossário. Só mantenha o padrão adotado ao adicionar
ou suprimir texto da proposta conforme está no topo da página.

> Se existir, pode ser mapeada com route=ferry + ferry=tertiary/secondary

Eu desconhecia a tag ferry=*. Ela é perfeita para manter a
continuidade na classificação.

>  Eu acho que nós evitaríamos situações assim e teríamos uma classificação que 
> respeita as relações hierárquicas das vias se limitarmos o uso de motorway da 
> seguinte forma:
> 1. Cada sistema motorway regional tem que estar enraizado em alguma cidade de 
> grande porte. Não precisa ir até o núcleo da cidade, mas deve começar nas 
> proximidades do perímetro urbano.
> 2. Toda motorway tem que preencher também os requisitos das trunks, ou seja, 
> o sistema motorway tem que ser um subconjunto do sistema trunk.
> 3. Um trecho motorway tem que ter uma extensão mínima. Uma exceção seria 
> motorways que ligam outras motorways muito próximas entre si.

Eu tendo a concordar com o apresentado por alguns motivos: (1)
continuidade, pois não faz sentido que as motorways sejam trechos de
níveis inferiores a trunk, (2) o próprio fato da divergência quanto ao
entendimento da acessibilidade direta a lotes, o que parece ser comum
e que na prática desbancaria provavelmente a maioria das atuais
motorways do país.

Irei adicionar à lista dos pontos a discutir na proposta.


> A expectativa geralmente é que essas vias trunks sejam radiais, ou
> seja, partam das cidades grandes para outros lugares, ou seja, não
> incluiria anéis e perimetrais. Estes seriam classificados conforme a
> classificação do plano diretor, ou por continuidade com as vias nas
> proximidades (ex.: se só partem vias primárias da cidade, não faz
> sentido ela ter um anel trunk).

Nessa linha de raciocínio, parece-me estranho que vias internas de uma
cidade concorram com a via que a atravessa, conforme o que foi
apresentado na abordagem norteadora da proposta.

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

Re: [Talk-br] Nova proposta de classificação viária

[santamariense]

> 1. Parece haver um equívoco na interpretação do raio de influência. De
> maneira precisa, o critério é: "Considerar as cidades com distância igual
> ou menor à raiz quadrada da população da MENOR cidade". Isso significa que
> a população de São Paulo é irrelevante, pois nenhuma cidade na América do
> Sul é maior que ela.

Hm. O que reduziria na prática o número de interligações a serem
definidas, isso que tu quer dizer?  Em outras palavras, determinada
cidade, a exceção de São Paulo, deve ter rota ideal determinada entre
ela e cada uma das cidades maiores que estão no seu raio de
importância. É. Parecia-me num primeiro momento que era uma forma
diferente de dizer o mesmo, mas não é. De qualquer maneira a imagem do
esquema simplificado da proposta ainda está correta. Todavia, ainda me
parece que no resultado final não vai fazer diferença, mas de qualquer
maneira se reduzir o número de rotas a serem definidas já é bom.
Apontamentos ou oposições à correção disto na proposta?

> 2. A classificação no RS foi feita com base numa mistura de critérios
> físicos, funcionais e administrativos. Do ponto de vista físico, a
> classificação tem algumas propriedades:
>
> a) Todas as vias motorway, trunk e primary são pavimentadas, sem exceção.

Não houve intenção de abrir brecha para vias não-pavimentadas serem
motorways, até porque imagino que isso seja consenso, de qualquer
maneira vou corrigir o texto. Na proposta apresentada a nível nacional
decidi deixar de fora a exigência de ser pavimentada as trunks e
primarys devido às diferenças que temos entre os extremos do país. A
intenção com isso não é abrir brecha para que se defina rotas ideias
por vias não-pavimentadas onde houver opção de rotas asfaltadas. Penso
que a própria seleção de rota ideal entre par de cidades naturalmente
vai selecionar as vias com melhores características físicas. Por outro
lado, temos regiões remotas do país, onde pode haver cidades que
tenham porte populacional para ter classificação viária maior do que
as estradas que levam até ela se fosse aplicada essa restrição, e caso
isso ocorra vai criar ilhas no sistema viário. Há de se considerar
também que, por exemplo, uma rodovia trunk no Acre de nada
interferiria no sistema viário de São Paulo. Ok, algumas cidades são
de fato isoladas da malha viária principal do país, como esta [1], e
daí não há o que ser feito.

Estou juntando informações de diversas fontes, bem como cruzando
dados, para obter como resultados quais das mais de 5500 cidades do
país não tem acesso asfáltico e poderia ser de fato afetada pelo que
está sendo discutido nesse item. São questões pontuais que deverão ser
discutidas no decorrer da proposta.

> b) Todas as rodovias duplicadas por mais de 10 km são trunk ou motorway.
Este item não obstrui a classificação, apenas adiciona algumas
rodovias a mais às categorias mais elevadas de classificação, e que
poderiam muito bem ser usadas como alternativa às outras de igual
qualidade, então eu concordo, desde que não venha a ter "tocos" de
trunk desconexos da malha principal. Acho que é isso que se quer dizer
com esta definição, não? Mas se pudéssemos deixá-la com a definição
mais restritiva, melhor.

> c) Todas as motorway são duplicadas e sem cruzamentos em nível.

Isso. Creio não haver diferença, ou pelo menos não grande diferença
entre esta proposta e a do RS, na qual a primeira é baseada na
segunda, mas não idêntica. Tem se discutido em alguns momentos no
grupo @osm_classificacao_vias algumas outras variáveis para que uma
via se encaixe em motorway.

> 3. Na minha opinião, o critério deveria ser o mesmo em todo o Brasil. Como
> consequência, haverá mais trunk e motorway em São Paulo e menos na região
> Norte. Isso reflete a realidade. Em algumas regiões, a importância do
> transporte fluvial e aéreo é relativamente maior, em parte pelas longas
> distâncias combinadas com a precariedade das rodovias. O mapa deve refletir
> isso.

Acho que serão casos que deverão ser tratados pontualmente. De
qualquer maneira naturalmente haverá mais em São Paulo que no Norte.

> 4. A proposta é derivada dos critérios adotados no RS. Esses foram fruto de
> um extenso trabalho, que incluiu o teste da metodologia também nos estados
> de SC e PR. Sugiro que avaliem o passo a passo da metodologia, descrita em:
> https://wiki.openstreetmap.org/wiki/Brazil/RS/Classifica%C3%A7%C3%A3o_das_rodovias_do_RS
> Seguindo os mesmos critérios, é possível elaborar mapas teste para os
> demais estados. Isso traria informação útil para a discussão.

Sim. Estamos avançando nessa direção.

> 5. Apesar de ser um assunto  importantíssimo (ou talvez justamente por
> isso), a discussão não deve ser breve. Por um longo tempo, eu defendi uma
> classificação puramente física, mas com a evolução da discussão concordamos
> em combinar os três tipos de critério. É importante que eventuamente se
> chegue a um consenso, mas que isso seja feito com calma e dando bastante
> tempo para as pessoas refletirem a respeito, avaliar e aj

Re: [Talk-br] Nova proposta de classificação viária

[santamariense]

> Já tem alguém elaborando esse mapa?

Vamos migrar para o grupo do Telegram @osm_classificacao_vias e dar
prosseguimento com a construção do mapa em grupo, assim como fizemos
no RS.

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

Re: [Talk-br] Nova proposta de classificação viária

[santamariense]

> (...)afinal o que queremos representar no mapa? O país como ele é ou como 
> deveria ser?

Essencialmente o que se busca é o descrito no conceito de continuidade
[1], respeitando a função que determinada via exerce. Daí vem o
"salada de frutas" que eu citei, que aliás nem fui eu que o criei; o
termo já vem sendo usado em alguns momentos nos grupos do telegram, e
pensei que você já tivesse ouvido falar também.

Concordo com o "the truth is on the ground", embora tenhamos um ponto
de vista diferente dele. Existem tags diversas para mapear a verdade a
campo segundo cada uma das limitações físicas citadas no esquema
br2013, como superfície (surface), velocidade (speed), faixas (lanes),
acostamento (shoulder), canteiro central (mapear cada um dos lados com
uma geometria highway diferente). Se voltarmos a origem da definição
de trunk [2], pela definição não há restrição quanto as suas
características físicas e sim sobre sua importância, ou seja, a função
que ela tem. Logo, a verdade a campo para a tag highway é definir a
importância/função dela, justamente o que está sendo proposto e
balizado aqui. E vejam só, o próprio esquema br2013 recorre a
conceitos funcionais em alguns momentos, por exemplo, quando usa os
termos arterial e preferencial.

Pelo esquema br2013:

motorway - Canteiro central, acostamento e sem obstruções (semáforos
ou intersecções)
trunk - Multifaixas sem canteiro central?
primary - Em zona urbana, via pavimentada arterial com velocidade
menor que 80 km/h. Em zona urbana ou rural, via pavimentada com só 1
faixa por sentido, velocidade maior que 80 km/h, e COM acostamento.
secondary - Em área urbana, mesmas características das tertiary, porém
preferencial sobre ela (promovida por preferência). Em zona urbana ou
rural, via pavimentada com só 1 faixa por sentido e SEM acostamento.
tertiary - Em áreas rurais, via de solo compactado. Em áreas urbanas,
preferencial sobre vias residential e unclassified e com velocidade
média de 40 km/h.
unclassified - Em áreas rurais, via de solo não-compactado. Em áreas
urbanas, vias não-residenciais.
residential - Somente para vias urbanas residenciais.

Algumas comparações do esquema br2013 com a nova proposta:

* Preservam o mesmo conceito: motorway, residential e unclassified em
zona urbana.
* Na zona rural: A título de exemplo de incoerência, pelo esquema
br2013 são tertiary as vias compactadas, mesmo se leve a 1 propriedade
só, por outro lado, são unclassified as vias não-compactadas que levam
a uma vila de operários, onde muitas vezes teria um fluxo maior de
veículos e pedestres. Já o novo esquema tende equalizar essas
disparidades, até porque se for analisar o próprio governo de um
município tende a dar maior manutenção para as estradas que interligam
sedes de distritos do que as demais.
* Na zona urbana, para as vias que não são rodovias que cruzam a
cidade, a nova proposta pouco difere na prática. Apenas retira as
limitações físicas fazendo com que se preserve a continuidade
harmônica delas.
* Parece-me que as maiores diferenças entre as duas propostas está na
trinca trunk-primary-secondary, principalmente fora de perímetros
urbanos. E onde, a discussão maior vai se dar.

Vejo o esquema br2013, como ótimo para aquele momento onde estavamos
"desbravando" novas áreas do mapa, desenhando geometrias sem saber, ou
sem querer saber, da sua importância, olhando só para ela sem entender
a sua função no conjunto de vias ao seu redor.

Exemplos de incoernências no esquema br2013:

* Ainda sobre o conceito de continuidade, não faz sentido, exceto se
for um lugar ilhado da malha viária do país, que uma cidade tenha
porte para ter primary no seu sistema viário, e a estrada principal
que leve até ela seja secondary por causa de uma de suas limitações
físicas (não ter acostamento).
* Ser tertiary na zona rural só porque é compactada. Já vi estrada
compactada acabar dentro de lavoura no pampa gaúcho.
* Inúmeros exemplos de falhas no princípio de continuidade[3] ou só
porque algumas vias tem características físicas melhores que aquelas
que a circundam [3].

> Vamos fazer um pequeno exercício. Hoje, se eu olho o mapa e vejo uma
> rodovia tipo trunk o que eu posso pensar? Pela proposta de 2013, eu deduzo
> que se trata de uma rodovia de maior porte, melhor que uma primary. Esta é
> uma informação útil, fácilmente acessível por qualquer usuário leigo do OSM.

Isto irá naturalmente se preservar a nível local e regional, segundo a
nova proposta. Digo isso porque nesse seu exemplo a rota ideal entre
dois locais naturalmente se dará pela via de maior porte, a qual
provavelmente teria preferência na escolha. Já a nível nacional, por
que não harmonizar a rede viária do mapa? Seria o mesmo que determinar
que só teriam direito ao uso de nível trunk os países de primeiro
mundo, os quais tem maior condição financeira de construir estradas de
melhor qualidade.


[1] - 
https://wiki.openstreetmap.org/wiki/Brazil/Classifica%C3%A7%C3%A3o_das_rodovias_do_Brasil
[2] - https://wiki.openstre

Re: [Talk-br] Nova proposta de classificação viária

[santamariense]

> A proposta se baseia na ligação entre duas cidades, mas quais duas cidades?
> Aí eu li o tal raio de influência, fazendo uma conta no caso de BH isto dá
> 1700 km. Então devo considerar que todas as cidades no raio de 1700 km com
> mais de 200 mil habitantes devem estar ligados por vias tipo trunk? Se der
> o resultado que eu tô pensando quase tudo viaria trunk, e perderíamos a
> hierarquia das vias.

Isso. Bem, é difcil imaginar o quão denso seria o mapa por ti
vislumbrado. Daí também entra a questão de analisar perante estudos a
possibilidade de flexibilizar a população por diferentes estados, como
já comentado. Em um primeiro momento, pode parecer que haverá 1 rota
diferente para cada ligação de BH com as cidades dentro do seu raio,
porém o que se procura é a rota ideal entre cada par de cidades,
ocorrendo, na prática, que a maioria das rotas irão se sobrepor em
diversos trechos. Por exemplo, estive analisando a ligação de São
Paulo com o Nordeste e o Sul, e é impressionante como Feira de Santana
e Curitiba, respectivamente, acabam por concentrar boa parte das rotas
de cidades de suas regiões até São Paulo.

> Sabe, isto me soa muito como um algorítmo, penso que seja factível fazer
> uma simulação. Tipo baixar o mapa, isolar as cidades por população e
> distância, e reclassificar as rodovias. E depois estudar como ficou a
> hierarquia viária. Pelo menos algo semelhante seria necessário para ajustar
> o tal raio de influência. Daria um bom projeto de TCC.

Bem colocado. É preciso aqui explanar que concomitantemente à análise
e discussão da proposta, vai se dar o resultado parcial em forma de
mapas das discussões das maiores classificações (trunk e primary),
antes de ser votado. Num primeiro momento cabe apresentar aqui a
proposta para se obter uma primeira impressão dos membros da
comunidade interessados no assunto.

> A premissa do esquema br2013 era que o formato da via seria proporcional à
sua importância. (...)

Sim, pelo esquema br2013 mede-se a importância de uma via pela sua
característica física. Exatamente isso que tem gerado vários casos da
chamada "salada de frutas" na classificação viaria, muitas vezes
ferindo o conceito de continuidade, quando o mapeador a leva ao pé da
letra (e é só dar uma passeada pelo mapa, ou mesmo acompanhar edições
Brasil afora, para se deparar com diversos casos). Na prática, a nova
proposta apresentada acaba levando em conta, no momento da seleção da
melhor rota entre duas cidades, aquelas vias que tiverem as melhores
características físicas, e isso acontece de forma natural. Já o
contrário nem sempre é verdade, pois uma melhor característica física
nem sempre representa uma maior importância da via, e isso ocorre
pelos mais variados motivos. É importante lembrar ainda que existem
inúmeras tags complementares que cumprem o papel de descrever
caracterstícas físicas e que podem ser, e são, utilizadas por
roteadores como parâmetros para o cálculo de rotas.

Quanto ao caso específico de MG, imagino que o fluxo de transito
poderia ajudar na seleção das chamadas rotas ideais. Por outro lado,
há problema de distribuitividade ao se analisar exclusivamente o fluxo
de trânsito. A título de exemplo, inúmeras ruas cetrais de uma capital
teriam mais fluxo que uma rodovia do interior do seu estado. Já,
quanto aos demais estados, creio que poucos teriam esses dados.

Eu poderia fazer uma análise de caso para MG de modo a aplicar esta
proposta, teria o link para esses dados?

--

> Uma dúvida que me veio foi quanto as regiões conurbadas. Aí no Rio Grande
> do Sul vocês consideraram elas como uma única cidade, inclusive, unindo a
> população dos municípios constituintes ou as ignoraram?

Consideramos. Inclusive interestadualmente ou internacionalmente, se
for o caso. Adicionei ao texto da proposta a questão de cidades
conurbadas.

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

Re: [Talk-br] Nova proposta de classificação viária

[santamariense]

Adicionei à proposta as observações feitas ( de 1 a 4 )

> 4. Para os níveis secondary e tertiary, o termo "rodovia" deve ser
> trocado pelo termo "estrada" para incluir vias não-pavimentadas que
> satisfaçam a regra da rota ideal. Especialmente importante em várias
> regiões menos desenvolvidas do país que muitas vezes não têm ligações
> viárias pavimentadas.

Caberia aqui resaltar a diferença entre os termos estrada e rodovia
como "nota" na proposta. Qual seria exatamente a diferença a que tu se
refere? Uma asfaltada e outra não? Uma implantada e outra não? Não
haverá também casos onde a rota ideal entre cidades médias e grandes
se dará por estradas e não por rodovias?

> 5. Acredito que as comunidades dos outros estados vão querer avaliar
> com cuidado se o limiar populacional se ajusta à sua realidade local.
> Os limiares padrões do OSM a princípio seriam a metade dos propostos:
> 100k, 10k, 1k, etc. Pode ser muito num estado denso como São Paulo ou
> pouco num pouco denso como o Amazonas.

Acredito que em diálogos com membros de diferentes estados, poderíamos
chegar a uma melhor definição, ou, tabelar por estados. Ou ainda,
estender o conceito para as cidades principais de Regiões Geográficas
Imediatas e Intermediárias conforme [1]

[1] - 
https://wiki.openstreetmap.org/w/index.php?title=Brazil/Classifica%C3%A7%C3%A3o_das_rodovias_do_Brasil&action=submit#Outras_possibilidades_a_discutir

> 6. "Para esta finalidade, convencionou-se que uma cidade X exerce
> influência num raio determinado pela raiz quadrada de sua população."
>
> No caso do RS, a aplicação desse critério não mudaria em nada a
> classificação final que foi aprovada.  Embora eu não discorde a
> priori, as implicações não chegaram a ser discutidas nem no fórum, nem
> no Telegram. Pra classificação viária, o raio de influência de uma
> cidade raramente vai além das suas conexões diretas com as cidades
> mais próximas na categoria de lugar sendo considerada (100k ou 200k
> para trunk, 10k ou 20k para primary). O que varia de regiões densas
> pras esparsas é a distância dessas cidades de mesma categoria mais
> próximas, e em alguns casos (especialmente onde o sistema viário é
> muito denso), é necessário ir para o próximo conjunto de cidades.
>
> Por esse critério, São Paulo teria um raio de influência de pouco
> menos de 3500km, indo até o Ushuaia e até San Jose, na Costa Rica. Ou
> seja, para completar o sistema trunk, teríamos que tentar encontrar a
> melhor rota entre São Paulo e San Jose (que não existe [1]), ou entre
> São Paulo e, digamos, Caracas, na Venezuela. Faz parte dessa rota o
> trecho Porto Velho - Manaus, que não é pavimentado. Acho difícil
> argumentar que São Paulo influencia o sistema viário muito além do que
> seria o percurso factível em 1 dia de viagem (~1320km se for a 110km/h
> continuamente por 12 horas) ou muito além das capitais dos estados
> vizinhos, sendo que pra viagens mais longas outros modais são
> preferíveis (trem ou barco para cargas, avião para passageiros). Por
> outro lado, Palmas, no Tocantins, teria um raio de apenas 546km, que
> por pouco não cobre todo o estado do Tocantins. O projeto das BRs com
> certeza inclui prioritariamente no mínimo a interligação entre as
> capitais estaduais.
>
> Agora, se limitarmos em 1320km, algumas cidades grandes em regiões
> pouco densas, como Manaus, teriam uma área de influência viária
> reduzida.
>
> [1] https://pt.wikipedia.org/wiki/Regi%C3%A3o_de_Dari%C3%A9n

Na prática, em muitos casos, ocorrerá ligação ideal entre cidades
intermediárias, que levará a completar a conexão mesmo entre as
cidades mais longínquas. Casos excepcionais deverão ser documentados.
Poderíamos considerar aqui que pelo menos o admin_centre de um
admin_level exerce importância em todo o seu território.

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

[Talk-br] Nova proposta de classificação viária

[santamariense]

Olá,

Venho por meio desta apresentar uma nova proposta de classificação
viária a ser discutida e aperfeiçoada em conjunto com a comunidade.
Ela baseia-se no resultado satisfatório e menos controverso ao qual
chegamos no RS.

Em resumo, a proposta é fundamentada principalmente na característica
funcional da via de modo a se escolher a melhor rota entre 2 cidades.

A proposta completa está documentada em
https://wiki.openstreetmap.org/wiki/Brazil/Classifica%C3%A7%C3%A3o_das_rodovias_do_Brasil
para apreciação da comunidade.

Creio que para fins de documentação é mais adequada a lista Talk-Br,
porém o Telegram tem proporcionado dinamicidade às discussões, por
isso, quem estiver interessado, se possível, entre no grupo
@osm_classificacao_vias para discutir essa proposta. (
https://t.me/osm_classificacao_vias ou
https://web.telegram.org/#/im?p=@osm_classificacao_vias )


santamariense

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

Re: [Talk-br] unsubsrcibe

[santamariense]

Olá, Roberto. Para se desinscrever acesse
https://lists.openstreetmap.org/listinfo/talk-br e vá na parte de
baixo da página onde diz "Para se desinscrever de Talk-br,..."


>1. unsubsrcibe (robert colombo)

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

Re: [Talk-br] Padronização de tags DER

[santamariense]

Um usuário mueschel sugeriu na discussão de uma changeset [1] o
seguinte esquema:

A common way would be
ref:BR:DAER:category
ref:BR:DAER:zone

'ref' because it's a reference number
'BR' as country code of Brazil
'DAER' as this seems to be the name of transport organization
"zone","category" as name of the tag

A scheme like this is used in several countries (notably France) and
makes reading / understanding tags and separating those from different
regions simple.

[1] - https://www.openstreetmap.org/changeset/70596092

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

[Talk-br] Padronização de tags DER

[santamariense]

Todos os estados do país tem um DER (Departamento de Estradas de
Rodagem) [1] ou equivalentes como DAER, DEER, Deinfra, Deter, entre
outros, a depender do estado e até da própria administração pelo que
tudo indica.

Ao mapear tags específicas como zona_de_fiscalizacao=* e
categoria_rodoviaria=* no RS surgiu já há algum tempo a necessidade de
padronizar um prefixo para elas e documentar na wiki.

Inicialmente pensamos em DAER:*=* pois no estado o órgão responsável é
o DAER, porém para compatibilizar a nível nacional seria preciso uma
tag que contemplasse todos. DER foi sugerida por parecer ser a mais
usada desde os primórdios quando de suas criações nos estados.

Proposta. Criação e padronização do prefixo de tag a ser adotado
nestas situações: DER:*=* ou DER:UF:*=* (UF: estado). O que acham?


[1] - https://pt.wikipedia.org/wiki/Departamento_de_Estradas_de_Rodagem

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

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[santamariense]

> As ruas da prefeitura tão no conjunto separado, EIXOS, da SMURB, que também 
> não interessa porque não é igual ao OSM.
> O que vale são os nomes que tão no OSM.

O ideal é que o nome dos logradouros bata 100% com o nome dos
logradouros nos housenumbers, mas isso não interfere em nada o
funcionamento de aplicativos. Ao meu ver poderia ser importado com os
nomes conforme estão na base da prefeitura se fosse o caso.

> Para o OSM, então, ok, terão que ser adicionados estes campos, quando 
> faltantes, a milhares de objetos.

Provavelmente quase todo housenumber que chegou ao OSM sem addr:street
ou relação veio por meio de importações. Naturalmente, "qualquer"
mapeador que for adicionar um endereço no mapa já vai assim fazer com
com o nome da rua junto.

89% dos addr:housenumber tem addr:street -
https://taginfo.openstreetmap.org/keys/addr%3Ahousenumber#combinations

Podemos dar uma sondada, em um primeiro momento, para ver se achamos
uma solução >automatizada< de com o ponto e seu ângulo, e a com uma
geometria de ruas extraídas do OSM conseguir obter o nome das ruas.

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

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[santamariense]

Notou se algum campo destes pontos teria algum código que
referenciasse um logradouro ao invés de diretamente o nome do
logradouro?

> -Levantada a questão de que: "para um endereço ser localizado no OSM, precisa 
> ter ainda addr:street=*".

Eu diria que seria a melhor situação, a qual não geraria erros. Pontos
sem addr:street são associados ao logradouro mais próximo, ou seja,
nem sempre ao logradouro ao qual está registrado (como você comentou).
Em Paris por exemplo foi importado assim ( ex.:
https://www.openstreetmap.org/node/1916243227 ) com relação
type=associatedStreet. Creio que o nominatim não encontra pela
associatedStreet.

Não entendo muito. Mas não seria possível associar um logradouro
automaticamente pelo "angle" do ponto? No QGIS? Algum código? Talvez a
solução para esta questão esteja nele.

Se ninguém se dispuser a fazer esse trabalho manual, que se importe
assim mesmo. Estando no OSM a comunidade naturalmente pode ir
adicionado os dados faltantes como addr:(street/postalcode)

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

Re: [Talk-br] Parceria OSM e ANA

[santamariense]

> Podemos pensar em uma proposta de os colaboradores da plataforma nos 
> auxiliarem na identificação da toponímia dos cursos d’água e massas d’água de 
> nossas bases da ANA

Interessante que boa parte dos cursos d'água tem diferentes nomes a
depender da fonte (órgão governamental), e se for a campo conferir,
principalmente nas zonas rurais, os moradores nem sabem que tem nome,
chamando apenas de "sanga", "rio", -- Não é por acaso que até órgãos
governamentais tem dificuldade para identificá-los e muitas vezes
identificam determinado curso d'água com nome diferente do
identificado por outro órgão, ou mesmo com traçado diferente,
principalmente em ponto próximos a nascentes onde tem vários braços e
não se sabe qual deles leva o nome.

Tem alguma ideia de como poderia desenhar essa possível parceria?

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

Re: [Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / Importação de numeração predial

[santamariense]

Comunico que pretendo mudar a metodologia de importação devido ao
tempo astronômico que a outra estava demorando. Com a nova metodologia
a expectativa é demorar menos de 1/3 do tempo da primeira metodologia
apresentada.

A nova metodologia garante que os pontos estejam junto a seu
respectivo logradouro, ainda dentro do lote, porém não necessariamente
em cima da building do terreno. Apesar de não mover cada ponto
separadamente, eles são movidos em lotes por face de quadra e acabam
na sua maioria ficando em cima das buildings de qualquer maneira.
Também observei, enquanto mapeava na metodologia anterior, que
inúmeros lotes tem mais de uma casa, fazendo com que eu tivesse que
largar o ponto na parte fronto-central do lote sem ter como  ter
certeza se era mesmo aquela casa, ou seja, apesar de eu estar me
guiando pelas construções, ainda assim tive que deixar o ponto fora de
cima da building. O mesmo ocorreu em buildings que estavam no fundo do
terreno, onde, se eu tivesse posto o ponto em cima da building,
certamente haveria roteamentos até ela pela rua de trás cujo lote não
tem acesso - nessa situação, portanto, apesar da building, também
optei por largar o ponto na frente do terreno.

A metodologia anterior deu resultado como esses
https://www.openstreetmap.org/changeset/65511032 . A nova metodologia
que estou apresentando deu como resultado esses
https://www.openstreetmap.org/changeset/65527957 . Lembrando que a
imagem de satélite foi realinhada para o alinhamento dos lotes. Caso
alguém queira alguma amostra (tanto dos pontos quanto das áreas dos
lotes) é só me solicitar por mensagem privada. Não é possível enviar
aqui na lista. - Eu sinceramente acho que no final das contas o
resultado é muito parecido. Mas de qualquer maneira, como mudei a
metodologia, estou documentando ela aqui.

A metodologia a ser adotada a partir de agora (caso não haja
objeções), doravante chamada de metodologia2:
- Carregar lotes como camada de fundo;
- Adicionar a camada do Bing;
- Realinhar a camada do Bing para casar c'os lotes;
- Realinhar todos os pontos com base na camada de lotes, usando o Bing
para tirar dúvidas;
- Query no Overpass por todos os addr:housenumbers do bairro, carregar
eles pro JOSM, e adicionar a tag xxx=xxx neles;
- Verificar todos os xxx=xxx, dando merge dos xxx=xxx neles, e
excluindo a tag xxx=xxx também;
- Não havendo mais xxx=xxx, significa que foram verificadas todos os
números já existentes no OSM afim de se evitar duplicatas;
- Query no Overpass por todos as geometrias type:way, bem como
type:relation(type=multipolygon), que sejam passíveis de se ter
endereço atrelado a elas, e dar merge nelas de todos os pontos cujo
endereço certamente pertencer a ela, segundo a posição dela no lote.
- "Atualizar objetos modificados" para averiguar se não houve edição
conflitante;
- A changeset está pronta para ser subida ao OSM.

 Objeções e contrapontos de qualquer tipo, favor se pronunciar o mais
breve possível.

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

Re: [Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / Importação de numeração predial

[santamariense]

Fiz uma primeira importação da numeração predial para testes,
metodologia e ver na prática problemas que podem aparecer.
A ideia é além de documentar, também saber se a comunidade não tem
algum ponto de vista diferente sobre algo específico.

A changeset é esta https://www.openstreetmap.org/changeset/65282825 ou
pelo OSMcha https://www.openstreetmap.org/changeset/65282825 ,
realizada no bairro Centro Cívico.

Metodologia adotada:
- Carregar lotes como camada de fundo;
- Adicionar a camada do Bing;
- Realinhar a camada do Bing para casar c'os lotes;
- Carregar os pontos a serem importados, adicionar tag xxx=xxx neles;
- Query no Overpass por todos os addr:housenumbers do bairro, carregar
eles pro JOSM, e adicionar a tag xxx=yyy neles;
- Verificar todos os xxx=yyy, dando merge dos xxx=xxx neles;
- Não havendo mais xxx=yyy, significa que foram verificadas todos os
números já existentes no OSM afim de se evitar duplicatas;
- Para cada xxx=xxx realinha, dando merge com objetos existentes
quando existirem (ex.: building), e cola a tag "xxx=", o que na
prática faz com que a tag xxx=xxx seja excluída;
- Não havendo mais xxx=xxx, significa que a edição foi completada;
- "Atualizar objetos modificados" para averiguar se não houve edição
conflitante;
- A changeset está pronta para ser subido ao OSM.

Obs.1: as tags xxx=xxx e xxx=yyy são apenas para controle de fluxo de
trabalho, poderiam ser qualquer outra que não já exista. E não serão
subidas ao OSM.
Obs.2: essa foi a maneira que eu encontrei de não deixar passar nada
sem ser realinhado e verificado. Alguma ideia melhor?

Apontamentos gerais e decisões tomadas na prática:
- Havendo já o mesmo endereço, mantem-se o que está e como está, a
menos que não pareça fazer sentido;
- Ao se adicionar e retirar a tag, a changeset conta como uma
modificação, embora não tenha ocorrido de fato. De qualquer maneira
confirma que o objeto foi verificado;
- Locais onde fica evidente que a divisão dos lotes não é mais aquela,
a numeração predial não foi/é/será importada. Exemplo: onde hoje está
o prédio do Ministério Público do Estado do Paraná, antes eram 4
lotes;
- Havendo building única no lote já desenhada, merge do número no prédio;

Creio que nas próximas changesets não vai fugir muito deste padrão.
Caso tenha novos problemas, documento aqui. Objeções e contrapontos de
qualquer tipo, favor se pronunciar o mais breve possível.

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

Re: [Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / Importação de numeração predial

[santamariense]

Ficou legal. Anotei para completar num futuro próximo a metodologia em
https://wiki.openstreetmap.org/wiki/Brasil/Metodologia/Importa%C3%A7%C3%A3o_de_endere%C3%A7os
, assim que eu finalizar a importação fase 1.

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

Re: [Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / Importação de numeração predial

[santamariense]

Muitos dias de processamentos e erros devido a quantidade de dados
depois, consegui automatizar o alinhamento dos centroides junto a
frente dos lotes. Para tal tive que dividir em várias partes o arquivo
dos lotes para que o QGIS pudesse dar vencimento, e depois unir
novamente os resultados parciais. Enfim, vamos aos passos:

1 - Dar dissolve no arquivo dos lotes. Lotes dissolvidos nos dá as quadras;
2 - Dar buffer de -5m (menos cinco metros) no arquivo das quadras;
3 - Fazer a diferença Lotes menos Quadras. Isso nos dá como resultado
polígonos da frente dos lotes. Polígonos que mantém a medida original
da testada, porém, agora com apenas 5 metros de comprimento em direção
ao fundo dos lotes;
4 - Feito isso é só gerar os centroides, que agora ficam alinhados ao
eixo da rua, numa distância de 2,5m adentro do terreno *.

* Alguns cuidados e considerações precisam ser tomados:
a - Ao fazer a diferença, alguns lotes podem ficar totalmente sem
geometria (0,2% do total). Para saber quais ficaram sem geometrias, é
calculada a área deles. Lotes sem geometria nos dá área nula. Para
contornar esse problema, abre-se o arquivo de lotes originais e se faz
um join de tabelas com a tabela dos lotes cortados. Então, na tabela
de atributos é selecionadas todas as geometrias com área nula. A
seleção é salva como nova camada de shapefile. Do arquivo de lotes
cortados, é excluída as geometrias de área nula e adicionada suas
geometrias originais (lotes inteiros) - esses não tem jeito, é
necessário o alinhamento manual.
b - Todos os lotes de esquina cortados tendem a ficar em formato de
"L", fazendo com que seja quase sempre necessário fazer o
realinhamento manual.
c - Muitos lotes cortados ficam com várias partes descontinuadas (~5%
do total), de qualquer maneira, é gerado apenas um centroide que fica
a meio caminho entre as partes, mais ou menos, ou exatamente, no
centroide do lote original. Esses também não tem jeito, se faz
necessário o alinhamento manual.

É importante destacar que apesar de muitos pontos já saírem na sua
posição final, ainda assim é preciso que todos sejam verificados
porque podem não existir mais (percebi muitos lotes que agora são
ruas, por exemplo), ou mesmo porque exista já o endereço mapeado, ou
ainda que precisa ser movido o endereço do ponto para a área
(building, ou outra), caso ela já estiver sido mapeada.

Por fim, optei por dividir os pontos gerados por bairro, de modo que
para fins de importação no OSM, fique prático e fácil manipular
pequenos arquivos, principalmente neste caso que não só insere novos
dados no OSM, como também modifica existentes, e arquivos grandes
deixam mais tempo exposto a conflito de edições durante a importação.

Assim que começar a importação (de fato) compartilho aqui os
problemas, soluções e/ou dúvidas que possam surgir. Nova conta
exclusiva para importação foi criada. Nessa conta farei esta
importação e outras que possam vir futuramente, em Curitiba ou em
qualquer outro lugar. Quanto ao nome das changesets, o nome das
changesets será " #Import Curitiba: Endereços - IPPUC. Bairro
nomeDObairro " e a source da chageset será "Prefeitura de
Curitiba:IPPUC:Lotes_2018-07", lembrando que a source apenas será
posta na changeset, não em todos os endereços importados. Nos
endereços importados só terá as tags addr:street e addr:housenumber.

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

Re: [Talk-br] Road network improvements in Brazil

[santamariense]

I agree with the modifications so that the road classification could
keep a coerency, crossing a urban area without changing its category.

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

Re: [Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / Importação de numeração predial

[santamariense]

Obrigado pessoal pelo feedback. Fiz na calculadora de campo mesmo a
formatação dos nomes e números, quanto a isso tá suave.

Trebien, talvez não tinha explicado direito, mas de qualquer maneira
acho que o Sérgio já deixou claro. O reposicionamento do centroide
para junto dos logradouros será feito antes de se enviar ao OSM.

Paulo, não me parece fácil de implementar. Mas vou tentar. Se não
conseguir vai ser manualmente mesmo.

Uma questão que me foi sugerida fora da discussão aqui da lista é de
não usar source=Prefeitura em todos os pontos gerados, mas sim apenas
nas changesets. Algum forte motivo para manter a source em todos os
pontos?

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

Re: [Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / Importação de numeração predial

[santamariense]

Esperei para ver se alguém se pronunciasse nesse meio tempo.

Já venho conversando com alguns colaboradores, e foi um censo comum
que se gerasse o centroide e se arrastasse ele para perto do
logradouro. Como foi feito em Recife por exemplo
(https://www.openstreetmap.org/node/5762458824).


> O costume tem sido um dos seguintes:
> 1. Atribuir o endereço ao lote todo, ou a um prédio que ocupa o lote.
> É feito assim em Moscou e partes de Londres e Nova Iorque.

Não temos as buildings disponíveis. Só se importássemos os lotes então
como place=plot.


> 2. Atribuir o endereço à entrada do lote, do lado de dentro. É feito
> assim em Berlim, Amsterdã, Paris, Madri e partes de Londres e Nova
> Iorque.

É essa que está sendo proposta.

> 3. Usar linhas interpoladoras junto às entradas dos lotes, do lado de
> dentro. É feito assim em Toronto, e Buenos Aires.

Poderia se fazer assim também. É preciso que haja algum conhecimento
por parte da comunidade e debatam isso, principalmente a local. Como
tu apontou, cada uma tem as suas vantagens. Uma desvantagem que
apontaria neste método é: Ruas (ou parte delas) que não tem numeração
dos prédios de forma regular e coerente, assim como acontece em alguns
casos em Santa Maria. O normal e comum é em metros, mas existem
numeração de casas que não seguem uma lógica e serviços de roteamento
poderiam levar o usuário para um local incorreto dos logradouro.

> Digamos que a opção escolhida seja a 1 ou a 2. Ainda restaria decidir se:
> 1. O ponto do endereço deve conter o nome da rua, como é feito em
> Berlim, Amsterdã, Paris e algumas partes de Londres, e também nos
> números dos interpoladores em Toronto e Buenos Aires
> 2. O ponto do endereço não deve conter o nome da rua mas deve estar
> vinculado à rua por uma relação do tipo street, como proposto pelo
> Anderson no fórum noutra discussão [3]

A verdade é que as relações para numeração de casas não funcionam
(pelo menos não no Nominatim). O que acontece no Nominatim é que em
caso de não ter addr:street, ela pega a rua mais próxima.

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

Re: [Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / Importação de numeração predial

[santamariense]

Então pessoal, dando sequência apresento um detalhamento de qual
arquivo será usado, quais campos ("tags") ele tem, e quais desses
campos parecem ser úteis. O detalhamento está documentado em
https://wiki.openstreetmap.org/w/index.php?title=Curitiba/Importa%C3%A7%C3%A3o_IPPUC&oldid=1688307

Caso alguém tenha alguma sugestão de mudança de metodologia apresente
o mais breve possível, para que a comunidade possa analisar e de comum
acordo implementar.

[]'s

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

[Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / Importação de numeração predial

[santamariense]

Olá pessoal,

Conseguiu-se autorização formal do Instituto de Pesquisa e
Planejamento Urbano de Curitiba quanto a cedência dos dados de
cartografia para o OSM disponibilizados em
http://ippuc.org.br/geodownloads/geo.htm e a declaração está
disponível em 
https://wiki.openstreetmap.org/wiki/File:Declara%C3%A7%C3%A3o_de_Ced%C3%AAncia_de_dados_IPPUC.pdf

Gostaria que analisassem a declaração e dessem um feedback, caso
alguém discorde que sim, está suficientemente claro que os dados podem
ser importados para o OSM.

A ideia principal, e para isso estou sendo incumbido, é importar a
numeração predial da cidade que está disponível em "Lotes -
(julho/2018)". Não é disponível o shapefile de prédios, mas sim dos
lotes. A proposta é transformar a área do lote em ponto no centroide
do seu respectivo lote, e realocar cada um dos pontos gerados para a
proximidade da rua onde o endereço está localizado, ou seja, dentro do
prédio, porém, mais próximo de onde provavelmente esteja a porta de
entrada dele.

Conforme as boas práticas, será mantido o histórico dos endereços já
mapeados no OSM, inclusive suas coordenadas, sem haver duplicação de
objetos na base de dados do OSM.

A documentação está sendo feita em
https://wiki.openstreetmap.org/wiki/Curitiba/Importa%C3%A7%C3%A3o_IPPUC

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

Re: [Talk-br] Fundar Associação OpenStreetMap Brasil

[santamariense]

Lembrete... A versão atual do estatuto para a criação da associação
OSM BR está para a apreciação da comunidade.
https://bit.ly/votaEstatutoVers0_3_3 . Certamente os já cadastrados
receberam por e-mail. Participem.

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

[Talk-br] Criação da OSM Brasil avança para a rodada 2

[santamariense]

Apos a Rodada-1 de discussões estruturadas e votações (
https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Associação/Rodada/4.1#RESULTADOS)
chegamos à versao 0.1.1 do Estatuto (https://bit.ly/2L9aEkU)
estará a partir de agora continuamente disponível para consulta
pública e comentários.
A votação da Rodada-2
(https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Associação/Rodada/4.2)
vai ser submetida dia 19.

Todo o andamento está sendo documentada na wiki em http://bit.ly/2rsmNs8

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

Re: [Talk-br] Fundar Associação OpenStreetMap Brasil

[santamariense]

Olá pessoal. Dando prosseguimento, estamos cadastrando usuários
interessados na criação da entidade "OSM Brasil".

Convido todos a participarem preenchendo o formulário em
https://goo.gl/forms/sQWoPm3xsvU2Z6833 .

A partir dela, os cadastrados serão convidados a participar da votação
de pontos importantes a serem tratados sobre a entidade durante a
construção até a consolidação da proposta, bem como posterior
formalização da entidade.

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

Re: [Talk-br] Projeto escolar de mapeamento da comunidade de Curupaiti Viseu, Pará

[santamariense]

OSM Tracker for android (Gravar trilhas e pegar posição de objetos)
Keypadmapper para pegar numeração de casas na rua
StreetComplete para ajudar a completar o que falta de dados. (Para
este ser útil já tem que ter pelo menos a geometria dos objetos
mapeadas)
Também é possível com o tradicional mapa impresso e caneta.

O primeiro passo que eu sugiro é pegar a imagem de satélite mais
recente e mapear o que já existia até então. Depois disso, daí sim dão
continuidade com gravar trilhas e essas coisas. Assim fica mais
produtivo.

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

Re: [Talk-br] Projeto escolar de mapeamento da comunidade de Curupaiti Viseu, Pará

[santamariense]

É possível gravar as trilhas e posição de objetos a serem mapeados com
uso de GPS ou com o próprio smartphone usando para isso aplicativos.
Existem vários. Eu poderia te ajudar por videoaula também caso sinta
necessidade.

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

Re: [Talk-br] Fundar Associação OpenStreetMap Brasil

[santamariense]

Voltando para fazer um resumo do que foi discutido até agora e algumas
questões que surgiram neste ínterim. (até 12:00 de 28 de fevereiro de
2018)

Vale lembrar que a discussão tem ocorrido na lista Talk-Br
(https://lists.openstreetmap.org/pipermail/talk-br/2018-February/012322.html),
no fórum (https://forum.openstreetmap.org/viewtopic.php?id=61459) e
algumas vezes nas comunidades OSM do Telegram
(https://wiki.openstreetmap.org/wiki/Pt:Contact).

O que vai sendo decido, acrescenta-se a
https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Associa%C3%A7%C3%A3o
(precisa e será feito revisão) e discussões e sintetizações das
discussões vão para o Talk da mesma.

Parece-me que existem várias pessoas interessadas quanto ao apoio
financeiro de se criar uma entidade, outros alegam não ter tempo para
esse corre-corre, ou para ajustes técnicos (no caso de um portal web).
Mas como as áreas de conhecimento dos colaboradores do OSM é
abrangente, e dado a quantidade de interessados somados desta proposta
à antiga de 2014, creio ser viável e no fim não acabe pesando para uma
pessoa apenas fazer tudo.

Levantou-se a necessidade de reuniões on-line. Dúvida: É preciso atas
antes da ata de criação? (só se fosse algo informal, já que não teria
assinaturas)

Uma questão também levantada foi a importância de não focar em
governança mas sim em funcionalidade operacional. Para isso se faz
necessários traçar objetivos (fins), e com os fins estabelecidos se
decide o melhor caminho para chegarmos a ele.

Muitos objetivos já foram enumerados. É preciso fazer uma compilação
deles, atualizá-los e reapresentá-los sempre que possível para
apreciação dos demais.

Quanto à burocracia, vem a tona a questão de definirmos que tipo de
entidade queremos ou podemos alcançar atualmente. Uma das propostas
inicial é sermos encubados por alguma entidade maior como o Wikimedia
ou o Open Knowledge até que o movimento crie corpo, as demais são
criar de fato já uma entidade jurídica para o OpenStreetMap Brasil.
Daí surgiu até agora 3 possibilidades: Fundação, Associação ou
Condomínio Voluntário. Dito isto, é preciso analisar 2 pontos-chave:
Se cada uma delas vão nos levar aos objetivos traçados e seus custos
operacionais, bem como a burocracia envolvida.

Para fins de esclarecer quem não entende desta área jurídica, fiz um
resumo da diferença entre Fundação / Associação / Condomínio
Voluntário

Segundo 
http://www.administradores.com.br/artigos/negocios/associacao-ou-fundacao/43197/
, a diferença básica entre Fundação e Associação, são estas:

-- Associação
Constituída por pessoas.
Pode (ou não) ter patrimônio inicial.
A finalidade é definida pelos associados.
Os associados deliberam livremente.
Registro e administração são mais simples.
Regida pelos artigos 44 a 61 do Código Civil.
Criada por intermédio de decisão em assembléia, com transcrição em ata
e elaboração de um estatuto.

-- Fundação
Constituída por patrimônio, aprovado previamente pelo Ministério Público.
O patrimônio é condição para sua criação.
A finalidade deve ser religiosa, moral, cultural ou de assistência,
definida pelo instituidor.
A finalidade é perene.
As regras para deliberações são definidas pelo instituidor e
fiscalizadas pelo Ministério Público.
Registro e Administração são mais burocráticos.
Regida pelos artigos 62 a 69 do Código Civil. Criada por intermédio de
escritura pública ou testamento.
Todos os atos de criação, inclusive o estatuto, ficam condicionados à
prévia aprovação do Ministério Público.

O Condomínio Voluntário seria a entidade mais simples de todas, e está
está sucintamente explicada com uma linguagem bem acessível em
https://medium.com/@peterkrauss/condom%C3%ADnio-volunt%C3%A1rio-a-propriedade-comum-que-descentraliza-os-direitos-da-propriedade-privada-5bc92081fd82

Há também uma preocupação com descentralização da entidade a ser
criada, de modo a possibilitar atuação o mais local possível junto a
organizações governamentais, de modo que a importância seja algo como
município > estado > união.

Como o OSM é individualmente inconstante, quero dizer com isso que os
usuários não estão por dentro de tudo ao tempo todo, se faz necessário
chamá-los para a conversa e saber qual o nível de interesse deles no
assunto. Também é preciso e até interessante levar a ideia para
projetos correlatos como o Qgis e a própria Wikimedia. Conforme
possível, vamos trabalhando nisso.

Sem mais para o momento, estejam a vontade para opinar e dar
seguimento ao assunto,

usuário santamariense

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

[Talk-br] Fundar Associação OpenStreetMap Brasil

[santamariense]

Olá caros colegas,

Surgiu o assunto sobre criarmos um Tasking Manager brasileiro, e a
partir das discussões sobre a falta de um, sobressaiu também a
discussão sobre termos algo mais abrangente e concreto, como uma
Associação/Organização.

Sabemos que isso já vem sendo pensado há um bom tempo, e estamos
querendo pôr em prática, por diversos motivos e objetivos. Tudo está
sendo documentado em
https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Associação

Ajude a preencher os seguintes tópicos. Sempre baseado no que já
estiver na wiki.

* Objetivos

* Lista de necessidades, possibilidades, meios e custos

* Propostas de organização interna

* Apoio financeiro

[em caso de pessoal física, se você tiver pré-interesse em ajudar
financeiramente, adicione seu nome (de usuário) na wiki, ou, peça para
adicionarem]

Sua participação é muito importante e fundamental

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

Re: [Talk-br] Como mapear Polícia Rodoviária?

[santamariense]

De forma mais abrangente poderíamos usar
operator=município|estado|união ou operator=municipal|estadual|federal
para classificar qualquer coisa. Só precisaríamos definir uma
padronização. Até porque facilitaria posterior extração de dados.
Exemplo de outras entidades que podem usar esta classificação: escolas

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

Re: [Talk-br] Mapeamento hidrológico

[santamariense]

@smaprs,

A gente poderia montar maratonas de mapeamento neste sentido. Teria
alguma ideia? Fazer um levantamento de áreas criticas?

.

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

Re: [Talk-br] Mapeamento hidrológico

[santamariense]

> Acho que isso não é necessário, da mesma forma que não definimos
> explicitamente que Rua Tal está na cidade Tal.

Então, pretendem subir ao OSM a delimitação de bacias hidrográficas?

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

Re: [Talk-br] Mapeamento hidrológico

[santamariense]

Qual a ideia de como mapear Bacias Hidrográficas? Criando relação e
adicionando os respectivos waterways? Ou adicionando tags do tipo
estánabacia="Bacia Hidrográfica do Aa" em cada waterway?

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

[Talk-br] Como faço para criar bairros ou áreas dentro de uma cidade através do Josm ou outro aplicativo e aplicar cores definidas nessas áreas?

[santamariense]

Eu acho que entendi a pergunta desd'o começo. O que tu quer é que no
mapa www.openstreetmap.org um bairro apareça de uma cor, outro bairro
de outra e assim por diante, né?

Isso é impossível, ou se você conseguir na "gambiarra" vai estar
mapeando para o renderizador. E isso não é correto.

O que aparece sim com certo destaque em mapa é a borda de divisa dos
bairros, assim como, de distritos, municípios, estados... Aparece
pontilhado em roxo, exemplo:
http://www.openstreetmap.org/relation/3103637#map=19/-29.70815/-53.82546

Mas não é porque um local não aparece destacado no mapa que não está
mapeado. Muito pelo contrário, um bairro corretamente mapeado constará
nos endereços de todos os objetos que estiverem dentro dele.

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

Re: [Talk-br] Numeração da Av paulista em SP - SP

[santamariense]

Também costumo fazer como o @bello.flavio disse, na building em si eu
coloco o número que é aquele que acessa os andares superiores e que
costuma ter um nome do prédio (addr:housename); Nas lojas do térreo eu
costumo adicionar um nó colado a building com as tags
entrance=main/yes e addr:housenumber e outras tags de endereço para
cada loja. Para lojas/amenities/... que não tem acesso direto da rua,
eu coloco nodes soltos dentro da building com endereço e level
(-1=subsolo,0=térreo,1,2,...)

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

Re: [Talk-br] Dúvida sobre nova versão do editor iD

[santamariense]

Quase nunca edito pelo ID, mas @Ivaldo, concordo com tuas ideia a
respeito do ID. Nada mais a declarar, assino embaixo.

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

Re: [Talk-br] Dúvida sobre nova versão do editor iD

[santamariense]

JOSM é produtividade! Dedique tempo para aprender o básico. Em pouco
tempo você estará mapeando muito mais coisas em muito menos tempo.

É verdade! Você não foi o único que vi reclamando disso.

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

Re: [Talk-br] Rodovia SC-114 Trecho Enedino Batista Ribeiro

[santamariense]

Não estudei bem este caso em particular, mas se uma rodovia tem uma
placa dizendo ser aquele nome, e esta placa foi colocada por órgãos
competente, no name vai o nome comum, reconhecido, ou com placa no
local, e, o nome official vai em official_name.

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

Re: [Talk-br] Ajuda no Mapa

[santamariense]

Se você já fez as modificações no local, é necessário esclarecer que
após a atualização/correção ainda demora alguns dias para que os
roteadores reconheçam as novas modificações em mapa.

Existem 2 trevos nas proximidades. Mas acho que você já fez a edição
no local desejado. Agora é esperar que atualize o roteador.

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

Re: [Talk-br] Buscando os pontos de uma área

[santamariense]

Para aplicações web existe "Reverse Geocoding", como o Nominatim. Exemplo:

http://nominatim.openstreetmap.org/reverse.php?format=html&lat=-9.64844&lon=-35.70226&zoom=21

que em XML é isto:
http://nominatim.openstreetmap.org/reverse.php?format=xml&lat=-9.64844&lon=-35.70226&zoom=21

Se você quiser gerar o endereço para pontos específicos e limitados,
você pode usar programa GIS como o QGis.

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

Re: [Talk-br] Buscando os pontos de uma área

[santamariense]

Tem sim como recuperar os pontos. Cita algum bairro como exemplo. Pelo
o que eu to imaginando você quer todos os pontos do polígono que forma
a área do bairro. É isso? (Embora eu não veja a utilidade)

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

[Talk-br] Dúvida sobre o copyright de dados derivados do OSM

[santamariense]

(Suposição) Tenho que mapear a sede e filiais de uma empresa. E os
dados que vou gerar, disponibilizarei em domínio público.

Situação 1: Uso como base um mapa comercial (Google, Here,...) para
obter suas coordenadas.

Situação 2: Uso o OSM como mapa base para obter suas coordenadas.

O que o uso da situação 1 e/ou 2 interfere na minha ideia inicial de
disponibilizar o pacote completo de empresas em domínio público? Qual
será o copyright dos dados da situação 1 e da situação 2 a partir do
momento que utilizei seu mapas para obter coordenadas?

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

Re: [Talk-br] Dados do Cadastro Nacional de Estabelecimentos de Saúde

[santamariense]

Eu vi alguns pontos que estão alinhados, outros não tenho certeza do
que se trata, até porque não dá para selecionar e ver os dados.

Nesses dados também consta contatos como número telefônico ou e-mail?

Se tiver telefone, a gente pode ligar para tirar a dúvida do local
exato. Em último caso, podemos importar com um
fixme="Averiguar/Corrigir posição. Importação tal".

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

Re: [Talk-br] Usuário possivelmente copiando nome de ruas

[santamariense]

Já tentaram mandar mensagem privada para ele? As vezes tem gente que
nem olha e-mail. Eu acho que o OSM tá precisando um sistema de
notificação como o que tem hoje para mensagens. Para que notifique
comentários em changesets, modificações em notas, comentários no
diário, e quiçá também um vinculo com o wiki, fórum,... Tudo isso no
site principal de edição OSM. E também, nos demais editores, como o
JOSM.

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

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

[santamariense]

@Jairo, você não pode estar em desacordo com a comunidade e sair
mapeando tudo a teu gosto. Tenha calma, se o correto for assim, assim
será.

Eu fiz duas perguntas e não responderam (o Vitor deu mais ou menos uma
opinião - acabei de ler). Não eram perguntas retóricas.

Eu ao contrário do que possa parecer até agora, não tenho opinião
formada sobre o assunto. Resolvi fazer um passeio OSM pela Europa para
ver como eles mapeiam situações assim (Se uma ou outra situação ganhar
é ao acaso. Se vocês encontrarem situações contrárias, postem:

1 - Utilizam no "name" o nome extenso de uma "ref":
- https://overpass-api.de/achavi/?changeset=46035604 : Itália
- http://www.openstreetmap.org/way/121783714 : Portugal

2 - Tem ref mas não tem name como seu nome por extenso:
- http://www.openstreetmap.org/way/23651035 : Itália
- http://www.openstreetmap.org/way/134656887 : Itália
- http://www.openstreetmap.org/way/91128550 : England
- http://www.openstreetmap.org/way/4887304 : England
- http://www.openstreetmap.org/way/2954056 : England
- http://www.openstreetmap.org/way/440988241 : Portugal
- http://www.openstreetmap.org/way/276423083 : Portugal
- http://www.openstreetmap.org/way/369707086 : Espanha
- http://www.openstreetmap.org/way/318492020 : Espanha
- http://www.openstreetmap.org/way/147969960 : França

Com base nos locais que estive averiguando, ao que tudo indica a
maioria não coloca o nome por extenso de uma rodovia. Essa não é só
uma questão local, é também uma questão de ordem mundial, pois não
parece haver total consenso da comunidade.

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

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

[santamariense]

Parece que cada um tem o seu conceito sobre o assunto dependendo das
rodovias que conhece.

Pergunto:

1 - As rodovias com nomes oficiais, porém (ainda) não amplamente usado
pela população, podem ter esses nomes adicionados a "official_name"
deixando "name" vazio?

2 - Como vocês fazem para mapear uma building associada a esta rodovia
quando o endereço-rua dado a ela difere do nome oficial da rodovia?

Eu penso que os nomes oficiais podem ser desconsiderados pela tag
"name" até que sejam reconhecidos pela população tanto ou mais que sua
referência.

Aqui em Santa Maria tem o caso da ERS-509, conhecida localmente como
"Faixa Velha (de Camobi)". Os endereços das empresas/residências ao
longo dela eram dado como "(Rodovia) RS-509, ". Depois veio o nome
oficial (Avenida Prefeito Evandro Behr), que embora oficial demorou
para começar a ser usado, porque querendo ou não a referência era
usada como sendo o "nome" do logradouro. Agora que o nome oficial está
em uso, parece ser a melhor forma de denominar aquelas estradas,
mas...

Recentemente uma lei federal, feita em gabinete, e aparentemente sem
assinatura dos moradores, denominou trechos de rodovias em Santa Maria
como "Rodovia Senador Tarso Dutra", "Rodovia Luiz Alves Rolim
Sobrinho". Tudo bem, são oficiais, mais cedo ou mais tarde é provável
que sejam usadas e acabem por serem reconhecidas, mas o fato é que até
AGORA, nunca vi ninguém se referir a elas para descrever como chegar a
um local, muito menos como endereço para seus estabelecimentos
comerciais ou residências. E daí vem uma situação muito estranha: A
via tem o nome de "Rodovia Senador Tarso Dutra", e daí você vai mapear
a building ao longo dela. Se você adicionar addr:street="Rodovia
Senador Tarso Dutra" você vai combinar com o nome não usual da via
associada.  E, se você adicionar addr:street="BR-287" não vai estar de
acordo com o nome da via associada (Rod. Sen. T. Dutra), mas vai estar
de acordo com o endereço das casas ao longo dela.

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

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

[santamariense]

Eu concordo com o Jairo. Não sei se é o correto, até porque precisamos
manter um paralelismo com a comunidade internacional, mas:

Entre os vários campos existentes para nome (name, alt_name, old_name,
official_name, ), concordamos que no campo name deve prevalecer o
que existe a campo, o que as pessoas reconhecem; E o que muitas vezes
as pessoas reconhecem é o uso da referência como sendo o nome da
rodovia, quer para se referir a ela, quer para dar o seu endereço.

E se for pensar, ref e name não terão exatamente o mesmo valor. Ref
seria nesse caso "ref=SC-114" e name seria "name=Rodovia SC-114", até
porque no campo nome deve ir o nome completo, e isso inclui o tipo de
logradouro. O nome offcial vai em "official_name".

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

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

[santamariense]

Corrigindo link quebrado para o relatório sobre a proposta 1 de
importação do CNEFE: https://github.com/santamariense/cnefe

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

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

[santamariense]

Compartilho com os senhores o relatório de uma simulação de mapeamento
de numeração de casas usando o CNEFE. O relatório consta de uma
arquivo de texto (o relatório em sí) + um *.osm de como ficou o
resultado do mapeamento.

Relatório: https://goo.gl/vTCEKf

O relatório se refere ao estudo de caso da Proposta 1
(https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/CNEFE_2010/Importa%C3%A7%C3%A3o_dos_endere%C3%A7os)

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

Re: [Talk-br] CNEFE

[santamariense]

@Papibaquígrafo, gostei da ideia. Só acrescento que se faz necessário
que esta camada tenha as faces também porque fica difícil, em muitos
locais, de se saber a qual rua pertence um ponto e muitos vezes isso
pode induzir a erros.

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

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

[santamariense]

Só para atualizar a situação da Mitula não dar créditos ao OSM...
A Mitula não respondeu em um prazo de um mês. Assim, contatei a
Mapbox. A resposta foi:

Hi there,

Thanks! I'll reach out to this user. No further actions needed on your end.

best,

Angelina

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

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

[santamariense]

@Peter, e demais colegas, eu estou vigiando as páginas wiki citadas
aqui sobre o CNEFE. Então, o andamento das propostas que lá forem
citadas, eu recebo em meu email. Sugiro que façam o mesmo (vigiar a
página para receber no email).

Eu não sei como poderia ser feita uma validação neste caso.

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

[Talk-br] Algorítimo CNEFE XML OSM

[santamariense]

Ao passo que cada linha do TXT do CNEFE está em ordem decrescente e
percorre a quadra (fechada ou não) da face N para a face 1, é possível
criar por meio de programa um XML já com a numeração de casas
esparramadas ao longo da face.

Se a gente conseguir fazer essa ideia sair do papel, não será preciso
ter que esparramar manualmente os números nas faces, ou seja, "80%" de
redução de trabalho braçal.

Alguém de vocês já programou escrevendo em arquivos XML? Pessoalmente
eu peguei a manha de ler arquivos XML em PHP, mas escrever um XML
nunca fiz. Posso até aprender, não me parece difícil. Mas não tenho
certeza que PHP seja a linguagem ideal, se há que exista, para
escrever os arquivos XML OSM. E mesmo que consiga escrever XML
precisaria de ajuda na parte lógica.

Alguém saberia onde encontrar programadores experientes dispostos (a
ajudar) a criar um programa para fazer isso? A menos que a gente tenha
aqui na lista mesmo ;) Ou todos são programadores :0  Eu sou mais
um entusiasta do que alguém preparado para isso.

Algorítimo: Ponta-pé inicial:

Algoritimo CNEFE_XML_OSM;

  Ler o arquivo “.osm” (XML) com as faces.  Armazenar os atributos de
cada face em um vetor;

  Ler o aquivo cnefeTXT. Armazenar os atributos de cada casa em um vetor;

  Para cada vetor(cnefeTXT) faça {
Busca no vetor de faces, a face correspondente;
Obtêm-se os nodes dos extremos da face;
Analisa-se o sentido do way da face, observando que o último node da
face atual será o primeiro node da face antecessora (visto que o
cnefeTXT está em ordem decrescente);
Com base nas coordenadas dos extremos das faces e com o uso de
geometria, aloca-se os pontos ao longo da face;
Escreve no XML os nodes e seus atributos;
Escreve no XML as faces e seus atributos, extinguindo-se os nodes
originais, e adicionando-se os nodes alocados como referencia;
  }

FIM_Algoritimo;

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

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

[santamariense]

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?

Resposta: Ao analisar visualmente 1 TXT como amostra, pude averiguar
que começa na quadra de maior número e vai até a de menor número. O
mesmo ocorre com as faces. Da maior para a menor. Tudo então, parece
indicar que a resposta é positiva (apenas está invertida -
decrescente).

@Papibaquígrafo, tem alguma ideia a nível de software, de como isso
pode ser automatizado? O problema é que teria q ter um txt em paralelo
para ajudar na edição. Aí complica...

O sentido das linhas das faces (geometria), este sim tudo indica ser aleatório.

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

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] 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] Mapeamento adequado de Estações de Trem

[santamariense]

@naoliv, ihhh que eu to confundindo as coisas. hahahaha. Isso que é o
bom do trabalho colaborativo, um corrige/ajuda o outro. Muito legal e
útil isto sobre "Lifecycle prefix".

Eu fiquei na dúvida em, sabendo-se as tags do texto a seguir, se é
necessário o uso de railway:historic=station e
historic:railway=station . Seriam elas usadas independentemente das
demais tags?

@naoliv, deixo para ti que tem mais prática no Maproulette. Abre um
pedido lá. Preferencialmente com o texto das tags como dispostas pelos
colegas.

Então vamos lá. Segunda compilação no texto:

1. Se a estação ainda está em pé, mas não é mais usada para a
finalidade para qual foi concebida, usa-se a tag
disused:railway=station
2. Se o prédio ainda existe, mas em estado de muita má conversação,
usa-se a tag abandoned:railway=station
3. Se não existe mais a estrutura (prédio) onde funcionava a estação,
usa-se a tag demolished:railway=station
4. Se a estrutura tem um valor histórico, deve-se informar a fonte
(source) de sua importância histórica (lei de tombamento histórico,
por exemplo); e, usar a historic=railway_station
5. Se existe aquela arquitetura clássica de estações de trem,
adicionar a tag building=train_station

Fim_da_segunda_compilacao

Com exceção do 1º, 2º e 3º item, uma tag não desdiz a outra, sendo que
em determinadas estacões deverá se usar várias tags. É interessante
fazer uma pesquisa para tentar identificar se a estação não poderia
estar sendo usada para outros fins (Museus, bibliotecas, etc). E, nos
locais onde as estações ainda são estações de fato, seria interessante
adicionar alguma nota (note=*) informando que ali ainda funciona.

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

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

[santamariense]

@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

Re: [Talk-br] Mapeamento adequado de Estações de Trem

[santamariense]

Caros colegas,

Fiz uma compilação da opinião de cada um a respeito do assunto. É
consenso de todos que railway=station deve ser abandonada em todo o
país, exceto é claro, onde ainda funciona.

Cheguei a seguinte conclusão em relação as tags:

1. Se a estação ainda está em pé, mas não é mais usada para a
finalidade para qual foi concebida, usa-se a tag
disused:railway=station
2. Se não existe mais a estrutura (prédio) onde funcionava a estação,
usa-se a tag abandoned:railway=station
3. Se a estrutura tem um valor histórico, deve-se informar a fonte
(source) de sua importância histórica (lei de tombamento histórico,
por exemplo); e, usar a tag historic:railway=station +
railway:historic=station (já que a wiki não é bem clara, usar as duas)
4. Se existe aquela arquitetura clássica de estações de trem,
adicionar a tag building=train_station

Com exceção do 1º e 2º item, uma tag não desdiz a outra, sendo que em
determinadas estacões deverá se usar várias tags. É interessante fazer
uma pesquisa para tentar identificar se a estação não poderia estar
sendo usada para outros fins (Museus, bibliotecas, etc). E, nos locais
onde as estações ainda são estações de fato, seria interessante
adicionar alguma nota (note=*) informando que ali ainda funciona.

Fim_da_Conclusão

Se alguém discordar dos disposto, pronuncie-se, dizendo o que não
concorda e o porquê.

É preciso de voluntários para fazer as devidas correções. O ideal é
que quem for editar cada estado(s), conheça a realidade atual da malha
ferroviária do local. Alguém se candidata?

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

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

[santamariense]

@naoliv, blza

@Peter, a ideia de um repositório é ótima. Vamos ter que montar um. De
qualquer maneira, existem alguns arquivos parciais postados em
https://goo.gl/x2TGCQ . A metodologia será esclarecida a todos de
forma ampla, para que deem sugestões, antes de uma geração de dados de
todo o país. Acho que seria interessante fazer testes em
cidades-cobaias. Não necessariamente já enviando os dados.

@Sérgio, é exatamente esta a solução encontrada. Imagino que
automatizar mais que isso (alinhar os pontos na ordem correta ao longo
da face) está inatingível. Acho que deve ser trazido pro OSM também as
linhas que formam as faces. Uma coisa que deve ser corrigida durante a
importação pra facilitar é deixar o nome das ruas já em caixa baixa
com iniciais em caixa alta.

... Mas aí que tá. A gente não precisa importar diretamente tudo isto
como foi gerado. A gente pode trabalhar em cima do material
manualmente e ir distribuindo a numeração ao longo da face. Em alguns
casos dá até para se ter certeza da exata casa de cada número.

Ficará de tarefa manual para nós: alinhar as faces com o alinhamento
do OSM, distribuir a numeração ao longo da face e colar cada ponto a
linha da face.

Por exemplo, se eu me comprometo a fazer um município, vou trabalhando
e salvando. Quando estiver completo o trabalho, eu envio ao OSM.

Se der pra ficar numa base como openadress.io, e funcionar em plena
integração com tudo do OSM, e permitir controle (manutenção, etc),
creio que já resolveria. >>> RE: Eu acho que se a numeração não
estiver no OSM isto vai dificultar futuras edições pela falta de dados
no OSM.  Só o fato de se ter a face com os números alinhados pode
servir de base de dados para melhorar o mapa em uma pós-importação do
CNEFE. Muitas vezes se tendo apenas o número de uma casa coletada a
campo, vai se poder montar o quebra-cabeças da numeração das outras
casas apenas pegando a numeração que já vai estar no OSM. E por fim
excluindo esta interpolação, porque, creio que a ideia é que seja algo
provisório.

Por fim eu digo que sou não favorável a importação direta, mas sim que
isto seja um material-base para se trabalhar em cima.

@Pedro, o ideal é exatamente isto. Mas nem sempre dá para se ter essa
certeza. Pelo o que eu estou imaginando, os números não ficarão
soltos. Eles ficarão presos a linha da face. Eles farão parte da linha
da face. Veja este exemplo: http://imgur.com/a/fsn3n

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

[Talk-br] Sobre addr:interpolation - possibilidades

[santamariense]

A comunidade do QGis está trabalhando de modo a deixar o material o
mais enxuto possível para ser ajustado por nós do OSM, para então ser
subido à base de dados do OSM. A ideia é automatizar ao máximo, e, que
seja gerado o shp de todo o pais e que já se largue o material para
nós do OSM em arquivos no formato *.osm para que possamos fazer apenas
o alinhamento via o editor JOSM. A ideia é que as tags já venham
prontas.

Então temos as tags originais do IBGE, e as tags que usamos aqui no
OSM. Temos que discutir, nesta provável importação, se há tags do IBGE
que vamos/devemos manter. Talvez algumas tags sejam necessárias para
futuras importações corretivas. Não tenho muita noção sobre isso.
Então seria importante a opinião de veteranos no assunto.

Tags originais dos pontos (housenumbers) do CNEFE (corrijam se estiver errado):
'Código da unidade geográfica=*
Situação do setor=*
Logradouro=*
Número no logradouro=*
Complemento=*
Latitude=*
Longitude=*
Localidade=*
Ponto de referência=*
Espécie de endereço=*
Tipo de estabelecimento=*
Indicador de endereço=*
Identificação domicílio coletivo=*
Número da quadra=*
Número da face=*
CEP=*


Tags originais das faces (corrijam se estiver errado):
Código da unidade geográfica=*
Código do setor=*
Código da quadra=*
código da face=*
Nome do tipo do logradouro=*
Nome do título do logradouro=*
Nome do logradouro=*
total de residências=*
total geral (residencias+estabelecimentos comerciais)=*

Enfim, temos as tags que devem ir ao OSM - e aqui que vem a discussão
desta etapa. Vou citar as tags básicas, e quem achar que deva ser
incluída ou modificada alguma tag, que corrija postando toda a lista
abaixo com as correções que julgar necessário.

tags que vão para as faces:

addr:interpolation=(all/even/odd/)
addr:inclusion=(potential/estimated)
source="IBGE/CNEFE 2010"

tags que vão para os pontos:

addr:housenumber={{numero_casa}}
addr:postcode={{CEP no formato X-XXX}}
addr:street={{Nome da Rua}}
source="IBGE/CNEFE 2010"

As tags que são as mesmas para todos os objetos são a addr:inclusion e source.
Preciso que vocês ajudem a analisar se seria mais adequada para a
addr:inclusion o valor estimated ou o valor potential. Analisem isto
em 
https://wiki.openstreetmap.org/wiki/Addresses#Using_Address_Interpolation_for_partial_surveys

E a tag source? Qual valor deve ter?

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

[Talk-br] Mapeamento adequado de Estações de Trem

[santamariense]

Eu (usuário santamariense), e os usuários Geogast e portalaventura,
discutimos a questão do mapeamento de Estações de Trem em uma nota
aberta em Santa Maria RS.

A discussão gira em torno do fato de que a maioria das
(railway=station)'s do Brasil não seriam mais ao pé da letra r=s
porque não funcionam mais como "transporte de passageiros / Transporte
público".

Chegou-se ao consenso que o correto é mudar da tag (railway=station)
para (historic:railway=station).

Abro aqui esta discussão para que possamos corrigir isto em todo o
território nacional.

A discussão original encontra-se em
https://www.openstreetmap.org/note/792826 e deve continuar aqui na
lista.

Atual cenário do mapeamento no Brasil:
r=s no BR: http://overpass-turbo.eu/s/kYN
h:r=s no BR: http://overpass-turbo.eu/s/kYO

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

Re: [Talk-br] Digest Talk-br, volume 100, assunto 1

[santamariense]

ctrlV(ctrlC+"source=Sérgio V.");

Em 02/01/2017, 
talk-br-requ...@openstreetmap.org
escreveu:
> Enviar submissões para a lista de discussão Talk-br para
>   talk-br@openstreetmap.org
>
> Para se cadastrar ou descadastrar via WWW, visite o endereço
>   https://lists.openstreetmap.org/listinfo/talk-br
> ou, via email, envie uma mensagem com a palavra 'help' no assunto ou
> corpo da mensagem para
>   talk-br-requ...@openstreetmap.org
>
> Você poderá entrar em contato com a pessoa que gerencia a lista pelo
> endereço
>   talk-br-ow...@openstreetmap.org
>
> Quando responder, por favor edite sua linha Assunto assim ela será
> mais específica que "Re: Contents of Talk-br digest..."
>
>
> Tópicos de Hoje:
>
>1. Bom Ano Novo (Sérgio V.)
>
>
> --
>
> Message: 1
> Date: Sun, 1 Jan 2017 13:09:23 +
> From: Sérgio V. 
> To: "talk-br@openstreetmap.org" 
> Subject: [Talk-br] Bom Ano Novo
> Message-ID:
>   
> 
>   
> Content-Type: text/plain; charset="iso-8859-1"
>
> Votos de bom ano para a comunidade OpenStreetMap no Brasil, para todos e
> para cada um,
>
> de consolidação, popularização e prosperidade do projeto OSM,
>
> ao qual cada um de nós estima e dedica muito de seu tempo de atividade
> física e mental,
>
> união e crescimento da comunidade como um projeto comum,
> crescimento pessoal e prosperidade de cada um,
>
> implementação e aprimoramento das boas ideias e possibilidades já
> levantadas,
>
> surgimento de novas boas ideias,
>
> difusão do OSM e de suas utilidades para a população em geral,
>
> e tudo o mais que for bom.
>
>
> Um abraço,
>
>
> Sérgio - http://www.openstreetmap.org/user/smaprs
> -- Próxima Parte --
> Um anexo em HTML foi limpo...
> URL:
> 
>
> --
>
> Subject: Legenda do Digest
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
> --
>
> Fim da Digest Talk-br, volume 100, assunto 1
> 
>

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

Re: [Talk-br] Mapeamento de biomas + Wikipédia

[santamariense]

> Para mim me parece ser o caso de usar
> https://wiki.openstreetmap.org/wiki/Proposed_features/Key:protected_area
>
> junto com um multipolígono
>
> https://wiki.openstreetmap.org/wiki/Relation#Multipolygon

Eu nunca mapeei área protegida, mas o problema é que Mata Atlântica
existem às milhares de áreas pelo Brasil. Basicamente quase todo mato
nativo (natural=wood) é Mata Atlântica, que originalmente cobria esta
área 
https://pt.wikipedia.org/wiki/Mata_Atl%C3%A2ntica#/media/File:Atlantic_Forest_WWF.jpg

@Alexandre Magno, e colegas, vocês acham que seria correto adicionar a
tag "wikipedia=pt:Mata Atlântica" a todos esses "natural=wood"? A
questão da tag wikipédia é que ela ilustra artigos da wikipédia e
atualmente só tem essa tag algumas áreas próximo a (ou na) cidade de
São Paulo (http://i.imgur.com/cdoDqDu.png). Eu pessoalmente já vi em
alguns locais na Europa a criação de objetos só para ilustrar artigos
da wikipédia, mesmo que não se tenha outra tag definidora aqui no OSM.

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

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

[santamariense]

Caros colegas, na questão que eu abri no grupo do Qgis, o colaborador
"Antônio Guarda" deu a entender que é mais simples do que parece. Eu
estou sem tempo, e não pude verificar a ideia dele. Mas compartilho
com vocês aqui o link para que possam analisar se ele acrescentou algo
além do que foi dito aqui.

https://groups.google.com/d/embed/msg/qgisbrasil/FiQksETzQXU/hPlFT8HGDQAJ

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

[Talk-br] Mapeamento de biomas + Wikipédia

[santamariense]

Estive discutindo com o usuário AjBelnuovo sobre como mapear o bioma
Mata Atlântica. Isto me parece ser algo abstrato de difícil
mapeamento. Transcrevo abaixo a discussão originada em
http://www.openstreetmap.org/changeset/25217160. Queria saber se
alguém já tem alguma experiência na área.

Comentário de santamariense
É correto nomear matos como "Mata Atlântica"? E, é correto adicionar a
tag "wikipedia=pt:Mata Atlântica" a todos estes matos?
A tag da Wikipédia, serve também para ilustrar artigos da Wikipédia. E
atualmente só estes matos da metrópole paulistana constam como tal em
todo o Brasil, vide imagem: http://i.imgur.com/cdoDqDu.png
Não sei se seria interessante usar a tag da wikipédia nestes casos
para mapear algo tão abstrato.

Comentário de AjBelnuovo
Começaria por contestar o termo que você usou " mato " . Pra mim mato
é uma folhagem que tem no máximo 80 cm de altura , o que não é caso da
mata em questão , que contém árvores diversas e é área de preservação
ambiental . Se a mata em questão , que está na Serra do Mar , não faz
parte do restou da Mata Atlântica , não sei onde ela estaria , mas se
você contesta o uso da tag , deveria dirigir a pergunta a ONG SOS Mata
Atlântica e remover o nome caso eles afirmem que não pertença .
Atualmente eu não dou nome a mata nativa , mas não uso Floresta
Manejada , onde vejo que ela não foi tratada desta forma .

Comentário de santamariense
Desculpa, primeiramente porque não compreendo muito dessas coisas, e
segundo porque aqui no sul a gente chama de mato mesmo, independente
do tamanho para generalizar. Talvez eu me fiz entender mal. Eu não
discordei que fosse mata atlântica, mas se seria correto adicionar
"Mata Atlântica" no nome. Seria como adicionar name=Casa à todas as
casas (building=house) que estão no mapa. Ou adicionar o nome açude à
todas os landuse=reservoir. Ou coisa parecida.
A questão é que mata atlântica é um bioma (relembrei meus tempos de
colégio agora). Existem sim outras tags que classificam os tipos de
árvores (https://wiki.openstreetmap.org/wiki/Forest) mas não sei se
exatamente bioma.
Acho que deve haver tags mais apropriadas para definir o tipo de mata
em questão. Eu desconheço porque nunca me ative a mapear este
detalhamento aqui no OSM.
Eu te perguntei porque cheguei a pensar que você tivesse falado com a
comunidade OSM sobre este assunto.
Eu vim para essa conversa ao ver o artigo Mata Atlântica da Wikipédia.
Eu tinha a intenção de iniciar um debate se é correto adicionar a tag
"wikipedia=pt:Mata Atântica" a todos os milhares de retalhos de Mata
Atlântica que existem no Brasil. Atualmente dá a entender que estas
áreas de matas são as únicas que restaram em todo o território
nacional, como pode ser visto nesta imagem que eu reitero
(http://i.imgur.com/cdoDqDu.png). Dá uma olhadinha no mapa OSM da
wikipédia conforme a imagem e diga a sua opinião.

Comentário de AjBelnuovo
Me desculpe pelo jeito grosseiro da minha resposta . Vendo no artigo
da Wikipédia sobre a Mata Atlântica a foto que mostra a delimitação
criada pela WWF sobre ela vejo que contempla exatamente a área que
você marcou na foto http://i.imgur.com/cdoDqDu.png . Acho que seria um
bom tópico para discussão e que dela talvez fosse gerado uma forma de
se nomear a toda essa floresta .

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

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

[santamariense]

Agora sim a coisa está andando. :)

@Sergio, de onde você obteve o que significa cada parte do layout?
Deduziu? Ou achou a fonte?

Eu pensei em trabalhar com coordenadas UTM, visto que a numeração das
casas é em metros. Isso poderia facilitar de alguma maneira. Tendo os
alinhamentos das faces, por cálculos se poderia distribuir a numeração
ao longo do caminho.

É possível mover pontos espacialmente no QGIS utilizando-se
calculadora de campo? Se não for, um programa externo poderia gerar as
coordenadas.

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

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

[santamariense]

@Marcos Fedato, tudo o que você falou é verdade. Só seria útil e
preciso se tivesse coordenadas como na zona rural. Acrescento dizendo
que para piorar cada setor censitário pode conter N quadras. Mapeei em
outra oportunidade os setores censitários em Santa Maria, vejam em
http://overpass-turbo.eu/s/9zr.

Eu diria que seria possível complementar informações já existentes.
Mas uma importação tá quase impossível. Seria uma compilação manual
apenas. Exemplos de coisas que se pode extrair manualmente:

1. Se o setor censitário tiver 4 ruas, e no OSM se tem o nome de 3,
provavelmente lá se encontrará o nome da 4ª.
2. Se no OSM tivermos já o número das casas. Podemos posicionar POIs
do CNEFE no OSM.
3. Em ruas que passam por vários setores censitários, e que tiverem
numerações coerentes, até seria possível, ter ideia de onde a rua
começa/termina, bem como faixas de números referente a cada setor
censitário.

Mas tudo isso, se tivéssemos os dados como uma camada de fundo para
edições manuais, não consigo ainda vislumbrar uma importação.

@Vítor Rodrigo Dias, eu acho que o que foi falado acima possa
responder tua pergunta. E eu também já pensei nisso que você tá
astuciando, mesmo sem usar o CNEFE/IBGE. No caso da minha cidade,
sabendo onde começam (nº1) e terminam as ruas (nº [medida em metros a
partir do início da rua]), seria sim possível gerar algo provisório,
mas muito útil até que se tenha cada casa mapeada. E a ideia que
tinha, e que alguns colegas também tiveram, era aproveitando o próprio
eixo das vias.

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

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

[santamariense]

Eu concordo contigo neste ponto. Porém há quem prefira de trecho em
trecho para melhor precisão. Chegamos a discutir, aqui mesmo neste
tópico, o uso do próprio eixo da via para isso, sem criar novas
geometrias.

Tem aqueles que vão querer fazer de quadra em quadra, mas aí cada um
faz como quiser, chegando-se a um consenso em cada município/área de
interesse.

O único problema é que os pontos do CNEFE com os números das casas em
áreas urbanas não tem coordenadas. - Do meu ponto de vista é o maior
dos problemas.

O que é essa "base de dados de faces do IBGE" que vocês tanto falam
aqui É CNEFE + setores censitários

> Santamariense, tenho duas ideias:
>
> - extrair o maior e o menor número de cada face, ao invés de interpolar
> cada número
> - associar os extremos às pontas de cada traço de interpolação
> - utilizar a própria base de dados de faces do IBGE para adicionar os dados
> de interpolação
>
> É viável?

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

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

[santamariense]

Postei na comunidade do QGis um tópico sobre a criação de SHPs a
partir do CNEFE para ver se alguém tem alguma ideia disso para
posteriormente facilitar nosso trabalho aqui no OSM. Tópico:
https://goo.gl/g39rCO

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

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

[santamariense]

@Vítor, já tive a infelicidade de conhecer este arquivo do CNEFE sem
tabulações/; - Isso dificultaria muito a nossa ideia de importação. Se
baixar os CSV por setores censitários, eu consegui transformar em shp,
mãnnnsss, as zonas urbanas, de onde temos o maior interesse, não tem
coordenadas, de modo que todos os shp gerados ficam numa mesma
coordenada.

@Sérgio, só para corrigir, percebi que o site
ftp://ftp.ibge.gov.br/Censos/Censo_Demografico_2010/Cadastro_Nacional_de_Enderecos_Fins_Estatisticos/
tem os dados por subdistrito, ou distrito na falta do primeiro, e não
por município. Isso pelo menos no caso de Santa Maria. Achei 17
arquivos referentes ao município.

@Sérgio, quando eu disse o "Jamais somente importe" direcionava o
saber para quem cai aqui na lista de paraquedas quando pesquisam na
internet. E eu digo isso também pelo fato de que os dados estão em
caixa alta, abreviados, precisam bater com os dados já existentes
(nome exato da rua, por exemplo), e inúmeros outras sujeiras, de modo
que no final das contas não creio que isso possa ser chamado de
"importação", pois será preciso analisar cada objeto minuciosamente. -
Essa ao menos foi a conclusão que eu cheguei processando os dados da
área rural de Santa Maria, que alias não terminei ainda. OBS: Nas
áreas rurais se tem as coordenadas dos objetos.

@Pedro, concordo contigo: "Acho que se focássemos em convencer
professores com e-mail e vídeos tutoriais explicativos, o resultado
para o OSM em geral seria melhor do que ficar tentando convencer as
pessoa leiga a mapear." - Só para complementar, digo que ser leigo não
seria o problema, porque quem gosta duma coisa, aprende. E mesmo essas
pessoas leigas poderiam ajudar na coleta de dados, cabendo a nós,
OpenStreetMappers, a digitalização dos dados para o OSM.

Acho que temos um certo consenso na comunidade que devemos ter um
trabalho de extensão nas comunidades e escolas. Conforme exemplos do
passado, poderia se colher muitos frutos.

@Papibaquígrafo, o problema dessa "não importação" é que os dados
ficam dispersos. Eu até concordo contigo nos argumentos, mas essa
dispersão deixa muito a desejar.

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

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

[santamariense]

@Sérgio, eu não estava acompanhando esta discussão ainda. Mas isso é
bom que vem para mostrar que a comunidade, dentro do universo
problemático de mapeamento do dia-a-dia, parece querer chegar a uma
forma consensual, rápida e útil de numeração aproximada de casas.

Eu pessoalmente preferia a versão mais rápida e não necessariamente a
mais exata, porque a ideia que tenho é em "pouco" tempo recolher
"todas" as numerações de casas de Santa Maria a campo, casa a casa.
Não é algo de outro mundo, por exemplo, esta semana creio ter
capturado cerca de 500 números de casas (+ POIs), em duas horas de
caminhada e 7km percorridos. Estou trabalhando no processamento para
então publicar.

Uma coisa que eu já fiquei ciente é que pouco adianta ficar falando do
OSM para leigos, sem saber sobre essas pessoas. Eu tento sempre
apresentar o OSM como solução de suas necessidades cotidianas. Coisas
tipo "faça uma caridade e ajude a melhorar o mapa do OSM" funciona sim
para algumas pessoas como eu, e provavelmente como vocês, caros
colegas. Mas não para as pessoas de modo geral. Então, neste contexto,
eu tenho pensado em criar mapas impressos para cada associação de
bairro fazer o levantamento de dados do local (inclusive números de
casas), e a ideia é apresentar o OSM como algo que pode fazer de fato
a diferença para a localidade. Não pensei ainda bem nos argumentos,
mas tenho já algumas ideias, como: "O mapa que vocês ajudarem a montar
poderá ser usado pelo SAMU para agilizar o socorro de pessoas pq
poderá encontrar mais rápido o endereço. A polícia poderá chegar ao
local da ocorrência com mais agilidade, o que aumentará a segurança. A
defesa civil vai poder ter estudos de áreas mais detalhados e poder
ajudar e até mesmo precaver maiores desastres. O turismo e o comercio
do local poderá ser fomentado porque o OSM ajuda a divulgar e jamais
dará destaque a uma lanchonete multinacional em detrimento da
lanchonete do zé da esquina. E assim por diante.". Em outras palavras,
o potencial do OSM é imenso, e por isso não precisamos estar "chorando
migalhas".

Sobre o CNEFE: Onde vocês acham esses dados? Eu vejo pelo
http://www.censo2010.ibge.gov.br/cnefe/ , só que por este site é
possível apenas salvar um CSV, e de apenas um setor censitário por
vez. E mesmo assim não tem coordenadas geográficas. Então como vocês
estão fazendo o processamento? Visualmente?

O CNEFE na zona rural tem coordenadas. Então fica um dica para quem
tem esse interesse. Salva o CSV no computador, abre/importa ele para o
qgis e transforma em SHP. Abre ele no JOSM, e trabalha nos dados para
trazer para o OSM muita coisa interessante, como pontos de interesse,
e até numeração de casas, tudo isso já com coordenadas. JAMAIS apenas
importe, faça uma inspeção de cada objeto, e misture com o que já
existe, sem fazer de fato uma "importação".

Só para constar, que em caso de aprovação de uma versão mais
generalizada do interpolation, não quer dizer que todos terão que
fazer assim, mas sim que fica reconhecido como forma de mapear também,
documentada, e assim aceita de fato pelos desenvolvedores que passaram
a fazê-la útil de fato.

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

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

[santamariense]

Por falar em casa da sogra Saca só isso de um usuário do maps.me
(https://www.openstreetmap.org/node/4556153195 +
https://www.openstreetmap.org/note/818057). Inúmeros novos usuários
criam um POI com acesso à internet, dão a ele o nome de "casa ~",
geralmente este POI é uma guest_house, shelter ou algo parecido
simbolicamente. Eu fico pensando se não estariam estes novos usuário
dos Maps.me, selecionando o objeto que mais pareceria uma casa/lar
para poder adicionar uma casa, sem se importar com o nome do objeto,
ou seja, sem se importar com o que ele representa de fato.

### Caiu para 32 a quantidade de eletropostos no Brasil:
http://overpass-turbo.eu/s/kFY ###

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

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

[santamariense]

@Daniel, realmente eu não sabia disso. É de deixar a gente boquiaberto
que o Google faça isso. O mundo inteiro tem trabalhado de graça para
eles então?!?!

@Pedro, realmente bem diferente daqui a regra de numeração das casas.

Enfim, eu estava pensando em criar uma addr:interpolation no eixo da
rua, sem criar outra linha (http://overpass-turbo.eu/s/kG7). Daí eu
achei alguns casos já feitos (parecidamente) assim:
1 - http://www.openstreetmap.org/way/262938121/history :: Neste caso
foi feito a linha de interpolação e mais tarde alguém a definiu como
footway também.
2 - http://www.openstreetmap.org/way/94482257 :: Este sim seria um bom
exemplo do que eu queria fazer. Porém não parece adequado, até porque
o eixo da rua fica tracejado. Então por este simples fato do
renderizador fazer isso, parece ser um procedimento não aceito.

 {{IDEIA}} {{PROPOSTA}} 

A ideia seria mais ou menos o seguinte. Adicionar o número 1 no início
da rua, medir ela até o seu final, e no final da rua colocar o valor
medido em metros. Daí seria aplicada a tag addr:interpolation=all, ou
even/odd em caso de avenidas por exemplo, ao eixo da rua. O problema
disso é que as ruas podem ser quebradas, o que pode estragar a função.
Uma ideia seria se criar um tipo de relação para isto. A relação teria
os dois pontos numerados e os vários trechos de ruas.

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

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

[santamariense]

@Gerald, o carinha que adicionou a guesthouse usou o maps.me e o
comentário "Created a clinic and a guest_house" é gerado pelo próprio
aplicativo.

@naoliv, a comunidade tá de parabéns pela celeridade em arrumar os
falsos eletropostos.

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

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

[santamariense]

Só para constar, apesar dos problemas que temos com o maps.me é
preciso dizer que ele pode ser de grande ajuda para a comunidade. Dele
pode surgir novos colaboradores ativos como nós. Hoje, por exemplo,
presenciei um novo colaborador alucinado adicionando pontos de
interesse em Cruz Alta / RS
(https://overpass-api.de/achavi/?changeset=44419776). Parece ser
edição de boa fé. Algumas caixas altas, outras marcações de POIs já
existentes em áreas. Mas isso se aprende e corrige com o tempo.

Existem atualmente 52 eletropostos mapeados no Brasil, muitos
certamente mal mapeados. 1 deles pelo próprio usuário citado em Cruz
Alta. Os postos também pode ser vistos e exportados para o JOSM pelo
overpass: http://overpass-turbo.eu/s/kFY

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

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

[santamariense]

Muitos dos comentários dos apps Maps.me e OSMAnd que vejo são sobre a
falta que faz os números para achar endereços.

Eu pessoalmente não gosto de interpolation porque se eu saio para
recolher numeração de casas eu recolho de todas as casas (e não só as
da esquina, por exemplo), mas claro que vocês devem estar falando de
faces de quadras disponíveis por órgãos públicos.

Um problema que eu vejo no CNEFE, por exemplo, é que muitos dos
setores são formados por várias quadras.

Alguém sabe se é possível criar addr:interpolation usando o próprio
eixo da via? Aqui em Santa Maria / RS o esquema de numeração é bem
simples. A numeração começa ao norte ou ao oeste, dependendo do
alinhamento das ruas. Caminhando do início da numeração ao final, a
direita se tem as casas ímpares, e a esquerda as pares.

Claro que isso é uma generalização, e isto causa muitos erros,
principalmente em ruas onde as casas não tem uma numeração lógica. E é
exatamente esse lixo que o Google Maps tem, mas que muitas pessoas
gostam e acham muito útil. Muitas vezes bate o número com a posição
das casas, mas algumas vezes pode deixar você mais perdido ainda.

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

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

[santamariense]

Aham. Existem mesmo alguns pontos de interesse com este nome :). Mas
eu creio que estava falando disto
(http://www.openstreetmap.org/node/4550835791), se não me engano,
mapeada como uma guesthouse(https://pt.wikipedia.org/wiki/Guesthouse).
Poderia existir de fato este local com este nome? Talvez... mas é
muito estranho/coincidência ele ter sido usado por um usuário novato
pelo maps.me - o problema é que eu já vi muita coisa sendo mapeada
como guesthouse por novatos.

___
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

[santamariense]

Gostaria de registrar aqui que o Gabriel entrou em contato comigo. Ele
relatou poder ter cometido alguns erros (falou de forma abrangente,
não da específica que estamos tratando aqui). Eu não insisti na
pergunta, até porque não cabe ao julgado criar provas contra si mesmo.
Procurei incentivar a permanência dele no OSM, bem como passando links
de como usar a camada do IBGE para mapear nomes de ruas (uma coisa tão
simples e que dispensa aquela consulta no tão-presente Google Maps
goela-abaixo em nossas vidas).

Ele disse ter pouco conhecimento do sistema de mensagens. E pelo o que
o @thundercel relatou de uso indevido da conta, que não teria sido
ele, é bem provável que possa ter sido outra pessoa que porventura
compartilhe o computador com ele.

Também tenho notado que ele tem excluído as coisas "indevidas". Como
este objeto (http://www.openstreetmap.org/node/4472678103/history). Só
que claro que só isso não adianta, objeto vai ser excluído da base de
dados do OSM de modo que não seja possível restaurá-lo e nem ver no
histórico que este objeto em dado momento recebeu este nome.

@naoliv, você tem entrado em contato com a comunidade internacional
sobre o caso? Formas mais práticas de revisão? Uma query no overpass
não poderia trazer os dados editados por ele para se criar uma camada
de revisão?

___
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

[santamariense]

Correto. Analisando de um ângulo diferente, não é não um spam. Eu
tinha chegado a conclusão esta depois de ver isto no GM
(https://goo.gl/CR1pqZ) de onde deduzi que seria uma imobiliária
anunciando este imóvel, e fazendo auto-promoção. A "Chácara S J T"está
mal caracterizada no GM, isto seria um espaço de eventos e não um
hotel/pousada - mas isso é problema deles.
Só que isso não explica o fato-chave de uma simples pousada/espaço se
tornar aqui no OSM o nome da cidade toda pela tag "addr:city",
coincidentemente destacada no mapa do Google.

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

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

[santamariense]

Há várias entradas errôneas no OSM de "highway=rest_area" querendo
representar uma casa/lar. Vejam isso de hoje:
https://www.openstreetmap.org/node/4553695893 +
https://www.openstreetmap.org/note/816116, inclusive com acesso a
internet. Espero que seja de graça :)

Voltando ao assunto, existe eletroposto (amenity=charging_station) no Brasil?

___
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

[santamariense]

Tudo bem @Thundercel, questiona ele. Mas não vai pensar que eu não
tentei falar com ele (assim como o @naoliv e o @Gerald Weber também
tentaram), seja pela discussão de changeset, seja por mensagem
privada. Em ambos os casos não respondidas.

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

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

[santamariense]

Sobre nome de vias públicas (ruas/estradas/...) gostaria de
compartilhar a minha experiência.

1 - Busco sempre saber se existe um nome oficial (pesquisa nas Leis
Municipais), no caso da minha cidade temos uma excelente fonte única
que é uma lei que consolidou cerca de 1,5 mil denominações
(http://www.camara-sm.rs.gov.br/camara/print_pdf/lei-ordinaria/2011/555/5558/lei-ordinaria-n-5558-2011-consolida-a-legislacao-municipal-sobre-denominacao-de-ruas).
Claro que depois dessa lei surgiram leis esparsas, daí é só questão de
acompanhar as novas leis criadas;

2 - Há casos em que a razão pode ser sim da placa. Existe uma placa
"Estr. Mun. José Santo Fighera" (provavelmente colocada pelos próprios
familiares) onde fica a família do Arroz Fighera. Quem criou a lei,
aportuguesou o nome (Estr. Mun. José Santos Figueira), talvez porque
ouviu e entendeu que fosse assim, sem tirar dúvidas em um documento
com mais calma.

3 - Há casos em que não se pode confiar em placas. Neste caso, cito a
R. Enesto Beck. Essa pessoa consta em livros de história sobre a
cidade. Mas existe uma variação muito forte do nome dele, que é
(Coronel) Ernesto Becker, seja em (algumas) placas, usado pela
prefeitura, media local e até um ponto de táxi com o nome errado (sem
falar que isso foi certamente agravado por erro de mapas conhecidos,
como o GM, porque querendo ou não as pessoas veem o nome errado lá e
passam a usá-lo - falei disso no diário certa feita:
http://www.openstreetmap.org/user/santamariense/diary/37275). No OSM,
é claro, temos os dois nomes. No IBGE tá certo o "Beck", mas tá errado
o "coronel", porque o título não aparece no nome oficial.

4 - Até onde eu sei, o IBGE não é totalmente seguro quanto nome de
ruas. Pode sim conter erros como qualquer outra fonte. Até porque há
nomes que são capturados verbalmente com moradores.

Se há variações do nome, e são de fontes lícitas, devemos colocar no
OSM todas elas. Nas mais diferentes tags name, loc_name, alt_name,
official_name, old_name,... Na tag "name" eu sempre preferia colocar o
nome oficial, mas hoje eu tenho opinião diferente, nesta tag devemos
colocar o que se acha in-loco, seja placas ou consenso de moradores.

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