Re: [Talk-br] Dúvida sobre
https://lists.openstreetmap.org/pipermail/talk-br/2014-April/007094.html Para remover a tag ref com o iD: selecione a linha, clique em Todas as etiquetas no painel à esquerda, e depois clique na lixeira ao lado de ref. Mas como eu disse na minha mensagem original, acho que a MG-424 está correta adentrando a cidade porque as rodovias são logicamente conectadas umas nas outras. Isso é prática comum em vários países, mesmo onde a velocidade é reduzida, ficando igual à do meio urbano. E por isso, a MG-238 precisa ser consertada pra passar pelo meio da cidade (é como se ela começasse um pouquinho lá na BR-040, sumisse, e reaparecesse do outro lado da cidade). E acho que o traçado dela no Google Maps está certo. 2014-04-22 2:31 GMT-03:00 Alexandre Magno Brito de Medeiros alexandre@gmail.com: Acho que entendi. O erro parece ser que a MG-424 está quase completando um balão na cidade. É lógico que ela só deveria fazer entorno por um dos lados da cidade. E está duplicada tanto num lado do balão como no outro. Alexandre Magno Em 21 de abril de 2014 20:21, Aristeu Sales aristeusa...@gmail.com escreveu: Conforme pode ser visualizado no link abaixo, a MG-424 está adentrando a cidade e continua pela Avenida Perimetral. http://www.openstreetmap.org/#map=16/-19.4812/-44.2250 Como fazer para corrigir isto? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Dúvida sobre iD e relações
Para quem usa o iD, ele está dando alguma mensagem de aviso quando a pessoa modifica ou apaga um caminho pertencente a uma relação? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Dúvida sobre iD e relações
Não, nunca deu, e eu já reclamei: https://github.com/openstreetmap/iD/issues/1461 Mas se mais gente reclamar, talvez isso ajude a convencê-los de que devem colocar esse aviso. 2014-04-22 11:05 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: Para quem usa o iD, ele está dando alguma mensagem de aviso quando a pessoa modifica ou apaga um caminho pertencente a uma relação? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Dúvida sobre iD e relações
2014-04-22 12:20 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: https://github.com/openstreetmap/iD/issues/1461 Tinha esquecido disso (e achei que já tinha sido resolvido) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Fwd: [OpenStreetMap] Re: Edições em Sete Lagoas
Trebien, Não vi documentado em nenhum lugar, só acabei chegando nessa conclusão sozinho, e já cheguei a corrigir um texto de ajuda fazendo uma modificação no wiki. Foi o amenity=fast_foodhttp://wiki.openstreetmap.org/wiki/Pt-br:Tag:amenity%3Dfast_food . Pra mim, apesar de a interface inteira estar em português, a descrição do elemento vem em inglês (mesmo tendo definido português no perfil do OSM e nas preferências de idioma do navegador). Mas isso pra qual predefinição? Pode ser que ela simplesmente não foi traduzida. (daí ele pega da descrição em inglês) Em 22 de abril de 2014 00:55, Fernando Trebien fernando.treb...@gmail.comescreveu: John, você lembra de ver documentado em algum lugar que o texto vem mesmo de Pt:ValueDescription, ou seja, do artigo com o prefixo Pt:? Pra mim, apesar de a interface inteira estar em português, a descrição do elemento vem em inglês (mesmo tendo definido português no perfil do OSM e nas preferências de idioma do navegador). 2014-04-22 0:01 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Resolvido o mistério de Sete Lagoas: http://www.openstreetmap.org/relation/314658 Foi uma exclusão acidental mesmo. Teria sido mais fácil descobrir se a relação do limite de Sete Lagoas incluísse o nó label (que eu incluí agora). Tempos atrás, eu passei pelas maiores cidades do Brasil fazendo esse ajuste. Quem sabe fazemos isso em todas? 2014-04-21 23:34 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com : Pois é, mas manter a tradução genérica vai na contramão de deixar a informação útil tão próxima quanto possível do usuário, de modo a evitar a necessidade de fazê-lo navegar pelo wiki. É melhor o usuário saber que uma primária é uma arterial urbana ou uma rodovia tipicamente com [características x, y e z] do que é uma estrada que liga as cidades grandes (é o que o wiki diz hoje), que obviamente não diz nada sobre primárias urbanas, nem sobre a hierarquia das vias, ou sobre os fatores que as tornam mais ou menos importantes, enfim. Se o debate que tivemos sobre classificação foi homérico, não será uma descrição genérica tão simples que ajudará o usuário iniciante a chegar a boas conclusões sobre como classificar as vias (e a reclassificar onde não estiver bom). Não será suficiente para ele ter alguma certeza de que a classificação atual do mapa está boa ou ruim. E daí: - ou nós vamos ter que ficar policiando todo o mundo e consertando classificações o tempo todo no país inteiro - ou algum outro Fernando Trebien vai classificar uma cidade inteira à sua maneira e só ser avisado que estava errado 3 meses depois (foi muito, muito frustrante, e teria sido muito mais se eu tivesse descoberto que existe algo como o artigo do wiki e o fluxo de classificação) 2014-04-21 23:15 GMT-03:00 John Packer john.pack...@gmail.com: Primeiro que um tradutor não terá concluído a tradução do software sem antes traduzir o wiki (e nem está a par disso pra começar) Isso até dá pra contornar traduzindo somente as descrições das etiquetas na wiki, embora não seja uma solução elegante. Creio eu que a razão porquê é feito assim é porquê daí eles não precisam adicionar uma string para cada chave ou etiqueta documentada. Por falta de tempo acabei não comentando sobre isso, mas a idéia inicial seria simplesmente tornar o campo de descrição o mais genérico possível. Não sei como podemos fazer nesse caso das vias em específico, mas devemos evitar falar algo específico do Brasil. Em 21 de abril de 2014 19:44, Fernando Trebien fernando.treb...@gmail.com escreveu: Esses caras não entendem nada de acoplamento de software né... (vou lá reclamar). Primeiro que um tradutor não terá concluído a tradução do software sem antes traduzir o wiki (e nem está a par disso pra começar), e ainda por cima qualquer edição no wiki pode afetar a interface do iD. Entramos num acordo com a comunidade portuguesa que pt-br e pt seriam fundidos no wiki mas permaneceriam separados na aplicação. Agora isso complica as coisas. 2014-04-21 16:53 GMT-03:00 John Packer john.pack...@gmail.com: Acho que vale à pena adicionar uma nota na ajuda do iD encaminhando os usuários para a página sobre classificação de vias no wiki. Isso seria feito alterando a tradução da ajuda do iD. Na verdade, até onde eu sei a nota de ajuda que o iD mostra é o campo description do template Pt:ValueDescription da página do wiki Pt-br:Tag:highway=primary. Já que há planos de fundir os wikis Pt e Pt-br, é importante deixar essa nota de ajuda o mais genérico possível (talvez pedindo para olhar a página completa do wiki), para não favorecer Brasil ou Portugal sobre o outro. Em 20 de abril de 2014 11:03, Fernando Trebien fernando.treb...@gmail.com escreveu: Pessoal, Acho que vale à pena adicionar uma nota na ajuda do iD encaminhando os usuários
Re: [Talk-br] Fw: Reverter changeset.
Pessoal, precisamos reverter este changeset de vandalismo: http://www.openstreetmap.org/changeset/21735125 Já incluí na wiki. http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Revers%C3%B5es []s Arlindo 2014-04-06 10:21 GMT-03:00 Arlindo Pereira openstreet...@arlindopereira.com : Gostaria de dizer que, dadas as condições expostas pelo Marcio, não há impedimento algum à importação dos dados no OSM. []s Arlindo Em 05/04/2014 22:10, thunder...@gpsinfo.com.br escreveu: Roger, a partir do momento que um editor de mapa é recebido no projeto ele, pelo menos para mim é digno de confiança e suas ações não devem gerar duvidas. Só deixará de ser digno de confiança a partir do momento que existirem fortes indícios de que ele cometeu algo recriminado pelo OSM. Creio que se começarmos a colocar barreiras dificilmente o projeto caminhará a passos largos no Brasil. Vamos a um exemplo prático que está ocorrendo neste momento comigo. A família de minha esposa reside em Barra de São Francisco, interior do ES, e para lá me desloco do Rio de Janeiro frequentemente. Desenhei toda essa cidade de Barra de São Francisco para o Tracksource e não empreguei imagem satélite alguma porque na ocasião que desenhei, em 2008, não existia imagem satélite com satisfatória resolução na área. Sendo uma pequena cidade, de aproximadamente 70 mil habitantes, fiquei circulando pelas ruas dela levantando tracklogs com meu gps e os nomes das ruas. Dessa forma desenhei o arruamento de todas a cidade e tenho esse mapa aqui comigo. Quando ingressei no OSM identifiquei que essa cidade de Barra de São Francisco tinha poucas ruas desenhadas no mapa OSM, sem nomes e a rodovia que corta a cidade estava errada. Não é o caso, mas os dados existentes no mapa OSM ali eram pouco aproveitáveis. Mesmo assim e até por não saber fazer, deixei de efetuar o “changeset” e decidi iniciar manualmente o desenho não importei o mapa que desenho daquela cidade pela segunda vez. Ainda não terminei. Ainda pouco consultei Guararema, próximo a Barra de São Francisco, mas distrito de Águia Branca – ES. Para lá também me desloco com certa frequência e quem desejar verificar existem tracklogs por mim levantados e arquivados na base OSM. De inicio identifiquei que no mapa OSM não existiam dados da rodovia ES-381 por mim desenhada para o Tracksource. Essa rodovia foi asfaltada em 2012 e liga Águia Branca a Nova Venécia, ambas do ES. Mesmo tendo aqui comigo toda essa rodovia desenhada decidi mais uma vez fazer na mão o desenho no OSM, sem importar para ele os dados. Ainda estou desenhando a rodovia e já subi um grande trecho dela, entretanto para minha surpresa identifico no entroncamento dela com a rodovia ES-137 um pequeno desenho feito há 2 anos pelo Skippern . Vide https://www.openstreetmap.org/way/152419115#map=18/-18.76660/-40.47218 Aquele entroncamento está muito diferente do que foi desenhado e o que me espanta é que desenho semelhante e com erro se encontra no Google Maps. Será que ele se valeu dessa ferramenta Google? Não sei e confesso que em principio, sendo ele um elemento experiente no OSM, não agiria dessa forma copiando o Google. Além de desenhar a rodovia irei corrigir esse entroncamento manualmente. O entroncamento do outro lado, com a ES-080 acabei de desenhar já que também não existia no mapa. Vide https://www.openstreetmap.org/way/272190586 Desculpem o imenso post, mas é importante esse exemplo de área onde não existem dados no OSM e os poucos existentes estão incorretos e não refletem a realidade. []s Marcio *From:* Roger C. Soares rogersoa...@gmail.com *Sent:* Saturday, April 5, 2014 9:23 PM *To:* OpenStreetMap no Brasil talk-br@openstreetmap.org *Subject:* Re: [Talk-br] Fw: Reverter changeset. Se a área está vazia é um complicador a menos. Eu não vejo problema em você incluir seus dados lá. Porém a legalidade dos dados pode gerar dúvidas. É melhor você descrever como gerou os dados, as fontes utilizadas e mais algumas outras perguntas que o pessoal da lista fizer, inclusive para deixar documentado, caso alguém no futuro levante dúvidas sobre o changeset. Se fosse eu, só por garantia, comentaria na lista a intenção de subir os dados, pediria alguma recomendação e para alguém revisar o changeset antes de subir. Principalmente nas primeiras vezes, o pessoal da lista vira e mexe levanta pontos que eu nunca teria imaginado sozinho... Atenciosamente, Roger. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Fwd: [OpenStreetMap] Re: Edições em Sete Lagoas
Ah, e pra complementar: o taginfo também faz o mesmo que o editor iD (pegar uma descrição da chave ou etiqueta no wiki a partir do *locale*). Isso já estava sendo levado em consideração, que precisaríamos entrar em contato com esses desenvolvedores para consertar isso. O JOSM também precisaria consertar os seus *links* para as páginas do wiki das chaves/etiquetas. (agora não tenho certeza se ele leva em consideração o *locale* ou não, mas vou confirmar isto quando puder) Suponho que o iD e o taginfo fazem isso simplesmente para economizar trabalho dos tradutores de interface. Em 22 de abril de 2014 14:48, John Packer john.pack...@gmail.com escreveu: Trebien, Não vi documentado em nenhum lugar, só acabei chegando nessa conclusão sozinho, e já cheguei a corrigir um texto de ajuda fazendo uma modificação no wiki. Foi o amenity=fast_foodhttp://wiki.openstreetmap.org/wiki/Pt-br:Tag:amenity%3Dfast_food . Pra mim, apesar de a interface inteira estar em português, a descrição do elemento vem em inglês (mesmo tendo definido português no perfil do OSM e nas preferências de idioma do navegador). Mas isso pra qual predefinição? Pode ser que ela simplesmente não foi traduzida. (daí ele pega da descrição em inglês) Em 22 de abril de 2014 00:55, Fernando Trebien fernando.treb...@gmail.com escreveu: John, você lembra de ver documentado em algum lugar que o texto vem mesmo de Pt:ValueDescription, ou seja, do artigo com o prefixo Pt:? Pra mim, apesar de a interface inteira estar em português, a descrição do elemento vem em inglês (mesmo tendo definido português no perfil do OSM e nas preferências de idioma do navegador). 2014-04-22 0:01 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Resolvido o mistério de Sete Lagoas: http://www.openstreetmap.org/relation/314658 Foi uma exclusão acidental mesmo. Teria sido mais fácil descobrir se a relação do limite de Sete Lagoas incluísse o nó label (que eu incluí agora). Tempos atrás, eu passei pelas maiores cidades do Brasil fazendo esse ajuste. Quem sabe fazemos isso em todas? 2014-04-21 23:34 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com : Pois é, mas manter a tradução genérica vai na contramão de deixar a informação útil tão próxima quanto possível do usuário, de modo a evitar a necessidade de fazê-lo navegar pelo wiki. É melhor o usuário saber que uma primária é uma arterial urbana ou uma rodovia tipicamente com [características x, y e z] do que é uma estrada que liga as cidades grandes (é o que o wiki diz hoje), que obviamente não diz nada sobre primárias urbanas, nem sobre a hierarquia das vias, ou sobre os fatores que as tornam mais ou menos importantes, enfim. Se o debate que tivemos sobre classificação foi homérico, não será uma descrição genérica tão simples que ajudará o usuário iniciante a chegar a boas conclusões sobre como classificar as vias (e a reclassificar onde não estiver bom). Não será suficiente para ele ter alguma certeza de que a classificação atual do mapa está boa ou ruim. E daí: - ou nós vamos ter que ficar policiando todo o mundo e consertando classificações o tempo todo no país inteiro - ou algum outro Fernando Trebien vai classificar uma cidade inteira à sua maneira e só ser avisado que estava errado 3 meses depois (foi muito, muito frustrante, e teria sido muito mais se eu tivesse descoberto que existe algo como o artigo do wiki e o fluxo de classificação) 2014-04-21 23:15 GMT-03:00 John Packer john.pack...@gmail.com: Primeiro que um tradutor não terá concluído a tradução do software sem antes traduzir o wiki (e nem está a par disso pra começar) Isso até dá pra contornar traduzindo somente as descrições das etiquetas na wiki, embora não seja uma solução elegante. Creio eu que a razão porquê é feito assim é porquê daí eles não precisam adicionar uma string para cada chave ou etiqueta documentada. Por falta de tempo acabei não comentando sobre isso, mas a idéia inicial seria simplesmente tornar o campo de descrição o mais genérico possível. Não sei como podemos fazer nesse caso das vias em específico, mas devemos evitar falar algo específico do Brasil. Em 21 de abril de 2014 19:44, Fernando Trebien fernando.treb...@gmail.com escreveu: Esses caras não entendem nada de acoplamento de software né... (vou lá reclamar). Primeiro que um tradutor não terá concluído a tradução do software sem antes traduzir o wiki (e nem está a par disso pra começar), e ainda por cima qualquer edição no wiki pode afetar a interface do iD. Entramos num acordo com a comunidade portuguesa que pt-br e pt seriam fundidos no wiki mas permaneceriam separados na aplicação. Agora isso complica as coisas. 2014-04-21 16:53 GMT-03:00 John Packer john.pack...@gmail.com: Acho que vale à pena adicionar uma nota na ajuda do iD encaminhando os usuários para a página sobre classificação de vias no
Re: [Talk-br] Fw: Reverter changeset.
2014-04-22 14:57 GMT-03:00 Arlindo Pereira openstreet...@arlindopereira.com: precisamos reverter este changeset de vandalismo: http://www.openstreetmap.org/changeset/21735125 Eu reverto. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Fw: Reverter changeset.
Valeu naoliv! []s On Tue, Apr 22, 2014 at 3:03 PM, Nelson A. de Oliveira nao...@gmail.comwrote: 2014-04-22 14:57 GMT-03:00 Arlindo Pereira openstreet...@arlindopereira.com: precisamos reverter este changeset de vandalismo: http://www.openstreetmap.org/changeset/21735125 Eu reverto. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Fwd: [OpenStreetMap] Re: Edições em Sete Lagoas
Bem, assim: - se não juntarmos os prefixos pt-br e pt, temos a liberdade de adotar uma descrição menos genérica no wiki - se juntarmos, teremos que conversar com os portugueses pra ver o que eles querem, apresentar os prós e os contras, etc. Outro problema de se basear no locale é que o locale da maioria dos brasileiros é pt-br (browser E configuração do perfil do usuário no site). Acho possível mas pouco provável que as aplicações selecionem automaticamente a descrição no artigo pt caso o artigo pt-br não exista no wiki. Uma solução seria manter redirects de pt-br para pt, mas a aplicação pode não segui-los. 2014-04-22 15:01 GMT-03:00 John Packer john.pack...@gmail.com: Ah, e pra complementar: o taginfo também faz o mesmo que o editor iD (pegar uma descrição da chave ou etiqueta no wiki a partir do locale). Isso já estava sendo levado em consideração, que precisaríamos entrar em contato com esses desenvolvedores para consertar isso. O JOSM também precisaria consertar os seus links para as páginas do wiki das chaves/etiquetas. (agora não tenho certeza se ele leva em consideração o locale ou não, mas vou confirmar isto quando puder) Suponho que o iD e o taginfo fazem isso simplesmente para economizar trabalho dos tradutores de interface. Em 22 de abril de 2014 14:48, John Packer john.pack...@gmail.com escreveu: Trebien, Não vi documentado em nenhum lugar, só acabei chegando nessa conclusão sozinho, e já cheguei a corrigir um texto de ajuda fazendo uma modificação no wiki. Foi o amenity=fast_food. Pra mim, apesar de a interface inteira estar em português, a descrição do elemento vem em inglês (mesmo tendo definido português no perfil do OSM e nas preferências de idioma do navegador). Mas isso pra qual predefinição? Pode ser que ela simplesmente não foi traduzida. (daí ele pega da descrição em inglês) Em 22 de abril de 2014 00:55, Fernando Trebien fernando.treb...@gmail.com escreveu: John, você lembra de ver documentado em algum lugar que o texto vem mesmo de Pt:ValueDescription, ou seja, do artigo com o prefixo Pt:? Pra mim, apesar de a interface inteira estar em português, a descrição do elemento vem em inglês (mesmo tendo definido português no perfil do OSM e nas preferências de idioma do navegador). 2014-04-22 0:01 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Resolvido o mistério de Sete Lagoas: http://www.openstreetmap.org/relation/314658 Foi uma exclusão acidental mesmo. Teria sido mais fácil descobrir se a relação do limite de Sete Lagoas incluísse o nó label (que eu incluí agora). Tempos atrás, eu passei pelas maiores cidades do Brasil fazendo esse ajuste. Quem sabe fazemos isso em todas? 2014-04-21 23:34 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Pois é, mas manter a tradução genérica vai na contramão de deixar a informação útil tão próxima quanto possível do usuário, de modo a evitar a necessidade de fazê-lo navegar pelo wiki. É melhor o usuário saber que uma primária é uma arterial urbana ou uma rodovia tipicamente com [características x, y e z] do que é uma estrada que liga as cidades grandes (é o que o wiki diz hoje), que obviamente não diz nada sobre primárias urbanas, nem sobre a hierarquia das vias, ou sobre os fatores que as tornam mais ou menos importantes, enfim. Se o debate que tivemos sobre classificação foi homérico, não será uma descrição genérica tão simples que ajudará o usuário iniciante a chegar a boas conclusões sobre como classificar as vias (e a reclassificar onde não estiver bom). Não será suficiente para ele ter alguma certeza de que a classificação atual do mapa está boa ou ruim. E daí: - ou nós vamos ter que ficar policiando todo o mundo e consertando classificações o tempo todo no país inteiro - ou algum outro Fernando Trebien vai classificar uma cidade inteira à sua maneira e só ser avisado que estava errado 3 meses depois (foi muito, muito frustrante, e teria sido muito mais se eu tivesse descoberto que existe algo como o artigo do wiki e o fluxo de classificação) 2014-04-21 23:15 GMT-03:00 John Packer john.pack...@gmail.com: Primeiro que um tradutor não terá concluído a tradução do software sem antes traduzir o wiki (e nem está a par disso pra começar) Isso até dá pra contornar traduzindo somente as descrições das etiquetas na wiki, embora não seja uma solução elegante. Creio eu que a razão porquê é feito assim é porquê daí eles não precisam adicionar uma string para cada chave ou etiqueta documentada. Por falta de tempo acabei não comentando sobre isso, mas a idéia inicial seria simplesmente tornar o campo de descrição o mais genérico possível. Não sei como podemos fazer nesse caso das vias em específico, mas devemos evitar falar algo específico do Brasil. Em 21 de abril de 2014 19:44, Fernando Trebien fernando.treb...@gmail.com escreveu: Esses caras não entendem nada de acoplamento
[Talk-br] Reverter objeto para versão anterior
Opa pessoal, alguém aí pode reverter este objeto para a versão anterior? http://www.openstreetmap.org/way/241923266 O usuário transformou a quadra em circulo, eu mandei mensagem no mesmo dia mas ele não respondeu. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Reverter objeto para versão anterior
2014-04-22 16:04 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Opa pessoal, alguém aí pode reverter este objeto para a versão anterior? http://www.openstreetmap.org/way/241923266 Eu vejo esse também. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Reverter objeto para versão anterior
Vlw Em 22/04/2014 16:07, Nelson A. de Oliveira nao...@gmail.com escreveu: 2014-04-22 16:04 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Opa pessoal, alguém aí pode reverter este objeto para a versão anterior? http://www.openstreetmap.org/way/241923266 Eu vejo esse também. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Exemplo de visualização 3D com dados do OSM
Pessoal, terminei transformação dos dados do CNEFE para ficar com uma base de número de andares por edifício (na verdade por bloco) para o bairro de vista alegre. Está aqui: https://www.dropbox.com/s/6qycg6ifammbihu/CNEFE2010_altura_edificos_VISTA_ALEGRE_Rio_de_Janeiro_RJ.xls Demorou um pouco porque tive que dar um hipon nos dados (normalizar por bloco e agregar, hipóteses sobre a numeração de números de apartamento baixo) mas agora saiu. Arlindo, dá uma olhada para ver se as coisas fazem sentido na sua área. Só tratei dos casos em que o CNEFE diz que há apartamentos, e mais de um, em cada endereço. Agora que já tá feito, basta rodar o script para o Brasil todo ou qualquer outra subivisão (municípios, distrito, subdistrito, etc). Se alguém quiser para sua área me peça. Detalhes: Ao fazer isso tive que fazer umas hipóteses sobre como os apartamentos são numerados nos edifícios; Alguém sabe se existe uma regra, ou pelo menos um padrão comummente aplicado para numeração de apartamento de certo prédio/bloco? Os edifícios começam sempre no térreo, e o andar imediatamente acima é o 1o? Na maioria dos casos é isso que tenho encontrado, mas há casos em que a numeração dos apartamentos está começando no 201, ..., Nestes casos posso considerar que o 1o andar seria o térreo (que não tem apartamentos)? Em geral os endereços na base são do tipo 101, 102, 103, 201, 202, 203, etc.. Há também uns poucos casos com 101 b, em que ignorei o b. A regra que apliquei foi: a) se os números dos apartamentos tem 3 ou 4 dígitos, e o antepenúltimo número é zero em todos os apartamentos do bloco, então tenho certeza que a centena (ou do milhar+centena) denota o andar. b) caso contrário (números de 3 ou 4 dígitos mas um dos penúltimos número não é zero), então é necessário um procedimento mais complicado. Por exemplo, o número de apartamento 111. A dúvida é se se trata de o apartamento 11 do 1o andar ou do apartamento 1 do 11o andar (tenho uma tia que mora num apartamento 111, e se trata do 1o andar) Neste caso a estratégia é: suponha que o algarismo da dezena (ou da dezena e do milhar) seja o andar. Verifique se há um número constate de apartamentos por andar ( identificados pelos dígitos das dezenas e unidades, e/ou pelo número de linhas daquele andar na base) Lucas 2014-04-22 0:18 GMT-03:00 Alexandre Magno Brito de Medeiros alexandre@gmail.com: Alguém sabe dizer se e como é possível modelar esta caixa d'águahttp://goo.gl/maps/9ul5d ? Alexandre Magno Em 13 de abril de 2014 10:24, Paulo Carvalho paulo.r.m.carva...@gmail.com escreveu: Legal isso! Os prédios que mapeei ficaram ótimos: http://demo.f4map.com/#lat=-23.0017312lon=-43.3906494zoom=17camera.phi=35.753 As duas escadinhas são minha tentativa de reproduzir o condomínio Sundeck: [image: Imagem inline 1] ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Exemplo de visualização 3D com dados do OSM
Alexandre, Dê uma olhada em building:part e min_level ou min_height, usando de dois polígonos para montar isso. Um problema é que uma caixa d'agua não se encaixa exatamente com building=*, mas se for um ponto de referência relativamente bom, não vejo porquê não adicionar. Acho que não tem como fazer essa inclinação de baixo pra cima, mas não é um problema, já que o principal objetivo dessas informações 3D é pra ter uma visualização 2.5D (ou seja, ver as construções com o mapa 2D, de cima, mas com um certo relevo). Em 22 de abril de 2014 00:18, Alexandre Magno Brito de Medeiros alexandre@gmail.com escreveu: Alguém sabe dizer se e como é possível modelar esta caixa d'águahttp://goo.gl/maps/9ul5d ? Alexandre Magno Em 13 de abril de 2014 10:24, Paulo Carvalho paulo.r.m.carva...@gmail.com escreveu: Legal isso! Os prédios que mapeei ficaram ótimos: http://demo.f4map.com/#lat=-23.0017312lon=-43.3906494zoom=17camera.phi=35.753 As duas escadinhas são minha tentativa de reproduzir o condomínio Sundeck: [image: Imagem inline 1] ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Exemplo de visualização 3D com dados do OSM
Beleza Lucas, obrigado pelo trabalho! Assim que tiver um tempinho vou aplicar a edição aos edifícios mapeados no bairro e mapear os restantes para que possamos testar. Me parece que a numeração dos andares se dá sempre com as dezenas reservadas para o apartamento e centenas para os andares. Por exemplo, o número 111 necessariamente denotaria o décimo primeiro apartamento no primeiro andar - o do décimo primeiro andar seria 1101 (ou ). Isto posto, acho que não há regra para essa numeração. Por exemplo, no prédio em que moro, o térreo é o primeiro andar, com um apartamento (101) e o andar seguinte já é o segundo (201, 202, 203). Por outro lado, edifícios maiores, com garagem, playground etc. geralmente tem o térreo como T ou 0 e o primeiro andar (que não é necessariamente contíguo ao térreo) é denotado por 1. Acho que podemos ignorar isso e assumir a quantidade de andares indicada expressamente pelo CNEFE (se vai até o apartamento 40X, tem 4 andares), por que nunca teremos como saber quantos andares além dos andares de apartamento existem sem visitar o apartamento em questão. Penso ainda que se essa informação vai na tag building:levels, devemos usar source:building:levels = CNEFE. []s Arlindo 2014-04-22 16:52 GMT-03:00 Lucas Ferreira Mation lucasmat...@gmail.com: Pessoal, terminei transformação dos dados do CNEFE para ficar com uma base de número de andares por edifício (na verdade por bloco) para o bairro de vista alegre. Está aqui: https://www.dropbox.com/s/6qycg6ifammbihu/CNEFE2010_altura_edificos_VISTA_ALEGRE_Rio_de_Janeiro_RJ.xls Demorou um pouco porque tive que dar um hipon nos dados (normalizar por bloco e agregar, hipóteses sobre a numeração de números de apartamento baixo) mas agora saiu. Arlindo, dá uma olhada para ver se as coisas fazem sentido na sua área. Só tratei dos casos em que o CNEFE diz que há apartamentos, e mais de um, em cada endereço. Agora que já tá feito, basta rodar o script para o Brasil todo ou qualquer outra subivisão (municípios, distrito, subdistrito, etc). Se alguém quiser para sua área me peça. Detalhes: Ao fazer isso tive que fazer umas hipóteses sobre como os apartamentos são numerados nos edifícios; Alguém sabe se existe uma regra, ou pelo menos um padrão comummente aplicado para numeração de apartamento de certo prédio/bloco? Os edifícios começam sempre no térreo, e o andar imediatamente acima é o 1o? Na maioria dos casos é isso que tenho encontrado, mas há casos em que a numeração dos apartamentos está começando no 201, ..., Nestes casos posso considerar que o 1o andar seria o térreo (que não tem apartamentos)? Em geral os endereços na base são do tipo 101, 102, 103, 201, 202, 203, etc.. Há também uns poucos casos com 101 b, em que ignorei o b. A regra que apliquei foi: a) se os números dos apartamentos tem 3 ou 4 dígitos, e o antepenúltimo número é zero em todos os apartamentos do bloco, então tenho certeza que a centena (ou do milhar+centena) denota o andar. b) caso contrário (números de 3 ou 4 dígitos mas um dos penúltimos número não é zero), então é necessário um procedimento mais complicado. Por exemplo, o número de apartamento 111. A dúvida é se se trata de o apartamento 11 do 1o andar ou do apartamento 1 do 11o andar (tenho uma tia que mora num apartamento 111, e se trata do 1o andar) Neste caso a estratégia é: suponha que o algarismo da dezena (ou da dezena e do milhar) seja o andar. Verifique se há um número constate de apartamentos por andar ( identificados pelos dígitos das dezenas e unidades, e/ou pelo número de linhas daquele andar na base) Lucas 2014-04-22 0:18 GMT-03:00 Alexandre Magno Brito de Medeiros alexandre@gmail.com: Alguém sabe dizer se e como é possível modelar esta caixa d'águahttp://goo.gl/maps/9ul5d ? Alexandre Magno Em 13 de abril de 2014 10:24, Paulo Carvalho paulo.r.m.carva...@gmail.com escreveu: Legal isso! Os prédios que mapeei ficaram ótimos: http://demo.f4map.com/#lat=-23.0017312lon=-43.3906494zoom=17camera.phi=35.753 As duas escadinhas são minha tentativa de reproduzir o condomínio Sundeck: [image: Imagem inline 1] ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Exemplo de visualização 3D com dados do OSM
Não é source:building:levels=IBGE? Alexandre Magno Em 22 de abril de 2014 17:14, Arlindo Pereira openstreet...@arlindopereira.com escreveu: Acho que podemos ignorar isso e assumir a quantidade de andares indicada expressamente pelo CNEFE (se vai até o apartamento 40X, tem 4 andares), por que nunca teremos como saber quantos andares além dos andares de apartamento existem sem visitar o apartamento em questão. Penso ainda que se essa informação vai na tag building:levels, devemos usar source:building:levels = CNEFE. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Exemplo de visualização 3D com dados do OSM
Ops, exatamente isso. 2014-04-22 17:18 GMT-03:00 Alexandre Magno Brito de Medeiros alexandre@gmail.com: Não é source:building:levels=IBGE? Alexandre Magno Em 22 de abril de 2014 17:14, Arlindo Pereira openstreet...@arlindopereira.com escreveu: Acho que podemos ignorar isso e assumir a quantidade de andares indicada expressamente pelo CNEFE (se vai até o apartamento 40X, tem 4 andares), por que nunca teremos como saber quantos andares além dos andares de apartamento existem sem visitar o apartamento em questão. Penso ainda que se essa informação vai na tag building:levels, devemos usar source:building:levels = CNEFE. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
