Re: [Talk-br] Excesso de tertiary em Porto Alegre
Tá lá no primeiro post da discussão no fórum, onde diz Arquivos de grafo: http://forum.openstreetmap.org/viewtopic.php?id=21275 Talvez seja melhor colocar ele diretamente no wiki. Vou fazer isso, daí referencio o wiki a partir do fórum. 2013/8/23 Felipe G. Nievinski fgnievin...@gmail.com: Trebien, teria como você disponibilizar o SVG do diagrama de classificação? http://wiki.openstreetmap.org/wiki/File:Br-classification-flowchart-pt.png Que sw vc usou para desenhá-lo? Abc, -F. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Excesso de tertiary em Porto Alegre
Flávio, você deveria ter lido toda a discussão original, mensagem por mensagem. Volto à questão central dela: como se define importância? Como se define o que é via de escoamento? Você tem uma fonte oficial que liste quais ruas são o quê? Ou a importância é uma impressão subjetiva sua? O fluxograma foi feito para usar critérios objetivos. Então, defina essas coisas. Sem isso eu não tenho muito como argumentar contra ou à favor, apenas filosofar à respeito (e não estou aqui pra isso ;D). 2013/8/23 Flavio Bello Fialho bello.fla...@gmail.com: Não é para me agradar. É para o mapa ficar melhor. No fluxograma, o problema todo está naquela parte mais de baixo, dentro da linha pontilhada. Como para primary funcionou bem, podemos usar algo semelhante. Especificamente: A pergunta arterial direciona para primary se a resposta for S e para a pergunta área residencial se a resposta for N. Entre as duas perguntas, podem ser colocadas as perguntas para definir se uma via é secondary ou tertiary. Algo do tipo: arterial? ---S--- primary ---N--- via importante de ligação entre bairros? ---S--- secondary ---N--- via importante de escoamento do bairro? ---S--- tertiary ---N--- área residencial? ---S--- residential ---N--- unclassified (a pergunta pode ser diferente, mas a idéia é essa) Em 23 de agosto de 2013 15:53, Felipe G. Nievinski fgnievin...@gmail.com escreveu: Entendo que você não gostou, mas ainda não entendo o que você suger[e] que se mude [n]a forma de definição de secondary e tertiary. Digamos que eu estivesse disposto a corrigir a classificação das ruas para agradá-lo, como deveria fazê-lo? -F. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Excesso de tertiary em Porto Alegre
E se você tiver uma idéia melhor de classificar (algo que não deixe dúvidas ao tomar a decisão de classificação, algo que duas pessoas com cabeças totalmente diferentes possam usar para chegar a uma classificação coerente, sem divergências), por favor proponha. Se for melhor do que o que temos, alteraremos, no fluxograma e no mapa, eu prometo. :D Só precisa nos convencer, considerando todo o contexto anterior da discussão. Usar critérios objetivos (mensuráveis) tem um propósito: evitar discussões por picuinhas, sobre cada pedaço de metro quadrado do mapa, sobre cada rua individual. Ah, e você também não disse de que forma o mapa ficaria melhor segundo a sua proposta de classificação. Melhor em que aspecto? Melhor para quem? Se for melhor no desenho, lembro: não mapear para o renderizador. É o princípio mais reiterado aqui na comunidade e pela comunidade internacional. O mapa é de todos e para todos, não é nem meu, nem seu. Se fosse por mim, faria várias coisas diferentes do que faço hoje, mas me moldo às decisões da comunidade. É mera coincidência o fato de ter estimulado a discussão (e de tê-la influenciado, mas não tê-la determinado - não tenho esse poder, nem acho justo tê-lo). 2013/8/23 Fernando Trebien fernando.treb...@gmail.com: Flávio, você deveria ter lido toda a discussão original, mensagem por mensagem. Volto à questão central dela: como se define importância? Como se define o que é via de escoamento? Você tem uma fonte oficial que liste quais ruas são o quê? Ou a importância é uma impressão subjetiva sua? O fluxograma foi feito para usar critérios objetivos. Então, defina essas coisas. Sem isso eu não tenho muito como argumentar contra ou à favor, apenas filosofar à respeito (e não estou aqui pra isso ;D). 2013/8/23 Flavio Bello Fialho bello.fla...@gmail.com: Não é para me agradar. É para o mapa ficar melhor. No fluxograma, o problema todo está naquela parte mais de baixo, dentro da linha pontilhada. Como para primary funcionou bem, podemos usar algo semelhante. Especificamente: A pergunta arterial direciona para primary se a resposta for S e para a pergunta área residencial se a resposta for N. Entre as duas perguntas, podem ser colocadas as perguntas para definir se uma via é secondary ou tertiary. Algo do tipo: arterial? ---S--- primary ---N--- via importante de ligação entre bairros? ---S--- secondary ---N--- via importante de escoamento do bairro? ---S--- tertiary ---N--- área residencial? ---S--- residential ---N--- unclassified (a pergunta pode ser diferente, mas a idéia é essa) Em 23 de agosto de 2013 15:53, Felipe G. Nievinski fgnievin...@gmail.com escreveu: Entendo que você não gostou, mas ainda não entendo o que você suger[e] que se mude [n]a forma de definição de secondary e tertiary. Digamos que eu estivesse disposto a corrigir a classificação das ruas para agradá-lo, como deveria fazê-lo? -F. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] OSM e TrackSource
seria até para a proteção do próprio usuário novato (e bem intecionado) que se sentiria mais seguro para fazer edições sabendo que não vai causar estragos por desconhecimento. 4) Estabelecer uma lista de tags source, e obrigar a escolher uma delas. Ou seja, deveria ser impossível salvar qualquer dado sem source. Se nenhuma das opções pré-existentes atende, abre-se a discussão e registra-se novas opções de origem de dados. Imagine o seguinte: chega o usuário novo e pega uma coisa do Google e tenta colocar na base, aí ele é obrigado a escolher uma source pré-definida e não aparece Google, no mínimo vai desconfiar, não vai? Quantos usuários já colocaram dados do Google na melhor das intenções, até colocam source=Google? Ou seja, ou é isto, ou então se aceita que a base de dados do OSM será uma eterna colcha de retalhos de dados que vieram sabe-se lá de onde, e aceita-se que os dados do OSM não são confiáveis já que em qualquer momento alguém pode vir e apagar uma relação crucial ou apagar ou introduzir dados falsos. É uma questão que o OSM vai ter que tratar se quiser sobreviver e não cair na irrelevância. A wikipedia custou mas teve de fazer isto e não vejo como nós podemos continuar sendo cegos para o problema. abraços Gerald ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] OSM e TrackSource
Falando em moderação/monitoração de alterações, acabei de descobrir outro sistema para monitorar alterações: http://owl.apis.dev.openstreetmap.org/ Ainda está em beta, mas é mais fácil de usar que o OSM History Viewer. 2013/8/23 Fernando Trebien fernando.treb...@gmail.com: Eu concordo com 97% do que disseste, Gerald, e com os outros 3% eu não tenho uma posição muito clara ainda. Acho - e creio que poderíamos solicitar à comunidade internacional - que aquele recurso do OSM History Viewer deva ser algo integrado na interface web do OSM. Ou seja, ao clicar num changeset, você precisa de uma forma gráfica de comparar o antes e o depois, que realce o que foi alterado. Era muito prático, quando estava no ar, e não está mais. Quanto ao TrackSource, também tenho uma certa inveja (no sentido de saber que não vai dar em nada), mas na verdade isso é algo que é impossível de prever. Eu disse esses dias que a gestão do Google pode mudar a qualquer momento, e provavelmente eles fariam uma caça às bruxas caso começassem a perder o mercado de mapas (caso o OSM fique mais popular, algo que tende a acontecer a longo prazo na minha opinião). Então, sim, rola uma inveja, mas o OSM veio pra ficar, e o TrackSource, bem (sem ofensas) mas estão com uma briga de egos nesse momento, tendo que lidar com uma administração meio linha-dura. Aqui no OSM eles podem mapear coisas que nunca sonharam em mapear no TrackSource (talvez não tenham interesse? ou talvez sim), mas a liberdade tem um custo. Concordo que os usuários não deveriam ser tão anônimos. A Wikipédia tem um sistema de moderação, e sei que o OSM na Alemanha (talvez também em outros países) tem o mesmo (mas não é integrado no sistema). Talvez devamos descobrir como eles fazem e nos organizar da mesma forma. Ainda assim, moderação é algo muito... complicado. Há casos de moderadores na Wikipédia que moderam demais, outros que moderam de menos. Temos que pensar em como estruturar esse sistema pra não ficar tão rígido quanto é no TrackSource (e acabar com as mesmas desavenças). A qualidade dos dados do OSM é, desde o princípio, a mesma qualidade que os dados da Wikipédia. Ou seja, sem garantias. Você confia que a maior parte das pessoas que se dispôs a editar tinham uma boa intenção. Você confia que elas produzirão um resultado bom se a ferramenta de edição for boa, se houver informação na internet (no wiki, por exemplo) que ajude a resolver as dúvidas, etc. (Foi por isso que eu parei a minha importação de rotas de ônibus em PoA, porque a tradução do iD é extremamente importante, tem impacto direto na qualidade do mapa. Existem até textos explicativos no iD que poderíamos modificar para dar instruções que valem aqui no Brasil, e talvez até instruções melhores que as originais em inglês.) Então sim, você confia que o OSM é uma colcha de retalhos, em que cada pedaço foi costurado por uma pessoa diferente. Nossa premissa é que as ferramentas melhorarão e as comunidades crescerão a ponto de se formar uma cultura que uniformize os problemas locais ao longo do tempo. É uma colcha de retalhos que, a cada dia que passa, parece mais e mais com uma colcha inteira. Poderíamos solicitar aos criadores do iD e do Potlatch que preenchessem a tag source com o texto Bing (ou survey se estiver importando de um tracklog). Talvez até o JOSM poderia preencher essa tag automaticamente em alguns casos. Agora impossível salvar os dados sem source... não sei se ia funcionar. A API é muito livre - muito mesmo. Há gente que se opõe que essa tag seja preenchida em importações e que seja na verdade uma tag do changeset (foi o que me disseram quando eu preparava os aglomerados subnormais). Então, o que eu apoio: sistema de visualização gráfica de changesets, sistema de moderação. Ah sim, e também concordo que a pessoa teria que ser associada à lista de e-mails pra que tirasse as suas dúvidas. Podemos requisitar tudo isso, eu acho. Só não sei se vão nos atender pra amanhã, e talvez nos digam tá aqui o código-fonte, façam, mostrem que funciona, se gostarmos colocamos no ar no nosso servidor. 2013/8/23 Gerald Weber gwebe...@gmail.com: Prezado Vitor assim como você eu prezo a liberdade e a informalidade. Do contrário não participaria do OSM. 2013/8/23 Vitor George vitor.geo...@gmail.com Sobre a identificação dos usuários, não há descaso. O que há é que o OpenStreetMap tem uma cultura anti-burocrática, muito diferente do que estamos acostumados. Discordo. O descontrole é completo, já que os usuário são anônimos. Desculpa, mas cultura anti-burocrática é uma coisa, descontrole total é outra. Eu simplesmente não vejo como conciliar total controle dos dados com total descontrole dos usuários. Para se abrir uma empresa no Brasil, por exemplo, são exigidos vários documentos e procedimentos, o que toma muito tempo (e dinheiro). Esta burocracia, criada na maior das boas intenções, no final das contas não garante que
Re: [Talk-br] Excesso de tertiary em Porto Alegre
Se alguém quiser reler a discussão na comunidade brasileira desde o começo, eis o link da primeira das mais de 150 mensagens (pode-se navegar por elas no final da página): http://www.mail-archive.com/talk-br@openstreetmap.org/msg03108.html Defina escoamento do bairro e eu começarei a achar que é objetivo. Pra mim, todas as vias servem para escoamento de um lugar para outro. A idéia original de que as vias formam uma sequência de preferência de tráfego (motorways têm prefência sobre trunks, que têm preferência sobre primaries, que têm preferência sobre secondaries, etc.) está esboçada nesse texto antigo do wiki: http://wiki.openstreetmap.org/wiki/Pt-br:How_to_map_a#Classifica.C3.A7.C3.A3o_de_vias_.28obsoleto.2C_substitu.C3.ADdo_pelo_fluxograma.29 Que foi inspirada em discussões da comunidade internacional, cujos links eu não guardei (não achei que seria necessário, agora vejo que devia). Preferencial (ou prioritária, como costumam chamar em inglês) é a via que tem preferência de passagem. Essa via é identificada pela presença de placas-pare nas suas transversais. É um termo de uso corrente e comum. Se você chegar num cruzamento e estiver na preferencial, não precisa parar. Caso contrário, precisa. Parar no cruzamento afeta a velocidade média sobre a via (a facilidade de passar por ela), e também serve de evidência para a tão-subjetiva e indefinida importância. Em ruas maiores, o conceito de preferência evolui para o de controle, ou seja, as placas-pare são substituídas por semáforos. E nas vias mais importantes (motorways), elas são eliminadas e substituídas por passagens suspensas, para dar vazão ao tráfego. Sugiro que estudem um pouco de engenharia de tráfego, tem uns links interessantes que eu deixei nos artigos do wiki que eu já citei. A organização do sistema de trânsito é hierárquica, é essa hierarquia que queremos capturar ao classificar as vias, pois ela tem forte impacto em definir quais são os caminhos mais bem mantidos e acessíveis, mais rápidos, mais populares, etc. Em suma, os mais importantes de uma forma genérica e abstrata. Quanto à ligação entre bairros, acho esse um critério estranho. Se o bairro for pequeno, quase todas as suas vias serão de ligação com bairros vizinhos. Se for grande, quase nenhuma. Tamanho e limites de bairro não têm nada a ver com importância de vias (e sim com política provinciana :P); como discutimos, estrutura da via tem mais a ver (pois estrutura reflete capacidade de fluxo, e essa capacidade costuma estar dimensionada ao tráfego esperado). Nas cidades a estrutura reflete mais história do que uso, então nas cidades a preferência é uma evidência mais clara da importância (afinal, é uma decisão tomada pelo planejamento urbano após analisar os padrões de tráfego). Ideal mesmo seria ter acesso aos dados do planejamento urbano da prefeitura, mas acho que isso é quase impossível conseguir - e pior, manter atualizado. Além disso, não pensem que determinar quais vias são arteriais foi inspiração divina minha :P. Quando eu cheguei no OSM, metade das atuais primárias em Porto Alegre (incluindo trechos da mais importante, a Avenida Ipiranga) estava marcada como secundária ou terciária, refletindo o descuido da comunidade local com essas definições. Há uma lista de avenidas importantes de Porto Alegre na Wikipédia, me baseei nela. Sei que essa lista tem publicação oficial em algum outro lugar (talvez mais completa e atualizada), e que provavelmente é a única informação útil (para classificação de vias) tipicamente publicada por prefeituras. Se souberem de algo além disso, me avisem. 2013/8/23 Felipe G. Nievinski fgnievin...@gmail.com: Trebien, dei uma olhada na discussão e não encontrei algo dedicado a esse problema (secondary vs. tertiary)... Você poderia apontar para a mensagem específica? Eu concordo que o quadrado cinza no final do diagrama precisa ser esclarecido. O critério indicado, atualmente preferencial, é vago -- a ponto deu ser incapaz de usá- lo se tentasse aplicá-lo. O critério sugerido pelo Flavio é mais objetivo: baseia-se na função da via: - secondary: ligação entre bairros - tertiary: escoamento do bairro É um bom começo, mas precisa ser refinado. Flavio, será que você poderia dar alguns exemplos no OSM de ruas que mereceriam ser re-classificadas? Acho que assim daria para derivar uma regra geral. -F. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Excesso de tertiary em Porto Alegre
No fim eu não respondi diretamente à sua pergunta, Felipe. Mas a diferença entre secondary e tertiary (no fluxograma de classificação) é que secondary é preferencial sobre tertiary. Só isso. Na prática, varia por país. A descrição no wiki em inglês é um tanto vaga, e mais fácil de interpretar fora das cidades. No Brasil, depende de a pessoa querer seguir o fluxograma (que já discutimos em conjunto, criticamos, melhoramos, aparamos as arestas) ou querer seguir o seu coração cantando a mesma canção. :P Se vocês querem trazer esse assunto à tona, sugiro criar um post no fórum para tratar da melhor forma de definir essas diferenças, daí só os interessados participam da discussão (quem está nesta lista, a princípio, ou não se importa, ou já deu a sua manifestação contrária sem propor critérios altenativos, ou acha ok o fluxograma dada a forma com que é apresentado: permitindo divergências do método mas explicando-as com a tag note). Se quiserem, podem fazer um fluxograma alternativo com expressões mais vagas, mas eu acho que logo vocês vão estar se deparando com guerras de edição com usuários que interpretam essas definições vagas de formas diferentes. Ou talvez pior, vocês vão os estar espantando porque, afinal, só vocês usuários experientes sabem o que é primary e secondary, porque não está escrito em lugar nenhum como se decide uma coisa ou outra, ou quem decide, e muito menos por que se decide assim. Me parece muito injusto criticar um usuário que mudou a classificação sem apontar um critério claro e sem respaldo em decisões democráticas tomadas pela comunidade. Pensem, se é pra classificar por importância (sem especificar mais), então as ruas onde eu moro e onde eu trabalho têm que ser primary, porque são muito, muito importantes pra mim. ;D Não vislumbram discussões desse cunho no futuro? Ok, talvez seja algo mais do tipo Esta via é importante porque há 200 anos morava o fundador da associação XYZ. É um critério de importância logicamente válido, se nada mais estiver decidido sobre o que é importância no OSM. A comunidade internacional está transbordando com casos assim (e os motivos são diversos, depende inteiramente da personalidade do indivíduo). Lembrem que o OSM é livre e qualquer um - qualquer um - pode editar e mudar qualquer coisa, inclusive classificações (que são as mais tentadoras - afinal, eu gosto mais de branco do que de amarelo). Se for pra discutir com cada usuário que decidir mudar uma classificação, é bom ter argumentos sólidos e claros, e não ter dois pesos e duas medidas, ou seja, regras que variam caso-a-caso, ou um grande número de casos distintos. Pensem sobre isso e me digam se têm um critério melhor que ajuda a reduzir o número desses casos. Pensem também como vocês explicariam para um leigo, talvez para um idoso, o que significam as coisas que ele vê no mapa. Com esse critério de preferência, a pessoa consegue calcular rotas rápidas sem nem precisar de um navegador GPS, e de cara fica sabendo quais trechos das ruas tendem a ser evitados pelos motoristas (porque não são rápidos). Além do critério ser simples, não deixar dúvidas, e assim não gerar quase nenhuma disputa ou caso particular que mereça discussão, as implicações da sua informação são muito úteis (para motoristas, para pedestres, para ciclistas, para planejamento urbano, para turistas, etc.). Bom pro usuário, e bom pra nós que temos que monitorar o mapa. 2013/8/23 Fernando Trebien fernando.treb...@gmail.com: Se alguém quiser reler a discussão na comunidade brasileira desde o começo, eis o link da primeira das mais de 150 mensagens (pode-se navegar por elas no final da página): http://www.mail-archive.com/talk-br@openstreetmap.org/msg03108.html Defina escoamento do bairro e eu começarei a achar que é objetivo. Pra mim, todas as vias servem para escoamento de um lugar para outro. A idéia original de que as vias formam uma sequência de preferência de tráfego (motorways têm prefência sobre trunks, que têm preferência sobre primaries, que têm preferência sobre secondaries, etc.) está esboçada nesse texto antigo do wiki: http://wiki.openstreetmap.org/wiki/Pt-br:How_to_map_a#Classifica.C3.A7.C3.A3o_de_vias_.28obsoleto.2C_substitu.C3.ADdo_pelo_fluxograma.29 Que foi inspirada em discussões da comunidade internacional, cujos links eu não guardei (não achei que seria necessário, agora vejo que devia). Preferencial (ou prioritária, como costumam chamar em inglês) é a via que tem preferência de passagem. Essa via é identificada pela presença de placas-pare nas suas transversais. É um termo de uso corrente e comum. Se você chegar num cruzamento e estiver na preferencial, não precisa parar. Caso contrário, precisa. Parar no cruzamento afeta a velocidade média sobre a via (a facilidade de passar por ela), e também serve de evidência para a tão-subjetiva e indefinida importância. Em ruas maiores, o conceito de preferência evolui para o de controle, ou seja, as placas-pare são substituídas por semáforos. E
Re: [Talk-br] Conta bloqueada ao editar pagina wiki
Olá Edil,
Você consegue editar a sua talk page?
http://wiki.openstreetmap.org/wiki/User_talk:Eqaedil
Se sim, você pode postar lá um pedido de desbloqueio. Vi vários
usuários na Wikipédia (que usa o mesmo sistema de wiki) acrescentando
uma seção (com o título == Unblock request ==) e dentro colocando uma
descrição usando o template {{unblock|Some description text.}} (você
tem que digitar exatamente assim, com chaves, barra vertical e a
palavra unblock antes da sua descrição). Infelizmente acho que o
seu pedido teria que ser em inglês, mas o pessoal aqui pode ajudar a
escrever o texto se precisar.
Mais algumas instruções que podem ser úteis:
http://en.wikiquote.org/wiki/Template:Autoblock
O texto dessa página me sugere que você deve estar recebendo alguma
mensagem de erro ao tentar acessar o wiki para edição. Se você nos
copiar a mensagem, talvez fique mais fácil ajudar. Em algum lugar dela
deve dizer se está bloqueado o seu IP ou só a sua conta e talvez até o
motivo.
E um guia completo de solicitações de desbloqueio (mas é mais um guia
de cordialidade, serve mais pros casos em que se quer disciplinar
alguém que praticou vandalismo):
http://en.wikipedia.org/wiki/Wikipedia:Guide_to_appealing_blocks
2013/8/21 Edil Queiroz De Araujo edil...@gmail.com:
Olá!
Fui acrescentar informações sobre pedidos de informação na pagina
http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Importações/Prefeituras
e minha conta foi bloqueada.
Segundo a mensagem, a edição foi considerada automaticamente como nociva,
assim como outros hoje: http://wiki.openstreetmap.org/wiki/Special:BlockList
Será que foi por ter colocado uma url sem a formatação adequada para urls?
Com quem entro em contato para resolver?
--
Edil
Enviado via iPad
Em 21/08/2013, às 22:22, 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
http://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. Re: RES: Má importação em Sobradinho (IMPORTANTE) (Vitor George)
2. Re: OSM e TrackSource (Nelson A. de Oliveira)
3. Re: OSM e TrackSource (Gerald Weber)
4. Re: OSM e TrackSource (Klederson Bueno)
5. Re: OSM e TrackSource (Nelson A. de Oliveira)
mime-attachment
mime-attachment
mime-attachment
mime-attachment
mime-attachment
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br
--
Fernando Trebien
+55 (51) 9962-5409
The speed of computer chips doubles every 18 months. (Moore's law)
The speed of software halves every 18 months. (Gates' law)
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Conta bloqueada ao editar pagina wiki
Postei essa questão no fórum pra ver se alguém nos dá uma indicação mais clara do que fazer: http://forum.openstreetmap.org/viewtopic.php?pid=356280 2013/8/22 Edil Queiroz de Araujo edil...@gmail.com: Oi Wille. Sim, levei ao pé da letra a mensagem Not the same as your OSM map editing account. e então usei outro login para editar :P Olá Fernando Trebien, nao consigo editar. Provavelmente foi bloqueado o IP também, pois também não consigo me logar com o nome de usuário OSM, conforme o Wille falou. A mensagem é: “ Você não possui permissão para editar esta página, pelo seguinte motivo: O seu nome de usuário ou endereço de IP foi bloqueado. O bloqueio foi realizado por Abuse filter. O motivo apresentado foi Automatically blocked by abuse filter. Description of matched rule: Spam bot (main). Início do bloqueio: 17h03min de 21 de agosto de 2013 Expiração do bloqueio: infinito Destino do bloqueio: Eqaedil Você pode contatar Abuse filter ou outro administrador para discutir sobre o bloqueio. Você só poderá utilizar a funcionalidade Contatar usuário se um endereço de e-mail válido estiver especificado em suas preferências de usuário e você não tiver sido bloqueado de utilizar tal recurso. O seu endereço de IP atual é 186.201.143.144 e a ID de bloqueio é #27476. Por favor, inclua todos os detalhes acima em quaisquer tentativas de esclarecimento. ” Meu inglês é fraco (na verdade, não falo, só leio e olha lá...)... vou tentar entrar em contato com um admin mais próximo da administração da Wiki --- Edil Queiroz de Araujo ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Conta bloqueada ao editar pagina wiki
Edil, não sei se você acompanhou o fórum hoje, mas o seu usuário foi desbloqueado. Parece que o filtro de spam é um recurso novo do wiki (tão novo que é desconhecido mesmo de usuários bem envolvidos) e ainda precisa de uns ajustes. Você não fez nada de errado, foi só azar mesmo. 2013/8/22 Fernando Trebien fernando.treb...@gmail.com: Postei essa questão no fórum pra ver se alguém nos dá uma indicação mais clara do que fazer: http://forum.openstreetmap.org/viewtopic.php?pid=356280 2013/8/22 Edil Queiroz de Araujo edil...@gmail.com: Oi Wille. Sim, levei ao pé da letra a mensagem Not the same as your OSM map editing account. e então usei outro login para editar :P Olá Fernando Trebien, nao consigo editar. Provavelmente foi bloqueado o IP também, pois também não consigo me logar com o nome de usuário OSM, conforme o Wille falou. A mensagem é: “ Você não possui permissão para editar esta página, pelo seguinte motivo: O seu nome de usuário ou endereço de IP foi bloqueado. O bloqueio foi realizado por Abuse filter. O motivo apresentado foi Automatically blocked by abuse filter. Description of matched rule: Spam bot (main). Início do bloqueio: 17h03min de 21 de agosto de 2013 Expiração do bloqueio: infinito Destino do bloqueio: Eqaedil Você pode contatar Abuse filter ou outro administrador para discutir sobre o bloqueio. Você só poderá utilizar a funcionalidade Contatar usuário se um endereço de e-mail válido estiver especificado em suas preferências de usuário e você não tiver sido bloqueado de utilizar tal recurso. O seu endereço de IP atual é 186.201.143.144 e a ID de bloqueio é #27476. Por favor, inclua todos os detalhes acima em quaisquer tentativas de esclarecimento. ” Meu inglês é fraco (na verdade, não falo, só leio e olha lá...)... vou tentar entrar em contato com um admin mais próximo da administração da Wiki --- Edil Queiroz de Araujo ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-legal-talk] [Talk-br] RES: Má importação em Sobradinho (IMPORTANTE)
I'm copying this to the legal-talk list for a sanity check of myself. :P I agree that we have a problem of trust before having a problem of contribution licensing, unless an explicit license made by the individual would transfer any responsibility to them and save us any trouble. In fact, TrackSource contributors seem not worried about licenses at all, many of them are learning about licensing conditions as they interact with us. To me this means they have good will (perhaps also a bit of naivety). I think they are also learning the rules of the open community (theirs is a hierarchical, closed community). Some of them claim that the portions of the map that they contributed have been entirely generated by themselves over the years. We know that much of their data has been generated from their own GPS tracklogs as well as traced over Google imagery (some of it, most of it, it probably varies by contributor). My advice so far has been to realign the nodes and ways to Bing prior to uploading; other advices include removing data with any risk of coming from other sources - such as street names -, therefore only contribute data they are absolutely sure to be clean. Beyond that I don't see any reasons to mistrust the entire TrackSource community based solely on their involvement, that would be prejudice. However, we should continue to monitor reckless imports (as has been the case only once so far - and one of their first attempts at doing so). 2013/8/21 Vitor George vitor.geo...@gmail.com: Alex, The problem is that Tracksource uses often proprietary data as source, not compatible with ODbL. As they can't tell exactly which portions are genuinely open, I think we can't mix this data with OpenStreetMap. Vitor 2013/8/21 Alex Barth a...@mapbox.com On that note, I've started to tinker with a license that allows dedication of data to OSM but reserves all other rights. This is not finalized but could be a good idea to adopt if Tracksource wanted to open its data to OSM but not to anyone else: https://github.com/osmlab/odl 2013/8/21 Gerald Weber gwebe...@gmail.com O TrackSource é um projeto muito legal, e seus mapas são fantásticos, especialmente no tocante a trilhas 4x4. Fico satisfeito em ver algum diálogo entre OSM-Brasil e Tracksource, ainda que seria desejável que fosse em circunstâncias mais felizes. Acho importante a manutenção deste diálogo para minimizar problemas e deixar explícito o que pode e o que não pode ser compartilhado. Dito tudo isto, eu confesso que me dá certa aflição ver o esforço de mapear este país gigantesco sendo dividido em duas comunidades distintas. Os projetos tem perfis muito diferentes, cada um com suas vantagens e desvantagens. Mas o objetivo final é essencialmente o mesmo: ter mapas bons para usar. Assim fico imaginando o tanto que os dois projetos poderiam estar muito mais avançados se houvesse uma colaboração mais estreita. abraço a todos Gerald 2013/8/20 Projeto TrackSource falecono...@tracksource.org.br: Exato! Parabéns a todos do OSM! Sempre fui grande admirador do projeto como um todo, mas infelizmente quando montamos o Projeto TrackSource, votamos por um tipo de licença que no caso do OSM, não permite a integração, fora o uso de ferramentas que pelo que vi, ferem as regras do OSM, como o uso de imagens do google para montar os mapas (usando o GPS TrackMaker), mapas cedidas apenas para serem usadas conosco e outras ferramentas. Abs! Alex Rodrigues Projeto TrackSource www.TrackSource.org.br ___ Talk-br mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-br] [alt-tracksource] Re: Orientações para pontenciais contribuintes do projeto OSM
Para conhecimento. 2013/8/21 Erick Leal erickdeoliveiral...@gmail.com: Eu nunca usei mapas do Google pra mapear nada, desenhei muitas cidades do Goiás, mas sem colocar nomes, justamente por não confiar em desenhos do Google. o DF também está livre de traçados do Google. Em quarta-feira, 21 de agosto de 2013 10h16min09s UTC-3, Paulo Carvalho escreveu: Amigos, Mensagens correm pelos grupos de usuários com informações falsas de que nenhum mapa pode ser compartilhado com o projeto OSM, absolutamente. Essas mensagens visam manter o monopólio sobre a produção cartográfica voluntária no Brasil, confundir e desmoralizar aqueles que tentam torná-la livres tal como em muitos países onde os mapas do OSM florescem. Orientações: 1) Mapas derivados do Bing e do IBGE (pesquisa feita pelo Fernando, do OSM) podem ser compartilhados com o projeto OSM sem o menor problema. 2) Mapas derivados de dados de domínio público, como os do IPP, do Rio de Janeiro, também podem ser livremente compartilhados. 3) Mapas derivados das linhas vetoriais do Google (as fotos muitas vezes estão deslocadas) podem ser reposicionados a fim de não infringir a licença de copyright que protege seu ortorreferenciamento. Usem tracks coletados em campo ou uma fonte autorizada com o Bing para reposicionar os dados. 4) Antes de concretizar contribuições ao OSM, façam uma aproximação com a comunidade de usuários já existente no local em que for feita a inclusão de dados. O Fernando do OSM pode orientá-los nesse sentido. 5) NUNCA apagar o que já existe no OSM para derramar em cima um conteúdo totalmente diverso. Além de apagar dados que você não tem, isto é desrespeito com o trabalho alheio e é considerado vandalismo pela comunidade. O objetivo é COMPLETAR os mapas do OSM com informações não existentes lá. 6) Sempre apresentar nos fóruns do OSM ( http://forum.openstreetmap.org/viewforum.php?id=74 fórum do Brasil ) a origem dos dados e a licença dos mesmos, de forma a evitar rollbacks e bloqueio de conta. 7) A licença Creative Commons do Tracksource protege os produtos finais disponibilizados por eles. A obra original são os mapas-fonte editados pelos desenvolvedores, que podem dispor de seu trabalho livremente. 8) Como corolário da orientação 7), sugiro aqueles que não são os desenvolvedores originais dos mapas, que entrem em contato com os ex-desenvolvedores e peça-lhes permissão para compartilhar a parte que eles desenvolveram. [ ]s e qualquer dúvida, perguntem Paulo -- Você está recebendo esta mensagem porque se inscreveu no grupo Alt-Tracksource dos Grupos do Google. Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para alt-tracksource+unsubscr...@googlegroups.com. Para obter mais opções, acesse https://groups.google.com/groups/opt_out. -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] RES: Má importação em Sobradinho (IMPORTANTE)
I'm copying this to the legal-talk list for a sanity check of myself. :P I agree that we have a problem of trust before having a problem of contribution licensing, unless an explicit license made by the individual would transfer any responsibility to them and save us any trouble. In fact, TrackSource contributors seem not worried about licenses at all, many of them are learning about licensing conditions as they interact with us. To me this means they have good will (perhaps also a bit of naivety). I think they are also learning the rules of the open community (theirs is a hierarchical, closed community). Some of them claim that the portions of the map that they contributed have been entirely generated by themselves over the years. We know that much of their data has been generated from their own GPS tracklogs as well as traced over Google imagery (some of it, most of it, it probably varies by contributor). My advice so far has been to realign the nodes and ways to Bing prior to uploading; other advices include removing data with any risk of coming from other sources - such as street names -, therefore only contribute data they are absolutely sure to be clean. Beyond that I don't see any reasons to mistrust the entire TrackSource community based solely on their involvement, that would be prejudice. However, we should continue to monitor reckless imports (as has been the case only once so far - and one of their first attempts at doing so). 2013/8/21 Vitor George vitor.geo...@gmail.com: Alex, The problem is that Tracksource uses often proprietary data as source, not compatible with ODbL. As they can't tell exactly which portions are genuinely open, I think we can't mix this data with OpenStreetMap. Vitor 2013/8/21 Alex Barth a...@mapbox.com On that note, I've started to tinker with a license that allows dedication of data to OSM but reserves all other rights. This is not finalized but could be a good idea to adopt if Tracksource wanted to open its data to OSM but not to anyone else: https://github.com/osmlab/odl 2013/8/21 Gerald Weber gwebe...@gmail.com O TrackSource é um projeto muito legal, e seus mapas são fantásticos, especialmente no tocante a trilhas 4x4. Fico satisfeito em ver algum diálogo entre OSM-Brasil e Tracksource, ainda que seria desejável que fosse em circunstâncias mais felizes. Acho importante a manutenção deste diálogo para minimizar problemas e deixar explícito o que pode e o que não pode ser compartilhado. Dito tudo isto, eu confesso que me dá certa aflição ver o esforço de mapear este país gigantesco sendo dividido em duas comunidades distintas. Os projetos tem perfis muito diferentes, cada um com suas vantagens e desvantagens. Mas o objetivo final é essencialmente o mesmo: ter mapas bons para usar. Assim fico imaginando o tanto que os dois projetos poderiam estar muito mais avançados se houvesse uma colaboração mais estreita. abraço a todos Gerald 2013/8/20 Projeto TrackSource falecono...@tracksource.org.br: Exato! Parabéns a todos do OSM! Sempre fui grande admirador do projeto como um todo, mas infelizmente quando montamos o Projeto TrackSource, votamos por um tipo de licença que no caso do OSM, não permite a integração, fora o uso de ferramentas que pelo que vi, ferem as regras do OSM, como o uso de imagens do google para montar os mapas (usando o GPS TrackMaker), mapas cedidas apenas para serem usadas conosco e outras ferramentas. Abs! Alex Rodrigues Projeto TrackSource www.TrackSource.org.br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] OSM e TrackSource
Bem, se fosse a pessoa A importando o mapa feito pela pessoa B sem falar com ela (por exemplo, baixando diretamente do site), faria sentido essa discussão. Mas nesse caso, a pessoa A, que foi quem fez o mapa, está nos dizendo (garantindo) que os dados são inteiramente gerados por ela. Ela teve acesso ao seu mapa no seu estado inicial e certamente é a única pessoa que pode responder qual parte do mapa não é efetivamente sua. Acreditar ou não é uma questão de confiança. Por exemplo, se a pessoa A dissesse: Eu fiz esse trecho do mapa por 5 anos, mas não participo do TrackSource, o que faríamos, impediríamos a sua contribuição? Me parece mais lógico permiti-la. Se não confiamos, o que precisamos fazer é pensar numa forma eficaz de fiscalizar. Sugiro uma: por amostragem. Não verificaríamos tudo, apenas pequenas partes aleatórias do mapa (sugiro usar isto: http://sautter.com/map/). Se acharmos algo suspeito, seguimos o protocolo de sempre: entramos em contato, solicitamos a reversão, se não tivermos resposta revertemos nós mesmos, se a pessoa repetir o erro bloqueamos ela, se repetir de novo banimos, etc. Isso é o que me parece mais justo. Sei que talvez não tenhamos mão de obra suficiente para fazer a tal fiscalização. Mas também sei que o pessoal do TrackSource tem se interessado e se informado sobre a forma correta de proceder. Acho que não devemos tender aos extremos, senão acabaremos sozinhos. 2013/8/21 Nelson A. de Oliveira nao...@gmail.com: 2013/8/21 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: E como se garante o contrario? Como não dá para garantir nada, utiliza-se o que é mais seguro: não utilizar nada vindo do TrackSource. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] RES: Má importação em Sobradinho (IMPORTANTE)
para usar. Assim fico imaginando o tanto que os dois projetos poderiam estar muito mais avançados se houvesse uma colaboração mais estreita. abraço a todos Gerald 2013/8/20 Projeto TrackSource falecono...@tracksource.org.br: Exato! Parabéns a todos do OSM! Sempre fui grande admirador do projeto como um todo, mas infelizmente quando montamos o Projeto TrackSource, votamos por um tipo de licença que no caso do OSM, não permite a integração, fora o uso de ferramentas que pelo que vi, ferem as regras do OSM, como o uso de imagens do google para montar os mapas (usando o GPS TrackMaker), mapas cedidas apenas para serem usadas conosco e outras ferramentas. Abs! Alex Rodrigues Projeto TrackSource www.TrackSource.org.br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Má importação em Sobradinho
Tinha um serviço muito bom, o OSM History Viewer, que traduzia o changeset pra um mapa marcando tudo aquilo que foi excluído, alterado, acrescentado, e também comparando as tags dos elementos modificados. Infelizmente faz uns meses que esse serviço não está mais no ar. 2013/8/15 Gerald Weber gwebe...@gmail.com Eu nunca entendo direito esses changeset, tenho dificuldade em entender o que já existia e o que é novo. Dito isto, eu vi muitos Terra Draft que são uma notação usada pela pessoal do Tracksource. Será que foi alguma importação de lá? abraço Gerald 2013/8/15 Vitor George vitor.geo...@gmail.com Oi Pessoal, Parece que o usuário Tecpenleal fez uma má importação: http://www.openstreetmap.org/browse/changeset/17108276 http://www.openstreetmap.org/?box=yesbbox=-48.0388436%2C-15.7698883%2C-47.6756855%2C-15.4907031#map=15/-15.6446/-47.8169 Já mandei uma mensagem pra ele via OpenStreetMap. Se alguém tiver alguma informação sobre este usuário, me avisem. Provavelmente vamos reverter este changeset nos próximos dias, e talvez bloquear a conta se ele não se manifestar. Abraços, Vitor. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] roteamento estranho na BR-116
Geralmente sim, mas nesse caso nenhum dos dois trechos tem tags de velocidade: http://www.itoworld.com/map/124?lon=-48.00315lat=-24.55411zoom=8fullscreen=true Como não há vias alternativas no intervalo que eu mexi no final da rota (menos de 100 metros sobre a mesma rodovia, passando apenas por um cruzamento), não tem como ser esse o problema. Acho que o desenvolvedor já está olhando o problema de perto. Sugiro não mexerem nessa via por uns dias. 2013/8/15 Nelson A. de Oliveira nao...@gmail.com 2013/8/15 Fernando Trebien fernando.treb...@gmail.com: Acho que é um bug mesmo, o primeiro que eu vejo no OSRM. Seria legal reportar esse problema. Investiguei em detalhes e decidi reportar: https://github.com/DennisOSRM/Project-OSRM/issues/706 O que eu descobri é que: - funciona até este ponto: http://osrm.at/4FN - passa a dar erro logo depois: http://osrm.at/4FO Geralmente isso acontece por causa de trechos com velocidade errada (ou ausência da mesma). ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Mapeando áreas
Hm, eu concordo que isso pode ser uma regra geral que simplifica a vida do iniciante, mas eu não concordo que seja errado juntar as tags do restaurante ao edifício se o restaurante é a única coisa que opera naquele edifício. Nesse caso, é impossível separar as duas coisas. (Não seria o caso de um edifício residencial com uma fachada comercial, ou de um edifício com vários estabelecimentos dentro.) Se fosse assim, metade do wiki teria que ser re-escrito mudando os casos de uso de várias tags para se aplicarem somente a pontos. 2013/8/8 Wille wi...@wille.blog.br: Mudando um pouco de assunto, mas ainda sobre áreas. Eu estava revisando a tradução do iD há uns dias e encontrei essa recomendação no manual que tem dentro do iD: The rule of thumb is to map a building as a shape whenever possible, and map companies, homes, amenities, and other things that operate out of buildings as points placed within the building shape. Então, por exemplo, se você vai mapear um restaurante, você pode desenhar a área do prédio, taguear como building e colocar algumas outras tags, como as de endereço, mas a tag amenity=restaurant você põe em um nó separado do polígono. Eu sempre costumava colocar todas as tags no polígono, a não ser quando havia mais de um ponto de interesse no mesmo prédio. Isso não chega a ser um problema grave, mas é bom fazer da maneira certa a partir de agora... wille On 08-08-2013 15:41, Vitor George wrote: Começando novo tópico... Nelson, eu já fiz algumas praças assim aqui em São Paulo. Se a rua é o que delimita onde a praça termina, porque não mapear assim? Eu não sei se existe alguma recomendação contraria a isso, mas quando mapeei de outra maneira ficou um vácuo entre a área e a rua, e não me pareceu correto. Existem um recomendação fechada sobre esta questão? 2013/8/8 Nelson A. de Oliveira nao...@gmail.com Falar também para não grudar áreas nas ruas. Por exemplo, a pessoa traça as ruas e depois traça uma praça sobrepondo o caminho das ruas e grudada nos nós: http://i.imgur.com/ugkYEyG.png Já peguei muitos casos que a pessoa traça várias ruas de uma cidade com apenas 1 caminho, indo e voltando, e nisso tem 2 coisas: - Falar para não traçar vias sobrepostas - Falar para utilizar 1 caminho para cada rua Eu vi que falaram para não deixar vias cruzando sem os nós mas também tem que falar para ligar os nós finais das vias. Muita gente deixa as ruas começando/terminando muito próximas das outras rias (o que parece que está conectado), mas na verdade não está. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Fwd: [Transifex] New announcement in project iD Editor
Em uma via pedestrian (calçadão) não passam carros, em uma living street sim. O conceito de living street não existe no Brasil, então estamos adaptando. Foi um pouco debatido na época que discutimos sobre classificação de vias. O conceito original é que os pedestres têm a preferência sobre os veículos. Estamos aplicando para vias onde essa seja uma preferência por prática (por haver muitos pedestres na via) mas sem a obrigatoriedade legal. Alguns (e eu inclusive) acham útil usar o mesmo tipo de via para vielas (ruas estreitas), onde só 1 veículo pode passar por vez, mas isso já é uma extensão do conceito original. Se excluirmos a possibilidade de usar living street, então todas essas vias seriam residential ou unclassified. http://wiki.openstreetmap.org/wiki/Pt-br:How_to_map_a#Fluxograma_de_classifica.C3.A7.C3.A3o Como no Brasil legalmente a preferência continua sendo do veículo (ou seja, legalmente, os pedestres estão fazendo algo a que não teriam direito), partilhada com pedestres refletiria essa idéia. Outra que surgiu há pouco é mais parecida com partilhada pedestres/veículos, o que eu acho que para um iniciante significaria a mesma coisa, só seria um nome mais comprido. 2013/8/5 Samuel Vale srcv...@minaslivre.org: Em Seg, 2013-08-05 às 09:55 -0300, Samuel Vale escreveu: Em Seg, 2013-08-05 às 02:01 +, Fernando Trebien escreveu: Oi Blademir, Só pra avisar, na discussão que está se desenrolando no fórum, acho que chegamos a um bom nome para living street: via partilhada com pedestres. Foi inspirado no conceito australiano de shared zone: http://en.wikipedia.org/wiki/Shared_Zone Olá Fernando, Discordo do termo. Consultando o Features do wiki, o texto diz que nas living streets os pedestres tem prioridade sobre veículos motorizados. Talvez a tradução deva sugerir ao contrário: uma via de pedestres onde carros podem transitar em baixa velocidade. Além disso, o texto diz que pedestres tem prioridade legal sobre veículos, o que nunca vi por estas bandas em área residenciais. Consultando a entrada abaixo na página de Features, a etiqueta highway=pedestrian sugere que seja o mesmo tipo de via, mas aplicado numa área comercial. Correção: pode ser aplicado numa área comercial. A primeira parece ser algo mais comum lá, será que temos algo parecido no Brasil? Até, Abraço, 2013/8/4 Fernando Trebien fernando.treb...@gmail.com: Já troquei pra pátio na minha planilha. :D Certamente viela significa rua estreita. O problema é que living street quer dizer outra coisa. Nem no wiki nem na Wikipédia há menção à largura da rua, mas ambos se referem à dificuldade de passar pela via devido à presença de pedestres, que nela têm a preferência para circulação. Considerando isso, nem viela nem rua viva traduzem bem essa definição. Viela porque sugere que a rua é estreita (ela pode ser, mas nem sempre é), e rua viva porque a rua não está de fato viva. Aí vão mais algumas idéias. Características citadas no wiki (http://wiki.openstreetmap.org/wiki/Tag:highway%3Dliving_street): - generally have lower speed limits, and special traffic/parking rules compared to streets tagged using highway=residential - Terms for these street vary considerably around the world and include Home Zone (UK), Woonerf (Netherlands/Flanders), 'Verkehrsberuhigter Bereich' - Home Zone: zona de habitação/moradia - http://en.wikipedia.org/wiki/Home_zone - Woonerf: bairro/zona residencial - Verkehrsberuhigter Bereich: zona de tráfego acalmado Todos os países listados têm velocidade máxima de 20km/h e preferência ao tráfego de pedestres nessas ruas. A primeira característica é fácil descrever: via de baixa velocidade. A segunda, nem tanto, pode se confundir com calçadão, como você disse, exceto que no calçadão o acesso a veículos é proibido. Dentre os países listados, apenas a Itália não usa living streets, onde eles decidiram usar living street apenas nos raros lugares onde aparece uma placa específica. E só a Inglaterra tem uma menção a ruas estreitas no código de trânsito (e pelo wiki, parece que living street se aplica a esse caso lá também): https://www.gov.uk/road-users-requiring-extra-care-204-to-225/pedestrians-205-to-210 Características citadas na Wikipédia (http://en.wikipedia.org/wiki/Living_street): - França: Zone de rencontre (zona de reunião/encontro) - Suécia: Gångfartsområde (zona de velocidade de caminhada) - Suíça: Begegnungszone (zona de encontro) - Estados Unidos: Complete street (rua completa) - http://en.wikipedia.org/wiki/Complete_streets - Outros países: rua/zona/área residencial Que tal coisas mais como rua em zona de encontro (talvez impreciso demais), rua em zona de pedestres (talvez com um pouco de confusão ainda) ou rua em zona de caminhada (que pode dar a impressão de uma área de esportes)? 2013/8/4 Blademir Andrade de Lima
Re: [Talk-br] Fwd: [Transifex] New announcement in project iD Editor
É uma alternativa também. Cairia na categoria de estrangeirismo. Vou alterar na planilha com essa observação. 2013/8/5 Vitor George vitor.geo...@gmail.com: Porque não deixar como Living Street mesmo? Se o conceito não existe no Brasil, isto poderia até evitar que os mapeadores confundam com coisas parecidas, como viela, calçadão, etc. No dia em que começar a existir por aqui poderemos saber qual vai ser o nome tropicalizado e aí poderemos passar a utilizá-lo para mapeamento. Vitor 2013/8/5 Fernando Trebien fernando.treb...@gmail.com Em uma via pedestrian (calçadão) não passam carros, em uma living street sim. O conceito de living street não existe no Brasil, então estamos adaptando. Foi um pouco debatido na época que discutimos sobre classificação de vias. O conceito original é que os pedestres têm a preferência sobre os veículos. Estamos aplicando para vias onde essa seja uma preferência por prática (por haver muitos pedestres na via) mas sem a obrigatoriedade legal. Alguns (e eu inclusive) acham útil usar o mesmo tipo de via para vielas (ruas estreitas), onde só 1 veículo pode passar por vez, mas isso já é uma extensão do conceito original. Se excluirmos a possibilidade de usar living street, então todas essas vias seriam residential ou unclassified. http://wiki.openstreetmap.org/wiki/Pt-br:How_to_map_a#Fluxograma_de_classifica.C3.A7.C3.A3o Como no Brasil legalmente a preferência continua sendo do veículo (ou seja, legalmente, os pedestres estão fazendo algo a que não teriam direito), partilhada com pedestres refletiria essa idéia. Outra que surgiu há pouco é mais parecida com partilhada pedestres/veículos, o que eu acho que para um iniciante significaria a mesma coisa, só seria um nome mais comprido. 2013/8/5 Samuel Vale srcv...@minaslivre.org: Em Seg, 2013-08-05 às 09:55 -0300, Samuel Vale escreveu: Em Seg, 2013-08-05 às 02:01 +, Fernando Trebien escreveu: Oi Blademir, Só pra avisar, na discussão que está se desenrolando no fórum, acho que chegamos a um bom nome para living street: via partilhada com pedestres. Foi inspirado no conceito australiano de shared zone: http://en.wikipedia.org/wiki/Shared_Zone Olá Fernando, Discordo do termo. Consultando o Features do wiki, o texto diz que nas living streets os pedestres tem prioridade sobre veículos motorizados. Talvez a tradução deva sugerir ao contrário: uma via de pedestres onde carros podem transitar em baixa velocidade. Além disso, o texto diz que pedestres tem prioridade legal sobre veículos, o que nunca vi por estas bandas em área residenciais. Consultando a entrada abaixo na página de Features, a etiqueta highway=pedestrian sugere que seja o mesmo tipo de via, mas aplicado numa área comercial. Correção: pode ser aplicado numa área comercial. A primeira parece ser algo mais comum lá, será que temos algo parecido no Brasil? Até, Abraço, 2013/8/4 Fernando Trebien fernando.treb...@gmail.com: Já troquei pra pátio na minha planilha. :D Certamente viela significa rua estreita. O problema é que living street quer dizer outra coisa. Nem no wiki nem na Wikipédia há menção à largura da rua, mas ambos se referem à dificuldade de passar pela via devido à presença de pedestres, que nela têm a preferência para circulação. Considerando isso, nem viela nem rua viva traduzem bem essa definição. Viela porque sugere que a rua é estreita (ela pode ser, mas nem sempre é), e rua viva porque a rua não está de fato viva. Aí vão mais algumas idéias. Características citadas no wiki (http://wiki.openstreetmap.org/wiki/Tag:highway%3Dliving_street): - generally have lower speed limits, and special traffic/parking rules compared to streets tagged using highway=residential - Terms for these street vary considerably around the world and include Home Zone (UK), Woonerf (Netherlands/Flanders), 'Verkehrsberuhigter Bereich' - Home Zone: zona de habitação/moradia - http://en.wikipedia.org/wiki/Home_zone - Woonerf: bairro/zona residencial - Verkehrsberuhigter Bereich: zona de tráfego acalmado Todos os países listados têm velocidade máxima de 20km/h e preferência ao tráfego de pedestres nessas ruas. A primeira característica é fácil descrever: via de baixa velocidade. A segunda, nem tanto, pode se confundir com calçadão, como você disse, exceto que no calçadão o acesso a veículos é proibido. Dentre os países listados, apenas a Itália não usa living streets, onde eles decidiram usar living street apenas nos raros lugares onde aparece uma placa específica. E só a Inglaterra tem uma menção a ruas estreitas no código de trânsito (e pelo wiki, parece que living street se aplica a esse caso lá também): https://www.gov.uk/road-users-requiring-extra-care-204-to-225/pedestrians-205-to-210
Re: [Talk-br] [alt-tracksource] Bugs PFM2OSM - última versão
Isso varia um pouco por aplicação. O Nominatim (serviço de geocoding usado pelo OSRM) extrai o ponto central de polígonos e trata esse ponto tal como outros objetos equivalentes mapeados como pontos. Assim, tanto polígonos como pontos com a tag shop=mall viram uma única coordenada e vão parar na mesma categoria de POIs no banco de dados do Nominatim. O OsmAnd faz algo praticamente igual (mas é online), e o MapFactor Navigator (que eu uso porque é offline) também. Praticamente porque não testei todas as possibilidades, mas todas as que eu testei funcionaram da mesma forma. No MapFactor eu achei uma ou outra diferença em objetos menos procurados (ex.: lagos, que não são retornados na busca), mas isso é em parte porque o MapFactor é menos usado (então tem menos gente apontando os erros na lógica dos desenvolvedores). O geocoding tende a não dar certo quanto o desenvolvedor (que raramente é um mapeador) não mapeou o tempo suficiente (porque ele desenvolve, não mapeia) nem leu o wiki com cuidado (é um wiki extenso afinal, prova disso é a longa lista de mais de 600 traduções em que estamos trabalhando agora) pra perceber que a comunidade do OSM: - tende a aprovar tags que podem ser combinadas livremente (os valores da tag é que são não-combináveis no mesmo objeto) - tende a aprovar tags que possam ser filtradas com lógica positiva (ex.: considerar que lojas são todos os objetos com a tag shop sem inventar de excluir as que têm também a tag landuse) - burla essas duas regras de vez em quando e não avisa ninguém :P E que também o time do JOSM identifica o que é combinável e o que não é e organiza tudo num sistema de menus, onde coisas em menus diferentes geralmente são combináveis, e coisas no mesmo menu não. (Ainda assim, em uma ou outra situação é necessário pensar um pouco pra saber qual a combinação certa de elementos cartográficos e tags, e às vezes simplesmente testar e ver qual o efeito nas ferramentas.) Exemplo: como mapear um estacionamento debaixo de um hospital? Tanto hospital quanto estacionamento usam a tag amenity, cada um com um valor diferente. Você não pode atribuir duas tags amenity ao mesmo objeto, o sistema não deixa. A solução da comunidade foi mapear as entradas do estacionamento com amenity=parking_entrance (ao invés do polígono do prédio com amenity=parking) e atribuir às entradas outras tags de estacionamento como name, fee, etc., e desde então, esse passou a ser o estilo preferível para estacionamentos combinados com edifícios (inclusive em shoppings). Mas ninguém explicou isso direito no wiki. Por ser algo meio difícil de achar, um desenvolvedor dando uma rápida olhada na sua cidade pode acabar esquecendo de incluir os objetos com amenity=parking_entrance na lista de estacionamentos do seu aplicativo de GPS. Exemplo: as tags landuse e building raríssimas vezes são combináveis no mesmo objeto. Talvez seriam se alguém plantasse grama no terraço de um edifício, mas mesmo assim a combinação seria meio questionável. Um desenvolvedor pode ser dar conta disso, pensar que essa combinação é impossível, e com isso (talvez até sem querer) não incluir na sua lista de edifícios aqueles que têm a tag landuse, ou talvez não os desenhar no mapa como edifícios. Já building e amenity costumam ser combináveis, mas parece que a equipe do Mapnik (o sistema que renderiza o mapa do OSM no site principal) não previu a combinação quando amenity=parking: o resultado fica ilegível. Essas coisas vão se ajeitando com o tempo. Um dia alguém faz um programa que conserta tudo automaticamente, ou então simplemente uma prática cai em desuso e ninguém mais dá suporte a ela. Os aplicativos também vão melhorando à medida que mais desses casos vão sendo reportados aos desenvolvedores. 2013/8/5 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Fernando, e no caso de navegadores para o OpenStreetMap, você tem conhecimento de como funcionam as buscas? No caso do OSMand por exemplo... Em 5 de agosto de 2013 19:28, MARCIO MS soaresmm@gmail.com escreveu: Mapeamos o shopping com polígono para representar visualmente no mapa área do mesmo, entretanto temos de colocar o POI desse shopping caso contrario ele não será encontrado na busca de shoppings pelo GPS. O sistema GPS não indexa na busca polígonos, só indexa POIs. []s Marcio From: Fernando Trebien Sent: Monday, August 05, 2013 5:45 PM To: alt-tracksou...@googlegroups.com Subject: Re: [alt-tracksource] Bugs PFM2OSM - última versão Uma pergunta. Quando vocês mapeiam um shopping com polígono, acrescentam um POI também? Se sim, o certo é mapear o polígono do shopping com landuse=retail e o POI com shop=mall. Se não, então o polígono deve ter tanto landuse=retail quanto shop=mall. Explicando: shop geralmente acompanha uma outra tag. Shop significa este objeto serve como loja. O objeto em si pode ser um edificio, uma casa, até mesmo um jardim. Landuse é usado para representar terrenos. Um shopping completo geralmente é mapeado no OSM
Re: [Talk-br] Fwd: [Transifex] New announcement in project iD Editor
Ah sim, estou no elemento Piscina, linha 373. :P Acho que termino até o final do dia. 2013/8/4 Fernando Trebien fernando.treb...@gmail.com Oi Wille, Acho que estamos com uma preocupação parecida. Desde que eu ajudei com as traduções do iD, decidi retomar esse assunto (que eu já tinha começado há meses para a tradução do JOSM, mas parei). Queria centralizar no wiki e no fórum as discussões sobre as melhores traduções para cada termo, especialmente os termos mais difíceis. Acho que várias cabeças pensando juntas vão produzir um resultado melhor. Eu ia postar isso mais tarde quando tivesse concluído a minha parte, mas se você já quiser ir dando uma olhada: https://docs.google.com/spreadsheet/ccc?key=0Aut_CDnmHfE7dEg2ZVRRM1M2WVdudnVMdzV4bG5FeUEusp=sharing Abre um post lá no fórum, é mais fácil pra manter um registro da discussão. Sobre os termos que você citou, as minhas traduções sugeridas são: - Aeroway = aerovia (o termo em inglês é um neologismo, então podemos inventar também) - Apron = plataforma de estacionamento (é como a wikipédia traduz - sugiro acrescentar em aeroporto pra não confundir com outros estacionamentos), mas podemos usar apron se todos concordarem - Town = vila (é como a wikipédia traduz, o termo original em inglês não pressupõe nada sobre o tamanho da população, apenas uma ordem entre as diversas categorias de colônias humanas) - Village = aldeia (povoado conflita com a tradução que a Wikipédia dá para hamlet) - Living street = rua viva (sugestão que eu copiei de uma tradução que eu achei no Linguee.pt, mas como não existe de fato em português, podemos inventar) - Fountain = chafariz (apenas fonte ornamental segundo a descrição no wiki do OSM, fonte de água potável é o elemento drinking water que não é o mapeado pelo iD) 2013/8/4 Wille wi...@wille.blog.br Hoje revisei parte dos presets e fiquei em dúvida sobre algumas traduções. Acho que a definição da tradução é muito importante, pois vai afetar bastante como os novos usuários vão mapear. Aeroway - Via Aérea (acho que seria melhor manter o termo em inglês ou aerovia) Apron - Plataforma de Estacionamento em Aeroporto (também acho que seria melhor manter o termo em inglês, visto que é um termo técnico da aeronáutica) Town - Vila (esse é um problema de definição do OSM, mas no Brasil usa-se vila como parte de uma cidade, então sugiro traduzir como Cidade de até 10 mil habitantes ou Pequena Cidade) Village - Povoado (estava como Aldeia, mas mudei para Povoado, visto que aldeia é um temo mais utilizado para designar lugares indígenas. Talvez o mais adequado fosse Vila / Povoado) Living Street - Rua Viva (talvez rua preferencial para pedestres fique mais claro) Fountain - Chafariz (o problema é que Fountain pode significar tanto fonte ornamental quanto fonte de água potável. Acho que o termo fonte é mais popular do que chafariz, então sugiro colocar os dois: Chafariz / Fonte) O que acham? Parabéns a quem ajudou a traduzir, somos um dos 5 idiomas com 100% do iD traduzido! abçs, wille On 31-07-2013 16:08, Vitor George wrote: Pessoal, Em breve sairá nova versão do iD e seria legal avançar na tradução para o português. Aqui está o link para quem puder ajudar: https://www.transifex.com/projects/p/id-editor/language/pt_BR/ Vitor -- Forwarded message -- From: Transifex ad...@transifex.com Date: Wed, Jul 31, 2013 at 2:49 PM Subject: [Transifex] New announcement in project iD Editor To: vitor.geo...@gmail.com Hi Vitor George, you have a notification from Transifex. A new announcementhttps://www.transifex.com/projects/p/id-editor/announcement/36685/has been added to the project iD Editor: 1.1 release upcoming Hello and thanks to all translators. This is just a quick announcement that iD 1.1 is nearing release. Immediately prior to the release I will update the translations from Transifex, so get them in now. Thank you! -- The Transifex Robot https://www.transifex.com Modify notification settingshttps://www.transifex.com/settings/notices/ ___ Talk-br mailing listTalk-br@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Fwd: [Transifex] New announcement in project iD Editor
Abri o post: http://forum.openstreetmap.org/viewtopic.php?pid=351837#p351837 2013/8/4 Fernando Trebien fernando.treb...@gmail.com Ah sim, estou no elemento Piscina, linha 373. :P Acho que termino até o final do dia. 2013/8/4 Fernando Trebien fernando.treb...@gmail.com Oi Wille, Acho que estamos com uma preocupação parecida. Desde que eu ajudei com as traduções do iD, decidi retomar esse assunto (que eu já tinha começado há meses para a tradução do JOSM, mas parei). Queria centralizar no wiki e no fórum as discussões sobre as melhores traduções para cada termo, especialmente os termos mais difíceis. Acho que várias cabeças pensando juntas vão produzir um resultado melhor. Eu ia postar isso mais tarde quando tivesse concluído a minha parte, mas se você já quiser ir dando uma olhada: https://docs.google.com/spreadsheet/ccc?key=0Aut_CDnmHfE7dEg2ZVRRM1M2WVdudnVMdzV4bG5FeUEusp=sharing Abre um post lá no fórum, é mais fácil pra manter um registro da discussão. Sobre os termos que você citou, as minhas traduções sugeridas são: - Aeroway = aerovia (o termo em inglês é um neologismo, então podemos inventar também) - Apron = plataforma de estacionamento (é como a wikipédia traduz - sugiro acrescentar em aeroporto pra não confundir com outros estacionamentos), mas podemos usar apron se todos concordarem - Town = vila (é como a wikipédia traduz, o termo original em inglês não pressupõe nada sobre o tamanho da população, apenas uma ordem entre as diversas categorias de colônias humanas) - Village = aldeia (povoado conflita com a tradução que a Wikipédia dá para hamlet) - Living street = rua viva (sugestão que eu copiei de uma tradução que eu achei no Linguee.pt, mas como não existe de fato em português, podemos inventar) - Fountain = chafariz (apenas fonte ornamental segundo a descrição no wiki do OSM, fonte de água potável é o elemento drinking water que não é o mapeado pelo iD) 2013/8/4 Wille wi...@wille.blog.br Hoje revisei parte dos presets e fiquei em dúvida sobre algumas traduções. Acho que a definição da tradução é muito importante, pois vai afetar bastante como os novos usuários vão mapear. Aeroway - Via Aérea (acho que seria melhor manter o termo em inglês ou aerovia) Apron - Plataforma de Estacionamento em Aeroporto (também acho que seria melhor manter o termo em inglês, visto que é um termo técnico da aeronáutica) Town - Vila (esse é um problema de definição do OSM, mas no Brasil usa-se vila como parte de uma cidade, então sugiro traduzir como Cidade de até 10 mil habitantes ou Pequena Cidade) Village - Povoado (estava como Aldeia, mas mudei para Povoado, visto que aldeia é um temo mais utilizado para designar lugares indígenas. Talvez o mais adequado fosse Vila / Povoado) Living Street - Rua Viva (talvez rua preferencial para pedestres fique mais claro) Fountain - Chafariz (o problema é que Fountain pode significar tanto fonte ornamental quanto fonte de água potável. Acho que o termo fonte é mais popular do que chafariz, então sugiro colocar os dois: Chafariz / Fonte) O que acham? Parabéns a quem ajudou a traduzir, somos um dos 5 idiomas com 100% do iD traduzido! abçs, wille On 31-07-2013 16:08, Vitor George wrote: Pessoal, Em breve sairá nova versão do iD e seria legal avançar na tradução para o português. Aqui está o link para quem puder ajudar: https://www.transifex.com/projects/p/id-editor/language/pt_BR/ Vitor -- Forwarded message -- From: Transifex ad...@transifex.com Date: Wed, Jul 31, 2013 at 2:49 PM Subject: [Transifex] New announcement in project iD Editor To: vitor.geo...@gmail.com Hi Vitor George, you have a notification from Transifex. A new announcementhttps://www.transifex.com/projects/p/id-editor/announcement/36685/has been added to the project iD Editor: 1.1 release upcoming Hello and thanks to all translators. This is just a quick announcement that iD 1.1 is nearing release. Immediately prior to the release I will update the translations from Transifex, so get them in now. Thank you! -- The Transifex Robot https://www.transifex.com Modify notification settingshttps://www.transifex.com/settings/notices/ ___ Talk-br mailing listTalk-br@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's
Re: [Talk-br] Fwd: [Transifex] New announcement in project iD Editor
City e Town no brasil, que assim seja. Apron: Não seriam melhor usar o termo Pátio ou Pátio de Aeronaves? From: fernando.treb...@gmail.com Date: Sun, 4 Aug 2013 14:05:37 + To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Fwd: [Transifex] New announcement in project iD Editor Oi Wille, Acho que estamos com uma preocupação parecida. Desde que eu ajudei com as traduções do iD, decidi retomar esse assunto (que eu já tinha começado há meses para a tradução do JOSM, mas parei). Queria centralizar no wiki e no fórum as discussões sobre as melhores traduções para cada termo, especialmente os termos mais difíceis. Acho que várias cabeças pensando juntas vão produzir um resultado melhor. Eu ia postar isso mais tarde quando tivesse concluído a minha parte, mas se você já quiser ir dando uma olhada: https://docs.google.com/spreadsheet/ccc?key=0Aut_CDnmHfE7dEg2ZVRRM1M2WVdudnVMdzV4bG5FeUEusp=sharing Abre um post lá no fórum, é mais fácil pra manter um registro da discussão. Sobre os termos que você citou, as minhas traduções sugeridas são: - Aeroway = aerovia (o termo em inglês é um neologismo, então podemos inventar também) - Apron = plataforma de estacionamento (é como a wikipédia traduz - sugiro acrescentar em aeroporto pra não confundir com outros estacionamentos), mas podemos usar apron se todos concordarem - Town = vila (é como a wikipédia traduz, o termo original em inglês não pressupõe nada sobre o tamanho da população, apenas uma ordem entre as diversas categorias de colônias humanas) - Village = aldeia (povoado conflita com a tradução que a Wikipédia dá para hamlet) - Living street = rua viva (sugestão que eu copiei de uma tradução que eu achei no Linguee.pt, mas como não existe de fato em português, podemos inventar) - Fountain = chafariz (apenas fonte ornamental segundo a descrição no wiki do OSM, fonte de água potável é o elemento drinking water que não é o mapeado pelo iD) 2013/8/4 Wille wi...@wille.blog.br Hoje revisei parte dos presets e fiquei em dúvida sobre algumas traduções. Acho que a definição da tradução é muito importante, pois vai afetar bastante como os novos usuários vão mapear. Aeroway - Via Aérea (acho que seria melhor manter o termo em inglês ou aerovia) Apron - Plataforma de Estacionamento em Aeroporto (também acho que seria melhor manter o termo em inglês, visto que é um termo técnico da aeronáutica) Town - Vila (esse é um problema de definição do OSM, mas no Brasil usa-se vila como parte de uma cidade, então sugiro traduzir como Cidade de até 10 mil habitantes ou Pequena Cidade) Village - Povoado (estava como Aldeia, mas mudei para Povoado, visto que aldeia é um temo mais utilizado para designar lugares indígenas. Talvez o mais adequado fosse Vila / Povoado) Living Street - Rua Viva (talvez rua preferencial para pedestres fique mais claro) Fountain - Chafariz (o problema é que Fountain pode significar tanto fonte ornamental quanto fonte de água potável. Acho que o termo fonte é mais popular do que chafariz, então sugiro colocar os dois: Chafariz / Fonte) O que acham? Parabéns a quem ajudou a traduzir, somos um dos 5 idiomas com 100% do iD traduzido! abçs, wille On 31-07-2013 16:08, Vitor George wrote: Pessoal, Em breve sairá nova versão do iD e seria legal avançar na tradução para o português. Aqui está o link para quem puder ajudar: https://www.transifex.com/projects/p/id-editor/language/pt_BR/ Vitor -- Forwarded message -- From: Transifex ad...@transifex.com Date: Wed, Jul 31, 2013 at 2:49 PM Subject: [Transifex] New announcement in project iD Editor To: vitor.geo...@gmail.com Hi Vitor George, you have a notification from Transifex. A new announcement has been added to the project iD Editor: 1.1 release upcoming Hello and thanks to all translators. This is just a quick announcement that iD 1.1 is nearing release. Immediately prior to the release I will update the translations from Transifex, so get them in now. Thank you! -- The Transifex Robot Modify notification settings ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br
Re: [Talk-br] Fwd: [Transifex] New announcement in project iD Editor
Oi Blademir, Só pra avisar, na discussão que está se desenrolando no fórum, acho que chegamos a um bom nome para living street: via partilhada com pedestres. Foi inspirado no conceito australiano de shared zone: http://en.wikipedia.org/wiki/Shared_Zone 2013/8/4 Fernando Trebien fernando.treb...@gmail.com: Já troquei pra pátio na minha planilha. :D Certamente viela significa rua estreita. O problema é que living street quer dizer outra coisa. Nem no wiki nem na Wikipédia há menção à largura da rua, mas ambos se referem à dificuldade de passar pela via devido à presença de pedestres, que nela têm a preferência para circulação. Considerando isso, nem viela nem rua viva traduzem bem essa definição. Viela porque sugere que a rua é estreita (ela pode ser, mas nem sempre é), e rua viva porque a rua não está de fato viva. Aí vão mais algumas idéias. Características citadas no wiki (http://wiki.openstreetmap.org/wiki/Tag:highway%3Dliving_street): - generally have lower speed limits, and special traffic/parking rules compared to streets tagged using highway=residential - Terms for these street vary considerably around the world and include Home Zone (UK), Woonerf (Netherlands/Flanders), 'Verkehrsberuhigter Bereich' - Home Zone: zona de habitação/moradia - http://en.wikipedia.org/wiki/Home_zone - Woonerf: bairro/zona residencial - Verkehrsberuhigter Bereich: zona de tráfego acalmado Todos os países listados têm velocidade máxima de 20km/h e preferência ao tráfego de pedestres nessas ruas. A primeira característica é fácil descrever: via de baixa velocidade. A segunda, nem tanto, pode se confundir com calçadão, como você disse, exceto que no calçadão o acesso a veículos é proibido. Dentre os países listados, apenas a Itália não usa living streets, onde eles decidiram usar living street apenas nos raros lugares onde aparece uma placa específica. E só a Inglaterra tem uma menção a ruas estreitas no código de trânsito (e pelo wiki, parece que living street se aplica a esse caso lá também): https://www.gov.uk/road-users-requiring-extra-care-204-to-225/pedestrians-205-to-210 Características citadas na Wikipédia (http://en.wikipedia.org/wiki/Living_street): - França: Zone de rencontre (zona de reunião/encontro) - Suécia: Gångfartsområde (zona de velocidade de caminhada) - Suíça: Begegnungszone (zona de encontro) - Estados Unidos: Complete street (rua completa) - http://en.wikipedia.org/wiki/Complete_streets - Outros países: rua/zona/área residencial Que tal coisas mais como rua em zona de encontro (talvez impreciso demais), rua em zona de pedestres (talvez com um pouco de confusão ainda) ou rua em zona de caminhada (que pode dar a impressão de uma área de esportes)? 2013/8/4 Blademir Andrade de Lima blademi...@hotmail.com: Boa Noite. Bom, a tradução que encontrei para o Living street seria Viela, que se encaixaria para o seu uso no Brasil. City e Town acho melhor abrirmos um outra discussão porque essa vai render. Apron: Eu voto pelo termo Pátio. Fiz umas traduções do JOSM, seria ideal que entre elas e o ID sejam as mesmas. Forte Abraço Blademir Andrade de Lima From: fernando.treb...@gmail.com Date: Sun, 4 Aug 2013 14:42:40 + To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Fwd: [Transifex] New announcement in project iD Editor Hehe ok, fui eu mesmo quem insistiu no uso de living street para ruas muito estreitas e para as preferenciais de pedestre, como você tem usado. A comunidade ainda não me parece concordar plenamente com esses usos, e certamente isso tem um impacto na tradução que escolhermos para o termo. Que outros termos você sugere então? City e town é a mesmo tipo de problema, acho que nunca foi discutido aqui. Não vejo muito motivo pra não usar essa distinção se isso afeta o renderizador (especialmente nos níveis de ampliação mais afastados). Só faria sentido não usar se todas as cidades estivessem com a tag population preenchida, mas não é o caso. Apron: pátio é o termo que se usa nos aeroportos? Agora vi que a Wikipédia usa pátio num artigo e plataforma em outro. http://en.wikipedia.org/wiki/Airport_apron http://pt.wikipedia.org/wiki/Plataforma_de_estacionamento http://pt.wikipedia.org/wiki/Aer%C3%B3dromo Se não houver diferença, prefiro pátio porque é mais curto e não confunde com outras plataformas. Mas acrescentaria de aeródromo para que os seus usos fiquem claros. 2013/8/4 Blademir Andrade de Lima blademi...@hotmail.com Bom Dia a todos. Gostaria de discordar da tradução de Living street, o qual a tradução Rua Viva não se encaixa perfeitamente. Living Street são as ruas em que pedestres tem a preferencial, e não a exclusividade (o qual são os Calçadões). O Termo Living seria viver, morar (no caso) e não viva, o qual é Live. No Brasil ja usei estas marcações, mas para aquelas ruas bem estreitas, onde carros passam muito devagar e que pedestres tem preferencial
Re: [Talk-br] Fwd: [Transifex] New announcement in project iD Editor
O endereço do post é esse: http://forum.openstreetmap.org/viewtopic.php?id=22084 Basta você acessar o link, clicar em Login e digitar o mesmo login (e-mail ou nome de usuário + senha) que você usa para fazer contribuições no OSM. 2013/8/5 Blademir Andrade de Lima blademi...@hotmail.com: Perfeito. Como faço para participar do forum? Abraços From: fernando.treb...@gmail.com Date: Mon, 5 Aug 2013 02:01:31 + To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Fwd: [Transifex] New announcement in project iD Editor Oi Blademir, Só pra avisar, na discussão que está se desenrolando no fórum, acho que chegamos a um bom nome para living street: via partilhada com pedestres. Foi inspirado no conceito australiano de shared zone: http://en.wikipedia.org/wiki/Shared_Zone 2013/8/4 Fernando Trebien fernando.treb...@gmail.com: Já troquei pra pátio na minha planilha. :D Certamente viela significa rua estreita. O problema é que living street quer dizer outra coisa. Nem no wiki nem na Wikipédia há menção à largura da rua, mas ambos se referem à dificuldade de passar pela via devido à presença de pedestres, que nela têm a preferência para circulação. Considerando isso, nem viela nem rua viva traduzem bem essa definição. Viela porque sugere que a rua é estreita (ela pode ser, mas nem sempre é), e rua viva porque a rua não está de fato viva. Aí vão mais algumas idéias. Características citadas no wiki (http://wiki.openstreetmap.org/wiki/Tag:highway%3Dliving_street): - generally have lower speed limits, and special traffic/parking rules compared to streets tagged using highway=residential - Terms for these street vary considerably around the world and include Home Zone (UK), Woonerf (Netherlands/Flanders), 'Verkehrsberuhigter Bereich' - Home Zone: zona de habitação/moradia - http://en.wikipedia.org/wiki/Home_zone - Woonerf: bairro/zona residencial - Verkehrsberuhigter Bereich: zona de tráfego acalmado Todos os países listados têm velocidade máxima de 20km/h e preferência ao tráfego de pedestres nessas ruas. A primeira característica é fácil descrever: via de baixa velocidade. A segunda, nem tanto, pode se confundir com calçadão, como você disse, exceto que no calçadão o acesso a veículos é proibido. Dentre os países listados, apenas a Itália não usa living streets, onde eles decidiram usar living street apenas nos raros lugares onde aparece uma placa específica. E só a Inglaterra tem uma menção a ruas estreitas no código de trânsito (e pelo wiki, parece que living street se aplica a esse caso lá também): https://www.gov.uk/road-users-requiring-extra-care-204-to-225/pedestrians-205-to-210 Características citadas na Wikipédia (http://en.wikipedia.org/wiki/Living_street): - França: Zone de rencontre (zona de reunião/encontro) - Suécia: Gångfartsområde (zona de velocidade de caminhada) - Suíça: Begegnungszone (zona de encontro) - Estados Unidos: Complete street (rua completa) - http://en.wikipedia.org/wiki/Complete_streets - Outros países: rua/zona/área residencial Que tal coisas mais como rua em zona de encontro (talvez impreciso demais), rua em zona de pedestres (talvez com um pouco de confusão ainda) ou rua em zona de caminhada (que pode dar a impressão de uma área de esportes)? 2013/8/4 Blademir Andrade de Lima blademi...@hotmail.com: Boa Noite. Bom, a tradução que encontrei para o Living street seria Viela, que se encaixaria para o seu uso no Brasil. City e Town acho melhor abrirmos um outra discussão porque essa vai render. Apron: Eu voto pelo termo Pátio. Fiz umas traduções do JOSM, seria ideal que entre elas e o ID sejam as mesmas. Forte Abraço Blademir Andrade de Lima From: fernando.treb...@gmail.com Date: Sun, 4 Aug 2013 14:42:40 + To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Fwd: [Transifex] New announcement in project iD Editor Hehe ok, fui eu mesmo quem insistiu no uso de living street para ruas muito estreitas e para as preferenciais de pedestre, como você tem usado. A comunidade ainda não me parece concordar plenamente com esses usos, e certamente isso tem um impacto na tradução que escolhermos para o termo. Que outros termos você sugere então? City e town é a mesmo tipo de problema, acho que nunca foi discutido aqui. Não vejo muito motivo pra não usar essa distinção se isso afeta o renderizador (especialmente nos níveis de ampliação mais afastados). Só faria sentido não usar se todas as cidades estivessem com a tag population preenchida, mas não é o caso. Apron: pátio é o termo que se usa nos aeroportos? Agora vi que a Wikipédia usa pátio num artigo e plataforma em outro. http://en.wikipedia.org/wiki/Airport_apron http://pt.wikipedia.org/wiki/Plataforma_de_estacionamento http://pt.wikipedia.org/wiki/Aer%C3%B3dromo Se não houver diferença, prefiro pátio porque é mais curto e não
Re: [Talk-br] linha de ônibus
Na verdade, esse ponto é um pouco polêmico. A recomendação de separar quando há barreira física não é pra ficar bonito no mapa (o que seria o mesmo que mapear para o renderizador) e sim para representar que o lado oposto da via não pode ser acessado diretamente (ou seja, não basta chegar até o local e atravessar pro destino virando à esquerda em qualquer ponto da via). Exatamente o mesmo ocorre quando há separação legal. http://www.mail-archive.com/talk-us@openstreetmap.org/msg07430.html http://gis.19327.n5.nabble.com/Carriageway-divider-tp5721108p5721131.html De qualquer forma, seria necessário representar a separação legal de algum jeito, ou como via separada ou com alguma tag, para que os programas de roteamento saibam por qual direção eles devem abordar o destino (em alguns casos, isso leva a rotas muito diferentes, e ignorar isso pode causar grandes inconveniências). Eu sou totalmente a favor de uma marcação com tags (é muito mais fácil de manter), mas as únicas propostas envolvendo isso foram abandonadas: http://wiki.openstreetmap.org/wiki/Proposed_features/Divider http://wiki.openstreetmap.org/wiki/Proposed_features/Divided_road Existe também esta proposta aprovada, que surpreendentemente não inclui separadores legais: http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension Idealmente isso seria feito também fora do meio urbano, mas daí minha opinião é mais flexível. Na prática, quase sempre você vai chegar a algo que está do outro lado da divisão legal parando no acostamento e esperando o tráfego dar uma oportunidade de atravessar (isso quase nunca vale em meio urbano). Além disso, quase nunca há caminhos alternativos, então você só teria essa opção mesmo. Quando você tiver alternativas (por exemplo, em pequenas povoações, que valem como área urbana, ainda que pequena), acho melhor mapear separadamente. 2013/8/1 Flavio Bello Fialho bello.fla...@gmail.com: Só mapeie em duas vias separadas se tiver barreira física. Divisão legal não é barreira física. Em 31/07/2013 22:34, Fernando Trebien fernando.treb...@gmail.com escreveu: Primeira questão: não é o caso de uma via separada? (Será separada se tiver barreira física ou, em área urbana, divisão legal, como por exemplo uma faixa contínua separando os sentidos.) Se for separada, primeiro separe-a em duas vias, daí o pedaço de ida é diferente do da volta, e ambos são adicionados à relação. Segunda questão: a ida e a volta coincidentes são na mesma relação de rota? O costume é separar o caminho de ida e o de volta em duas relações de rota diferentes, e daí agrupar as duas numa relação route_master (http://wiki.openstreetmap.org/wiki/Relation:route_master). Assim, a chance de a mesma rota passar duas vezes pela mesma via é menor (mas ainda assim pode acontecer). Exemplo: http://www.openstreetmap.org/browse/relation/1148315 Se não for nenhum dos casos anteriores, sim, você acrescenta a via duas vezes na relação, uma vez com o papel forward e outra vez com o papel backward. Será forward se o ônibus estiver indo na mesma direção da aresta (way), senão será backward. Como você está mapeando as rotas? A melhor sugestão que eu posso lhe dar é usar o plug-in public_transport do JOSM. Com ele, você consegue: - verificar se há pedaços faltando na sua rota - verificar se todos os pedaços foram incluídos na relação na ordem certa (a ordem seguida pelo ônibus ao longo do trajeto) e com os papéis certos (de modo que o final de um membro coincida com o início do próximo membro na relação) - adicionar paradas de ônibus às rotas automaticamente 2013/7/31 Claiton Neisse claiton.nei...@gmail.com: Salve pessoal. Qual a melhor maneira de mapear uma linha de ônibus que vai e volta por uma mesma via? Ou que passa mais de uma vez por uma via de mão dupla? Se adiciona a via mais de uma vez na relação? Atenciosamente, Claiton Neisse ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Endereçamento com interpoladores
Pois é, faz um certo sentido pra eles porque nem todos os países seguem essa regra de numeração baseada na distância do início da via. Pra nós seria mais conveniente que essa regra não existisse. Mas fazer o quê? Continuo achando que não está errado, mas é bom saber pra incluir um tratamento disso em scripts e conversores. 2013/7/31 Roger C. Soares rogersoa...@gmail.com: E a resolução lá foi rápida :). É o tamanho mesmo, a distância tem que ser menor que 1000m. Talvez o que dê pra melhorar é o fato de se adicionar um número no meio e não reindexar. Depois eu coloco uns números no meio dessa e da independência pra ver se alguma funciona sem ter que quebrar ou recriar a interpolação... e por enquanto eu vou parar de conectar nros muito longes... Atenciosamente, Roger. -- Fernando Trebien escreveu: Postei essa informação lá. Começo a desconfiar que é por causa do tamanho do intervalo (mais de 1000 números), mas vamos aguardar a resposta deles. 2013/7/30 Roger C. Soares rogersoa...@gmail.com: Ok, sem problema. Só pra ser mais preciso, o intervalo de 555 a 1855 pra mim não funcionou em nenhuma situação, qdo eu quebrei em 3 caminhos ficou exatamente como está agora.. só retornava para o intervalo de 1855 a 2089. Atenciosamente, Roger. -- Fernando Trebien escreveu: Hm olha só, o Nominatim não está gerando os números de 555 a 1855, mas os outros sim. Já criei um ticket descrevendo essa situação (https://trac.openstreetmap.org/ticket/4925), então peço pra você não alterar o interpolador até que eles investiguem. (Da última vez, demoraram umas 2 semanas para me dar uma resposta.) 2013/7/30 Fernando Trebien fernando.treb...@gmail.com: Eu já vi alguém descrevendo alguma situação parecida no TRAC do Nominatim, acho que é um bug conhecido (e até acho que já aconteceu comigo, mas como alterei mais coisas de uma vez só, não tive certeza). De qualquer forma, estava tão certo o jeito que você fez antes quanto está agora quanto estava quando quebrado em 3 partes (só um pouquinho menos eficiente). Era pra funcionar em todas essas situações. Também já passei por casos em que o Nominatim demorou pra atualizar, então eu sugiro que você olhe 1 dia depois da alteração pra confirmar que continua funcionando. Se sim, me avisa que eu abro o bug. De qualquer forma, sugeriria deixar como está até que eles olhem o problema e, se não consertarem, daí quebrar em 3 partes de novo (ruim, mas podemos fazer muito pouco, a menos que criemos um serviço alternativo ao Nominatim). 2013/7/30 Roger C. Soares rogersoa...@gmail.com: Recaptulando, Rua Campos Salles, Ribeirão Preto, No início nenhum nro aparecia nas buscas: 555|1855--|2089 (1 way) Depois adicionei o nro 2005 na interpolação e continuou não retornando nros nas buscas: 555|1855---2005-|2089 (1 way) Depois apenas quebrei a interpolação em 3 caminhos, de 1855 a 2089 começou a funcionar: 555||1855|---|2005|-|2089 (3 ways) E por último combinei o caminho da interpolação em 1 novamente, e de 1855 a 2089 continuou funcionando: 555|1855---2005-|2089 (1 way) Eu não vou abrir bug por enquanto, mas se vc quiser abrir manda ver. Capaz que exista alguma limitação de tamanho mesmo, na av independência tem uma interpolação que vai de 1500 a 2514 que tb não funciona. Talvez como ela já foi indexada, se eu colocar outros nros no meio não seja suficiente para reindexar, teria que apagar o caminho e criar um novo... Atenciosamente, Roger. -- Fernando Trebien escreveu: Agora entendi. Bem, deixar os terminais vazios não faria muito sentido. Nesse caso o melhor ou é dar um número aproximado ou colocar os terminais com uma tag fixme pedindo para alguém avaliar o melhor número. Eu tenho esse costume em Porto Alegre: vou marcando várias coisas com fixme, depois tiro 1 dia pra fazer inspeção e resolver as dúvidas. Tem funcionado muito bem. Agora sinceramente não sei por que os seus interpoladores não funcionam, tudo me parece correto. Uma sugestão: tente quebrá-los em algum ponto (digamos, na metade) e veja se alguma coisa muda (se um dos lados passa a funcionar, ou ambos). Se mudar, sugiro que você desfaça a sua alteração, verifique que parou de funcionar de novo, e daí abra um ticket no TRAC do Nominatim (se você quiser posso fazer isso) relatando o problema: https://trac.openstreetmap.org 2013/7/27 Roger C. Soares rogersoa...@gmail.com: Nesse meu comentário eu estava pensando nos nós terminais vazios: []_[20]_[40]_[] / \ []---highway-[] Até um tempo atrás eu imaginava que ele pudesse tirar uma média e calcular que o primeiro nó é próximo do 0 e o último próximo do 60. Assim, se alguém buscasse por 10 ou 50 um ponto na rua seria retornado, mesmo a casa 20 sendo a primeira e a 40 a última. Quanto a rejeitar apenas o
Re: [Talk-br] linha de ônibus
Primeira questão: não é o caso de uma via separada? (Será separada se tiver barreira física ou, em área urbana, divisão legal, como por exemplo uma faixa contínua separando os sentidos.) Se for separada, primeiro separe-a em duas vias, daí o pedaço de ida é diferente do da volta, e ambos são adicionados à relação. Segunda questão: a ida e a volta coincidentes são na mesma relação de rota? O costume é separar o caminho de ida e o de volta em duas relações de rota diferentes, e daí agrupar as duas numa relação route_master (http://wiki.openstreetmap.org/wiki/Relation:route_master). Assim, a chance de a mesma rota passar duas vezes pela mesma via é menor (mas ainda assim pode acontecer). Exemplo: http://www.openstreetmap.org/browse/relation/1148315 Se não for nenhum dos casos anteriores, sim, você acrescenta a via duas vezes na relação, uma vez com o papel forward e outra vez com o papel backward. Será forward se o ônibus estiver indo na mesma direção da aresta (way), senão será backward. Como você está mapeando as rotas? A melhor sugestão que eu posso lhe dar é usar o plug-in public_transport do JOSM. Com ele, você consegue: - verificar se há pedaços faltando na sua rota - verificar se todos os pedaços foram incluídos na relação na ordem certa (a ordem seguida pelo ônibus ao longo do trajeto) e com os papéis certos (de modo que o final de um membro coincida com o início do próximo membro na relação) - adicionar paradas de ônibus às rotas automaticamente 2013/7/31 Claiton Neisse claiton.nei...@gmail.com: Salve pessoal. Qual a melhor maneira de mapear uma linha de ônibus que vai e volta por uma mesma via? Ou que passa mais de uma vez por uma via de mão dupla? Se adiciona a via mais de uma vez na relação? Atenciosamente, Claiton Neisse ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] linha de ônibus
Na verdade eu estou no meio do processo de importação das informações do transporte público em Porto Alegre: http://forum.openstreetmap.org/viewtopic.php?id=21839 Mas não sei se ajuda muito no seu caso. O melhor mesmo é tentar um contato com a empresa de transportes no local. Se eu não tivesse conseguido os dados do PoaTransporte, talvez tivesse copiado as rotas à mão do mapa em PDF e deixado as paradas como tarefa a ser feita a longo-prazo por várias pessoas. Quanto à tag network, tenho colocado EPTC por ser a empresa que organiza o transporte na cidade, reunindo as informações de todas as empresas de ônibus. Não tenho certeza absoluta de que está certo, se eu mudar de idéia comparando com outros países, te aviso. Um dos grandes desafios é popular o arquivo GTFS com os dados corretos. Um dos requisitos é o horário em que cada ônibus passa em cada parada. Pelo menos em Porto Alegre, só há os horários de saída dos terminais, não os horários por parada. Estamos pensando em gerar esses horários de forma automática. 2013/8/1 Claiton Neisse claiton.nei...@gmail.com: Não era nenhum dos casos que você citou. Era mesmo sobre uma linha de ônibus que cruza duas vezes por uma via de mão dupla sem divisão física ou sinalização horizontal. Mas, foi bom me lembrar de separar as vias urbanas que tem uma divisão legal. Eu tenho feito uma relação para cada sentido e agrupando-as numa route_master (junto com relações com itinerários ligeiramente diferentes). Na verdade, ainda não criei uma relação desse tipo, mas já pensava assim. Até agora criei poucas rotas de transporte coletivo urbano e intermunicipal na região de Santa Maria - RS. É extremamente (tenho quase certeza que não existem) dificil conseguir informações de órgãos públicos e de empresas que operam as linhas, então tenho inserido as que eu conheço. Mas, em Outubro fica pronto um Plano de Mobilidade Urbana, e então talvez consiga. Também em Outubro fica pronto um levantamento aerofotogrametrico na escala 1:2000 da area urbana do município. Eu não estava utilizando o plugin public_transport, mas vou passar a utiliza-lo, facilita as edições. E mexendo nele, lembrei de outras coisas: Como utilizar a tag network em linhas de transporte coletivo urbano (dentro do municipio)? A segunda lembrei vendo a opção criar pontos a partir de gtfs... Conheci o responsável pelo trafeguebem.com.br no FISL e eu sugeri pra ele usar OSM + OTP + GTFS (como a intenção dele é abrir o projeto e ter informações de todo estado, nada mais natural que usar o OSM). Sabe qual é a situação do OSM, em POA, referente as informações sobre o transporte público? Abraços, Claiton Neisse Em 31 de julho de 2013 22:34, Fernando Trebien fernando.treb...@gmail.com escreveu: Primeira questão: não é o caso de uma via separada? (Será separada se tiver barreira física ou, em área urbana, divisão legal, como por exemplo uma faixa contínua separando os sentidos.) Se for separada, primeiro separe-a em duas vias, daí o pedaço de ida é diferente do da volta, e ambos são adicionados à relação. Segunda questão: a ida e a volta coincidentes são na mesma relação de rota? O costume é separar o caminho de ida e o de volta em duas relações de rota diferentes, e daí agrupar as duas numa relação route_master (http://wiki.openstreetmap.org/wiki/Relation:route_master). Assim, a chance de a mesma rota passar duas vezes pela mesma via é menor (mas ainda assim pode acontecer). Exemplo: http://www.openstreetmap.org/browse/relation/1148315 Se não for nenhum dos casos anteriores, sim, você acrescenta a via duas vezes na relação, uma vez com o papel forward e outra vez com o papel backward. Será forward se o ônibus estiver indo na mesma direção da aresta (way), senão será backward. Como você está mapeando as rotas? A melhor sugestão que eu posso lhe dar é usar o plug-in public_transport do JOSM. Com ele, você consegue: - verificar se há pedaços faltando na sua rota - verificar se todos os pedaços foram incluídos na relação na ordem certa (a ordem seguida pelo ônibus ao longo do trajeto) e com os papéis certos (de modo que o final de um membro coincida com o início do próximo membro na relação) - adicionar paradas de ônibus às rotas automaticamente 2013/7/31 Claiton Neisse claiton.nei...@gmail.com: Salve pessoal. Qual a melhor maneira de mapear uma linha de ônibus que vai e volta por uma mesma via? Ou que passa mais de uma vez por uma via de mão dupla? Se adiciona a via mais de uma vez na relação? Atenciosamente, Claiton Neisse ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br
Re: [Talk-br] Transformar polígonos inteiriços em relações
Tem uma maneira meio fácil. Primeiro você cria uma relação para cada polígono (um pouco trabalhoso), depois quebra as bordas coincidentes (fácil com um plug-in). Em detalhes: - instale o plug-in merge-overlap no JOSM (precisa reiniciar a aplicação) - abra os polígonos que você importou no JOSM - para cada polígono individualmente, selecione-o e vá em More Tools Create multipolygon (ou simplesmente Ctrl+Alt+A) - selecione todos os polígonos (com uma busca por closed) e depois vá em More Tools Merge overlap Como é uma receita de bolo que pode ser útil pra mais pessoas, estou copiando pra lista. Detalhe: por alguma razão o meu JOSM mostra dois menus More Tools com a opção Merge overlap apenas no segundo, pode acontecer com o de vocês também. 2013/7/29 Vítor Rodrigo Dias vitor.d...@gmail.com: Fernando, Existe alguma maneira fácil de fazer essa transformação? Baixei os arquivos de setores censitários do IBGE em Minas Gerais para trabalhar com alguns níveis de limites e não sei como fazer essa transformação. Abraços, Vítor Rodrigo Dias Revisor de textos Tradutor port/ing/port e port/esp/port Telefone: (31) 9895-3975 - TIM -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Endereçamento com interpoladores
Eu já vi alguém descrevendo alguma situação parecida no TRAC do Nominatim, acho que é um bug conhecido (e até acho que já aconteceu comigo, mas como alterei mais coisas de uma vez só, não tive certeza). De qualquer forma, estava tão certo o jeito que você fez antes quanto está agora quanto estava quando quebrado em 3 partes (só um pouquinho menos eficiente). Era pra funcionar em todas essas situações. Também já passei por casos em que o Nominatim demorou pra atualizar, então eu sugiro que você olhe 1 dia depois da alteração pra confirmar que continua funcionando. Se sim, me avisa que eu abro o bug. De qualquer forma, sugeriria deixar como está até que eles olhem o problema e, se não consertarem, daí quebrar em 3 partes de novo (ruim, mas podemos fazer muito pouco, a menos que criemos um serviço alternativo ao Nominatim). 2013/7/30 Roger C. Soares rogersoa...@gmail.com: Recaptulando, Rua Campos Salles, Ribeirão Preto, No início nenhum nro aparecia nas buscas: 555|1855--|2089 (1 way) Depois adicionei o nro 2005 na interpolação e continuou não retornando nros nas buscas: 555|1855---2005-|2089 (1 way) Depois apenas quebrei a interpolação em 3 caminhos, de 1855 a 2089 começou a funcionar: 555||1855|---|2005|-|2089 (3 ways) E por último combinei o caminho da interpolação em 1 novamente, e de 1855 a 2089 continuou funcionando: 555|1855---2005-|2089 (1 way) Eu não vou abrir bug por enquanto, mas se vc quiser abrir manda ver. Capaz que exista alguma limitação de tamanho mesmo, na av independência tem uma interpolação que vai de 1500 a 2514 que tb não funciona. Talvez como ela já foi indexada, se eu colocar outros nros no meio não seja suficiente para reindexar, teria que apagar o caminho e criar um novo... Atenciosamente, Roger. -- Fernando Trebien escreveu: Agora entendi. Bem, deixar os terminais vazios não faria muito sentido. Nesse caso o melhor ou é dar um número aproximado ou colocar os terminais com uma tag fixme pedindo para alguém avaliar o melhor número. Eu tenho esse costume em Porto Alegre: vou marcando várias coisas com fixme, depois tiro 1 dia pra fazer inspeção e resolver as dúvidas. Tem funcionado muito bem. Agora sinceramente não sei por que os seus interpoladores não funcionam, tudo me parece correto. Uma sugestão: tente quebrá-los em algum ponto (digamos, na metade) e veja se alguma coisa muda (se um dos lados passa a funcionar, ou ambos). Se mudar, sugiro que você desfaça a sua alteração, verifique que parou de funcionar de novo, e daí abra um ticket no TRAC do Nominatim (se você quiser posso fazer isso) relatando o problema: https://trac.openstreetmap.org 2013/7/27 Roger C. Soares rogersoa...@gmail.com: Nesse meu comentário eu estava pensando nos nós terminais vazios: []_[20]_[40]_[] / \ []---highway-[] Até um tempo atrás eu imaginava que ele pudesse tirar uma média e calcular que o primeiro nó é próximo do 0 e o último próximo do 60. Assim, se alguém buscasse por 10 ou 50 um ponto na rua seria retornado, mesmo a casa 20 sendo a primeira e a 40 a última. Quanto a rejeitar apenas o intervalo que não passou na validação, vc tem razão. Percebi agora que um dos exemplos que eu estava usando tem um nro no meio que está estragando a sequência. Acho que era um prédio em construção, ou eu digitei errado ou eles colocaram um nro estranho, preciso voltar lá. Em Ribeirão Preto, na Quintino Bocaiúva, apesar do segundo intervalo não retornar, o primeiro retorna, realmente boa notícia: Rua Quintino Bocaiúva - de 9 a 275 (266 nros), 220m Já na campos salles, os 2 intervalos não retornam, apesar de terem menos nros por metro que na quintino: Rua Campos Salles - de 555 a 1855 (1300 nros), 1310m Rua Campos Salles - de 1855 a 2089 (234 nros), 230m Talvez pq os nros estão muito distantes um do outro? Atenciosamente, Roger. -- Fernando Trebien escreveu: Olha, ele aceita nós sem número sim. Esses nós servem apenas para fazer o interpolador acompanhar melhor as curvas da via principal. Veja este nó por exemplo: http://www.openstreetmap.org/browse/node/2249544793 Daí onde diz Parte de, clique no link para ver o interpolador. Ele é bem longo e cheio de nós, alguns com número, outros sem. Os sem número ficam totalmente sem tags. Outro nó no mesmo interpolador (logo ao lado do anterior), mas com número: http://www.openstreetmap.org/browse/node/2248442311 Se você agora buscar por avenida guaíba 10740 poa vai encontrar um resultado. Uma coisa interessante sobre esse interpolador (que diz algo sobre como funciona o Nominatim) é que a verificação de sanidade rejeita o primeiro intervalo, de 9894 a 10652, mas não rejeita os demais (boa notícia). Nesse intervalo há uma diferença de 758 números em uma distância de 92 metros. (Esse é o caso mais
Re: [Talk-br] Nomes de rua abreviados
Há um tempo eu fiz um script em Python para arquivos .osm que faz substituições de strings (incluindo expressões regulares) nos valores das tags escolhidas (filtradas pelo nome da chave e por tipo de elemento - nó, linha, relação, etc.) ajustando corretamente o atributo action de cada elemento e considerando ou ignorando maiúsculas e minúsculas. Ele funciona em linha de comando (inclui um help básico), mas ainda não tive tempo de concluir a interface gráfica (posso dar uma acelerada nisso e disponibilizar). Já usei ele em alguns datasets meus e em Brasília onde um usuário importou dados com problemas nos caracteres acentuados. Acho que seria útil para esse trabalho já que seria essencialmente substituir as seguintes expressões regulares (ignorando maiúsculas e minúsculas) nas linhas highway: ^R[. ] Rua ^Av[. ] Avenida Podemos fazer mais dessas, baseados nessa lista de abreviaturas: http://wiki.openstreetmap.org/wiki/Name_finder:Abbreviations#Portugu.C3.AAs_-_Portuguese O bot poderia simplesmente baixar os pedaços do mapa, aplicar o script e então submeter o resultado. 2013/7/25 Arlindo Pereira openstreet...@arlindopereira.com: Pessoal, a discussão sobre endereçamento me lembrou de um outro problema: ainda existem diversas cidades no país com uma grande quantidade de ruas com nomes abreviados. Por exemplo, Manaus: http://openstreetmap.org/?lat=-3.12454lon=-60.00528zoom=17layers=M Alguém anima uma força tarefa para corrigir isso? Me parece o tipo de tarefa apropriada para um bot. []s Arlindo Nighto Pereira ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Endereçamento com interpoladores
Eu sabia que deveria ter feito a rua 4 e a rua 5 no exemplo. :P Não tenho dúvidas de que é estritamente errado. Aliás, estritamente, os interpoladores são errados, pois produzem vários números interpolados que não existem na realidade. Tomando como exemplo as quadras de Buenos Aires de 100m de comprimento e com intervalo de numeração de 100 números: se houver 20 prédios em cada quadra (10 de cada lado da via), 80% dos números interpolados não existirão. Se são errados, por que são usados? Porque são úteis. A minha questão é se é útil ao usuário final saber que existe o buraco na numeração ou se é mais útil obter uma aproximação sempre que possível. Todos os outros mapas que eu conheço (particularmente os dois melhores, Google Maps e Nokia HERE Maps) não têm esses buracos. O meu receio é que um usuário, ao se deparar com um buraco desses, considere o OSM como um sistema inferior. Mas então, a rua 4 e a rua 5 seriam variações da rua 2, com uma modificação: estenderíamos a linha interpoladora através do cruzamento, passando pela via transversal. Na rua 4 a ligação entre os números de cada lado seria simplesmente uma linha reta. A rua 5 é o exemplo de como eu fiz em Porto Alegre, onde essa extensão passaria necessariamente pelo nó central do cruzamento. Acho que a rua 4 seria o melhor equilíbrio entre o útil e o estritamente correto. A rua 4 então modificaria a rua 2 acrecentando interpoladores (linhas retas) entre os números: 18 e 24, 15 e 27, 52 e 64, 69 e 63. O resultado: os números exatos são renderizados, e posições aproximadas são obtidas para todo o intervalo da numeração. Para completar, essas extensões que passam pelo cruzamento poderiam receber a tag addr:inclusion=potential. Que tal? 2013/7/25 Arlindo Pereira openstreet...@arlindopereira.com: O método 3 me parece estritamente errado. Os endereços não existem, ponto. Adicioná-los me parece, usando uma gíria carioca, forçação de barra para evitar uma falha/bug/feature do buscador. Uma espécie de tag for the renderer. []s 2013/7/25 Fernando Trebien fernando.treb...@gmail.com Uma imagem vale mais do que mil palavras, então só pra explicar melhor: http://i.imgur.com/uwNSCWA.png Ignorem os pontos e as cruzes amarelas (não me aventurei a descobrir uma forma de escondê-las). A rua 1 está feita com o método mais simples. Serve bem para as ruas onde a numeração obedeceu a regra da distância desde o início da rua. Tem a eventual desvantagem de, em alguns casos, gerar coordenadas que são mais próximas de uma das vias transversais do que da via principal. A rua 2 está feita da forma que eu observei no RJ. É a mais estritamente correta, mas se alguém procurar por um número que cairia dentro do cruzamento, nenhum resultado é encontrado. A rua 3 está feita da forma que eu observei em Buenos Aires. Notem que na rua mais à direita a numeração original foi preservada por causa da grande diferença de numeração entre os dois lados. Não é tão correta, mas a interpolação (por ser uma aproximação) também não é, e teria a vantagem de sempre chegar a uma posição aproximada (mesmo que o endereço não exista, ou seja um endereço novo ainda não mapeado, etc.). Penso que seja a melhor para conversores e importações automáticas, a menos que se tenha certeza do cuidado que tiveram com a numeração. Claro que todas esses métodos também servem para 1 único interpolador ao invés de 2 (um para cada lado). Se alguém quiser o arquivo original para modificar e fazer seus próprios exemplos: http://db.tt/vtIIhLjG O que eu fiz em Porto Alegre não é nenhum desses 3 métodos :P Seria basicamente um misto da rua 2 com a rua 1 passando a linha do interpolador pelo meio do cruzamento sempre. Mas estou tendendo mais ao método da rua 3 agora. 2013/7/25 Fernando Trebien fernando.treb...@gmail.com: Acho que não foi ainda bem estabelecida a forma mais correta de usar os interpoladores. Para o Nominatim e para o meu GPS (MapFactor Navigator) basta: - addr:interpolation na linha (o interpolador) que acompanha via principal pela lateral - addr:housenumber em alguns dos nós ao longo dessa linha, sempre acompanhado de addr:street com o valor correto (os nós sem número servem apenas para definir o contorno do interpolador e gerar coordenadas nos lugares certos, algo importante em curvas) Colocar addr:street na linha me pareceu o jeito mais natural desde o começo, mas acabei descobrindo que não é necessário. Por outro lado, repetir esse mesmo valor em cada nó com numeração me parece uma tremenda redundância de informação... não faço idéia do que a comunidade tinha em mente quando decidiram fazer assim. 2013/7/25 Arlindo Pereira openstreet...@arlindopereira.com: O que eu tenho feito é mapear vias com addr:street=[nome da rua] e addr:interpolation:[odd|even], com seus nós tendo addr:street=[nome da rua] (de novo) e addr:housenumber=[numero], uma para cada quarteirão. Por exemplo: Procurem por Rua Bento Lisboa
Re: [Talk-br] Endereçamento com interpoladores
Os dados que eu tenho registram apenas o número inicial e final de cada quadra. Ainda tenho que confirmar se são números reais ou potenciais (ex.: atribuindo número para um terreno na esquina onde nada foi construído ainda). Os do TrackSource eu não sei, mas acredito que varie por região e/ou desenvolvedor. Só pra tirar a dúvida: o caso da rua 3 é o caso em que o OSM encontra resultados para todos os endereços (exceto quando há uma quebra muito forte entre duas quadras consecutivas). O da rua 2 é o que tem buracos na numeração, que poderia lhe deixar sem resultados caso você procurasse por 60 (o número aproximado) ao invés de 65 ou 66 (o número exato). O da rua 1 retornaria todo o intervalo mas, por causa da forte quebra na última quadra, a interpolação seria bastante imprecisa (nesse exemplo ela jogaria você para a quadra errada quase 75% das vezes). 2013/7/26 Roger C. Soares rogersoa...@gmail.com: Acho que eu tb não usaria o 3 apenas pelo fato da busca no osm não retornar para todos os números. Eu até acho isso meio irritante, mas como os nros aparecem no mapa, dá pra se localizar. Os dados para serem importados possuem apenas as pontas dos quarteirões? Se tiver mais nros nas posições corretas, acho que seria interessante importar todos, assim alguém poderia desenhar os contornos sem ter que inspecionar tudo.. Atenciosamente, Roger. -- Arlindo Pereira escreveu: O método 3 me parece estritamente errado. Os endereços não existem, ponto. Adicioná-los me parece, usando uma gíria carioca, forçação de barra para evitar uma falha/bug/feature do buscador. Uma espécie de tag for the renderer. []s 2013/7/25 Fernando Trebien fernando.treb...@gmail.com Uma imagem vale mais do que mil palavras, então só pra explicar melhor: http://i.imgur.com/uwNSCWA.png Ignorem os pontos e as cruzes amarelas (não me aventurei a descobrir uma forma de escondê-las). A rua 1 está feita com o método mais simples. Serve bem para as ruas onde a numeração obedeceu a regra da distância desde o início da rua. Tem a eventual desvantagem de, em alguns casos, gerar coordenadas que são mais próximas de uma das vias transversais do que da via principal. A rua 2 está feita da forma que eu observei no RJ. É a mais estritamente correta, mas se alguém procurar por um número que cairia dentro do cruzamento, nenhum resultado é encontrado. A rua 3 está feita da forma que eu observei em Buenos Aires. Notem que na rua mais à direita a numeração original foi preservada por causa da grande diferença de numeração entre os dois lados. Não é tão correta, mas a interpolação (por ser uma aproximação) também não é, e teria a vantagem de sempre chegar a uma posição aproximada (mesmo que o endereço não exista, ou seja um endereço novo ainda não mapeado, etc.). Penso que seja a melhor para conversores e importações automáticas, a menos que se tenha certeza do cuidado que tiveram com a numeração. Claro que todas esses métodos também servem para 1 único interpolador ao invés de 2 (um para cada lado). Se alguém quiser o arquivo original para modificar e fazer seus próprios exemplos: http://db.tt/vtIIhLjG O que eu fiz em Porto Alegre não é nenhum desses 3 métodos :P Seria basicamente um misto da rua 2 com a rua 1 passando a linha do interpolador pelo meio do cruzamento sempre. Mas estou tendendo mais ao método da rua 3 agora. 2013/7/25 Fernando Trebien fernando.treb...@gmail.com: Acho que não foi ainda bem estabelecida a forma mais correta de usar os interpoladores. Para o Nominatim e para o meu GPS (MapFactor Navigator) basta: - addr:interpolation na linha (o interpolador) que acompanha via principal pela lateral - addr:housenumber em alguns dos nós ao longo dessa linha, sempre acompanhado de addr:street com o valor correto (os nós sem número servem apenas para definir o contorno do interpolador e gerar coordenadas nos lugares certos, algo importante em curvas) Colocar addr:street na linha me pareceu o jeito mais natural desde o começo, mas acabei descobrindo que não é necessário. Por outro lado, repetir esse mesmo valor em cada nó com numeração me parece uma tremenda redundância de informação... não faço idéia do que a comunidade tinha em mente quando decidiram fazer assim. 2013/7/25 Arlindo Pereira openstreet...@arlindopereira.com: O que eu tenho feito é mapear vias com addr:street=[nome da rua] e addr:interpolation:[odd|even], com seus nós tendo addr:street=[nome da rua] (de novo) e addr:housenumber=[numero], uma para cada quarteirão. Por exemplo: Procurem por Rua Bento Lisboa, 60. http://openstreetmap.org/?lat=-22.926233lon=-43.179654zoom=18layers=M Nesse exemplo, os números dos prédios na Rua Bento Lisboa antes e depois da Rua Tavares Bastos são 72 e 96. Dessa forma, procurando antes ou depois de qualquer um desses números a interpolação funciona, mas entre os dois não, pois de fato não há casas com este endereço. Não sei se é
Re: [Talk-br] Endereçamento com interpoladores
Acho que é isso sim. Só pra não ter dúvidas: o número 80 não seria um nó, seria o número interpolado, certo? Os únicos nós seriam o 72 e o 88, um de cada lado da via transversal, ambos próximos do cruzamento, e o tracejado (---) seria o interpolador conectando os dois, com a tag addr:inclusion=potential. 2013/7/26 Arlindo Pereira openstreet...@arlindopereira.com: Só para ver se eu entendi direito, teríamos então uma via com os números reais de endereçamento na ponta dos quarteirões e, entre eles, isto é, embaixo da rua transversal teríamos a média entre esses números? Por exemplo: 72-|80|-88 Se for isso mesmo, com uma tag específica para esses casos, acho que estou de acordo. []s Em 26/07/2013 10:38, Fernando Trebien fernando.treb...@gmail.com escreveu: Eu sabia que deveria ter feito a rua 4 e a rua 5 no exemplo. :P Não tenho dúvidas de que é estritamente errado. Aliás, estritamente, os interpoladores são errados, pois produzem vários números interpolados que não existem na realidade. Tomando como exemplo as quadras de Buenos Aires de 100m de comprimento e com intervalo de numeração de 100 números: se houver 20 prédios em cada quadra (10 de cada lado da via), 80% dos números interpolados não existirão. Se são errados, por que são usados? Porque são úteis. A minha questão é se é útil ao usuário final saber que existe o buraco na numeração ou se é mais útil obter uma aproximação sempre que possível. Todos os outros mapas que eu conheço (particularmente os dois melhores, Google Maps e Nokia HERE Maps) não têm esses buracos. O meu receio é que um usuário, ao se deparar com um buraco desses, considere o OSM como um sistema inferior. Mas então, a rua 4 e a rua 5 seriam variações da rua 2, com uma modificação: estenderíamos a linha interpoladora através do cruzamento, passando pela via transversal. Na rua 4 a ligação entre os números de cada lado seria simplesmente uma linha reta. A rua 5 é o exemplo de como eu fiz em Porto Alegre, onde essa extensão passaria necessariamente pelo nó central do cruzamento. Acho que a rua 4 seria o melhor equilíbrio entre o útil e o estritamente correto. A rua 4 então modificaria a rua 2 acrecentando interpoladores (linhas retas) entre os números: 18 e 24, 15 e 27, 52 e 64, 69 e 63. O resultado: os números exatos são renderizados, e posições aproximadas são obtidas para todo o intervalo da numeração. Para completar, essas extensões que passam pelo cruzamento poderiam receber a tag addr:inclusion=potential. Que tal? 2013/7/25 Arlindo Pereira openstreet...@arlindopereira.com: O método 3 me parece estritamente errado. Os endereços não existem, ponto. Adicioná-los me parece, usando uma gíria carioca, forçação de barra para evitar uma falha/bug/feature do buscador. Uma espécie de tag for the renderer. []s 2013/7/25 Fernando Trebien fernando.treb...@gmail.com Uma imagem vale mais do que mil palavras, então só pra explicar melhor: http://i.imgur.com/uwNSCWA.png Ignorem os pontos e as cruzes amarelas (não me aventurei a descobrir uma forma de escondê-las). A rua 1 está feita com o método mais simples. Serve bem para as ruas onde a numeração obedeceu a regra da distância desde o início da rua. Tem a eventual desvantagem de, em alguns casos, gerar coordenadas que são mais próximas de uma das vias transversais do que da via principal. A rua 2 está feita da forma que eu observei no RJ. É a mais estritamente correta, mas se alguém procurar por um número que cairia dentro do cruzamento, nenhum resultado é encontrado. A rua 3 está feita da forma que eu observei em Buenos Aires. Notem que na rua mais à direita a numeração original foi preservada por causa da grande diferença de numeração entre os dois lados. Não é tão correta, mas a interpolação (por ser uma aproximação) também não é, e teria a vantagem de sempre chegar a uma posição aproximada (mesmo que o endereço não exista, ou seja um endereço novo ainda não mapeado, etc.). Penso que seja a melhor para conversores e importações automáticas, a menos que se tenha certeza do cuidado que tiveram com a numeração. Claro que todas esses métodos também servem para 1 único interpolador ao invés de 2 (um para cada lado). Se alguém quiser o arquivo original para modificar e fazer seus próprios exemplos: http://db.tt/vtIIhLjG O que eu fiz em Porto Alegre não é nenhum desses 3 métodos :P Seria basicamente um misto da rua 2 com a rua 1 passando a linha do interpolador pelo meio do cruzamento sempre. Mas estou tendendo mais ao método da rua 3 agora. 2013/7/25 Fernando Trebien fernando.treb...@gmail.com: Acho que não foi ainda bem estabelecida a forma mais correta de usar os interpoladores. Para o Nominatim e para o meu GPS (MapFactor Navigator) basta: - addr:interpolation na linha (o interpolador) que acompanha via principal pela lateral - addr:housenumber em alguns dos nós ao
[Talk-br] Endereçamento com interpoladores
Pessoal, O Paulo Carvalho tem desenvolvido um conversor TrackSource OSM e eu estou prestes a importar a numeração das casas em Porto Alegre via script. Eu queria opiniões sobre um detalhe de como fazer isso para produzir um resultado com mais qualidade. Já encontrei interpoladores no Rio e em Buenos Aires (mas não em outras grandes cidades de outros países, onde quase tudo está mapeado edifício por edifício). Em ambos, sempre há 1 linha para cada quadra, com um número associado ao nó inicial e outro ao final. No Rio, o número usado foi exatamente o da última casa naquela quadra, logo antes do cruzamento. Isso deixa alguns números faltando na sequência; se alguém pesquisar por um desses números, o sistema não retorna absolutamente nada. Em Buenos Aires, parece que eles escolheram números de uma forma tal que não fiquem buracos na numeração: se de um lado o último número é o 20 (numeração par), do outro o primeiro número é o 22 ou o 18, mas não se pula para o 24 ou para o 16 (ou qualquer número mais distante), o que deixaria o número 22 ou o 18 de fora dos resultados da busca. Exemplo em Buenos Aires: http://openstreetmap.org/?lat=-34.60868lon=-58.37489zoom=17layers=M Então, a questão: optamos pela exatidão absoluta e deixamos que o usuário do mapa fique confuso de vez em quando (especialmente no caso de novos endereços que ainda não foram mapeados), ou fazemos as conversões fechando esses buracos? Por exemplo, se de um lado o número é 20 e do outro é 40, aproximaríamos isso atribuindo um lado ao número 30 e o outro lado ao 32. O fechamento seria feito somente quando a numeração dos dois lados é próxima: se houver um salto muito grande, digamos, de mais de 100 (ex.: um lado é 80 e o outro é 190), os números originais seriam usados. A minha opinião é de que o fechamento seria interessante porque os interpoladores são invariavelmente uma mera aproximação. Acho que a exatidão absoluta faria mais sentido se todos os edifícios estivessem mapeados individualmente, como é o caso de Berlim, Paris, Londres, etc. Mas não sei se a minha opinião está de acordo com a opinião geral, pesquisando não achei absolutamente nenhuma recomendação da comunidade internacional para o uso dos interpoladores. -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Endereçamento com interpoladores
Pessoal, acho que gerei um monte de dúvidas. Certamente a idéia de poder deduzir a numeração a partir da distância é tentadora (embora fazer isso só olhando para a métrica do JOSM tenha uma tendência a introduzir erros de aproximação nas vias mais longas). Mas no caso do conversor do Paulo e do meu script, esses números podem ser gerados automaticamente a partir de bases confiáveis (no caso dele os mapas já produzidos por DMs e DEs para o TrackSource, no meu caso a base do Instituto de Geologia da UFRGS). Essas fontes de dados já tem a numeração inicial de cada rua (e também as intermediárias, por cruzamento). Creio que em muitos casos essa numeração foi inspecionada e não medida ou deduzida, portanto, é mais próxima da numeração oficial, incluindo os casos em que a regra da distância não foi seguida à risca. A minha questão é: o usuário busca por Rua A, 500 e esse valor cai perto do meio do cruzamento. Os números mais próximos nos interpoladores existentes são 496 e 512. É aceitável/importante/útil/desejável/indesejável mudar os interpoladores ligeiramente para que a busca do usuário retorne algum resultado razoável? Se ajustarmos de 496 para 504 e de 512 para 506, isso não faz quase nenhuma diferença no meio da quadra, mas a busca passa a retornar resultados para os números intermediários (inclusive o solicitado pelo usuário). Alguém que estiver procurando um endereço com um GPS (e não olhando para o mapa) encontraria esse resultado assim. Sem o ajuste, o resultado seria nada encontrado e o usuário ficaria se perguntando se passaram o endereço errado pra ele, se ele digitou errado, se o mapa é que é ruim, se o GPS é que não funciona, etc. Só lembrando: não é necessário mudar todos os interpoladores que já foram mapeados, essa questão é mais para esses processos de conversão automática. Se for desejável, uma boa hora pra implementar esse recurso no conversor do Paulo (e no meu script de importação) é agora, do contrário se um dia decidirmos que isso é bom vamos ter que ajustar tudo à mão. Se for indesejável, me avisem. :D 2013/7/25 Nelson A. de Oliveira nao...@gmail.com: A forma mais simples é criar apenas um caminho, do começo da rua até o fim, com addr:interpolation=all (a interpolação vai servir para os lados par e ímpar) e addr:inclusion=estimate (para dizer que existirá números na interpolação que não existem de fato na realidade). Coloca no nó inicial o menor número que existe na rua e o nó final o último número que existe na mesma. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Endereçamento com interpoladores
Nesse exemplo, era pra ser o número exato das casas na esquina, obtidos (supostamente) por inspeção. No caso do conversor e da minha importação, esse número também poderia ser algo proveniente de um registro legal ou oficial (possivelmente um pouco desatualizado). 2013/7/25 Nelson A. de Oliveira nao...@gmail.com: 2013/7/25 Fernando Trebien fernando.treb...@gmail.com: A minha questão é: o usuário busca por Rua A, 500 e esse valor cai perto do meio do cruzamento. Os números mais próximos nos interpoladores existentes são 496 e 512. 496 e 512 seriam os números de casa que existem na realidade ou são valores aproximados? ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Endereçamento com interpoladores
Você poderia colocar um número de casa no nó central do cruzamento, mas haveria um conflito se você tivesse que fazer isso para dois interpoladores (um para cada rua do cruzamento). Eu vinha mapeando passando pelo nó central mas colocando os números pouco antes e pouco depois do cruzamento, assim: http://www.openstreetmap.org/?lat=-30.050852lon=-51.224171zoom=18layers=M Como fiz isso muito pouco (mais com o objetivo de testar o sistema mesmo), não me importo de consertar. Desse jeito há 2 vantagens: - a numeração é contínua (não há números faltando nos cruzamentos, sempre se consegue uma posição aproximada) - o roteamento é correto (mesmo os números no interior do cruzamento são projetados na rua certa, já que o interpolador é mais próximo da sua rua do que da outra que chega no cruzamento) Se o interpolador passasse por cima da rua transversal, os números próximos do cruzamento seriam projetados na rua errada. Se nesse local as ruas fossem todas de sentido único (como costuma ser nas regiões mais densas das cidades), isso poderia mudar drásticamente o roteamento (no restante não mudaria muito). Além do aspecto engraçado (repetindo esse padrão visual em X em cada cruzamento :P), tem uma desvantagem em fazer do jeito que eu fiz (e pode ter sido essa a razão para não ter funcionado pra você algumas vezes). O Nominatim faz uma verificação de sanidade nos interpoladores: se numa distância curta a diferença de numeração for muito grande, ele descarta o interpolador. Então, se o interpolador for feito em pedaços (como em Buenos Aires), a chance de algo ser descartado é muito menor. Descobri isso (e inclusive abri um ticket no TRAC do Nominatim pensando que era um erro) quando fui mapear a Avenida Guaíba aqui em Porto Alegre: em um trecho de uma quadra, a numeração saltava de 990 para 1300 entre os extremos. O Nominatim acha improvável haver 400 casas nesse espaço curto, pensa que é um erro e acaba não indexando essas casas. (Pelo que entendi o Nominatim não é muito esperto, cada valor interpolado gera uma entrada no índice. Softwares de GPS simplesmente calculam a posição interpolada ao invés de armazenar a posição de cada número separadamente.) Em lugares em que há tanto um interpolador quanto uma casa mapeada separadamente com o seu próprio número, o Nominatim retorna as 2 posições, mas a que vem do interpolador sempre aparece como segundo resultado, o primeiro é a própria casa. 2013/7/25 Roger C. Soares rogersoa...@gmail.com: A idéia seria continuar mapeando as construções e colocando o número exato nelas? Se a numeração for duplicada não vejo problema em considerar a interpolação como uma aproximação, inclusive seria até interessante que os nros na interpolação não batessem com o nro da construção para a busca não retornar 2 endereços repetidos. Tem a tag addr:inclusion pra dizer que o nro é aproximado e não o real. Eu tenho feito inspeções, e eu pego alguns números, na maioria eu tento pegar as pontas dos quarteirões. Mas nem sempre, então eu escolhi o modo mais fácil pra mim, eu ignoro os quarteirões, sendo o mais simples conectar as pontas das ruas, e alguns números no meio caso a rua faça alguma curva só para ficar mais bonito na renderização. E sempre coloco o nro exato. Se tem um POI mapeado com o mesmo nro eu adiciono no POI tb. Inclusive, eu acabei achando interessante conectar a rua inteira, tem algumas que são quebradas em alguma parte e continuam depois, a linha da interpolação me dá uma noção legal de continuidade do que deveria ser a rua, por exemplo: http://www.openstreetmap.org/?lat=-21.193062lon=-47.801154zoom=18layers=M O primeiro nro do quarteirão é 2210, mas se eu fosse guardar esse nro de cabeça eu iria buscar por 2200 ou 2000 (eu faço muito isso), e se a interpolação não estivesse conectada ela não retornaria nada. Com a interpolação contínua uma localização aproximada de onde eu quero ir deveria aparecer, mas pela minha experiência, nem sempre as interpolações funcionam no site do openstreetmap, já aconteceu dele ignorar o nro ou retornar em outra rua, e não entendi o pq na época... Eu li em algum lugar que a interpolação é uma forma rápida para mapear os nros, mas que a intenção ainda era colocar os nros exatos de cada construção, então eu comecei a considerar as interpolações como algo auxiliar/temporário. Mas como eu busco um tanto por nros redondos, não gostaria de perder as aproximações... Uma coisa que eu achei interessante em Porto Alegre, mas que não usei ainda foi: http://www.openstreetmap.org/?lat=-21.193062lon=-47.801154zoom=18layers=M A interpolação na rua General Câmara, entre a rua dos Andradas e Andrade Neves, ela tem o nro exato mas termina conectada com a rua. Talvez o nó da esquina poderia ter o nro intermediário... Atenciosamente, Roger. -- Fernando Trebien escreveu: Pessoal, O Paulo Carvalho tem desenvolvido um conversor TrackSource OSM e eu estou prestes a importar a numeração das casas em Porto Alegre via
Re: [Talk-br] Endereçamento com interpoladores
Acho que não foi ainda bem estabelecida a forma mais correta de usar os interpoladores. Para o Nominatim e para o meu GPS (MapFactor Navigator) basta: - addr:interpolation na linha (o interpolador) que acompanha via principal pela lateral - addr:housenumber em alguns dos nós ao longo dessa linha, sempre acompanhado de addr:street com o valor correto (os nós sem número servem apenas para definir o contorno do interpolador e gerar coordenadas nos lugares certos, algo importante em curvas) Colocar addr:street na linha me pareceu o jeito mais natural desde o começo, mas acabei descobrindo que não é necessário. Por outro lado, repetir esse mesmo valor em cada nó com numeração me parece uma tremenda redundância de informação... não faço idéia do que a comunidade tinha em mente quando decidiram fazer assim. 2013/7/25 Arlindo Pereira openstreet...@arlindopereira.com: O que eu tenho feito é mapear vias com addr:street=[nome da rua] e addr:interpolation:[odd|even], com seus nós tendo addr:street=[nome da rua] (de novo) e addr:housenumber=[numero], uma para cada quarteirão. Por exemplo: Procurem por Rua Bento Lisboa, 60. http://openstreetmap.org/?lat=-22.926233lon=-43.179654zoom=18layers=M Nesse exemplo, os números dos prédios na Rua Bento Lisboa antes e depois da Rua Tavares Bastos são 72 e 96. Dessa forma, procurando antes ou depois de qualquer um desses números a interpolação funciona, mas entre os dois não, pois de fato não há casas com este endereço. Não sei se é a forma mais correta, mas funciona. =) []s Arlindo Nighto Pereira 2013/7/25 Roger C. Soares rogersoa...@gmail.com Deveria. Na minha opinião não seria necessário nem um way com addr:interpolation, o engine deveria saber pegar os nros com o mesmo addr:street e interpolar segundo as regras de uma área que contém a rua, o país por exemplo. Mas o wiki define que interpolação tem que ter um way e talvez seja até pq a minha idéia não funcione para o mundo todo. A minha dúvida é: Como se mapeia a interpolação de forma contínua para a rua toda? Eu tenho colocado os nros conforme eu vou encontrando e ligando com addr:interpolation, me parece lógico. Segundo o comportamento do Nominatim descrito pelo Fernando, o que eu estou fazendo não funciona, e na prática realmente não funciona (sempre). Agora, isso é bug ou feature do Nominatim? Quem decide? Tem outro jeito correto para mapear? É correto manter a interpolação e tb numerar o contorno da construção? Muitas perguntas? :) Atenciosamente, Roger. -- Gerald Weber escreveu: Oi Pessoal Ao pensar nesta idéia de interpolação: isto não deveria ser tarefa do renderizador? Quer dizer, faz sentido popular a base de dados com informações hipotéticas? Abraços Gerald ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Maneira fácil de selecionar polígonos fácil.
Bem, há 2 tipos de polígonos no OSM: polígonos simples (objetos way com a propriedade closed) e multipolígonos. Para selecionar o primeiro tipo, basta dar um Ctrl+F (pra abrir a janela de busca) e procurar por closed (sem as aspas). Para o segundo, é interessante saber como funciona a função de busca do JOSM. Você sempre busca por uma expressão. Um exemplo: se você buscar por highway=primary, vai selecionar todos os objetos com essa tag (inclusive nodos e relações, se elas a tiverem, mesmo que seja um erro). Você pode buscar por dois critérios simultâneos. No exemplo anterior, se você só quiser as vias primárias e não os nós e relações incorretos, pode buscar por type:way highway=primary. O espaço em branco significa a operação de e lógico: A B equivale a A e B verdadeiros. Para um ou, você escreve A OR B. Se você quiser vias primárias ou secundárias, a busca fica type:way highway=primary OR highway=secondary. Você pode procurar por expressões negativas também colocando um - na frente daquilo que você não quer selecionado. Por exemplo, se quiser todas as vias que não são primárias, a expressão fica type:way -highway=primary (inclui vias sem a tag highway). As expressões nem sempre são tão convenientes e fáceis de escrever, então você pode mudar o modo de busca de replace selection (padrão) para add to selection, remove from selection e find in selection. São equivalentes a expressões com ou, não e e, respectivamente. Por exemplo, você pode buscar primeiro por type:way no modo replace selection e depois buscar por type=primary no modo remove from selection pra obter exatamente o mesmo resultado que no exemplo anterior. Se você também precisar das relações que são polígonos, você pode pesquisar por objetos do tipo relation que têm a tag type=multipolygon. Você escreve isso assim: type:relation type=multipolygon. type:relation seleciona todos os objetos do tipo relation, se você quisesse nodos seria type:node, e type=multipolygon filtra desses objetos os que têm a tag type=multipolygon. Como há um espaço em branco entre os dois, só vem no resultado aquilo que satisfizer ambas as condições. Mas você pode fazer da maneira em dois passos que eu disse antes. Há outros tipos de relações que também funcionam como polígonos, por exemplo, type:relation type=boundary e type:relation type=site. Daí você tem que fazer uma busca para cada caso. Às vezes ajuda copiar tudo (Ctrl+A) para uma outra camada e ir trabalhando nela por eliminação. Você pode selecionar todas a relações que não são nem multipolygon nem boundary com type:relation -type=multipolygon -type=boundary (ou com duas buscas usando o modo remove from selection). Daí pra saber os tipos que sobraram basta olhar quais relações foram selecionadas na janela Selection à direita (se não estiver aparecendo, vai em Window Selection). Recomendo essa leitura também: http://wiki.openstreetmap.org/wiki/JOSM/Search_function 2013/7/21 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Olá pessoal, existe alguma maneira de selecionar todos polígonos que estão no JOSM? ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Definição de canteiro central
Acho que obstáculos físicos como uma mureta deveriam ser considerados canteiro central também (não é exatamente um canteiro mas...). Na prática quase não há diferença funcional entre os dois: ambos impedem a travessia de veículos (impede também a ultrapassagem) e dificultam a travessia de pedestres, ciclistas, etc. 2013/7/19 Nelson A. de Oliveira nao...@gmail.com: 2013/7/19 Aun Yngve Johnsen li...@gimnechiske.org: No maioria eu mapeando eles como duas rodovias separado, nao sei se este e o concenso ou nao Mas a minha dúvida está com as separações. Por exemplo, uma mureta entre as duas vias eu considero como canteiro. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Solicitações de acesso à informação + importação de telefones públicos
Estou com a intenção sim. Quando tivesse as informações em mãos ia ver
quem daqui preferiria ter a sua cidade excluída do processo.
Eu fiz essa pergunta pra eles (se a informação tem copyright ou se é
domínio público) mas ainda não me responderam. Comecei a pensar
nisso porque a informação me pareceu fácil de importar pelos posts
originais. De repente se alguém mais solicitar eles acabam acelerando
a liberação da informação.
Como antes eu solicitei pro Ministério das Comunicações, eles já
responderam me apontando pra um novo serviço no site da Anatel, mas o
serviço é muito lento, levo pelo menos 1 minuto só pra conseguir
visualizar os telefones do meu bairro, e certamente não consigo
visualizá-los combinados com outros elementos do mapa.
2013/7/19 Robian rfra...@yahoo.com.br:
Fernando,
você tá com a intenção de importar os dados da ANATEL?
Pergunto isso pois eu tenho alguns dados georeferenciados de torres de
celular (também provenientes do site da Anatel) e ainda não sei se eles tem
alguma incompatibilidade com a licença do OSM.
{}'s
De: Fernando Trebien fernando.treb...@gmail.com
Para: OSM talk-br talk-br@openstreetmap.org
Enviadas: Quarta-feira, 17 de Julho de 2013 16:07
Assunto: [Talk-br] Solicitações de acesso à informação + importação de
telefones públicos
Descobri esse site hoje: http://www.acessoainformacao.gov.br/sistema/
Alguém já usou ele? Postei uma solicitação da base de telefones públicos
(que já esteve no ar uma vez e não está mais) mencionada aqui:
https://groups.google.com/forum/#!topic/thackday/n_7wjsyj-yA
Aparentemente o site da Anatel deveria ter a mesma informação:
http://sistemas.anatel.gov.br/sgmu/TUP/Lista/frmConsulta.asp
Mas o sistema não funciona - não carrega o nomes das cidades e quando
solicito os dados consolidados ele dá a mensagem Erro na Constante Modulo.
Até uns dias atrás eu não conseguia me cadastrar para abrir um atendimento
(ironicamente :P), mas consegui fazer isso agora e postei lá também.
--
Fernando Trebien
+55 (51) 9962-5409
The speed of computer chips doubles every 18 months. (Moore's law)
The speed of software halves every 18 months. (Gates' law)
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br
--
Fernando Trebien
+55 (51) 9962-5409
The speed of computer chips doubles every 18 months. (Moore's law)
The speed of software halves every 18 months. (Gates' law)
___
Talk-br mailing list
Talk-br@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Definição de canteiro central
Motorway sempre tem canteiro central, trunk nem sempre, tanto pela descrição do wiki em inglês quanto pela percepção da comunidade brasileira. Talvez o melhor termo para isso seria divisória central ou algo assim. De qualquer forma, poucos usuários se beneficiam efetivamente do traçado exato dessa barreira. Claro, é interessante que conste num mapa minucioso, até mesmo com motorways, indicando a posição e a forma do canteiro em relação à via. On Jul 19, 2013 11:58 PM, Blademir Andrade de Lima blademi...@hotmail.com wrote: A marcação do canteiro central só não é necessária em Motorway ou Trunk, que ja é previsto existir canteiro nesses dois, devido pela regra serem mão unica, um sentido de cada lado. A marcação do canteiro deve ser feita manualmente nos outros tipos de rodovias (primary, secondary etc), que sejam de pista dupla. Ja na marcação de mureta central, a que eu utilizo é barrier=jersey_barrier, ja que ela possui um perfil mais baixo que uma parede (wall). Blademir Andrade de lima -- Date: Fri, 19 Jul 2013 21:41:59 -0300 From: openstreet...@arlindopereira.com To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Definição de canteiro central Tendo mureta, imagem de satélite e tempo disponível, faço: landuse=grass na grama do canteiro barrier=wall na divisória do canteiro []s Em 19/07/2013 21:39, Fernando Trebien fernando.treb...@gmail.com escreveu: Acho que obstáculos físicos como uma mureta deveriam ser considerados canteiro central também (não é exatamente um canteiro mas...). Na prática quase não há diferença funcional entre os dois: ambos impedem a travessia de veículos (impede também a ultrapassagem) e dificultam a travessia de pedestres, ciclistas, etc. 2013/7/19 Nelson A. de Oliveira nao...@gmail.com: 2013/7/19 Aun Yngve Johnsen li...@gimnechiske.org: No maioria eu mapeando eles como duas rodovias separado, nao sei se este e o concenso ou nao Mas a minha dúvida está com as separações. Por exemplo, uma mureta entre as duas vias eu considero como canteiro. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Solicitações de acesso à informação + importação de telefones públicos
Descobri esse site hoje: http://www.acessoainformacao.gov.br/sistema/ Alguém já usou ele? Postei uma solicitação da base de telefones públicos (que já esteve no ar uma vez e não está mais) mencionada aqui: https://groups.google.com/forum/#!topic/thackday/n_7wjsyj-yA Aparentemente o site da Anatel deveria ter a mesma informação: http://sistemas.anatel.gov.br/sgmu/TUP/Lista/frmConsulta.asp Mas o sistema não funciona - não carrega o nomes das cidades e quando solicito os dados consolidados ele dá a mensagem Erro na Constante Modulo. Até uns dias atrás eu não conseguia me cadastrar para abrir um atendimento (ironicamente :P), mas consegui fazer isso agora e postei lá também. -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Relações
São importantíssimas. As relações agrupam coisas (como todos os pedaços de uma rodovia e duas vias e um nó numa restrição de conversão). Sem elas, não seria possível obter o traçado completo de uma rodovia, nem várias rotas (por exemplo, de ônibus) que compartilham parte de um trajeto, nem especificar que é proibido fazer o retorno ou dobrar à direita. Nem desenhar polígonos com buracos. Enfim, há muitos usos. On Jul 15, 2013 12:18 PM, Erick de Oliveira Leal erickdeoliveiral...@gmail.com wrote: Alguém pode me explicar o que são relações, pq vi que tem algumas rodovias que usam isso, e qual a importância delas? ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Relações
Uma relação, como qualquer outro elemento, tem tags. A diferença é que uma relação, além das tags, possui membros. Os membros podem ser de qualquer tipo, inclusive podem ser outras relações. Cada membro tem um papel (role) que especifica a sua função na relação. Por exemplo, relações de rotas de ônibus têm membros com os papéis forward e backward indicando a direção da rota em uma via. Além disso, a relação tem tags especificando o nome e o número da rota. Relações de restrição de conversão têm 3 membros: from e to (especificando de onde para onde que vale a restrição) e via especificando o nó que junta os dois segmentos, exatamente onde vale a restrição. Essas não têm tags obrigatórias (exceto type=restriction) mas pode ter tags como fixme e note. On Jul 15, 2013 1:07 PM, Fernando Trebien fernando.treb...@gmail.com wrote: São importantíssimas. As relações agrupam coisas (como todos os pedaços de uma rodovia e duas vias e um nó numa restrição de conversão). Sem elas, não seria possível obter o traçado completo de uma rodovia, nem várias rotas (por exemplo, de ônibus) que compartilham parte de um trajeto, nem especificar que é proibido fazer o retorno ou dobrar à direita. Nem desenhar polígonos com buracos. Enfim, há muitos usos. On Jul 15, 2013 12:18 PM, Erick de Oliveira Leal erickdeoliveiral...@gmail.com wrote: Alguém pode me explicar o que são relações, pq vi que tem algumas rodovias que usam isso, e qual a importância delas? ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Relações
Outro exemplo importante: as relações boundary agrupam os pedaços de fronteira que delimitam um bairro, uma cidade, um estado, um país, um continente, e adicionam informação como o nó admin_centre que representa o centro da cidade (geralmente o marco zero, e também o lugar onde se desenha o nome da cidade). On Jul 15, 2013 1:14 PM, Fernando Trebien fernando.treb...@gmail.com wrote: Uma relação, como qualquer outro elemento, tem tags. A diferença é que uma relação, além das tags, possui membros. Os membros podem ser de qualquer tipo, inclusive podem ser outras relações. Cada membro tem um papel (role) que especifica a sua função na relação. Por exemplo, relações de rotas de ônibus têm membros com os papéis forward e backward indicando a direção da rota em uma via. Além disso, a relação tem tags especificando o nome e o número da rota. Relações de restrição de conversão têm 3 membros: from e to (especificando de onde para onde que vale a restrição) e via especificando o nó que junta os dois segmentos, exatamente onde vale a restrição. Essas não têm tags obrigatórias (exceto type=restriction) mas pode ter tags como fixme e note. On Jul 15, 2013 1:07 PM, Fernando Trebien fernando.treb...@gmail.com wrote: São importantíssimas. As relações agrupam coisas (como todos os pedaços de uma rodovia e duas vias e um nó numa restrição de conversão). Sem elas, não seria possível obter o traçado completo de uma rodovia, nem várias rotas (por exemplo, de ônibus) que compartilham parte de um trajeto, nem especificar que é proibido fazer o retorno ou dobrar à direita. Nem desenhar polígonos com buracos. Enfim, há muitos usos. On Jul 15, 2013 12:18 PM, Erick de Oliveira Leal erickdeoliveiral...@gmail.com wrote: Alguém pode me explicar o que são relações, pq vi que tem algumas rodovias que usam isso, e qual a importância delas? ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Relações
Então, Erick, pra resumir: - nós (nodes) têm somente tags e posição - linhas (ways) têm tags e uma lista de nós; um par da sequência forma um segmento de reta, o par seguinte forma o segmento seguinte da linha, etc. e a ordem dos nós dá a direção da linha (áreas nada mais são do que linhas fechadas, ou seja, primeiro nó = último nó) - relações (relations) têm tags e membros com papéis, onde cada membro pode ser qualquer coisa (nó, linha ou relação) E agora exemplificando. *Rota representando o sentido bairro centro de uma linha de ônibus* http://www.openstreetmap.org/browse/relation/2727021 Repare nas etiquetas descrevendo a linha de ônibus e nos membros com os seus papéis forward, backward e stop. Especificação completa desse tipo de relação: http://wiki.openstreetmap.org/wiki/Relation:route#Bus_routes_.28also_trolley_bus.29 *Rota representando todas as partes de uma rodovia* http://www.openstreetmap.org/browse/relation/155359 Repare nas tags network, ref, type e route e também que os membros têm papéis forward e backward tal como na rota de ônibus. Especificação completa desse tipo de relação: http://wiki.openstreetmap.org/wiki/Relation:route#Road_routes *Restrição de conversão proibindo fazer o retorno* http://www.openstreetmap.org/browse/relation/3077198 Repare nos papéis via - um nó - e from e to - ambos linhas. Especificação completa: http://wiki.openstreetmap.org/wiki/Relation:restriction *Multipolígono representando um delta* http://www.openstreetmap.org/browse/relation/86833 Repare nos membros com papéis outer - borda externa - e inner - borda interna. Especificação completa: http://wiki.openstreetmap.org/wiki/Relation:multipolygon *Fronteira definindo uma mesorregião* http://www.openstreetmap.org/browse/relation/2844354 Repare nas etiquetas admin_level e type=boundary, também repare nos papéis outer e inner que funcionam exatamente da mesma forma que nos multipolígonos. Especificação completa: http://wiki.openstreetmap.org/wiki/Relation:boundary *Fronteiras definindo um bairro e uma cidade* http://www.openstreetmap.org/browse/relation/2727083 http://www.openstreetmap.org/browse/relation/242397 Repare o valor em admin_level em cada uma e os membros label e admin_centre (que aparecem com uma função similar. *Um rio que serve como fronteira em várias relações de fronteira* http://www.openstreetmap.org/browse/way/227577336 Repare lá no final a seção Parte de. Esse rio é membro das relações que representam as fronteiras de dois países (Brasil e Uruguai), de um estado brasileiro (Rio Grande do Sul), uma cidade brasileira (Jaguarão) e uma região uruguaia (Cerro Largo), além de uma microrregião brasileira e da relação que representa a região Sul do Brasil. (OBS: a tag name desse rio está errada. Combinei com um uruguaio que usaríamos a convenção européia de colocar ambos os nomes, em português e espanhol, separados por / , em ordem alfabética, mas ainda não tive tempo de atualizar toda a fronteira.) Pra mais detalhes, eis a lista das principais relações usadas no OpenStreetMap: http://wiki.openstreetmap.org/wiki/Types_of_relation A relação associatedStreet é pouco usada no Brasil, mas muito usada na Europa. A relação public_transport é nova e provavelmente será mais usada no futuro (faz mais diferença em lugares em que as paradas são complexas e atendem a vários modos de transporte simultaneamente). A relação route_master é usada para agrupar rotas (como os dois sentidos e as variações de uma mesma linha de ônibus), mas não sei de nenhum sistema que faça uso dela. Nunca vi usarem enforcement, bridge e tunnel. A relação site é meio polêmica (frequentemente usada sem necessidade) mas é muito usada. Tem gente que mapeia, por exemplo, a área de uma universidade, os prédios, daí agrupa tudo numa relação site. Muitos defendem que isso não é necessário e que uma aplicação deveria ser capaz de determinar que o prédio pertence à universidade usando um algoritmo geométrico simples. Outros (que defendem sistemas mais fáceis de programar) preferem que a informação de continência seja expressa por relações porque daí não envolve nenhum algoritmo geométrico complicado (mas também há espaço para erros bem grosseiros). É praticamente uma extensão da discussão sobre o uso das tags is_in (que é contra-indicado). 2013/7/15 Fernando Trebien fernando.treb...@gmail.com: Outro exemplo importante: as relações boundary agrupam os pedaços de fronteira que delimitam um bairro, uma cidade, um estado, um país, um continente, e adicionam informação como o nó admin_centre que representa o centro da cidade (geralmente o marco zero, e também o lugar onde se desenha o nome da cidade). On Jul 15, 2013 1:14 PM, Fernando Trebien fernando.treb...@gmail.com wrote: Uma relação, como qualquer outro elemento, tem tags. A diferença é que uma relação, além das tags, possui membros. Os membros podem ser de qualquer tipo, inclusive podem ser outras relações. Cada membro tem um papel (role) que especifica a sua
Re: [Talk-br] Relações
Oops, corrigindo, a primeira rota de ônibus é no setido centro bairro. 2013/7/15 Fernando Trebien fernando.treb...@gmail.com Então, Erick, pra resumir: - nós (nodes) têm somente tags e posição - linhas (ways) têm tags e uma lista de nós; um par da sequência forma um segmento de reta, o par seguinte forma o segmento seguinte da linha, etc. e a ordem dos nós dá a direção da linha (áreas nada mais são do que linhas fechadas, ou seja, primeiro nó = último nó) - relações (relations) têm tags e membros com papéis, onde cada membro pode ser qualquer coisa (nó, linha ou relação) E agora exemplificando. *Rota representando o sentido bairro centro de uma linha de ônibus* http://www.openstreetmap.org/browse/relation/2727021 Repare nas etiquetas descrevendo a linha de ônibus e nos membros com os seus papéis forward, backward e stop. Especificação completa desse tipo de relação: http://wiki.openstreetmap.org/wiki/Relation:route#Bus_routes_.28also_trolley_bus.29 *Rota representando todas as partes de uma rodovia* http://www.openstreetmap.org/browse/relation/155359 Repare nas tags network, ref, type e route e também que os membros têm papéis forward e backward tal como na rota de ônibus. Especificação completa desse tipo de relação: http://wiki.openstreetmap.org/wiki/Relation:route#Road_routes *Restrição de conversão proibindo fazer o retorno* http://www.openstreetmap.org/browse/relation/3077198 Repare nos papéis via - um nó - e from e to - ambos linhas. Especificação completa: http://wiki.openstreetmap.org/wiki/Relation:restriction *Multipolígono representando um delta* http://www.openstreetmap.org/browse/relation/86833 Repare nos membros com papéis outer - borda externa - e inner - borda interna. Especificação completa: http://wiki.openstreetmap.org/wiki/Relation:multipolygon *Fronteira definindo uma mesorregião* http://www.openstreetmap.org/browse/relation/2844354 Repare nas etiquetas admin_level e type=boundary, também repare nos papéis outer e inner que funcionam exatamente da mesma forma que nos multipolígonos. Especificação completa: http://wiki.openstreetmap.org/wiki/Relation:boundary *Fronteiras definindo um bairro e uma cidade* http://www.openstreetmap.org/browse/relation/2727083 http://www.openstreetmap.org/browse/relation/242397 Repare o valor em admin_level em cada uma e os membros label e admin_centre (que aparecem com uma função similar. *Um rio que serve como fronteira em várias relações de fronteira* http://www.openstreetmap.org/browse/way/227577336 Repare lá no final a seção Parte de. Esse rio é membro das relações que representam as fronteiras de dois países (Brasil e Uruguai), de um estado brasileiro (Rio Grande do Sul), uma cidade brasileira (Jaguarão) e uma região uruguaia (Cerro Largo), além de uma microrregião brasileira e da relação que representa a região Sul do Brasil. (OBS: a tag name desse rio está errada. Combinei com um uruguaio que usaríamos a convenção européia de colocar ambos os nomes, em português e espanhol, separados por / , em ordem alfabética, mas ainda não tive tempo de atualizar toda a fronteira.) Pra mais detalhes, eis a lista das principais relações usadas no OpenStreetMap: http://wiki.openstreetmap.org/wiki/Types_of_relation A relação associatedStreet é pouco usada no Brasil, mas muito usada na Europa. A relação public_transport é nova e provavelmente será mais usada no futuro (faz mais diferença em lugares em que as paradas são complexas e atendem a vários modos de transporte simultaneamente). A relação route_master é usada para agrupar rotas (como os dois sentidos e as variações de uma mesma linha de ônibus), mas não sei de nenhum sistema que faça uso dela. Nunca vi usarem enforcement, bridge e tunnel. A relação site é meio polêmica (frequentemente usada sem necessidade) mas é muito usada. Tem gente que mapeia, por exemplo, a área de uma universidade, os prédios, daí agrupa tudo numa relação site. Muitos defendem que isso não é necessário e que uma aplicação deveria ser capaz de determinar que o prédio pertence à universidade usando um algoritmo geométrico simples. Outros (que defendem sistemas mais fáceis de programar) preferem que a informação de continência seja expressa por relações porque daí não envolve nenhum algoritmo geométrico complicado (mas também há espaço para erros bem grosseiros). É praticamente uma extensão da discussão sobre o uso das tags is_in (que é contra-indicado). 2013/7/15 Fernando Trebien fernando.treb...@gmail.com: Outro exemplo importante: as relações boundary agrupam os pedaços de fronteira que delimitam um bairro, uma cidade, um estado, um país, um continente, e adicionam informação como o nó admin_centre que representa o centro da cidade (geralmente o marco zero, e também o lugar onde se desenha o nome da cidade). On Jul 15, 2013 1:14 PM, Fernando Trebien fernando.treb...@gmail.com wrote: Uma relação, como qualquer outro
Re: [Talk-br] Relações
Ah, mais um detalhe: a rota de ônibus está incompleta (era só um teste). Mas tem todos os elementos de uma rota completa. 2013/7/15 Fernando Trebien fernando.treb...@gmail.com Oops, corrigindo, a primeira rota de ônibus é no setido centro bairro. 2013/7/15 Fernando Trebien fernando.treb...@gmail.com Então, Erick, pra resumir: - nós (nodes) têm somente tags e posição - linhas (ways) têm tags e uma lista de nós; um par da sequência forma um segmento de reta, o par seguinte forma o segmento seguinte da linha, etc. e a ordem dos nós dá a direção da linha (áreas nada mais são do que linhas fechadas, ou seja, primeiro nó = último nó) - relações (relations) têm tags e membros com papéis, onde cada membro pode ser qualquer coisa (nó, linha ou relação) E agora exemplificando. *Rota representando o sentido bairro centro de uma linha de ônibus* http://www.openstreetmap.org/browse/relation/2727021 Repare nas etiquetas descrevendo a linha de ônibus e nos membros com os seus papéis forward, backward e stop. Especificação completa desse tipo de relação: http://wiki.openstreetmap.org/wiki/Relation:route#Bus_routes_.28also_trolley_bus.29 *Rota representando todas as partes de uma rodovia* http://www.openstreetmap.org/browse/relation/155359 Repare nas tags network, ref, type e route e também que os membros têm papéis forward e backward tal como na rota de ônibus. Especificação completa desse tipo de relação: http://wiki.openstreetmap.org/wiki/Relation:route#Road_routes *Restrição de conversão proibindo fazer o retorno* http://www.openstreetmap.org/browse/relation/3077198 Repare nos papéis via - um nó - e from e to - ambos linhas. Especificação completa: http://wiki.openstreetmap.org/wiki/Relation:restriction *Multipolígono representando um delta* http://www.openstreetmap.org/browse/relation/86833 Repare nos membros com papéis outer - borda externa - e inner - borda interna. Especificação completa: http://wiki.openstreetmap.org/wiki/Relation:multipolygon *Fronteira definindo uma mesorregião* http://www.openstreetmap.org/browse/relation/2844354 Repare nas etiquetas admin_level e type=boundary, também repare nos papéis outer e inner que funcionam exatamente da mesma forma que nos multipolígonos. Especificação completa: http://wiki.openstreetmap.org/wiki/Relation:boundary *Fronteiras definindo um bairro e uma cidade* http://www.openstreetmap.org/browse/relation/2727083 http://www.openstreetmap.org/browse/relation/242397 Repare o valor em admin_level em cada uma e os membros label e admin_centre (que aparecem com uma função similar. *Um rio que serve como fronteira em várias relações de fronteira* http://www.openstreetmap.org/browse/way/227577336 Repare lá no final a seção Parte de. Esse rio é membro das relações que representam as fronteiras de dois países (Brasil e Uruguai), de um estado brasileiro (Rio Grande do Sul), uma cidade brasileira (Jaguarão) e uma região uruguaia (Cerro Largo), além de uma microrregião brasileira e da relação que representa a região Sul do Brasil. (OBS: a tag name desse rio está errada. Combinei com um uruguaio que usaríamos a convenção européia de colocar ambos os nomes, em português e espanhol, separados por / , em ordem alfabética, mas ainda não tive tempo de atualizar toda a fronteira.) Pra mais detalhes, eis a lista das principais relações usadas no OpenStreetMap: http://wiki.openstreetmap.org/wiki/Types_of_relation A relação associatedStreet é pouco usada no Brasil, mas muito usada na Europa. A relação public_transport é nova e provavelmente será mais usada no futuro (faz mais diferença em lugares em que as paradas são complexas e atendem a vários modos de transporte simultaneamente). A relação route_master é usada para agrupar rotas (como os dois sentidos e as variações de uma mesma linha de ônibus), mas não sei de nenhum sistema que faça uso dela. Nunca vi usarem enforcement, bridge e tunnel. A relação site é meio polêmica (frequentemente usada sem necessidade) mas é muito usada. Tem gente que mapeia, por exemplo, a área de uma universidade, os prédios, daí agrupa tudo numa relação site. Muitos defendem que isso não é necessário e que uma aplicação deveria ser capaz de determinar que o prédio pertence à universidade usando um algoritmo geométrico simples. Outros (que defendem sistemas mais fáceis de programar) preferem que a informação de continência seja expressa por relações porque daí não envolve nenhum algoritmo geométrico complicado (mas também há espaço para erros bem grosseiros). É praticamente uma extensão da discussão sobre o uso das tags is_in (que é contra-indicado). 2013/7/15 Fernando Trebien fernando.treb...@gmail.com: Outro exemplo importante: as relações boundary agrupam os pedaços de fronteira que delimitam um bairro, uma cidade, um estado, um país, um continente, e adicionam informação como o nó admin_centre que representa o centro da cidade (geralmente o marco
Re: [Talk-br] Relações
Ah, olha só. Na rota da rodovia que eu mandei como exemplo há um erro. Alguém deve ter editado esse pedaço com o Potlatch: http://www.openstreetmap.org/?lat=-30.1085lon=-51.7269zoom=14layers=Mrelation=155359 O que acontece com o Potlatch: ao excluir um membro de uma relação, não é gerado aviso nenhum (e isso é péssimo, já tem um ticket no TRAC aberto pra isso mas nunca consertaram, e provavelmente não vão agora que o editor iD é o principal foco de desenvolvimento - a nova versão, que ainda não entrou no ar, adiciona suporte às relações). Atualmente, só o JOSM avisa ao excluir um membro de uma relação, e acho que só ele quebra uma linha que é membro de uma relação corretamente (não cheguei a testar com o iD). Ao quebrar uma linha, o certo é que, se ela inteira era parte de uma relação, os 2 novos pedaços sejam parte também; o JOSM faz certo (só dá um aviso), mas o Potlatch não adiciona 1 dos pedaços. Com isso, é muito comum que os iniciantes introduzam erros no mapa sem saber. Algo parecido acontece ao combinar linhas, especialmente em fronteiras: o JOSM mostra como as relações vão ser atualizadas, o Potlatch não dá aviso nenhum, então às vezes, sem o usuário saber, as fronteiras ficam inconsistentes e bizarras, incluindo pedaços que não fecham uma área, ou até pedaços soltos longe da área principal. Resumindo, até que o novo iD entre no ar, o melhor editor pra tratar de relações é o JOSM. No Potlatch, as relações podem ser visualizadas e editadas na tab Advanced na esquerda embaixo, mas o padrão é que o Potlatch mostre a tab Simple. 2013/7/15 Fernando Trebien fernando.treb...@gmail.com Ah, mais um detalhe: a rota de ônibus está incompleta (era só um teste). Mas tem todos os elementos de uma rota completa. 2013/7/15 Fernando Trebien fernando.treb...@gmail.com Oops, corrigindo, a primeira rota de ônibus é no setido centro bairro. 2013/7/15 Fernando Trebien fernando.treb...@gmail.com Então, Erick, pra resumir: - nós (nodes) têm somente tags e posição - linhas (ways) têm tags e uma lista de nós; um par da sequência forma um segmento de reta, o par seguinte forma o segmento seguinte da linha, etc. e a ordem dos nós dá a direção da linha (áreas nada mais são do que linhas fechadas, ou seja, primeiro nó = último nó) - relações (relations) têm tags e membros com papéis, onde cada membro pode ser qualquer coisa (nó, linha ou relação) E agora exemplificando. *Rota representando o sentido bairro centro de uma linha de ônibus* http://www.openstreetmap.org/browse/relation/2727021 Repare nas etiquetas descrevendo a linha de ônibus e nos membros com os seus papéis forward, backward e stop. Especificação completa desse tipo de relação: http://wiki.openstreetmap.org/wiki/Relation:route#Bus_routes_.28also_trolley_bus.29 *Rota representando todas as partes de uma rodovia* http://www.openstreetmap.org/browse/relation/155359 Repare nas tags network, ref, type e route e também que os membros têm papéis forward e backward tal como na rota de ônibus. Especificação completa desse tipo de relação: http://wiki.openstreetmap.org/wiki/Relation:route#Road_routes *Restrição de conversão proibindo fazer o retorno* http://www.openstreetmap.org/browse/relation/3077198 Repare nos papéis via - um nó - e from e to - ambos linhas. Especificação completa: http://wiki.openstreetmap.org/wiki/Relation:restriction *Multipolígono representando um delta* http://www.openstreetmap.org/browse/relation/86833 Repare nos membros com papéis outer - borda externa - e inner - borda interna. Especificação completa: http://wiki.openstreetmap.org/wiki/Relation:multipolygon *Fronteira definindo uma mesorregião* http://www.openstreetmap.org/browse/relation/2844354 Repare nas etiquetas admin_level e type=boundary, também repare nos papéis outer e inner que funcionam exatamente da mesma forma que nos multipolígonos. Especificação completa: http://wiki.openstreetmap.org/wiki/Relation:boundary *Fronteiras definindo um bairro e uma cidade* http://www.openstreetmap.org/browse/relation/2727083 http://www.openstreetmap.org/browse/relation/242397 Repare o valor em admin_level em cada uma e os membros label e admin_centre (que aparecem com uma função similar. *Um rio que serve como fronteira em várias relações de fronteira* http://www.openstreetmap.org/browse/way/227577336 Repare lá no final a seção Parte de. Esse rio é membro das relações que representam as fronteiras de dois países (Brasil e Uruguai), de um estado brasileiro (Rio Grande do Sul), uma cidade brasileira (Jaguarão) e uma região uruguaia (Cerro Largo), além de uma microrregião brasileira e da relação que representa a região Sul do Brasil. (OBS: a tag name desse rio está errada. Combinei com um uruguaio que usaríamos a convenção européia de colocar ambos os nomes, em português e espanhol, separados por / , em ordem alfabética, mas ainda não tive tempo de atualizar toda a fronteira.) Pra mais detalhes, eis a lista das
Re: [Talk-br] Tasking Manager: interessaria a communidade brasileira para mapear o Brasil ?
Bonjour Severin, vous allez bien? :D Eu estaria disposto a ajudar com a instalação e os custos de manutenção desse serviço no Brasil. Não tenho muita experiência com hosting de aplicações feitas em Python, você (ou algum conhecido) teria sugestões de serviços de hosting e/ou um tutorial para instalar a aplicação no servidor? (O tutorial pra mim poderia ser em qualquer uma dessas línguas: português, inglês, francês, espanhol, alemão.) Fazer hosting em casa sai caro no Brasil e tem outros inconvenientes, então provavelmente vale mais à pena pagar por um serviço remoto no exterior. Encontrei uma lista com sugestões de hostings mas não conheço nenhum dos serviços indicados: http://wiki.python.org/moin/PythonHosting Eu também queria saber mais sobre o projeto, por exemplo, quem é responsável por definir as tarefas? Provavelmente vamos precisar organizar uma equipe brasileira. Atualmente, há poucas pessoas envolvidas com o OSM no Brasil (o envolvimento dos argentinos é mais de 10x superior ao brasileiro, comparando estatísticas per capita). Para que essa iniciativa não se perca, sugiro registrar esse convite como um post no fórum: http://forum.openstreetmap.org/viewforum.php?id=74 2013/7/13 Severin MENARD severin.men...@gmail.com: Olá, Não sei se todo mundo conhece o Tasking Manager, que já apresentei aqui : é um administrador de tarefas que HOT (Humanitarian OSM Team) criou para ajudar o mapeamento remoto de regiões em crise ou também para coordenar mapeamento de terreno com grandes equipes. Se quiserem participar, não hesitem, cada contribuição é benéfica para terminar rapidamente uma tarefa. Mas é de uma outra coisa que queria falar hoje. Come cada ferramenta que HOT faz, é completamente open-source, pode encontrar ele no GitHub aqui. Se pode instala-lo num servidor e criar as suas próprias tarefas. A comunidade da Argentina já fez isso : http://tareas.openstreetmap.org.ar/, sobretudo para situações de crise. Pode ser que a comunidade brasileira ou uma instituição queria fazer isso também, por isso que informo vocês. Cordialmente, Severin ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Fwd: [Imports] IBGE license statement
Pessoal, vou repassar a informação para conhecimento da comunidade. Estou tentando um contato mais direto com o IBGE para saber que tipo de atribuição eles exigem. Acho que há duas leituras possíveis: - atribuição é a possibilidade de descobrir qual é a fonte dos dados (bastaria a tag source ou mesmo uma tag nos changesets da importação dos dados) - atribuição é uma indicação clara da fonte sempre que os dados forem disponibilizados para alguém A segunda leitura exigiria colocar uma nota por cima ou ao lado do mapa toda vez que esses dados fossem exibidos (impraticável) ou verificar com a fonte (no caso, o IBGE) se bastaria fazer a atribuição correta nesta página (referida tanto na página oficial ao lado do mapa quanto na configuração padrão dos slippymaps, usados em outros sites): http://www.openstreetmap.org/copyright Se o IBGE aceitar ser um contribuidor oficial, o melhor seria relatar esse fato aqui junto com o link para a licença: http://wiki.openstreetmap.org/wiki/Contributors Inclusive, seria interessante verificar se as outras fontes usadas em importações anteriores no Brasil poderiam constar nessa página. (Bem, isso é o mundo ideal, talvez essas fontes nem disponibilizem a sua licença de uso em algum lugar...) -- Forwarded message -- From: Andy Allan gravityst...@gmail.com Date: Sun, Jul 7, 2013 at 6:33 AM Subject: Re: [Imports] IBGE license statement To: Eric Ladner eric.lad...@gmail.com Cc: impo...@openstreetmap.org impo...@openstreetmap.org On 6 July 2013 22:45, Eric Ladner eric.lad...@gmail.com wrote: Worst case, put a source:IBGE on every imported item (which technically should be there anyway). No, please don't do that. As discussed on other threads, the correct place to provide attribution is on http://www.openstreetmap.org/copyright and the associated wiki page, http://wiki.openstreetmap.org/wiki/Contributors If you want to provide sources for the entities in the bulk import, then do so using a tag on the changeset. It uses approximately 1/50,000th of the space in the database. Further, since it's only the first version of the entity that comes from the bulk import, that source for that version can be automatically traced via the changeset, and saves us waiting 6 months before adding it to the ever-growing list of tags-to-automatically-strip-in-editors. In summary, the entities created in a bulk import should contain the absolute minimal set of tags. The changesets are an appropriate place for any necessary metadata regarding the import. Thanks, Andy ___ Imports mailing list impo...@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Regiões Administrativas do Distrito Federal
Tem razão, o DF (que tem governo próprio) é dividido em regiões administrativas (sem governo, subordinados ao DF) e é proibido por lei que uma região dessas tenha governo, então parece mais com a definição de distrito. http://pt.wikipedia.org/wiki/Regi%C3%A3o_Administrativa_(Distrito_Federal) http://pt.wikipedia.org/wiki/Distrito#Brasil http://pt.wikipedia.org/wiki/Distritos_do_Brasil Sendo assim, as relações das regiões teriam a tag admin_level=9. O nó com o papel admin_centre teria a tag place=city para Brasília (além de capital=yes). Para as outras regiões, se você não tiver um critério melhor (alguma classificação oficial de diferentes tipos de região), pode adotar o indicado no wiki (http://wiki.openstreetmap.org/wiki/Key:place) que é: - place=hamlet para regiões com menos de ~mil habitantes - place=village para regiões com menos de ~10 mil habitantes - place=town para regiões com menos de ~100 mil habitantes Pode ser útil: http://pt.wikipedia.org/wiki/Anexo:Lista_de_regi%C3%B5es_administrativas_do_Distrito_Federal_por_popula%C3%A7%C3%A3o Pela definição no wiki do OSM, as 10 mais populosas nessa lista seriam tipicamente consideradas cidades. Eu no fundo acho que não estaria errado colocar admin_level=9 para todas as regiões e usar a tag place livremente (inclusive com o valor city) já que antigamente essas regiões eram chamadas de cidades-satélite. 2013/7/8 Ednei Ramthum do Amaral edneirama...@ig.com.br: Sobre o assunto, vale lembrar que essa divisão da imagem da Wikipédia é a última oficial disponível, mas já foram criadas várias outras regiões administrativas (RAs) q não tiveram seus limites oficiais definidos. Pras RAs mais recentes, a melhor fonte q conheço é a q vem sendo usada pela Codeplan: http://www.codeplan.df.gov.br/areas-tematicas/demografia/257-pdad.html (ver notas metodológicas) Não sei se a melhor opção é listar as RAs desatualizadas, deixando de incluir as mais recentes, mas mantendo a limitação oficial; ou listar tds, usando limitação não oficial; ou até listar todas e usar limitação oficial pras antigas e a não oficial pras novas (o q poderia confundir, dando a entender que uma nova RA fica dentro de uma antiga...) -- Sobre a classificação, eu equivaleria a distrito, por ser intermediário entre cidade e bairro. Cidade no Brasil costuma ser associado a município, e não é o caso das RAs. Brasília, considerada como todo o DF, seria o mais próximo de município (assim é considerada, por exemplo, no Censo). Também não é sempre q existem áreas verdes entre as RAs. Algumas, como o Sudoeste/Octogonal, por exemplo, seriam perfeitamente bairros da RA I - Brasília. Ceilândia e Taguatinga são, visivelmente, uma coisa só. Distritos tb têm essa característica de às vezes serem conurbados (normalmente em cidades grandes), e em outras serem separados da sede (normalmente em municípios pequenos, qnd o distrito acaba buscando emancipação, com o tempo). -- Bom, não costumo participar aqui. Então desculpem se disse algo contrário a algum consenso já estabelecido... Ednei Em 8 de julho de 2013 04:09, Fernando Trebien fernando.treb...@gmail.com escreveu: Hm será que você tem permissão pra importar isso? Está com uma licença CC 2.5 na Wikipédia, ou seja, requer que as obras derivadas sejam disponibilizadas sob a mesma licença, até onde eu sei isso é incompatível com a licença ODbL do OSM. Se for possível, talvez você possa usar o plugin ImportVec para importar o SVG. Se não funcionar, você pode converter o SVG num PNG e traçar sobre ele usando o PicLayer. Uma coisa que você tem que definir é se essas regiões são cidades (admin_level = 8) ou bairros (admin_level = 10). Se for algo intermediário, talvez possam ser tratadas como distritos (admin_level = 9) (http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#admin_level). Pelo que lembro, o DF não é uma área urbana contínua, as regiões estão separadas por vegetação, então isso me pareceria mais com cidades independentes e não com distritos (normalmente são grandes porções de uma mesma cidade grande). Você já mexeu um pouco com relações no JOSM? Basicamente você vai precisar traçar 1 linha para cada fronteira entre cada par de regiões, e depois agrupar as fronteiras de uma mesma região numa relação com a tag boundary=administrative (http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative). Por exemplo, se as suas regiões fossem dois quadrados adjacentes, você teria 2 relações, cada uma com 4 membros (um para cada lado), você desenharia 7 linhas independentes e a linha do meio, compartilhada entre os dois quadrados, seria incluída em ambas as relações. Para fazer isso no JOSM, depois de ter desenhado as linhas, selecione elas e vá em Preset Relations Boundary. Dê um nome, escolha em Boundary type o valor administrative e em Administrative level o valor que você definiu (8 se for cidade, 9 se for distrito ou 10 se for bairro). Daí o JOSM já abre direto o editor
Re: [Talk-br] Renomear várias ruas de uma vez
Exato. É recomendação da comunidade não abreviar nomes na tag name: http://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29 O Nominatim suporta várias abreviaturas (inclusive em Português) e o Mapnik também deveria suportá-las ao renderizar (quer dizer, deveria converter os nomes completos para os abreviados): http://wiki.openstreetmap.org/wiki/Name_finder:Abbreviations#Portugu.C3.AAs_-_Portuguese Isso quer dizer que se você cadastrar uma avenida com Avenida, você pode encontrá-la usando tanto Avenida quanto Av. Mas se ela for cadastrada com Av, só poderá ser encontrada com Av e não com Avenida. Outro problema com abreviaturas é o processamento feito por aplicações mais simples (digamos, o seu GPS). Se você procurar por uma avenida, pode acabar não a encontrando porque está escrita com Av ao invés de Avenida. Como sempre, é melhor optar por um padrão consistente: ou abreviamos tudo, ou não abreviamos nada. Não abreviar nada é o mais genérico (já que Av pode significar outras coisas além de avenida). Já em nomes de lugares acho ok abreviar quando a prática local é usar a abreviatura e não o nome completo (ex.: UFRGS - Quarteirão 1 ao invés de Universidade Federal do Rio Grande do Sul - Quarteirão 1), desde que outra tag (alt_name, official_name, etc.) tenha o nome por extenso para permitir a busca. Infelizmente o Mapnik não usa a tag short_name por padrão (acho que deveria, reduziria os conflitos visuais em regiões densas) e aplicações mais simples que não têm conhecimento da tag short_name (como certos GPSs) funcionariam melhor com as abreviaturas. Sugiro usar official_name para o nome completo porque é rara em outros contextos e assim fica mais fácil corrigir quando for necessário/possível/útil. 2013/7/1 Nelson A. de Oliveira nao...@gmail.com: 2013/7/1 Blademir Andrade de Lima blademi...@hotmail.com: Acho que as abreviações deveriam aparecer de forma automática, ou pela escolha do usuário, do renderizador utilizado, ou da finalidade que se usa o mapa. Justamente por isso que tem que se utilizar o nome completo no OSM, sem nenhum tipo de abreviação. Fica fácil abreviar algo caso a aplicação necessite. Com o nome abreviado já se torna mais difícil (se alguém utilizar um A., não dá para saber se é alameda, artéria, avenida, etc). ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Aeroporto de Ribeirão
Pois é. Tentei investigar um pouco mais sobre esse assunto e parece que os italianos estão interessados num novo esquema de tags: http://wiki.openstreetmap.org/wiki/Proposed_features/Urban_settlements Consultando o TagInfo, parece que essa proposta só foi usada em 2 objetos até o momento. Considerando as discussões nesse artigo, lembrei deste outro: http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed Aqui se sugere que áreas urbanas são caracterizadas pela existência da tag place, e as não-urbanas pela sua ausência. Dei uma olhada em Berlim, Paris, Londres, Roma e mais algumas cidades pequenas próximas, e em nenhuma delas há um polígono/multipolígono representando a separação entre a área urbana e a não-urbana. Ou seja, esse mapeamento parece pouco comum. Ao invés disso, as áreas residenciais, industriais, comerciais e agrícolas (landuse=farmland) estão claramente demarcadas. Algumas têm nomes, outras não. Em alguns casos usaram a tag place na relação da fronteira administrativa da cidade. Não sei até que ponto isso faz sentido, especialmente considerando a lógica do artigo anterior. Acho que faria mais sentido evitar, a menos que a fronteira administrativa corresponda exatamente à área urbanizada. Então, acho que faria sentido usar a tag place num grande (multi)polígono demarcando a área urbana, e não usá-la nas relações administrativas. Fazendo assim acho que seria possível importar esses dados do IBGE. Um detalhe: o Mapnik não suporta essa combinação de tags no momento, então não teríamos nenhum retorno visual. Ao pesquisar pela cidade no Nominatim, haveria 3 entradas: uma para o nó da cidade, uma para a área urbana (que estamos adicionando), e uma para a fronteira administrativa (que normalmente inclui um pouco da área rural). Ao clicar na área urbana, ficaria visível o contorno. O que não faria sentido (e isso é apontado dentro do primeiro artigo) é usar landuse=residential, como já foi feito em algumas cidades brasileiras. Fazer isso pode ser considerado mapear para o renderizador. O multipolígono da área urbana então teria membros com o papel outer. Poderia ter um membro label apontando para o nó da cidade (o mesmo que tem o papel admin_centre na relação da fronteira adminitrativa da cidade). Poderia também ter uma tag settlement=yes para corresponder à proposta dos italianos (e isso facilitaria o trabalho de conversão caso um dia mudassem o esquema de tags para representar esses dados). 2013/6/28 Nelson A. de Oliveira nao...@gmail.com: Ressuscitando um pouco a parte de delimitação de área urbana e rural, no IBGE tem essa informação. Por exemplo, para SP tem o arquivo 35SEE250GC_SIR.shp (em ftp://geoftp.ibge.gov.br/malhas_digitais/censo_2010/setores_censitarios/sp.zip) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Aeroporto de Ribeirão
Mais uma coisa: o nome do multipolígono poderia ser Área Urbana de nome da cidade. Isso ajudaria a diferenciar os itens nos resultados de busca do Nominatim. 2013/6/29 Fernando Trebien fernando.treb...@gmail.com: Pois é. Tentei investigar um pouco mais sobre esse assunto e parece que os italianos estão interessados num novo esquema de tags: http://wiki.openstreetmap.org/wiki/Proposed_features/Urban_settlements Consultando o TagInfo, parece que essa proposta só foi usada em 2 objetos até o momento. Considerando as discussões nesse artigo, lembrei deste outro: http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed Aqui se sugere que áreas urbanas são caracterizadas pela existência da tag place, e as não-urbanas pela sua ausência. Dei uma olhada em Berlim, Paris, Londres, Roma e mais algumas cidades pequenas próximas, e em nenhuma delas há um polígono/multipolígono representando a separação entre a área urbana e a não-urbana. Ou seja, esse mapeamento parece pouco comum. Ao invés disso, as áreas residenciais, industriais, comerciais e agrícolas (landuse=farmland) estão claramente demarcadas. Algumas têm nomes, outras não. Em alguns casos usaram a tag place na relação da fronteira administrativa da cidade. Não sei até que ponto isso faz sentido, especialmente considerando a lógica do artigo anterior. Acho que faria mais sentido evitar, a menos que a fronteira administrativa corresponda exatamente à área urbanizada. Então, acho que faria sentido usar a tag place num grande (multi)polígono demarcando a área urbana, e não usá-la nas relações administrativas. Fazendo assim acho que seria possível importar esses dados do IBGE. Um detalhe: o Mapnik não suporta essa combinação de tags no momento, então não teríamos nenhum retorno visual. Ao pesquisar pela cidade no Nominatim, haveria 3 entradas: uma para o nó da cidade, uma para a área urbana (que estamos adicionando), e uma para a fronteira administrativa (que normalmente inclui um pouco da área rural). Ao clicar na área urbana, ficaria visível o contorno. O que não faria sentido (e isso é apontado dentro do primeiro artigo) é usar landuse=residential, como já foi feito em algumas cidades brasileiras. Fazer isso pode ser considerado mapear para o renderizador. O multipolígono da área urbana então teria membros com o papel outer. Poderia ter um membro label apontando para o nó da cidade (o mesmo que tem o papel admin_centre na relação da fronteira adminitrativa da cidade). Poderia também ter uma tag settlement=yes para corresponder à proposta dos italianos (e isso facilitaria o trabalho de conversão caso um dia mudassem o esquema de tags para representar esses dados). 2013/6/28 Nelson A. de Oliveira nao...@gmail.com: Ressuscitando um pouco a parte de delimitação de área urbana e rural, no IBGE tem essa informação. Por exemplo, para SP tem o arquivo 35SEE250GC_SIR.shp (em ftp://geoftp.ibge.gov.br/malhas_digitais/censo_2010/setores_censitarios/sp.zip) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Imagem de Gramado/RS
Qualquer, desde que não tenha copyright ou alguma licença de uso restrita. Não podemos usar imagens do Google mesmo com o PicLayer. On Jun 27, 2013 2:06 PM, Blademir Andrade de Lima blademi...@hotmail.com wrote: O que acontece também dando zoom ma mesma imagem é que ela some quando está próxima, no novo ID acontece, no Potlatach, e no JOSM em alguns casos (principalmente falha no software). mas no caso de gramado é que não tem foto satélite disponível. Mas de qualquer forma, qualquer imagem disponível ajuda, só usar Piclayer, e ajustala, não vejo problema em usa-las. pelo menos lá ja possui dados. Pior se tiver que começar do zero sem referência nenhuma. From: fernando.treb...@gmail.com Date: Thu, 27 Jun 2013 13:34:35 -0300 To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Imagem de Gramado/RS De qualquer forma, acabei de verificar que nenhuma das duas imagens é confiável o bastante. No máximo servem para saber aproximadamente onde estão os pontos de interesse. 2013/6/27 Leandro Motta Barros l...@stackedboxes.org: Desenhar as ruas usando esses mapas como base não seria violação de copyright? Acho que mesmo no caso de mapas produzidos por órgãos do governo, o orientação ainda é conseguir permissão expressa antes de usar como fonte pro OSM. (E o primeiro link, ainda que esteja num site oficial, parece ser reprodução de um mapa comercial) LMB 2013/6/27 Fernando Trebien fernando.treb...@gmail.com: Outra idéia: você também pode fazer isso se conseguir um mapa turístico (talvez em papel), desde o mapa tenha respeitado razoavelmente bem a geometria (formato das ruas e suas posições relativas). Este aqui me parece estar respeitando bem a geometria, mas é praticamente impossível de ler: http://www.gramado.rs.gov.br/images/stories/mapa_02.jpg Talvez este respeite, teria que sobrepor ao mapa atual para ter certeza: http://www.gramado.rs.gov.br/images/stories/turismo/mapa-turistico-alta.jpg Na verdade, combinando esses dois mapas, seria possível completar as ruas (com o primeiro mapa) e os pontos turísticos (com o segundo). 2013/6/27 Fernando Trebien fernando.treb...@gmail.com: Bem, o problema acontece tanto no JOSM quanto no Potlatch quanto no site do próprio Bing. É um buraco no mapa do Bing e não tem como corrigir até que eles fotografem a região de novo. O melhor que você pode fazer é conseguir outra imagem (pode ser um mapa em papel escaneado ou uma imagem aérea, talvez a prefeitura disponibilize algo assim?) e alinhá-la à imagem de fundo do Bing no JOSM usando o plugin PicLayer. Uma vez alinhado, você pode salvar o alinhamento e reutilizar quantas vezes quiser. Posso ajudar você nisso se você tiver a imagem em mãos. Já me ocorreu essa questão antes e eu não achei nenhum outro provedor de imagens para o Brasil (exceto o Google, que não podemos usar). O MapQuest Open Aerial (segunda melhor opção depois do Bing, aparentemente) não cobre o Brasil. Existe uma base de imagens chinesa-brasileira, o CBERS, mas não consegui achar imagens com detalhe suficiente nessa base. Uma coisa que você pode fazer (e talvez seja mais fácil) é adicionar os pontos turísticos como nodos (não como áreas) fazendo survey: você visita o ponto turístico, marca no seu GPS a posição em que você está, depois só faz upload dos pontos (é bom editar antes para corrigir eventuais problemas de precisão no GPS). Sem imagem é meio complicado fazer um desenho preciso de edifícios, mas acho que só marcar os pontos já seria muito melhor do que nada. 2013/6/27 Eduardo Medeiros eduardoamedei...@gmail.com: Alguém poderia indicar como corrigir (se for possível) as imagens de satélite de Gramado/RS. Dependendo do nível de zoom uma parte delas some. Quando aproxima mais reaparece. Até no mesmo zoom, quando rola para o lado elas somem. Gostaria de adicionar os pontos turísticos da cidade. []s, Eduardo Medeiros ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips
Re: [Talk-br] Encontro em Porto Alegre
Se organizarem uma Mapping Party, podem contar comigo. A região sul da cidade é a que mais tem ruas não-mapeadas. Além das ruas, acho que uma boa lista de metas para a mapping party seria esta: http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/RS/Porto_Alegre/Status#Progresso 2013/6/27 wille wi...@wille.blog.br: Olá, Na próxima semana vai acontecer o FISL 14 em Porto Alegre. Samuel Vale vai dar uma palestra no dia 04: http://fisl.org.br/14/papers_ng/activity/view?activity_id=383 Eu ainda dependo de um detalhe para participar do FISL, mas tudo indica que estarei lá. Acho que seria uma boa oportunidade de organizarmos uma Mapping Party para estimular o surgimento de novos colaboradores ou pelo menos um encontro informal entre mapeadores. O que acham? Alguém que mora em PoA se anima? Abraços, -- wille http://wille.blog.br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Imagem de Gramado/RS
Hm não entendo tanto de licenças. Você quer dizer que normalmente tem copyright ou que a lei diz claramente que tudo tem copyright até que se diga explicitamente o contrário? Creio que dados divulgados pelas prefeituras costumam ser públicos. 2013/6/27 Leandro Motta Barros l...@stackedboxes.org: Só tem que cuidar que *por padrão* as coisas tem copyright. Só podemos usar fontes que explicitamente permitam o uso (inclusive com fins comerciais). 2013/6/27 Fernando Trebien fernando.treb...@gmail.com: Qualquer, desde que não tenha copyright ou alguma licença de uso restrita. Não podemos usar imagens do Google mesmo com o PicLayer. On Jun 27, 2013 2:06 PM, Blademir Andrade de Lima blademi...@hotmail.com wrote: O que acontece também dando zoom ma mesma imagem é que ela some quando está próxima, no novo ID acontece, no Potlatach, e no JOSM em alguns casos (principalmente falha no software). mas no caso de gramado é que não tem foto satélite disponível. Mas de qualquer forma, qualquer imagem disponível ajuda, só usar Piclayer, e ajustala, não vejo problema em usa-las. pelo menos lá ja possui dados. Pior se tiver que começar do zero sem referência nenhuma. From: fernando.treb...@gmail.com Date: Thu, 27 Jun 2013 13:34:35 -0300 To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Imagem de Gramado/RS De qualquer forma, acabei de verificar que nenhuma das duas imagens é confiável o bastante. No máximo servem para saber aproximadamente onde estão os pontos de interesse. 2013/6/27 Leandro Motta Barros l...@stackedboxes.org: Desenhar as ruas usando esses mapas como base não seria violação de copyright? Acho que mesmo no caso de mapas produzidos por órgãos do governo, o orientação ainda é conseguir permissão expressa antes de usar como fonte pro OSM. (E o primeiro link, ainda que esteja num site oficial, parece ser reprodução de um mapa comercial) LMB 2013/6/27 Fernando Trebien fernando.treb...@gmail.com: Outra idéia: você também pode fazer isso se conseguir um mapa turístico (talvez em papel), desde o mapa tenha respeitado razoavelmente bem a geometria (formato das ruas e suas posições relativas). Este aqui me parece estar respeitando bem a geometria, mas é praticamente impossível de ler: http://www.gramado.rs.gov.br/images/stories/mapa_02.jpg Talvez este respeite, teria que sobrepor ao mapa atual para ter certeza: http://www.gramado.rs.gov.br/images/stories/turismo/mapa-turistico-alta.jpg Na verdade, combinando esses dois mapas, seria possível completar as ruas (com o primeiro mapa) e os pontos turísticos (com o segundo). 2013/6/27 Fernando Trebien fernando.treb...@gmail.com: Bem, o problema acontece tanto no JOSM quanto no Potlatch quanto no site do próprio Bing. É um buraco no mapa do Bing e não tem como corrigir até que eles fotografem a região de novo. O melhor que você pode fazer é conseguir outra imagem (pode ser um mapa em papel escaneado ou uma imagem aérea, talvez a prefeitura disponibilize algo assim?) e alinhá-la à imagem de fundo do Bing no JOSM usando o plugin PicLayer. Uma vez alinhado, você pode salvar o alinhamento e reutilizar quantas vezes quiser. Posso ajudar você nisso se você tiver a imagem em mãos. Já me ocorreu essa questão antes e eu não achei nenhum outro provedor de imagens para o Brasil (exceto o Google, que não podemos usar). O MapQuest Open Aerial (segunda melhor opção depois do Bing, aparentemente) não cobre o Brasil. Existe uma base de imagens chinesa-brasileira, o CBERS, mas não consegui achar imagens com detalhe suficiente nessa base. Uma coisa que você pode fazer (e talvez seja mais fácil) é adicionar os pontos turísticos como nodos (não como áreas) fazendo survey: você visita o ponto turístico, marca no seu GPS a posição em que você está, depois só faz upload dos pontos (é bom editar antes para corrigir eventuais problemas de precisão no GPS). Sem imagem é meio complicado fazer um desenho preciso de edifícios, mas acho que só marcar os pontos já seria muito melhor do que nada. 2013/6/27 Eduardo Medeiros eduardoamedei...@gmail.com: Alguém poderia indicar como corrigir (se for possível) as imagens de satélite de Gramado/RS. Dependendo do nível de zoom uma parte delas some. Quando aproxima mais reaparece. Até no mesmo zoom, quando rola para o lado elas somem. Gostaria de adicionar os pontos turísticos da cidade. []s, Eduardo Medeiros ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) -- Fernando Trebien +55 (51
Re: [Talk-br] Hierarquia das rodovias
fora os sentimentos para depois tentar chegar a um possível conjunto de regras. Pois bem. Existem ruas residenciais em que a preferência é do automóvel, que aceleram a 40+km/h mesmo que só até o próximo sinal, que somente os sinais de trânsito funcionam como limitadores de velocidade, que crianças não brincam na rua. Frequentemente a calçada é regular e livre para os pedestres andarem, enquanto o asfalto é exclusivo para veículos, tanto para deslocamento quanto para estacionamento. E existem ruas que apesar de serem permitidas para automóveis (portanto não highway=pedestrian), e serem públicas (não dentro de condomínio etc, não ser access=destination etc.) a velocidade é drasticamente reduzida, com diversos quebra-molas (traffic_calming=bump, não sei como se chama Brasil a fora), crianças brincam na rua, jogam bola, soltam pipa etc. Frequentemente os cruzamentos não são sinalizados, ou somente quando cruzarem ruas de maior prioridade/velocidade, a calçada é irregular e ocupada de veículos estacionados, e o pedestre anda na rua mesmo. Seguem links para o Google Street View dos dois tipos de rua: Exemplo do primeiro tipo: Rua Silveira Martins, no Catete: https://www.google.com/maps?ll=-22.944799,-43.1567spn=0.270316,0.528374cbp=12,92.39,,0,3.4layer=cpanoid=91uur_e5X83iYaiVIw1ynQcbll=-22.92574,-43.177378dg=optt=mz=12 Exemplo do segundo tipo: Rua Capitão Cruz, em Cordovil: https://www.google.com/maps?q=rua+capit%C3%A3o+cruz,+551hl=enie=UTF8ll=-22.824393,-43.30894spn=0.270556,0.528374sll=-22.824418,-43.308954layer=ccbp=13,68.55,,0,3.39cbll=-22.824393,-43.30894t=mz=12panoid=-VaAgpnzD5obs8e6LOaNHA Eu creio que deveríamos diferenciar os dois tipos de rua. Acredito que o primeiro tipo deveria ser highway=residential e o segundo highway=living_street. Quanto aos critérios: - Ser mão-dupla - A rua possui limitadores de velocidade // Quantos? A cada X metros? Por exemplo, a rua do segundo link, possui três quebra-molas a cada quarteirão. - Os pedestres circulam preferenciamente no asfalto ao invés de na calçada, se existir. Se sim, living_street, se não, residential. Note que o tipo padrão continua sendo residential, seria apenas uma especialização, só que para baixo ao invés de para cima em termos de prioridade/velocidade (tertiary, secondary). []s ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Hierarquia das rodovias
Hehe Nelson, na verdade eles são iguais. Sempre que surge um novo eu coloco tanto no fórum quanto no wiki. A versão em alemão por enquanto tem uma modificação estética que eu não tive tempo de passar para as demais versões. Foi uma solicitação da comunidade alemã, que se sentiu confusa ao interpretar por onde o fluxo começava (são 6 entradas possíveis, 1 principal e mais 5 para quem está usando a classificação do BIT). Flávio, eu acho melhor manter a especificação da largura. Lembre que não são só carros que usam as vias, caminhões também, e há carros de tamanhos diversos. Essa medida saiu da menor classe considerada nos projetos de estradas do DNIT (tem um link pra esse documento nesse mesmo artigo no wiki); se uma via é ainda menos larga que isso, provavelmente não está seguindo um projeto adequado. Uma das coisas que eu apoiei até agora foi a definição de critérios claros e não subjetivos; nada é mais claro do que uma medida exata. O seu item 2 me parece uma leitura quase literal do fluxograma. Por favor, aponte as diferenças. O seu item 3 pertence à discussão sobre o que seria uma living street no Brasil. Até agora ninguém (nem mesmo a comunidade alemã) reclamou dessa definição de living street, mas vamos abrir o diálogo então. Eu acho útil usá-lo para ruas estreitas e apontei a razão no meio das discussões: existe a possibilidade de moradores deixarem carros estacionados no meio do caminho (entre outros objetos), dificultando a passagem. No item 4 você deve notar que a seta que sai da caixa Só 1 faixa por sentido e leva a trunk e motorway é a seta Não, o que implica 2 ou mais faixas. Eu tenho a impressão que a sua lógica vai tornar o fluxograma mais complexo e sem benefícios aos usuários do mapa (eles saberão que trunk é usado em n casos diferentes mas não saberão qual dos casos é). No final do seu texto eu fiquei confuso se você acha que trunks e motorways devem todas possuir pelo menos 2 faixas ou não. No item 5 eu concordo com um critério mais específico sobre o que é acostamento, talvez possamos estabelecer uma largura mínima, o que você acha? Seria legal descobrir se o DNIT tem essa especificação em algum lugar. No item 6 todas as caixas que possuem vários itens (isso inclui a primeira caixa e também a caixa que distingue motorway de trunk) significam que todos os critérios têm que ser satisfeitos para seguir pelo lado Sim do fluxo. Se um deles não for satisfeito, é Não. Realmente é melhor escrever isso no wiki, pra deixar claro, ou até mesmo mudar o texto no gráfico. Me parece que mudar para velocidade permitida seria um problema porque que nessas vias geralmente não há sinalização de velocidade (pelo menos em Porto Alegre quase não há). Eu discordo de eliminar esse item porque senão você poderia acabar tendo uma via residencial de 2km de comprimento, fácil de trafegar, ampla, sem obstáculos, e ela seria considerada inferior a outras terciárias que são muito mais difíceis de trafegar (e muito provavelmente menos importantes). Existe um problema em definir quando essa discussão está madura. Há semanas ninguém mencionava qualquer coisa sobre ela. Há pouco alguém disse que concordava com o meu ponto de vista original (que a classificação deveria seguir a hierarquia administrativa), que é como as outras comunidades têm feito pelo mundo. Ou seja, acho que sempre haverão posições divergentes. Eu tenho me esforçado para extrair o consenso, mas não é possível fazer isso se as pessoas não participarem. Eu criei uma enquete no fórum sobre diferenças entre motorway e trunk e absolutamente ninguém respondeu até agora. Então, Flávio, como já passou um certo tempo e já trocamos mais de 150 mensagens a respeito e no final ninguém mais discordou, eu vou tentar encaixar as suas observações no fluxograma SE elas não o tornarem mais complexo do que já está (para facilitar para os iniciantes) E se parecerem úteis a mais pessoas E não houverem posições contrárias. Uma coisa que você pode fazer é baixar o fonte do fluxograma (o link está lá no fórum: http://forum.openstreetmap.org/viewtopic.php?id=21275), alterá-lo e compartilhar conosco para que possamos dar as nossas opiniões também. Se você não mexer com o yEd você pode até fazer um rascunho por cima (com algo como o Paint) que se houver apoio eu mudo no fluxograma depois. 2013/6/19 Nelson A. de Oliveira nao...@gmail.com: Flavio, 2013/6/19 Flavio Bello Fialho bello.fla...@gmail.com: Antes de mais nada, devo dizer que o fluxograma está muito bom, de forma geral. Há, contudo, alguns aspectos que ainda podem ser aperfeiçoados: A última versão seria esta: http://i.imgur.com/ih2G92Y.png Ela já contempla vários aspectos que você citou e acredito que esteja muito boa para classificar a grande maioria das vias. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months
Re: [Talk-br] Colaboradores estrangeiros
Pessoal, Em Roraima, o problema é na verdade com estas duas relações: http://www.openstreetmap.org/browse/relation/326282 http://www.openstreetmap.org/browse/relation/326288 Elas são visíveis a partir do zoom=8 no OSMI selecionando em View o item Multipolygons e apenas com a opção Ring not closed e suas sub-opções marcadas na lista Overlays. Para saber o número das relações que eu apontei acima, basta clicar em cima das bordas vermelhas e ver os detalhes no painel Selection à direita. Ambas foram quebradas por este changeset: http://www.openstreetmap.org/browse/changeset/16461474 Para descobrir, tive que ver como os membros da relação foram mudando a cada changeset usando o plugin Reverter. O problema aqui provavelmente foi o Potlatch, que não dá aviso nenhum ao quebrar e/ou combinar linhas que são membros de relações. Primeiro o usuário desconectou a fronteira entre Normandia e Uiramutã da fronteira com a Guiana e depois a reconectou ao rio (!). Deve ter sido um descuido só. Logo depois ele ajustou a fronteira, alinhando com o traçado mais detalhado do rio Maú que separa os dois países. A fronteira com a Guiana estava quebrada em 2 partes (uma para a Normandia, outra para Uiramutã), então ele resolveu combinar as linhas numa só. Nesse momento o JOSM daria um alerta, mas o Potlatch não avisou nada. O que o Potlatch fez foi excluir uma das fronteiras da Normandia e passá-la para a nova linha única, que passou a ser fronteira de Uiramutã. Uma confusão. Por fim, no norte da Normandia, o usuário adicionou um córrego que serviria para melhorar a definição da fronteira. Pra isso, ele primeiro excluiu um pedaço da fronteira (que era uma linha só dividindo as duas cidades) bem no meio da cidade, dividindo a fronteira em três, e daí excluiu a parte do meio. Nesse momento o JOSM teria dado outro alerta, e o Potlatch não faz isso. Depois disso ele traçou o córrego, e por fim duplicou o traçado fechando a fronteira, mas faltou acrescentar esse novo pedaço de fronteira como membro da relação. Do ponto de vista do usuário, estava tudo normal, pois nenhum alerta foi exibido. Eu também não o culpo por isso. Estou descrevendo em detalhe só pra que o pessoal que usa Potlatch procure entender melhor como funcionam as relações e tome cuidado ao mexer em fronteiras de bairro, municipais e estaduais. Talvez o iD trate disso melhor. On Mon, Jun 17, 2013 at 4:32 PM, Fernando Trebien fernando.treb...@gmail.com wrote: Tem razão. Eu questionei o usuário agora, parece que os problemas a que ele se referiu são as linhas verdes, que são um aviso do OSMI de que os multipolígonos estão com a tag type=boundary quando o mais certo (porque do jeito que está não está errado) seria ter type=multipolygon e boundary=administrative. http://wiki.openstreetmap.org/wiki/Relation:boundary#Software_implementation Talvez seja possível consertar isso de forma automática, sem muita urgência. On Mon, Jun 17, 2013 at 3:56 PM, Aun Johnsen li...@gimnechiske.org wrote: O problema e que o fronteira entre brasil e guiana-francese principal mente e selva silvestre - ninguem mora ai Aun Johnsen Sent from my iPhone On 17. juni 2013, at 15:49, Fernando Trebien fernando.treb...@gmail.com wrote: Pessoal, Estou passando adiante um problema apontado por um colaborador uruguaio sobre relações de fronteira na borda entre Brasil e Guiana Francesa. Ele corrigiu um problema lá mas disse que há outros com fronteiras com admin_level 4 ou 8. Alguém quer verificar? http://tools.geofabrik.de/osmi/?view=multipolygonlon=-60.33023lat=4.37133zoom=9overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes Ele disse que seria necessário ter conhecimento da fronteiras para consertar. Sei que uma boa fonte para fronteiras entre países é o LNCC (http://info.lncc.br). Para as estaduais e municipais talvez seja melhor alguém que mora no lugar ou que tem acesso aos dados oficiais verifique. -- Forwarded message -- From: muralito m-360508-de9...@messages.openstreetmap.org Date: Mon, Jun 17, 2013 at 12:49 PM Subject: [OpenStreetMap] Re: Brasil-Guyana border was broken To: fernando.treb...@gmail.com Hi Fernando Trebien, muralito has sent you a message through OpenStreetMap with the subject Re: Brasil-Guyana border was broken: == Sure, yesterday I also fixed some borders in RS. http://www.openstreetmap.org/browse/changeset/16569574 http://www.openstreetmap.org/browse/changeset/16569483 http://www.openstreetmap.org/browse/changeset/16567334 http://www.openstreetmap.org/browse/changeset/16567278 but there are others border relations broken that cannot be fixed without knowing the real border. I found them with OSM Inspector
Re: [Talk-br] Estados Unidos libera arquivos de fronteira internacional com maior precisão Fwd: [OSM-talk] Fw: Updated, more detailed international bdy. shapefiles (US Dept. of State Office of the Geo
Oi Arlindo, Me parece que a versão oficial das fronteiras é a disponibilizada pelo LNCC (http://info.lncc.br), então eu recomendo comparar com essa fonte de dados. O LNCC tem outras coisas interessantes, como a posição dos marcos de fronteira (boundary stones), que também podem ser importados no OSM (mais a título de curiosidade). Uma das vantagens do LNCC é a descrição textual da fronteira, que permitiria dar nomes a vários elementos geográficos usados para referência (como rios, morros, estradas, lagos, ilhas, etc.). On Tue, Jun 18, 2013 at 5:21 PM, Arlindo Pereira openstreet...@arlindopereira.com wrote: Se alguém quiser trabalhar na importação de fronteiras internacionais, um órgão governamental dos EUA liberou um arquivo em domínio público com precisão supostamente maior que o que temos atualmente no OSM. []s Arlindo Pereira -- Forwarded message -- From: Mikel Maron mikel_ma...@yahoo.com Date: Sun, Jun 16, 2013 at 10:09 AM Subject: [OSM-talk] Fw: Updated, more detailed international bdy. shapefiles (US Dept. of State Office of the Geographer) To: t...@openstreetmap.org t...@openstreetmap.org Of interest to those of us working on boundaries. Some recent updates geographers at US State. -Mikel * Mikel Maron * +14152835207 @mikel s:mikelmaron - Forwarded Message - Sent: Friday, June 7, 2013 5:10 PM Subject: Updated, more detailed international bdy. shapefiles (US Dept. of State Office of the Geographer) All, I have you all on my list of folks interested in detailed international boundary lines.* An update to our worldwide Large Scale International Boundaries (LSIB version 5) can be found as of today at http://HIU.state.gov (under “data”, down near the bottom (“June 2013 LSIB v. 5”, 17mb.)) This data set is in the public domain; no restrictions on its use. It includes update such as an approximation of last month’s ICJ ruling on Burkina Faso-Niger’s boundary. Also, after many requests, Kate Schaefer (in our sister “HIU” branch) and I put together last fall a worldwide country polygon file as well, which most closely matches the Sept. 2012 version (LSIB4b) of our international lines. It is posted in the same place. We’re fortunate in this office (intact here at DoS since 1921) to have or have easy access to voluminous maps, treaties, and other international boundary information from the past 150 years. We are also fortunate that our colleagues in DoD (NGA) and in the UK (DGC) have been researching and digitizing international boundaries since the late 1990’s; we continue to work closely today. That’s given us a pretty good head start on quality control for the world’s 320-some international land boundaries. Considering the caveats in the attached doc (i.e., we follow US govt. policies; certainly anyone else using this data set can change it to conform to their own policies), we always welcome from professional geographers like yourselves any corrections, suggestions, questions on international land (not maritime!) boundaries, their history, alignments, lengths, etc. all the best, Dave *if that’s not or no longer the case, let me know ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Colaboradores estrangeiros
Pessoal, Estou passando adiante um problema apontado por um colaborador uruguaio sobre relações de fronteira na borda entre Brasil e Guiana Francesa. Ele corrigiu um problema lá mas disse que há outros com fronteiras com admin_level 4 ou 8. Alguém quer verificar? http://tools.geofabrik.de/osmi/?view=multipolygonlon=-60.33023lat=4.37133zoom=9overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes Ele disse que seria necessário ter conhecimento da fronteiras para consertar. Sei que uma boa fonte para fronteiras entre países é o LNCC (http://info.lncc.br). Para as estaduais e municipais talvez seja melhor alguém que mora no lugar ou que tem acesso aos dados oficiais verifique. -- Forwarded message -- From: muralito m-360508-de9...@messages.openstreetmap.org Date: Mon, Jun 17, 2013 at 12:49 PM Subject: [OpenStreetMap] Re: Brasil-Guyana border was broken To: fernando.treb...@gmail.com Hi Fernando Trebien, muralito has sent you a message through OpenStreetMap with the subject Re: Brasil-Guyana border was broken: == Sure, yesterday I also fixed some borders in RS. http://www.openstreetmap.org/browse/changeset/16569574 http://www.openstreetmap.org/browse/changeset/16569483 http://www.openstreetmap.org/browse/changeset/16567334 http://www.openstreetmap.org/browse/changeset/16567278 but there are others border relations broken that cannot be fixed without knowing the real border. I found them with OSM Inspector. http://tools.geofabrik.de/osmi/?view=multipolygonlon=-54.00073lat=-29.38792zoom=7overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes (the warnings showed today are from data 2013-06-14 and still didn't show my corrections) Regards, M. On 2013-06-17 15:29:36 UTC Fernando Trebien wrote: Hi, Thanks for the help. If you wish you can fix the other borders as well, the Brazilian community will be glad :D I'll tell them about these issues but I think there's nobody mapping that remote area yet. Did you find out about this with Keep Right? On 2013-06-15 14:51:35 UTC muralito wrote: Fernando: Brasi-Guyana border was broken, probably by RCCaleffi. I closed the admin_level=2 ring in the node http://www.openstreetmap.org/browse/node/565262437 but I didn't adjust the border. There are also some borders of admin_level 4 and 8 broken in the same area. ¿Could you or someone in BR project check it and contact the user? Regards, M. == You can also read the message at http://www.openstreetmap.org/message/read/360508 and you can reply at http://www.openstreetmap.org/message/reply/360508 -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Colaboradores estrangeiros
Tem razão. Eu questionei o usuário agora, parece que os problemas a que ele se referiu são as linhas verdes, que são um aviso do OSMI de que os multipolígonos estão com a tag type=boundary quando o mais certo (porque do jeito que está não está errado) seria ter type=multipolygon e boundary=administrative. http://wiki.openstreetmap.org/wiki/Relation:boundary#Software_implementation Talvez seja possível consertar isso de forma automática, sem muita urgência. On Mon, Jun 17, 2013 at 3:56 PM, Aun Johnsen li...@gimnechiske.org wrote: O problema e que o fronteira entre brasil e guiana-francese principal mente e selva silvestre - ninguem mora ai Aun Johnsen Sent from my iPhone On 17. juni 2013, at 15:49, Fernando Trebien fernando.treb...@gmail.com wrote: Pessoal, Estou passando adiante um problema apontado por um colaborador uruguaio sobre relações de fronteira na borda entre Brasil e Guiana Francesa. Ele corrigiu um problema lá mas disse que há outros com fronteiras com admin_level 4 ou 8. Alguém quer verificar? http://tools.geofabrik.de/osmi/?view=multipolygonlon=-60.33023lat=4.37133zoom=9overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes Ele disse que seria necessário ter conhecimento da fronteiras para consertar. Sei que uma boa fonte para fronteiras entre países é o LNCC (http://info.lncc.br). Para as estaduais e municipais talvez seja melhor alguém que mora no lugar ou que tem acesso aos dados oficiais verifique. -- Forwarded message -- From: muralito m-360508-de9...@messages.openstreetmap.org Date: Mon, Jun 17, 2013 at 12:49 PM Subject: [OpenStreetMap] Re: Brasil-Guyana border was broken To: fernando.treb...@gmail.com Hi Fernando Trebien, muralito has sent you a message through OpenStreetMap with the subject Re: Brasil-Guyana border was broken: == Sure, yesterday I also fixed some borders in RS. http://www.openstreetmap.org/browse/changeset/16569574 http://www.openstreetmap.org/browse/changeset/16569483 http://www.openstreetmap.org/browse/changeset/16567334 http://www.openstreetmap.org/browse/changeset/16567278 but there are others border relations broken that cannot be fixed without knowing the real border. I found them with OSM Inspector. http://tools.geofabrik.de/osmi/?view=multipolygonlon=-54.00073lat=-29.38792zoom=7overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes (the warnings showed today are from data 2013-06-14 and still didn't show my corrections) Regards, M. On 2013-06-17 15:29:36 UTC Fernando Trebien wrote: Hi, Thanks for the help. If you wish you can fix the other borders as well, the Brazilian community will be glad :D I'll tell them about these issues but I think there's nobody mapping that remote area yet. Did you find out about this with Keep Right? On 2013-06-15 14:51:35 UTC muralito wrote: Fernando: Brasi-Guyana border was broken, probably by RCCaleffi. I closed the admin_level=2 ring in the node http://www.openstreetmap.org/browse/node/565262437 but I didn't adjust the border. There are also some borders of admin_level 4 and 8 broken in the same area. ¿Could you or someone in BR project check it and contact the user? Regards, M. == You can also read the message at http://www.openstreetmap.org/message/read/360508 and you can reply at http://www.openstreetmap.org/message/reply/360508 -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Abrir changeset
Erick e pessoal, Pelo visto essa técnica do Reverter não funciona sempre. Tem um jeito mais simples: 1. Abrir a página do changeset (por exemplo, uma em que estou trabalhando agora: http://www.openstreetmap.org/browse/changeset/16458886) 2. Clicar em osmChange XML 3. Salvar com a extensão .osc 4. Abrir no JOSM Isso não faz a reversão, apenas permite baixar um changeset para analisá-lo. Infelizmente não aparecem as modificações na lista de comandos, então serve apenas para saber o que foi incluído ou modificado no changeset. Para as exclusões, recomendo usar o OSM History Viewer. 2013/6/15 Fernando Trebien fernando.treb...@gmail.com: Eu descobri como fazer isso ainda hoje. Tem um truque. Primeiro, baixe o plugin Reverter. Depois, rode ele passando o número do changeset. Não se preocupe, você não vai reverter nada. O plugin vai baixar o changeset e (daí vem o truque) logo depois ele vai inverter todas as ações, marcando para exclusão o que foi criado e criando o que foi excluído. Nesse momento você faz um Undo. Isso desfaz a última ação, que invertia as ações. Ta-da: agora sim você tem o conteúdo exato do changeset. Se quiser, você pode salvar a camada com o nome arquivo.osm. Fonte: http://wiki.openstreetmap.org/wiki/User:Cobra/TipsAndTricks#Load_all_objects_of_a_changeset 2013/6/14 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Olá pessoal, eu não consigo de jeito nenhuma abrir o changeset a seguir como um arquivo.osm no JOSM... Alguém sabe se é possível, se sim, me ensinar ou passar o arquivo .osm já pronto. http://www.openstreetmap.org/api/0.6/changeset/16556781/download ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-legal-talk] Data import and license compatibility
Thank you Martin. I have one more question. Now we discovered that the data may contain some ways traced over Google imagery. If we take this data set and align it to Bing imagery (node by node, not just the same offset for everything), would the result still be considered subject to copyright? Would it be considered derived work? On Wed, Jun 12, 2013 at 7:14 PM, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2013/6/12 Fernando Trebien fernando.treb...@gmail.com There was one answer in the forum (http://forum.openstreetmap.org/viewtopic.php?pid=340685) saying: If he owns the rights to the data, he is able to publish the data under further licences. CC and CT/ODbL are non-exclusive licences. yes, he is right. cheers, Martin -- Martin Koppenhoefer (Dipl-Ing. Arch.) Via del Santuario Regina degli Apostoli, 18 00145 Roma |I|I|I|I|I|I|I|I| Italia N41.851, E12.4824 tel1: +39 06.916508070 tel2: +49 30 868708638 mobil: +39 392 3114712 mobil: +49 1577 7793740 m...@koppenhoefer.com http://www.koppenhoefer.com Hinweis: Diese Nachricht wurde manuell erstellt. Wir bemühen uns um fehlerfreie Korrespondenz, dennoch kann es in Ausnahmefällen vorkommen, dass bei der manuellen Übertragung von Informationen in elektronische Medien die übertragenen Informationen Fehler aufweisen. Wir bitten Sie, dies zu entschuldigen. Any views or opinions are solely those of the author and do not necessarily represent those of koppenhoefer.com unless specifically stated. This email and any files attached are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify postmas...@koppenhoefer.com Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read messages sent to and from our systems. Thank You. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-br] Aeroporto de Ribeirão
Não conhecia! Bem interessante e útil (pra mim, principalmente depois de mapear os bairros: a imagem de fundo fica mais opaca, com os filtros dá pra contornar isso). On Jun 14, 2013 8:41 AM, Bráulio brauliobeze...@gmail.com wrote: Não sei se você conhece, mas é sempre bom usar os filtros no JOSM para esconder o que não é interessante para a edição que você está fazendo no momento. Além de ficar menos confuso, a renderização fica mais rápida. 2013/6/13 Fernando Trebien fernando.treb...@gmail.com Hm, interessante. Depois de você dizer isso, fui conferir como é feito em Berlim, e é parecido (também com landuse=residential). Mas ao invés de polígonos (áreas), eles usam multipolígonos e agrupam as ruas que limitam as quadras com o papel outer. Desculpem a ignorância, é a primeira vez que vi isso. Como são multipolígonos, fica meio escondido no Potlatch, e no JOSM é visualmente confuso porque Berlim é muito densa. Converter uma representação em outra ia dar um trabalhão, mas sempre há o bom e o ótimo né. Eu não sei nem se eu recomendaria usar multipolígonos para isso porque me parece que eles são confusos para os iniciantes e para o contribuinte casual. Então, acho que mapear as quadras como áreas simples está ok. 2013/6/13 Arlindo Pereira openstreet...@arlindopereira.com Aqui no Rio, o IPP fornece um arquivo com o contorno bastante detalhado de quadras. Importei alguns trechos pequenos nos bairros de Botafogo e Copacabana como landuse=residential para testar como fica. []s Em 13/06/2013 12:52, Fernando Trebien fernando.treb...@gmail.com escreveu: Antes que me corrijam: num shopping center, landuse=retail vai para a área do terreno (se for necessário mapeá-lo assim, depende do tamanho e da estrutura do shopping né). O prédio do shopping (no interior dessa área) recebe building=yes e shop=mall. 2013/6/13 Fernando Trebien fernando.treb...@gmail.com Hm não respondi tudo do seu e-mail original. Também acho que ele não deveria mapear os quarteirões assim. Sei que na Coréia do Sul cada quarteirão tem um nome, daí faria algum sentido (embora deva haver um esquema de tags melhor - talvez um nó por quarteirão, ou uma relação de fronteira administrativa com um nível bem elevado, algo tipo 12 ou mais). Se ele só vai fazer isso para o mapa ficar parecido com o do SimCity, melhor não fazer nada. Bem, quando na região a atividade comercial geralmente é no andar térreo e residencial nos demais andares, então eu consideraria predominantemente residencial. Eu uso landuse=commercial para complexos puramente comerciais (ou às vezes por simplicidade, para evitar usar demais a relação site): digamos que exista um terreno, com um único endereço, e alguns prédios comerciais dentro dele (podem ser lojas ou escritórios, por exemplo) sem endereço de correspondência distinto (exceto pelo complemento, como nomes ou números internos), e todo o complexo tem um nome. Nesse caso, eu usaria landuse=commercial no terreno, que também teria tags de endereço e o nome do complexo. O complexo pode ser qualquer coisa com mais de 1 elemento dentro, tipo 2 ou mais prédios ou 1 prédio e 1 estacionamento logo em frente no mesmo terreno. Prefira o bom senso: se só tem 1 prédio, pense se o prédio sozinho já não bastaria. (Isso varia conforme o estilo pessoal, tem gente que enche de detalhes, tem gente que simplifica, tem gente que só coloca 1 nó e pronto. :P) Muito parecido com isso é o mapeamento de shopping centers, onde se usaria landuse=retail. O render fica idêntico no Mapnik. Note que isso às vezes pode variar com o contexto, como no caso de uma cidade fortemente planejada como Brasília. Lá essas tags poderiam ter outros usos mais interessantes. 2013/6/13 Fernando Trebien fernando.treb...@gmail.com Além do Rio, por um tempo apareceu Belo Horizonte como cidade interessante. Recentemente eles tiraram as cidades consideradas interessantes desse mapa, não sei a razão. Mas então, é outra alternativa a considerar no próprio Brasil. Não vou recomendar Porto Alegre porque não revisei o aeroporto daqui ainda. :P Sei que está bem apresentável, agora se segue bem direitinho as recomendações da comunidade, não tenho certeza. 2013/6/13 Fernando Trebien fernando.treb...@gmail.com Bem, eu jogava SimCity. Acho que algumas pessoas pensam que landuse=residential é como quando você marca um pedaço da cidade no jogo dizendo aqui eu quero que construam casas. :P O jogo também permite marcar áreas comerciais (landuse=commercial) e industriais (landuse=industrial) (!) haha. Se esse usuário tem cometido esses erros com frequência, pode-se abordá-lo educadamente pelo sistema de mensagens do OSM (basta clicar em send message na página do perfil do usuário) e sugerir algumas leituras ou dar meia dúzia de dicas. Fazer ele se sentir capaz e útil apesar dos enganos é essencial para manter ele interessado e continuar mapeando. :D Você também pode apontar exemplos e
Re: [Talk-br] Frotas de ônibus em Brasília mapeadas no OpenStreetMap
Se vocês forem falar com eles, podiam sugerir que instalassem e usassem o OpenTripPlanner. Com isso, dá pra calcular rotas envolvendo várias linhas de ônibus (ao estilo do Google Maps). Só é necessário mapear as paradas no OSM e depois fazer um feed GTFS relacionando as linhas às paradas e os horários que cada linha passa em cada parada. É um trabalhão mas eles já devem ter essa informação, provavelmente só precisaria converter, atualizar, etc. A prefeitura de Buenos Aires faz exatamente isso: http://mapa.buenosaires.gob.ar Um exemplo: clique em ¿Como llego? e tente fazer uma rota entre Museo de la Casa Rosada e Pza. Palermo Viejo, depois clique nos resultados à esquerda abaixo de Recorridos para ver as rotas com instruções. 2013/6/14 Robian rfra...@yahoo.com.br: Realmente, me sinto gratificado vendo os dados gerados pelo OSM sendo revertidos em benefício da população do DF. Eu acho que deveríamos usar esse site como uma vitrine para mostrar a outros governos as vantagens do uso do Openstreetmap, e, também, conseguir novos mappers para deixar os dados ainda mais consistentes. Duas perguntas: (1) Os pontos de ônibus mostrados no site são do OSM ou do GDF? Se forem deles, poderíamos solicitar os arquivos para incluir na nossa base de dados. (2) Será que eles também possuem dados relativos a semáforos e outros dispositivos presentes nas vias? Abraços a todos De: Erick de Oliveira Leal erickdeoliveiral...@gmail.com Para: OSM talk-br talk-br@openstreetmap.org Enviadas: Quinta-feira, 13 de Junho de 2013 20:04 Assunto: [Talk-br] Frotas de ônibus em Brasília mapeadas no OpenStreetMap Hoje o governo do Distrito Federal lançou um novo site que mostra linhas de ônibus em Brasília, utilizando dados do projeto OpenStreetMap, deêm olhada os mais antigos para verem se está tudo nos conformes no que se diz a citação senão, por favor, tomem as medidas que já foram tomada como no caso do G1. http://www.sistemas.dftrans.df.gov.br/horarios/src/mapas/index ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Matheus Eduardo está de volta
Olá José Carlos, Talvez lhe surpreenda quão fácil é monitorar a sua região. Eu uso um feed RSS do WhoDidIt por ser mais fácil. Se você tiver interesse, posso fornecer os detalhes. Um dos problemas desse método é que cada feed cobre uma área pequena (só um pouco mais do que Porto Alegre) mas não é impossível usar mais de um feed. Eu concordo que um sistema de moderadores (tal como o da Wikipédia e, de uma certa forma, também o do TrackSource) seria muito bem-vindo. On Jun 14, 2013 3:12 PM, Jose Carlos Medeiros jcnascime...@gmail.com wrote: O mapeamento do jeito que esta, fica um pouco complicado, e sem muita segurança, já que, se alguem quiser corromper alguma coisa, basta criar um email e sair alterando as coisas. Claro, que podemos reverter, mas os itens que tem alguem olhando sempre. Eu por exemplo, mapeei o meu bairro, mas não fico monitorando isso, se alguém alterar pode ser que eu nem veja, e o mapa fique errado. Deveria ser parecido com o Waze, onde existe o responsável pela área, tipo, você se cadastra pra alterar uma região, se la não tiver responsável, então você vira um. E caso desse algum problema de o dono da área não estar disponível ou outros problemas, acionar uma pessoa ou grupo, responsável pela cidade ou região maior. Ficamos falando sempre, do ganho em ter um mapa colaborativo, que podemos utilizar pra projetos e tal, mas do jeito que ele esta não da pra confiar. Imagina se você faz um sistema de logistica ou um programa de GPS, e alguem vai e altera o mapa, a pessoa pode até corrigir, mas nem todo mundo que ficar fazendo isso. Será que alguem ja propôs alguma coisa deste tipo para a OSF? []'s José Carlos Em 15 de abril de 2013 13:15, Vitor George vitor.geo...@gmail.comescreveu: Fernando, A primeira coisa a fazer se você notar que um contribuidor está fazendo más edições, é entrar em contato, cordialmente. Se o usuário responder e entrar em um acordo contigo, o caso está resolvido. Caso alguma polêmica persista, o próximo passo seria postar aqui na lista, para que a comunidade possa debater o caso e tentar chegar a uma solução. A maioria dos casos se resolve assim. Quando isso não funciona ou quando o usuário se recusa a discutir as suas edições, recorre-se à OpenStreetMap Foundation, que pode aplicar sanções, se necessário. Neste caso do Matheus Eduardo, ele não respondeu aos contatos que foram feitos e nem parou de fazer edições. A gente entrou em contato com a OSM Foundation explicando a situação, e este usuário recebeu um bloqueio de 3 meses. http://www.openstreetmap.org/user_blocks/308 É possível monitorar as edições de um usuário a partir da sua página no site do OSM. Lá também tem um link do feed RSS, caso você use um agregador. Vitor George www.mapaslivres.org twitter.com/mapaslivres 2013/4/15 Fernando Trebien fernando.treb...@gmail.com Olá, Só pra eu saber como isso está funcionando no Brasil, que tipo de providências podem ser tomadas nesses casos? Já tive que conversar com um usuário que estava introduzindo erros. 2013/4/15 Vitor George vitor.geo...@gmail.com Pessoal, O Matheus Eduardo está fazendo edições novamente: http://www.openstreetmap.org/user/Matheus%20Eduardo/edits Se alguém notar que ele continua fazendo má edições, por favor, avisem para que possamos tomar providências. Vitor ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The bitterness of poor quality remains long after the sweetness of meeting the schedule has been forgotten. (adapted from a sign in front of Church Brothers Auto Body Works, 1929) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Matheus Eduardo está de volta
Ah, só acrescentando. Quando um projeto colaborativo cresce, não há como fugir de aplicar algum tipo de moderação ativa. Já é assim no OpenStreetMap em vários lugares da Europa, e na Wikipédia também é assim em diversos artigos (mas não todos). A única solução para escapar da moderação é não fazer/usar mapas colaborativos. Mas veja que tanto Google quanto Navteq já têm alguns recursos colaborativos (o que quer dizer que também estão sujeitos a vandalismo), então já há pouca opção disponível com garantia de qualidade. A própria Apple optou por usar dados do OpenStreetMap através do Maps em algumas regiões. 2013/6/14 Fernando Trebien fernando.treb...@gmail.com: Olá José Carlos, Talvez lhe surpreenda quão fácil é monitorar a sua região. Eu uso um feed RSS do WhoDidIt por ser mais fácil. Se você tiver interesse, posso fornecer os detalhes. Um dos problemas desse método é que cada feed cobre uma área pequena (só um pouco mais do que Porto Alegre) mas não é impossível usar mais de um feed. Eu concordo que um sistema de moderadores (tal como o da Wikipédia e, de uma certa forma, também o do TrackSource) seria muito bem-vindo. On Jun 14, 2013 3:12 PM, Jose Carlos Medeiros jcnascime...@gmail.com wrote: O mapeamento do jeito que esta, fica um pouco complicado, e sem muita segurança, já que, se alguem quiser corromper alguma coisa, basta criar um email e sair alterando as coisas. Claro, que podemos reverter, mas os itens que tem alguem olhando sempre. Eu por exemplo, mapeei o meu bairro, mas não fico monitorando isso, se alguém alterar pode ser que eu nem veja, e o mapa fique errado. Deveria ser parecido com o Waze, onde existe o responsável pela área, tipo, você se cadastra pra alterar uma região, se la não tiver responsável, então você vira um. E caso desse algum problema de o dono da área não estar disponível ou outros problemas, acionar uma pessoa ou grupo, responsável pela cidade ou região maior. Ficamos falando sempre, do ganho em ter um mapa colaborativo, que podemos utilizar pra projetos e tal, mas do jeito que ele esta não da pra confiar. Imagina se você faz um sistema de logistica ou um programa de GPS, e alguem vai e altera o mapa, a pessoa pode até corrigir, mas nem todo mundo que ficar fazendo isso. Será que alguem ja propôs alguma coisa deste tipo para a OSF? []'s José Carlos Em 15 de abril de 2013 13:15, Vitor George vitor.geo...@gmail.com escreveu: Fernando, A primeira coisa a fazer se você notar que um contribuidor está fazendo más edições, é entrar em contato, cordialmente. Se o usuário responder e entrar em um acordo contigo, o caso está resolvido. Caso alguma polêmica persista, o próximo passo seria postar aqui na lista, para que a comunidade possa debater o caso e tentar chegar a uma solução. A maioria dos casos se resolve assim. Quando isso não funciona ou quando o usuário se recusa a discutir as suas edições, recorre-se à OpenStreetMap Foundation, que pode aplicar sanções, se necessário. Neste caso do Matheus Eduardo, ele não respondeu aos contatos que foram feitos e nem parou de fazer edições. A gente entrou em contato com a OSM Foundation explicando a situação, e este usuário recebeu um bloqueio de 3 meses. http://www.openstreetmap.org/user_blocks/308 É possível monitorar as edições de um usuário a partir da sua página no site do OSM. Lá também tem um link do feed RSS, caso você use um agregador. Vitor George www.mapaslivres.org twitter.com/mapaslivres 2013/4/15 Fernando Trebien fernando.treb...@gmail.com Olá, Só pra eu saber como isso está funcionando no Brasil, que tipo de providências podem ser tomadas nesses casos? Já tive que conversar com um usuário que estava introduzindo erros. 2013/4/15 Vitor George vitor.geo...@gmail.com Pessoal, O Matheus Eduardo está fazendo edições novamente: http://www.openstreetmap.org/user/Matheus%20Eduardo/edits Se alguém notar que ele continua fazendo má edições, por favor, avisem para que possamos tomar providências. Vitor ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The bitterness of poor quality remains long after the sweetness of meeting the schedule has been forgotten. (adapted from a sign in front of Church Brothers Auto Body Works, 1929) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed
Re: [Talk-br] Matheus Eduardo está de volta
Hm no caso é o preço que alguns pagam, né. A maioria simplesmente usa e não se envolve. Mas como a monitoração é fácil de fazer, é um preço pequeno. É mais barato do que seria pagar regularmente por um serviço de GPS, especialmente um que não conserta os erros que você mesmo encontra ou que não permite que você acrescente informação que você mesmo (ou alguém que você conhece) vai usar. 2013/6/14 Nelson A. de Oliveira nao...@gmail.com: Uma vez eu tive a mesma dúvida sobre vandalismos, edições erradas, novos usuários etc, e basicamente a resposta foi: é o preço que se paga pela visibilidade e por atrair mais gente. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Hierarquia das rodovias
Bem Vitor, várias pessoas me contestaram quando eu propus essa forma de classificação no início da discussão, dizendo que isso não reflete a importância das vias. Quando eu terminei o fluxograma, os alemães me disseram que era do jeito que você apontou (por nível administrativo: federal, regional e municipal) que eles fazem lá. Nesse ponto do processo eu já mudei a minha opinião de forma que a importância me parece melhor traduzida pelo volume de tráfego, que é mais objetivamente expresso pela estrutura (que também define a segurança, afetando a relevância - logo, a importância - da via ao calcular uma rota). Num mundo ideal, as vias nacionais deveriam ser as mais importantes, tanto pela distância que percorrem quanto pelo responsável por elas (o governo, que está no topo da hierarquia administrativa). A manifestação mais comum foi justamente de que isso não se verifica na prática em diversos casos. Então, embora a sua visão seja a mesma minha inicial e a mesma dos alemães e a dos argentinos (e provavelmente de várias outras comunidades também), nesse ponto eu já desconfio se seria útil classificar assim. Algo que expressasse a estrutura me parece mais útil para decidir a melhor rota. O que podemos fazer é o seguinte: fazemos um outro fluxograma tomando o nível administrativo como critério principal, e depois cada um vota no que achou melhor, e continuamos a partir daí. Podemos repetir a votação ano que vem, como o Geraldo sugeriu. Eu só não sei se isso faria muita diferença. Eu postei no fórum uma enquete sobre diferenças entre motorway e trunk e ninguém respondeu. Se optarmos pelo novo, já teremos um problema porque já há uma pessoa fazendo a reclassificação no Rio Grande do Norte. Eu mesmo não comecei no Rio Grande do Sul por falta de tempo, mas se tivesse, a essas alturas já teria mudado tudo. 2013/5/17 Vítor Rodrigo Dias vitor.d...@gmail.com: Tendo a concordar com a categorização orientada pela classificação de rodovias. Por mim, eu pensaria na seguinte orientação para áreas rurais: - motorway: a mesma sugestão com a qual todos mais ou menos concordam - trunk: rodovia federal, asfaltada - primary: rodovia estadual, asfaltada - secondary: rodovia estadual de ligação local ou acesso (em MG, as LMG e AMG), asfaltada; rodovia/estrada municipal asfaltada - tertiary: rodovia ou estrada federal/estadual/municipal, não asfaltada Nas edições que tenho feito, tenho seguido essa orientação, só não tenho colocado trunk para as rodovias federais pelas quais passo. Vítor Rodrigo Dias Revisor de textos Tradutor port/ing/port e port/esp/port Telefone: (31) 9895-3975 - TIM Em 17 de maio de 2013 00:11, Fernando Trebien fernando.treb...@gmail.com escreveu: Olá Pedro, Não quero me repetir, mas a minha proposta para classificação das vias (http://wiki.openstreetmap.org/wiki/Pt-br:How_to_map_a#Categoriza.C3.A7.C3.A3o_de_vias_.28outra_sugest.C3.A3o.29) dá prioridade à classificação oficial do governo e só usa essas outras características (como número de faixas) na falta dessa informação. Afinal, não é difícil (pelo menos por aqui no sul) encontrar uma via residencial de 4 pistas e uma via primária (arterial) de 2 pistas. Já a presença de pavimentação é um indicador mais forte, afinal as vias menos importantes tendem a não ser asfaltadas. Mas o indicador mais forte de todos é a preferência. Num cruzamento, a via que tem uma placa Pare tem que, necessariamente, ser de um tipo inferior ao da via que não tem. Onde há mais tráfego, há semáforos ao invés de placas Pare. Nesse caso, é a temporização do semáforo que indicaria algo sobre a preferência, mas esse já é um fator mais difícil de medir e que, inclusive, pode mudar e passar despercebido. Geralmente só muda em regiões que estão se desenvolvendo, onde terciárias estão virando secundárias. Mas note que a preferência sozinha não estabelece a classificação em todos os casos e pode gerar alguns situações contraditórias (como deadlocks de prioridade). Isso é raro, e quando acontece, acho melhor usar outras características pra classificar. Em particular, em motorways e trunks eu penso que a velocidade máxima é o fator predominante na classificação, pois ela define várias características de projeto da via (como o tipo de acesso, a pavimentação, o número de pistas, etc.). Mais de 80km/h é sempre motorway (como nas freeways e autobahns). 80km/h em meio urbano é trunk, sem dúvida, por se encaixar na definição de via expressa que consta no próprio wiki (em inglês). Já em meio rural, 80km/h pode ser trunk, primária, secundária ou até terciária, o critério para decidir é a classificação oficial (se é rodovia nacional, estadual ou intermunicipal). Na falta de classificação oficial, a melhor forma de prover uma classificação informal é por comparação com as vias próximas. Como são vias pouco importantes, eu não discutiria muito sobre a classificação delas a menos que impactasse significativamente o planejamento de rotas
Re: [Talk-br] Matheus Eduardo está de volta
Acho que seria realmente excelente se existisse algo assim! Você já deu essa sugestão aos desenvolvedores do OSM? Vou ser ousado: existe a possibilidade de criarmos um mirror do OSM (só para o Brasil), e provavelmente existe a possibilidade de sincronizar as edições dos dois. Fazendo um mirror poderíamos implementar esse esquema nós mesmos. Requer programação, tempo, e custos para manter o servidor, mas não é impossível. Há uma outra questão também, já no contexto das discussões que andamos fazendo: seria muito importante que os moderadores seguissem padrões/filosofias parecidas e éticas. Para não virarmos uma comunidade fechada e autoritária, também é importante explicar as razões desses padrões - e a melhor ferramenta para isso é o wiki. Velho ditado: com grande poder, vem grande responsabilidade. Não que alguém vá morrer se for impedido de incluir no mapa a sua igreja ou a sua sex shop preferida... :P Mas certamente autoritarismos assim não devem acontecer. 2013/6/14 Gerald Weber gwebe...@gmail.com: Eu penso que o OSM poderia implementar períodos de quarentena para novos usuários. Por exemplo, um usuário novo não deveria ser capaz de deletar nada inicialmente até que ele tenha feito um certo número de edições ele mesmo. Alternativamente, um usuário novo poderia ter todas as suas edições iniciais sendo validadas por usuários mais experientes. Acho que isto daria mais segurança a usuários novos pois eles não ficariam com medo de fazer besteira. Aliás, eu acho que muitos usuários novos não contribui por medo estarem fazendo coisas erradas, como tudo é muito técnico eles acabam ficando inibidos. Seria um jeito de resolver 2 problemas de uma vez só. Eu acho que do jeito que está fragiliza o sistema demasiadamente. abraço Gerald 2013/6/14 Fernando Trebien fernando.treb...@gmail.com Ah, só acrescentando. Quando um projeto colaborativo cresce, não há como fugir de aplicar algum tipo de moderação ativa. Já é assim no OpenStreetMap em vários lugares da Europa, e na Wikipédia também é assim em diversos artigos (mas não todos). A única solução para escapar da moderação é não fazer/usar mapas colaborativos. Mas veja que tanto Google quanto Navteq já têm alguns recursos colaborativos (o que quer dizer que também estão sujeitos a vandalismo), então já há pouca opção disponível com garantia de qualidade. A própria Apple optou por usar dados do OpenStreetMap através do Maps em algumas regiões. 2013/6/14 Fernando Trebien fernando.treb...@gmail.com: Olá José Carlos, Talvez lhe surpreenda quão fácil é monitorar a sua região. Eu uso um feed RSS do WhoDidIt por ser mais fácil. Se você tiver interesse, posso fornecer os detalhes. Um dos problemas desse método é que cada feed cobre uma área pequena (só um pouco mais do que Porto Alegre) mas não é impossível usar mais de um feed. Eu concordo que um sistema de moderadores (tal como o da Wikipédia e, de uma certa forma, também o do TrackSource) seria muito bem-vindo. On Jun 14, 2013 3:12 PM, Jose Carlos Medeiros jcnascime...@gmail.com wrote: O mapeamento do jeito que esta, fica um pouco complicado, e sem muita segurança, já que, se alguem quiser corromper alguma coisa, basta criar um email e sair alterando as coisas. Claro, que podemos reverter, mas os itens que tem alguem olhando sempre. Eu por exemplo, mapeei o meu bairro, mas não fico monitorando isso, se alguém alterar pode ser que eu nem veja, e o mapa fique errado. Deveria ser parecido com o Waze, onde existe o responsável pela área, tipo, você se cadastra pra alterar uma região, se la não tiver responsável, então você vira um. E caso desse algum problema de o dono da área não estar disponível ou outros problemas, acionar uma pessoa ou grupo, responsável pela cidade ou região maior. Ficamos falando sempre, do ganho em ter um mapa colaborativo, que podemos utilizar pra projetos e tal, mas do jeito que ele esta não da pra confiar. Imagina se você faz um sistema de logistica ou um programa de GPS, e alguem vai e altera o mapa, a pessoa pode até corrigir, mas nem todo mundo que ficar fazendo isso. Será que alguem ja propôs alguma coisa deste tipo para a OSF? []'s José Carlos Em 15 de abril de 2013 13:15, Vitor George vitor.geo...@gmail.com escreveu: Fernando, A primeira coisa a fazer se você notar que um contribuidor está fazendo más edições, é entrar em contato, cordialmente. Se o usuário responder e entrar em um acordo contigo, o caso está resolvido. Caso alguma polêmica persista, o próximo passo seria postar aqui na lista, para que a comunidade possa debater o caso e tentar chegar a uma solução. A maioria dos casos se resolve assim. Quando isso não funciona ou quando o usuário se recusa a discutir as suas edições, recorre-se à OpenStreetMap Foundation, que pode aplicar sanções, se necessário. Neste caso do Matheus Eduardo, ele não
Re: [Talk-br] Matheus Eduardo está de volta
Isso é meio parecido com a estrutura dos desenvolvedores de mapas do TrackSource. Eles têm dois níveis: os que são responsáveis por municipios, e os que são responsáveis por estados. Os dos estados são responsáveis por tudo aquilo que não tenha desenvolvedor municipal no estado. Nada impede que a mesma pessoa seja desenvolvedora de vários municípios (do mesmo estado ou não) ou de vários estados, ou de um estado e vários municipios dele. No caso do OSM isso poderia ser menos rígido (bastaria definir regiões de tamanhos diferentes, com ou sem buracos). Assim, uma cidade grande como Sao Paulo poderia ser subdividida, e de várias formas, e inclusive a subdivisão poderia evoluir. Mas assim, José Carlos, 99,% dos contribuintes do OSM têm boas intenções. Quando algo dá errado, 99,999% das vezes é apenas um engano. Como a maior parte das edições tem sido em área urbana, 99% dos casos podem ser detectados desde que 1 pessoa por cidade se prontifique a usar algo como o WhoDidIt periódicamente (tipo, 1x por semana). A propósito, você tem feito isso? Pelo seu nível de preocupação, acho que seria muito bom fazer. Você se sentiria mais seguro e acho que veria que a velocidade da introdução de erros é muito menor do que a do conserto. Essa é a minha experiência aqui em Porto Alegre. Até hoje só vi 1 erro e talvez 3 leves enganos (mas não erros), talvez mais uns 2 que seriam discutíveis, e faz 8 meses que mapeio. Em todos os casos eu abordei o usuário educadamente e ele não repetiu o engano e seguiu mapeando. (E eu confesso que cometi alguns erros no início e depois consertei, acho que a comunidade ainda precisa se esforçar mais para esclarecer certos assuntos para os iniciantes.) De qualquer forma, apoio a sua proposta de moderação, só com menos urgência. On Jun 14, 2013 5:47 PM, Jose Carlos Medeiros jcnascime...@gmail.com wrote: Eu acho este mapa muito sensível, para utilizar como GPS em massa ou algo mais sério como base para um produto comercial, um Waze da vida. Basta um mal intencionado cortar um nó, de estrada por exemplo, e a rota que uma pessoa faria poderia mudar toda. Da até pra desfazer algumas coisas, mas nem todo mundo tem familiaridade com o processo ou como usar o JOSM. O legal seria um sistema onde o pessoal faria as alterações num servidor de homologação, e para os commits ir para produção, utilizaríamos um workflow de aprovação, onde teríamos de um a dois aprovadores por região, parece complicado, mas basicamente o cara recebe um email, ve se ta certo e aprova. Agora de onde vem os aprovadores? Pode ser hierarquia, regiões sem aprovadores vai pra um nível acima, responsáveis por múltiplas regiões. E para o cara virar aprovador, poderia ser criado um sistema de karma, onde quanto mais altera e é aprovado, depois de um número, ele pode ser aprovador por uma região. Claro, precisaria de um sistema para isso, mas não vejo como algo muito complicado, da pra utilizar muita coisa existente. []'s José Carlos Em 14 de junho de 2013 16:34, Gerald Weber gwebe...@gmail.com escreveu: Eu penso que o OSM poderia implementar períodos de quarentena para novos usuários. Por exemplo, um usuário novo não deveria ser capaz de deletar nada inicialmente até que ele tenha feito um certo número de edições ele mesmo. Alternativamente, um usuário novo poderia ter todas as suas edições iniciais sendo validadas por usuários mais experientes. Acho que isto daria mais segurança a usuários novos pois eles não ficariam com medo de fazer besteira. Aliás, eu acho que muitos usuários novos não contribui por medo estarem fazendo coisas erradas, como tudo é muito técnico eles acabam ficando inibidos. Seria um jeito de resolver 2 problemas de uma vez só. Eu acho que do jeito que está fragiliza o sistema demasiadamente. abraço Gerald 2013/6/14 Fernando Trebien fernando.treb...@gmail.com Ah, só acrescentando. Quando um projeto colaborativo cresce, não há como fugir de aplicar algum tipo de moderação ativa. Já é assim no OpenStreetMap em vários lugares da Europa, e na Wikipédia também é assim em diversos artigos (mas não todos). A única solução para escapar da moderação é não fazer/usar mapas colaborativos. Mas veja que tanto Google quanto Navteq já têm alguns recursos colaborativos (o que quer dizer que também estão sujeitos a vandalismo), então já há pouca opção disponível com garantia de qualidade. A própria Apple optou por usar dados do OpenStreetMap através do Maps em algumas regiões. 2013/6/14 Fernando Trebien fernando.treb...@gmail.com: Olá José Carlos, Talvez lhe surpreenda quão fácil é monitorar a sua região. Eu uso um feed RSS do WhoDidIt por ser mais fácil. Se você tiver interesse, posso fornecer os detalhes. Um dos problemas desse método é que cada feed cobre uma área pequena (só um pouco mais do que Porto Alegre) mas não é impossível usar mais de um feed. Eu concordo que um sistema de moderadores (tal como o da Wikipédia e, de uma
Re: [Talk-br] Aeroporto de Ribeirão
Bem, a fonte da informação não está indicada (ou seja, não é oficial) e as demais tags me parecem bem pouco úteis, então acho que não tem nada a ser aproveitado. A melhor forma de excluir é deletar primeiro a relação e depois a área (se você fizer o contrário vai acabar com uma relação vazia que você vai ter que catar no menu de relações do JOSM, ou no validador). Eu acho improvável mas é possível que o contorno desse polígono seja útil para mapear os contornos dos bairros, então essa seria a minha última sugestão a conferir antes de apertar a tecla Delete. :D Ah não, mais uma. Eu olhei o histórico do polígono: http://www.openstreetmap.org/browse/changeset/6624206 E ele foi feito por esse cara: http://www.openstreetmap.org/user/Johan%20Dahlin Que parece estar fazendo edições ainda. (Note que ele é sueco.) Uma coisa que você pode fazer é perguntar para ele (cordialmente) se ele tirou a informação de algum lugar. Ao excluir, também coloque no changeset um comentário dizendo a razão e indicando que foi recomendação nossa, pra evitar brigas. 2013/6/14 Roger C. Soares rogersoa...@gmail.com: He he, fui dar uma olhada pra corrigir a área do aeroporto e já está tudo certo, inclusive já tem melhorias no mapeamento, que beleza! :D Qto à área landuse=residential delimitando a área urbana em São Carlos, ela é uma regra outer da relação: border_type=city name=São Carlos urban area border name:pt=Limite da Área Urbana de São Carlos type=boundary Nesse caso não sei o que fazer... Atenciosamente, Roger. -- Fernando Trebien escreveu: Bem, eu jogava SimCity. Acho que algumas pessoas pensam que landuse=residential é como quando você marca um pedaço da cidade no jogo dizendo aqui eu quero que construam casas. :P O jogo também permite marcar áreas comerciais (landuse=commercial) e industriais (landuse=industrial) (!) haha. Se esse usuário tem cometido esses erros com frequência, pode-se abordá-lo educadamente pelo sistema de mensagens do OSM (basta clicar em send message na página do perfil do usuário) e sugerir algumas leituras ou dar meia dúzia de dicas. Fazer ele se sentir capaz e útil apesar dos enganos é essencial para manter ele interessado e continuar mapeando. :D Você também pode apontar exemplos e dizer que se ele quiser saber o jeito certo de mapear, basta ele clicar em Edit e ver quais tags cada elemento recebeu. As melhores cidades mapeadas no OSM estão indicadas aqui: http://bestofosm.org Entre elas, no Brasil, temos o Rio de Janeiro. O Nelson tem razão. A área coberta pelas tags landuse a princípio pode ser qualquer uma, mas o uso deve ser com bom senso. A delimitação da área urbana é feita de outras formas (e até difícil, como você define a borda exata que separa o meio urbano do rural? geralmente é uma transição gradual), e seria no mínimo impreciso (e bastate óbvio, logo meio inútil) dizer que todas as partes da cidade são uma única área residencial. Acho absolutamente seguro excluir essa grande área que você apontou em São Carlos e Leme. Antes de fazer isso, eu só daria uma olhada se ela tem alguma outra tag relevante além de landuse=residential (às vezes é informação interessante que pode ser colocada em outro lugar, como na definição da própria cidade - no nó place=city ou na relação que define a fronteira). Eu tenho usado landuse=residential para condomínios residenciais e (mais recentemente) para as áreas de comunidades carentes (como vilas e favelas). O segundo caso se aproxima um pouco da definição de um bairro (mas não é bem bairro porque não é uma fronteira administrativa, poderia ser talvez uma fronteira civil mas isso nunca foi bem descrito no wiki do OSM). 2013/6/13 Nelson A. de Oliveira nao...@gmail.com 2013/6/13 Roger C. Soares rogersoa...@gmail.com: Eu estava colocando landuse apenas nos condomínios residenciais, foi o caso que eu mais vi por enquanto. Mas em São Carlos e Leme tem uma grande área, quase do tamanho da cidade, com landuse residential. Tem algum padrão preferido aqui no Brasil pra mapear landuse? Isso eu já não concordo (e acho errado) em utilizar landuse=residential para a área inteira da cidade. Acredito que as pessoas imaginam que utilizar landuse=residential seja a forma correta de delimitar a área urbana da cidade (e por isso o fazem). ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando
Re: [Talk-br] Renomear várias ruas de uma vez
Não que eu conheça, mas se você quiser, eu posso adaptar um script em Python pra isso (o mesmo script que estou usando para adaptar a estrutura de dados das vilas). Você simplesmente teria que instalar Python (http://www.python.org/download/) uma vez, e depois sempre que precisasse renomear, abriria o prompt de comando e executaria algo como: osmrename.py arquivo.osm nome da tag texto original texto novo Ex: osmrename.py brasilia.osm name Av Avenida osmrename.py brasilia 2.osm alt_name 23 Vinte e Três (Talvez já exista algo assim por aí.) 2013/6/14 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Não é possível no JOSM ou outro editor do OpenStreetMap procurar por ocorrências de uma palavra em várias ruas e substituir por outra palavra? ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Matheus Eduardo está de volta
ter rua com nome e classificação da via que me basta. Então não gosto muito de ficar monitorando se foi alterado ou não. Pode ser que apareçam mais pessoas com o mesmo objetivo, que mapeiem seus bairros e depois nem entrem mais no OSM, e depois de um bom tempo, vejam que o que fizeram foi perdido ou alterado. Ta certo, o cara poderia monitorar, mas vai que ele não quer, vai que ele tem outras coisas pra fazer da vida. Quanto mais coisas forem mapeadas, maior a chance de ter coisas alteradas indevidamente, então seria legar ter uma estrutura mais organizada. O pessoal do OSM tinha alguma coisa em mente? Ou nunca nem falaram nisso? Tem muitos registros na lista, nem sei como pesquisar para ver se o assunto ja foi abordado. []'s José Carlos Em 14 de junho de 2013 18:24, Fernando Trebien fernando.treb...@gmail.com escreveu: Além disso, não tem nada em português a respeito, mas há uma categoria inteira do wiki só sobre esse assunto: http://wiki.openstreetmap.org/wiki/Category:Counter-vandalism E também uma lista de e-mail dedicada a isso (também em inglês): http://wiki.openstreetmap.org/wiki/Moderation_mailing_list Eu posso postar a sua proposta lá. Mas se a lista já está no ar desde 2009, certamente já devem ter trabalhado com uma proposta parecida, e ainda não chegaram a um consenso OU não tiveram tempo/recursos para implementar (talvez porque a implementação seja complexa). 2013/6/14 Fernando Trebien fernando.treb...@gmail.com: Isso é meio parecido com a estrutura dos desenvolvedores de mapas do TrackSource. Eles têm dois níveis: os que são responsáveis por municipios, e os que são responsáveis por estados. Os dos estados são responsáveis por tudo aquilo que não tenha desenvolvedor municipal no estado. Nada impede que a mesma pessoa seja desenvolvedora de vários municípios (do mesmo estado ou não) ou de vários estados, ou de um estado e vários municipios dele. No caso do OSM isso poderia ser menos rígido (bastaria definir regiões de tamanhos diferentes, com ou sem buracos). Assim, uma cidade grande como Sao Paulo poderia ser subdividida, e de várias formas, e inclusive a subdivisão poderia evoluir. Mas assim, José Carlos, 99,% dos contribuintes do OSM têm boas intenções. Quando algo dá errado, 99,999% das vezes é apenas um engano. Como a maior parte das edições tem sido em área urbana, 99% dos casos podem ser detectados desde que 1 pessoa por cidade se prontifique a usar algo como o WhoDidIt periódicamente (tipo, 1x por semana). A propósito, você tem feito isso? Pelo seu nível de preocupação, acho que seria muito bom fazer. Você se sentiria mais seguro e acho que veria que a velocidade da introdução de erros é muito menor do que a do conserto. Essa é a minha experiência aqui em Porto Alegre. Até hoje só vi 1 erro e talvez 3 leves enganos (mas não erros), talvez mais uns 2 que seriam discutíveis, e faz 8 meses que mapeio. Em todos os casos eu abordei o usuário educadamente e ele não repetiu o engano e seguiu mapeando. (E eu confesso que cometi alguns erros no início e depois consertei, acho que a comunidade ainda precisa se esforçar mais para esclarecer certos assuntos para os iniciantes.) De qualquer forma, apoio a sua proposta de moderação, só com menos urgência. On Jun 14, 2013 5:47 PM, Jose Carlos Medeiros jcnascime...@gmail.com wrote: Eu acho este mapa muito sensível, para utilizar como GPS em massa ou algo mais sério como base para um produto comercial, um Waze da vida. Basta um mal intencionado cortar um nó, de estrada por exemplo, e a rota que uma pessoa faria poderia mudar toda. Da até pra desfazer algumas coisas, mas nem todo mundo tem familiaridade com o processo ou como usar o JOSM. O legal seria um sistema onde o pessoal faria as alterações num servidor de homologação, e para os commits ir para produção, utilizaríamos um workflow de aprovação, onde teríamos de um a dois aprovadores por região, parece complicado, mas basicamente o cara recebe um email, ve se ta certo e aprova. Agora de onde vem os aprovadores? Pode ser hierarquia, regiões sem aprovadores vai pra um nível acima, responsáveis por múltiplas regiões. E para o cara virar aprovador, poderia ser criado um sistema de karma, onde quanto mais altera e é aprovado, depois de um número, ele pode ser aprovador por uma região. Claro, precisaria de um sistema para isso, mas não vejo como algo muito complicado, da pra utilizar muita coisa existente. []'s José Carlos Em 14 de junho de 2013 16:34, Gerald Weber gwebe...@gmail.com escreveu: Eu penso que o OSM poderia implementar períodos de quarentena para novos usuários. Por exemplo, um usuário novo não deveria ser capaz de deletar nada inicialmente até que ele tenha feito um certo número de edições ele mesmo. Alternativamente, um usuário novo poderia ter todas as suas edições
Re: [Talk-br] Renomear várias ruas de uma vez
Se você quiser eu posso até acrescentar suporte a expressões regulares - quem mexe com scripts e linha de comando ia adorar. :P http://pt.wikipedia.org/wiki/Express%C3%A3o_regular#Sintaxe 2013/6/14 Fernando Trebien fernando.treb...@gmail.com: Hm é isso que eu pretendia que o script fizesse. Por exemplo, ele renomearia 123 Av Paulista para 123 Avenida Paulista. É o que você quer fazer, não? 2013/6/14 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: é, mas não seria renomear todo o campo, mas só uma parte do campo em vários nomes diferentes. Em 14 de junho de 2013 19:52, Fernando Trebien fernando.treb...@gmail.com escreveu: Não que eu conheça, mas se você quiser, eu posso adaptar um script em Python pra isso (o mesmo script que estou usando para adaptar a estrutura de dados das vilas). Você simplesmente teria que instalar Python (http://www.python.org/download/) uma vez, e depois sempre que precisasse renomear, abriria o prompt de comando e executaria algo como: osmrename.py arquivo.osm nome da tag texto original texto novo Ex: osmrename.py brasilia.osm name Av Avenida osmrename.py brasilia 2.osm alt_name 23 Vinte e Três (Talvez já exista algo assim por aí.) 2013/6/14 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Não é possível no JOSM ou outro editor do OpenStreetMap procurar por ocorrências de uma palavra em várias ruas e substituir por outra palavra? ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Abrir changeset
Eu descobri como fazer isso ainda hoje. Tem um truque. Primeiro, baixe o plugin Reverter. Depois, rode ele passando o número do changeset. Não se preocupe, você não vai reverter nada. O plugin vai baixar o changeset e (daí vem o truque) logo depois ele vai inverter todas as ações, marcando para exclusão o que foi criado e criando o que foi excluído. Nesse momento você faz um Undo. Isso desfaz a última ação, que invertia as ações. Ta-da: agora sim você tem o conteúdo exato do changeset. Se quiser, você pode salvar a camada com o nome arquivo.osm. Fonte: http://wiki.openstreetmap.org/wiki/User:Cobra/TipsAndTricks#Load_all_objects_of_a_changeset 2013/6/14 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Olá pessoal, eu não consigo de jeito nenhuma abrir o changeset a seguir como um arquivo.osm no JOSM... Alguém sabe se é possível, se sim, me ensinar ou passar o arquivo .osm já pronto. http://www.openstreetmap.org/api/0.6/changeset/16556781/download ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Aeroporto de Ribeirão
Bem, eu jogava SimCity. Acho que algumas pessoas pensam que landuse=residential é como quando você marca um pedaço da cidade no jogo dizendo aqui eu quero que construam casas. :P O jogo também permite marcar áreas comerciais (landuse=commercial) e industriais (landuse=industrial) (!) haha. Se esse usuário tem cometido esses erros com frequência, pode-se abordá-lo educadamente pelo sistema de mensagens do OSM (basta clicar em send message na página do perfil do usuário) e sugerir algumas leituras ou dar meia dúzia de dicas. Fazer ele se sentir capaz e útil apesar dos enganos é essencial para manter ele interessado e continuar mapeando. :D Você também pode apontar exemplos e dizer que se ele quiser saber o jeito certo de mapear, basta ele clicar em Edit e ver quais tags cada elemento recebeu. As melhores cidades mapeadas no OSM estão indicadas aqui: http://bestofosm.org Entre elas, no Brasil, temos o Rio de Janeiro. O Nelson tem razão. A área coberta pelas tags landuse a princípio pode ser qualquer uma, mas o uso deve ser com bom senso. A delimitação da área urbana é feita de outras formas (e até difícil, como você define a borda exata que separa o meio urbano do rural? geralmente é uma transição gradual), e seria no mínimo impreciso (e bastate óbvio, logo meio inútil) dizer que todas as partes da cidade são uma única área residencial. Acho absolutamente seguro excluir essa grande área que você apontou em São Carlos e Leme. Antes de fazer isso, eu só daria uma olhada se ela tem alguma outra tag relevante além de landuse=residential (às vezes é informação interessante que pode ser colocada em outro lugar, como na definição da própria cidade - no nó place=city ou na relação que define a fronteira). Eu tenho usado landuse=residential para condomínios residenciais e (mais recentemente) para as áreas de comunidades carentes (como vilas e favelas). O segundo caso se aproxima um pouco da definição de um bairro (mas não é bem bairro porque não é uma fronteira administrativa, poderia ser talvez uma fronteira civil mas isso nunca foi bem descrito no wiki do OSM). 2013/6/13 Nelson A. de Oliveira nao...@gmail.com 2013/6/13 Roger C. Soares rogersoa...@gmail.com: Eu estava colocando landuse apenas nos condomínios residenciais, foi o caso que eu mais vi por enquanto. Mas em São Carlos e Leme tem uma grande área, quase do tamanho da cidade, com landuse residential. Tem algum padrão preferido aqui no Brasil pra mapear landuse? Isso eu já não concordo (e acho errado) em utilizar landuse=residential para a área inteira da cidade. Acredito que as pessoas imaginam que utilizar landuse=residential seja a forma correta de delimitar a área urbana da cidade (e por isso o fazem). ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Aeroporto de Ribeirão
Hm, interessante. Depois de você dizer isso, fui conferir como é feito em Berlim, e é parecido (também com landuse=residential). Mas ao invés de polígonos (áreas), eles usam multipolígonos e agrupam as ruas que limitam as quadras com o papel outer. Desculpem a ignorância, é a primeira vez que vi isso. Como são multipolígonos, fica meio escondido no Potlatch, e no JOSM é visualmente confuso porque Berlim é muito densa. Converter uma representação em outra ia dar um trabalhão, mas sempre há o bom e o ótimo né. Eu não sei nem se eu recomendaria usar multipolígonos para isso porque me parece que eles são confusos para os iniciantes e para o contribuinte casual. Então, acho que mapear as quadras como áreas simples está ok. 2013/6/13 Arlindo Pereira openstreet...@arlindopereira.com Aqui no Rio, o IPP fornece um arquivo com o contorno bastante detalhado de quadras. Importei alguns trechos pequenos nos bairros de Botafogo e Copacabana como landuse=residential para testar como fica. []s Em 13/06/2013 12:52, Fernando Trebien fernando.treb...@gmail.com escreveu: Antes que me corrijam: num shopping center, landuse=retail vai para a área do terreno (se for necessário mapeá-lo assim, depende do tamanho e da estrutura do shopping né). O prédio do shopping (no interior dessa área) recebe building=yes e shop=mall. 2013/6/13 Fernando Trebien fernando.treb...@gmail.com Hm não respondi tudo do seu e-mail original. Também acho que ele não deveria mapear os quarteirões assim. Sei que na Coréia do Sul cada quarteirão tem um nome, daí faria algum sentido (embora deva haver um esquema de tags melhor - talvez um nó por quarteirão, ou uma relação de fronteira administrativa com um nível bem elevado, algo tipo 12 ou mais). Se ele só vai fazer isso para o mapa ficar parecido com o do SimCity, melhor não fazer nada. Bem, quando na região a atividade comercial geralmente é no andar térreo e residencial nos demais andares, então eu consideraria predominantemente residencial. Eu uso landuse=commercial para complexos puramente comerciais (ou às vezes por simplicidade, para evitar usar demais a relação site): digamos que exista um terreno, com um único endereço, e alguns prédios comerciais dentro dele (podem ser lojas ou escritórios, por exemplo) sem endereço de correspondência distinto (exceto pelo complemento, como nomes ou números internos), e todo o complexo tem um nome. Nesse caso, eu usaria landuse=commercial no terreno, que também teria tags de endereço e o nome do complexo. O complexo pode ser qualquer coisa com mais de 1 elemento dentro, tipo 2 ou mais prédios ou 1 prédio e 1 estacionamento logo em frente no mesmo terreno. Prefira o bom senso: se só tem 1 prédio, pense se o prédio sozinho já não bastaria. (Isso varia conforme o estilo pessoal, tem gente que enche de detalhes, tem gente que simplifica, tem gente que só coloca 1 nó e pronto. :P) Muito parecido com isso é o mapeamento de shopping centers, onde se usaria landuse=retail. O render fica idêntico no Mapnik. Note que isso às vezes pode variar com o contexto, como no caso de uma cidade fortemente planejada como Brasília. Lá essas tags poderiam ter outros usos mais interessantes. 2013/6/13 Fernando Trebien fernando.treb...@gmail.com Além do Rio, por um tempo apareceu Belo Horizonte como cidade interessante. Recentemente eles tiraram as cidades consideradas interessantes desse mapa, não sei a razão. Mas então, é outra alternativa a considerar no próprio Brasil. Não vou recomendar Porto Alegre porque não revisei o aeroporto daqui ainda. :P Sei que está bem apresentável, agora se segue bem direitinho as recomendações da comunidade, não tenho certeza. 2013/6/13 Fernando Trebien fernando.treb...@gmail.com Bem, eu jogava SimCity. Acho que algumas pessoas pensam que landuse=residential é como quando você marca um pedaço da cidade no jogo dizendo aqui eu quero que construam casas. :P O jogo também permite marcar áreas comerciais (landuse=commercial) e industriais (landuse=industrial) (!) haha. Se esse usuário tem cometido esses erros com frequência, pode-se abordá-lo educadamente pelo sistema de mensagens do OSM (basta clicar em send message na página do perfil do usuário) e sugerir algumas leituras ou dar meia dúzia de dicas. Fazer ele se sentir capaz e útil apesar dos enganos é essencial para manter ele interessado e continuar mapeando. :D Você também pode apontar exemplos e dizer que se ele quiser saber o jeito certo de mapear, basta ele clicar em Edit e ver quais tags cada elemento recebeu. As melhores cidades mapeadas no OSM estão indicadas aqui: http://bestofosm.org Entre elas, no Brasil, temos o Rio de Janeiro. O Nelson tem razão. A área coberta pelas tags landuse a princípio pode ser qualquer uma, mas o uso deve ser com bom senso. A delimitação da área urbana é feita de outras formas (e até difícil, como você define a borda exata que separa o meio urbano do rural? geralmente é uma
Re: [Talk-br] Frotas de ônibus em Brasília mapeadas no OpenStreetMap
Parece que está offline. 2013/6/13 Erick de Oliveira Leal erickdeoliveiral...@gmail.com Hoje o governo do Distrito Federal lançou um novo site que mostra linhas de ônibus em Brasília, utilizando dados do projeto OpenStreetMap, deêm olhada os mais antigos para verem se está tudo nos conformes no que se diz a citação senão, por favor, tomem as medidas que já foram tomada como no caso do G1. http://www.sistemas.dftrans.df.gov.br/horarios/src/mapas/index ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Frotas de ônibus em Brasília mapeadas no OpenStreetMap
Ah, agora está online. :D 2013/6/13 Erick de Oliveira Leal erickdeoliveiral...@gmail.com Só se eles tiverem usado alguma restrição por localização da pessoa que está consultando. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
[OSM-legal-talk] Data import and license compatibility
Hello, I'm trying to help a nice user who has interesting data ready to import, but there's a potential problem: he already published the same data elsewhere under a Creative Commons 2.5 BY-NC-ND license. Unfortunately I don't know enough about licensing. Since he generated the data himself, would it be legal to publish the same data under OSM's ODbL? There was one answer in the forum (http://forum.openstreetmap.org/viewtopic.php?pid=340685) saying: If he owns the rights to the data, he is able to publish the data under further licences. CC and CT/ODbL are non-exclusive licences. I just want to be extra sure that nothing has been overlooked. We verified that the publisher did not impose any contract requiring transfer of property rights, so I guess it is fine as long as we don't take the published data and instead we take the data received directly from the user. Even though the result would be exactly the same, any attribution to the publisher would clearly be a mistake under any perspective. Is this correct? -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
[Talk-br] TrackSource e OSM
Pessoal, Para quem não acompanha o fórum, peço para darem uma conferida nessa discussão e dar as suas opiniões sobre o assunto: http://forum.openstreetmap.org/viewtopic.php?pid=340688#p340688 Podem opinar lá ou aqui, onde preferirem. -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Aeroporto de Ribeirão
Você pode usar o plugin Reverter do JOSM pra isso. Mas se quiser eu posso fazer. On Jun 12, 2013 9:39 PM, Roger C. Soares rogersoa...@gmail.com wrote: Oi, A alteração http://www.openstreetmap.org/**browse/changeset/16494194http://www.openstreetmap.org/browse/changeset/16494194removeu a pista, o nome e alguns pontos a mais que estavam dentro do aeroporto de Ribeirão. Eu enviei um email na terça e por enquanto não obtive resposta. Alguém consegue voltar o conteúdo antigo? Atenciosamente, Roger. __**_ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-brhttp://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Aeroporto de Ribeirão
Geralmente o que acontece é um conflito. É o mesmo que acontece quando você baixa um pedaço do mapa, e enquanto você edita, alguém edita um dos mesmos objetos e já submete a alteração antes de você. Nesse caso, a versão do objeto na base do OSM é mais recente que aquela da qual você partiu na sua edição. Como você não soube da alteração até esse momento, o JOSM te avisa e te oferece uma forma de combinar as suas alterações com as que a outra pessoa fez: aparece uma janela onde você decide quais tags o objeto deve ter (você pode combinar as suas com as que foram submetidas), quais pontos devem estar na definição das linhas (os seus, os do outro, ou uma combinação dos dois), ou caso o objeto tenha sido excluído, se o que deve constar na base do OSM é o objeto que você ainda tem ou se ele deve ser deletado como o outro fez. Nesse caso, se outros changesets foram submetidos após o que você está revertendo, você estará com versões antigas dos objetos e haverão vários conflitos pendentes. A probabilidade de um conflito então é maior ao reverter changesets mais antigos. Nos recentes costuma ser bem tranquilo. Interessante, foi só uma exclusão mesmo: http://osmhv.openstreetmap.de/changeset.jsp?id=16494194 O que será que o usuário tinha em mente ao fazer isso? É bom ficar de olho, pode ser vandalismo. Você sabe como monitorar o mapa? (Eu uso uma combinação do WhoDidIt - que gera um feed RSS dos changesets numa área - com o OSM History Viewer - pra analisá-los rapidamente.) De qualquer forma, já foi revertido: http://www.openstreetmap.org/browse/changeset/16532848 2013/6/13 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Eu já fiz reversão algumas vezes e funcionou rs. Em 13 de junho de 2013 00:10, Roger C. Soares rogersoa...@gmail.com escreveu: Oi Fernando, Eu dei uma lida um tempo atrás sobre como reverter uma alteração e pelo o que eu entendi, nem sempre a reversão funciona do jeito que se espera, e o texto falava que era bom entender o que aconteceu antes de comitar. No final, eu ainda não me sinto muito confortável para fazer isso, qualquer hora eu preciso brincar um pouco com esse plugin pra entender melhor... Se vc puder fazer por enquanto, eu agradeço. Atenciosamente, Roger. -- Fernando Trebien escreveu: Você pode usar o plugin Reverter do JOSM pra isso. Mas se quiser eu posso fazer. On Jun 12, 2013 9:39 PM, Roger C. Soares rogersoa...@gmail.com wrote: Oi, A alteração http://www.openstreetmap.org/browse/changeset/16494194 removeu a pista, o nome e alguns pontos a mais que estavam dentro do aeroporto de Ribeirão. Eu enviei um email na terça e por enquanto não obtive resposta. Alguém consegue voltar o conteúdo antigo? Atenciosamente, Roger. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Fwd: O Globo - licença
Oh, deu certo! =D -- Forwarded message -- From: Gabriela Allegro - Unidade Digital - Infoglobo gabriela.alle...@oglobo.com.br Date: 2013/6/11 Subject: O Globo - licença To: fernando.treb...@gmail.com Cc: Ademar Victorino - Unidade Digital - Infoglobo ademar.victor...@oglobo.com.br Oi, Fernando Você está coberto de razão. Está sendo providenciado e não se repetirá. O crédito será inserido conforme o padrão, no canto inferior do mapa. http://leafletjs.com. Abs, Gabriela -- Gabriela Allegro tel: (21) 2534.5071 - - - - - - - - - - - - - - - - - - - - AVISO IMPORTANTE / IMPORTANT NOTICE - - - - - - - - - - - - - - - - - - - - - - Esta mensagem pode conter informações confidenciais e somente o indivíduo ou entidade a quem foi destinada pode utilizá-la. A transmissão incorreta da mensagem não acarreta a perda de sua confidencialidade. Caso esta mensagem tenha sido recebida por engano, solicitamos que o fato seja comunicado ao remetente e que a mensagem seja eliminada de seu sistema imediatamente. É vedado a qualquer pessoa que não seja o destinatário usar, revelar, distribuir ou copiar qualquer parte desta mensagem. Ambiente de comunicação sujeito a monitoramento. This message may include confidential information and only the intended addressee have the right to use it as is, or any part of it. A wrong transmission does not break its confidentiality. If you've received it because of a mistake or erroneous transmission, please notify the sender and delete it from your system immediately. This communication environment is controlled and monitored. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Fwd: O Globo - licença
Bem, eles usaram o teu link para a página de copyright do OSM, então certamente leram a tua mensagem. Talvez eles pensem que basta responder para uma pessoa que esta repassaria a informação para a comunidade. Ou talvez ainda estejam pensando em como te responder. 2013/6/11 Arlindo Pereira openstreet...@arlindopereira.com: Legal :-) Engraçado que eu mandei uma mensagem num tom semelhante via formulário de contato e facebook e não tive resposta. :-P []s Em 11/06/2013 11:05, Fernando Trebien fernando.treb...@gmail.com escreveu: Oh, deu certo! =D -- Forwarded message -- From: Gabriela Allegro - Unidade Digital - Infoglobo gabriela.alle...@oglobo.com.br Date: 2013/6/11 Subject: O Globo - licença To: fernando.treb...@gmail.com Cc: Ademar Victorino - Unidade Digital - Infoglobo ademar.victor...@oglobo.com.br Oi, Fernando Você está coberto de razão. Está sendo providenciado e não se repetirá. O crédito será inserido conforme o padrão, no canto inferior do mapa. http://leafletjs.com. Abs, Gabriela -- Gabriela Allegro tel: (21) 2534.5071 - - - - - - - - - - - - - - - - - - - - AVISO IMPORTANTE / IMPORTANT NOTICE - - - - - - - - - - - - - - - - - - - - - - Esta mensagem pode conter informações confidenciais e somente o indivíduo ou entidade a quem foi destinada pode utilizá-la. A transmissão incorreta da mensagem não acarreta a perda de sua confidencialidade. Caso esta mensagem tenha sido recebida por engano, solicitamos que o fato seja comunicado ao remetente e que a mensagem seja eliminada de seu sistema imediatamente. É vedado a qualquer pessoa que não seja o destinatário usar, revelar, distribuir ou copiar qualquer parte desta mensagem. Ambiente de comunicação sujeito a monitoramento. This message may include confidential information and only the intended addressee have the right to use it as is, or any part of it. A wrong transmission does not break its confidentiality. If you've received it because of a mistake or erroneous transmission, please notify the sender and delete it from your system immediately. This communication environment is controlled and monitored. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Formatar estrada de terra
Olá Blademir, Eu espero que o fluxograma de classificação que elaboramos recentemente ajude você a se confundir menos. Eu também me confundia bastante, por isso incentivei o debate. Você pode acessá-lo aqui: http://wiki.openstreetmap.org/wiki/Pt-br:How_to_map_a Na verdade, há opiniões um tanto diferentes sobre esse assunto. Chegamos ao consenso de seguir a classificação do BIT que distingue entre dois tipos de estrada de terra: as do tipo Implantadas seriam mapeadas como terciárias e as do tipo Leito Natural seriam mapeadas como unclassified. Se a estrada não tiver classificação no BIT, sugiro seguir o fluxograma que elaboramos há pouco. Na dúvida, use unclassified, como você disse que veio fazendo. Track deve ser usado para pequenos caminhos em fazendas e em florestas. Um critério menos subjetivo (independente de noções individuais de importância) para diferenciar track de unclassified é considerar a largura do caminho. Nem todos concordam com isso, mas não parece haver um critério mensurável melhor que esse no momento. 2013/6/11 Blademir Andrade de Lima blademi...@hotmail.com: Mapeio estradas rurais desde que iniciei no OSM, e sempre me confundo com as classificações. Inicialmente usava track, para renderizar e aparecer mais bonito, mas até o próprio track tem 5 niveis (grades!!!). Depois passei a usar Unclassified surface:unpaved ou ground, o que parecia mais justo, ja que não identificava sua classificação; melhor que outro Mapeador do local decida. Mas até que vi os mapas geográficos do IBGE, aonde pude ver que certas estradas rurais tem mais importância e nomes que outras, estas que são até largas em alguns casos, mas de terra, as mudei para Tertiary surface:unpaved. Acredito que para definir se é track ou tertiary vai depender do mapeador identificar a importância desta estrada rural, se ela leva a escolas, a vilas, vilarejos e povoados, ou se somente faz parte de um caminho de uma fazenda. Na duvida, poe unclassified. Map for the user, not for the renderer: não me esqueço desta frase. Abraços From: fernando.treb...@gmail.com Date: Mon, 10 Jun 2013 22:06:04 -0300 To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Formatar estrada de terra Vixe, lá vamos nós. :P Primeiro de tudo, você não deve mapear pensando em como aparece no mapa (sei que soa estranho, mas é essa a posição da comunidade). Isso tem um motivo: devemos pensar em como atribuir tags e deixar que outras pessoas pensem em como representá-las graficamente. É uma separação entre a lógica do mapa e a sua representação gráfica. Na Europa tem-se usando track para caminhos com função agrícola (em plantações/fazendas) ou florestal. Quando debatemos esse fluxograma, há pouco tempo atrás, decidimos (quer dizer, menos pessoas se opuseram) que uma forma menos ambígua de usar track é como está indicado: para as vias não pavimentadas que sejam estreitas, impendindo que 2 carros passem por ela simultaneamente. Na verdade, cada um tem uma idéia ligeiramente sobre quando usar track. Para não iniciar uma briga, sugiro que você siga o fluxograma até que você tenha lido todos os artigos do wiki, visto vários exemplos e tirado as suas conclusões. Há alguns exemplos com fotos nesse artigo: http://wiki.openstreetmap.org/wiki/Key:tracktype Mas lembre do que eu disse antes: estradas oficiais grandes sem pavimento que aparecem nos mapas do DNIT e do DER devem ser unclassified ou tertiary e não track. 2013/6/10 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Ah sim, utilizando o editor iD eu marquei como track e na renderização ele mostrou algo parecido já com terra. Só isso não é o bastante? Em 10 de junho de 2013 21:53, Nelson A. de Oliveira nao...@gmail.com escreveu: 2013/6/10 Fernando Trebien fernando.treb...@gmail.com: Você indica que a estrada é de terra usando a tag surface=sand. Só um detalhe aqui que sand é areia (e pode ter estradas que de fato são de terra (dirt)). Na dúvida é melhor utilizar unpaved. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law
Re: [Talk-br] Brasília no Worst of OSM
Ah, só especificando melhor (para quem estiver acompanhando a discussão a partir daqui), os dados de sua autoria são aqueles que você enviou para o TrackSource. Temos que ter o máximo de cuidado para não pegar informações que outros contribuíram para o projeto, senão pode haver uma intervenção legal no futuro solicitando a remoção dos dados que importarmos no OSM. On Jun 10, 2013 2:58 AM, Fernando Trebien fernando.treb...@gmail.com wrote: Certamente a importação é a parte menos problemática, principalmente dos POIs (que geralmente não precisam de conflação, mas possivelmente alguns ajustes manuais depois pra evitar duplicação). Nas palavras do wiki, conflação é o processo de combinar dados geográficos sobrepostos de modo a manter a precisão dos dados, evitar redundância (duplicação) e resolver os conflitos quando a informação diverge entre as fontes. O JOSM tem um plugin para conflação. O artigo sobre ele tem uma captura de tela mostrando uma etapa do processo: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Conflation No nosso caso, a conflação pegaria os dados que você filtrou do TrackSource (de sua autoria), encontraria as correspondências com as ruas que já estão no OSM e permitiria importar tags e atualizar o contorno. Para algumas ruas o processo provavelmente vai errar ao tentar achar a rua correspondente, daí é necessário fazer correções manuais. On Jun 10, 2013 1:32 AM, Erick de Oliveira Leal erickdeoliveiral...@gmail.com wrote: MAs eu considero a importação ainda de algumas partes e ainda de todos os pontos.A importação dos pontos é fácil né? Em 10 de junho de 2013 01:26, Erick de Oliveira Leal erickdeoliveiral...@gmail.com escreveu: Pois é e na verdade eu tou vendo aki existem áreas em Brasília no OSM que já são melhores que no TrackSource então não é bom mesmo a substiuição, o que é essa conflação? Em 10 de junho de 2013 01:23, Fernando Trebien fernando.treb...@gmail.com escreveu: Hahaha. :P Se houver uma forma de separar aquilo que é contribuição sua daquilo que já existia antes, então acho que podemos importar sim. Aparentemente dá pra fazer a conversão com o GPSBabel. Eu poderia te passar o arquivo convertido, daí você abriria no JOSM e removeria a informação que você não tem certeza se foi contribuída por você ou não, deixando só o que tem certeza. Se você tiver um arquivo de antes de você começar a contribuir para o TrackSource, seria excelente pra ter essa certeza. Talvez o próprio pessoal do projeto TrackSource possa conseguir essa informação. A etapa seguinte então seria fazer a conflação, que eu poderia fazer. O endereçamento é um problema à parte. Em Porto Alegre (e vale para qualquer cidade que tenha uma malha bem conectada mais ou menos em forma de grade), eu me dei conta que ele pode ser consideravelmente aproximando usando linhas com a tag addr:interpolation e marcando o número das casas nos cruzamentos que envolvem uma via arterial. Ainda assim é bastante trabalho. Em Brasília há varias ruas que são finais na malha (sem cruzamentos, apenas uma entrada), principalmente nessa região sem nomes de ruas. A boa notícia é que nesses casos ter ou não números de casas faz pouca diferença, por exemplo, para o cálculo de rotas. 2013/6/10 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Ops, era pra ter ido somente para o Trebien. rs Em 10 de junho de 2013 01:10, Erick de Oliveira Leal erickdeoliveiral...@gmail.com escreveu: E todas as mudanças recentes de Brasília pode-se dizer que eu que estou fazendo, então eu sei que nnão vai ter prejuizo de informações. Até pq estou usando os GTMs de fundo no OSM pra desenhar. porém, pra endereçar isso vai ser uma merda... Em 10 de junho de 2013 00:29, Erick de Oliveira Leal erickdeoliveiral...@gmail.com escreveu: Pois é. Eu gerei mitos dados lá, não vou dizer 100% mas foram muitos. Em 9 de junho de 2013 23:13, Fernando Trebien fernando.treb...@gmail.com escreveu: Pois é, acho que deletar tudo não seria o ideal, considerando o nível de contribuições nessa região. O melhor é fazer um processo chamado conflação (que eu não conheço muito bem, mas há tutoriais por aí). De qualquer forma, o principal seria adicionar os nomes das ruas, não precisaria importar tudo tudo (embora seria bem interessante). Eu tava tentando descobrir agora se podemos importar a sua fonte. Ela foi contribuída para o TrackSource, certo? Eles usam a licença Creative Commons, que é incompatível com a ODbL do OSM. Houve até uma ruptura um tanto recente, pois o OSM usava Creative Commons antes. Acabaram excluindo as contribuições dos usuários não aprovaram explicitamente a conversão da licença. Existe um post no fórum sobre colaboração com o TrackSource que não respondeu muito bem a questão da licença: http://forum.openstreetmap.org/viewtopic.php?id=21311 Se você baixou os dados do TrackSource, eles não poderiam ser usados
Re: [Talk-br] Importar X mapear
O contorno da Lagoa está ótimo, o que eu mexi foi no contorno da fronteira entre os países, que passa por cima da Lagoa. Estava muito suave, diferente do traçado anguloso (mas legalmente correto) do LNCC. Além disso, a fonte anterior (tag source) constava como CIA Worldbook. Como o LNCC é uma fonte nacional e tem descrições bilingues, achei que a CIA fosse mais questionável. Pelo menos em um trecho a distância entre as duas fronteiras era de mais de 1 quilômetro. O meu objetivo inicial não era nem mudar a fronteira e sim importar os marcos de fronteira. Havia várias outras coisas faltando na fronteira que a descrição do LNCC forneceu também: nomes de rios, de ilhas, e também de pontos de referência na própria Lagoa dos Patos (como pontas e enseadas. O fato de a descrição ser bilingue foi justamente o que motivou a minha discussão com o uruguaio sobre como nomear os elementos que são compartilhados entre os dois países. Isso não quer dizer que o mapa anterior não estava bom, apenas que surgiu uma fonte melhor. Além disso, ficou muito claro (pela diversidade de situações que eu encontrei) que essa informação não pode ser importada em massa, tem que ser feita manualmente. On Jun 10, 2013 9:08 AM, Flavio Bello Fialho bello.fla...@gmail.com wrote: O contorno da Lagoa dos Patos está bom porque eu corrigi ele a mão. Mapear não é só importar dados. O traçado manual das linhas sobre imagens de satélite é muito trabalhoso e muito preciso. Gostaria que os colegas se preocupassem menos com volume e mais com qualidade. A importação em massa pode apagar o trabalho de muitas semanas e incentivar usuários dedicados a abandonarem o projeto. Deixem a importação para coisas que ainda não existem, como a hidrografia. Por favor, não desconsiderem o trabalho que já foi feito ou nunca chegaremos a lugar algum. Em 09/06/2013 21:24, Fernando Trebien fernando.treb...@gmail.com escreveu: Você quer dizer as fronteiras com outros países? Eu comecei a fazer isso na fronteira com o Uruguai a partir dos dados do LNCC (http://info.lncc.br) mas parei logo no começo por 2 motivos: foi exatamente quando começamos a discutir sobre classificação, e também acabei me envolvendo numa discussão com um uruguaio sobre como definir a tag name nos elementos compartilhados da fronteira (como rios) (chegamos a uma solução interessante e justa: além das tags name:pt e name:es, a tag name teria ambos os nomes separados por / , como é feito na Europa, mas em ordem alfabética, não privilegiando assim nenhuma das duas línguas). Eu fui fazendo isso manualmente, primeiro pra ver se os dados tinham qualidade superior aos atuais (lembro que o contorno da fronteira veio da base de dados da CIA) e depois porque eu queria adicionar os marcos (boundary stones) e já fui aproveitando para melhorar a posição comparando com a imagem de satélite. Em alguns lugares os dados do LNCC estavam melhores (como sobre a Lagoa dos Patos), em outros a mudança não valia à pena (eram praticamente iguais). Nunca cheguei a fazer uma conflação automática, mas poderia começar a estudar como se faz com o JOSM. Você acha que o LNCC é uma boa fonte? Haveria outra melhor? 2013/6/9 Arlindo Pereira openstreet...@arlindopereira.com: Pode ser. Os dados do IPP são bem completos mas cobrem apenas a capital. Uma forma simples de fazer poderia ser abrir o arquivo osm no JOSM, excluir as comunidades dentro da capital, subir esses dados, criar uma coleção com eles e depois, num segundo momento, verificar se há alguma comunidade não mapeada nos dados do IPP que o IBGE tenha. Off-topic: precisamos de uma força com a importação das fronteiras, você poderia ajudar? Eu há alguns anos comecei a fazer segmento por segmento, mas não terminei. Poderíamos excluir estes dados e fazer de uma só vez. Em 08/06/2013 00:24, Fernando Trebien fernando.treb...@gmail.com escreveu: Hehe, aqui em Porto Alegre temos a Vila Cachorro Sentado (vai entender). Bem, colocar um prefixo é uma sugestão para diferenciar dos condomínios. Já que está tudo numa coleção, eu poderia acrescentar o prefixo facilmente com o JOSM se você quiser. Você teria interesse numa importação dos dados do IBGE do estado do RJ? Pode ser que complemente a informação do IPP. Acho que eu poderia resolver as duplicações manualmente, dá um certo trabalho mas pode ser interessante se você não tiver mapeado comunidades além das que estão na cidade do Rio. 2013/6/6 Arlindo Pereira openstreet...@arlindopereira.com: Legal! Por enquanto eu não poderia ajudar muito, uma vez que ainda não consegui importar todos os dados do IPP mesmo tendo começado há 4 anos atrás (!), mas acho válido usar todo dado público no nosso mapa. Aqui no Rio eu deixei o nome original mesmo. Tem uns nomes muito curiosos, tipo Vala do Sangue: http://www.openstreetmap.org/?minlon=-43.7040901184082minlat=-22.9206295013428maxlon=-43.6957855224609maxlat
Re: [Talk-br] Jornal O Globo usando o OSM sem dar créditos
Hm como você sabe que os dados vieram do OSM? Tem alguma característica que você reconheceu? Tentei olhar no código-fonte da página e não achei referências (também não fui a fundo nas chamadas dos scripts). Bem, uma primeira sugestão (e fácil) é tornar isso público. Twitter, Facebook, etc. Talvez a OSMF possa nos ajudar, mas acho que os recursos legais dependeriam da nossa legislação e eles provavelmente não sabem dos detalhes. 2013/6/10 Arlindo Pereira openstreet...@arlindopereira.com: Olá pessoal, vi que O Globo está usando o OpenStreetMap em um infográfico sobre o trânsito carioca: http://oglobo.globo.com/infograficos/acidentes-transito-mutilados/ infelizmente não há créditos ao OSM na matéria. Enviei a mensagem abaixo através do Fale Conosco. O que mais vocês sugerem? []s Arlindo Pereira Olá, como colaborador carioca do OpenStreetMap, é com satisfação que vejo O Globo fazendo uso do mapa, através do infográfico O mapa da violência no trânsito carioca (http://oglobo.globo.com/infograficos/acidentes-transito-mutilados/). Entretanto, não pude deixar de notar que não há créditos ao projeto. A licença do OpenStreetMap PERMITE o uso comercial (como o feito pelo jornal) DESDE QUE na página do mapa haja os créditos ao projeto, por exemplo numa nota de rodapé no final da matéria. Para maiores informações, visualize os seguintes links: http://www.openstreetmap.org/copyright e http://wiki.openstreetmap.org/wiki/Legal_FAQ Atenciosamente, Arlindo Pereira ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Jornal O Globo usando o OSM sem dar créditos
Se vamos comprar a briga é bom termos certeza. O que você viu no mapa da Globo que te deu certeza que era do OSM? Foi o contorno de algum bairro? Não poderia ter sido coincidência (Globo usando a mesma fonte pública importada no OSM)? On Jun 10, 2013 1:38 PM, Ronaldo Maia rom...@async.com.br wrote: Também de cara nào consegui ver que eram dados do OSM, mas clicando em uma região, pelo estilo do mapa, parece ser do osm mesmo. 2013/6/10 Fernando Trebien fernando.treb...@gmail.com: Hm como você sabe que os dados vieram do OSM? Tem alguma característica que você reconheceu? Tentei olhar no código-fonte da página e não achei referências (também não fui a fundo nas chamadas dos scripts). Bem, uma primeira sugestão (e fácil) é tornar isso público. Twitter, Facebook, etc. Talvez a OSMF possa nos ajudar, mas acho que os recursos legais dependeriam da nossa legislação e eles provavelmente não sabem dos detalhes. 2013/6/10 Arlindo Pereira openstreet...@arlindopereira.com: Olá pessoal, vi que O Globo está usando o OpenStreetMap em um infográfico sobre o trânsito carioca: http://oglobo.globo.com/infograficos/acidentes-transito-mutilados/ infelizmente não há créditos ao OSM na matéria. Enviei a mensagem abaixo através do Fale Conosco. O que mais vocês sugerem? []s Arlindo Pereira Olá, como colaborador carioca do OpenStreetMap, é com satisfação que vejo O Globo fazendo uso do mapa, através do infográfico O mapa da violência no trânsito carioca (http://oglobo.globo.com/infograficos/acidentes-transito-mutilados/). Entretanto, não pude deixar de notar que não há créditos ao projeto. A licença do OpenStreetMap PERMITE o uso comercial (como o feito pelo jornal) DESDE QUE na página do mapa haja os créditos ao projeto, por exemplo numa nota de rodapé no final da matéria. Para maiores informações, visualize os seguintes links: http://www.openstreetmap.org/copyright e http://wiki.openstreetmap.org/wiki/Legal_FAQ Atenciosamente, Arlindo Pereira ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Ronaldo Maia ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Jornal O Globo usando o OSM sem dar créditos
Estou investigando, mas assim: a licença da API e a licença dos dados são coisas separadas. Todos os exemplos do Leaflet que eu achei atribuem o OSM porque todos usam dados do OSM, mas a API é distribuída com a licença BSD. Se for possível usar a API com outra fonte de dados, acho que não é necessário atribuir nada a ninguém. On Jun 10, 2013 1:47 PM, Bruno Augusto stra...@gmail.com wrote: olá a todos! me parece que estão usando a api da http://leafletjs.com/ div class=leaflet-control-attribution leaflet-controlPowered by a href=http://leafletjs.com;Leaflet/a/div mas o tamanho do campo está totalmente zerado sendo assim fincando invisível. to certo? Bruno Augusto Mühlenhoff Em 10 de junho de 2013 13:41, Ronaldo Maia rom...@async.com.br escreveu: Também analizando o histórico de tiles, carregados, dá para ver que é do OSM mesmo: http://c.tile.openstreetmap.org/16/24816/37058.png 2013/6/10 Vitor George vitor.geo...@gmail.com: Legal que estão utilizando. Vamos fazer um pressãozinha para ver se resolvem logo. Publiquei algo no @mapaslivres. 2013/6/10 Arlindo Pereira openstreet...@arlindopereira.com Olá pessoal, vi que O Globo está usando o OpenStreetMap em um infográfico sobre o trânsito carioca: http://oglobo.globo.com/infograficos/acidentes-transito-mutilados/ infelizmente não há créditos ao OSM na matéria. Enviei a mensagem abaixo através do Fale Conosco. O que mais vocês sugerem? []s Arlindo Pereira Olá, como colaborador carioca do OpenStreetMap, é com satisfação que vejo O Globo fazendo uso do mapa, através do infográfico O mapa da violência no trânsito carioca (http://oglobo.globo.com/infograficos/acidentes-transito-mutilados/). Entretanto, não pude deixar de notar que não há créditos ao projeto. A licença do OpenStreetMap PERMITE o uso comercial (como o feito pelo jornal) DESDE QUE na página do mapa haja os créditos ao projeto, por exemplo numa nota de rodapé no final da matéria. Para maiores informações, visualize os seguintes links: http://www.openstreetmap.org/copyright e http://wiki.openstreetmap.org/wiki/Legal_FAQ Atenciosamente, Arlindo Pereira ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Ronaldo Maia ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Jornal O Globo usando o OSM sem dar créditos
Desculpem os questionamentos, só consegui ver agora o mapa. Por alguma razão meu outro navegador não estava carregando os tiles. Não acho que o maior canal de informação do país desconheceria essas questões de licenciamento de uso da informação... 2013/6/10 Vitor George vitor.geo...@gmail.com: Fernando, acho melhor esperar um par de dias antes de acionar a OSMF. Quero acreditar que não atribuiram por desconhecimento. Se não fizerem logo, tentaremos por este caminho. 2013/6/10 Fernando Trebien fernando.treb...@gmail.com Ah bom. Era o que precisávamos. Acho interessante avisá-los que sabemos disso. Alguém já notificou a OSMF? Posso fazer (daqui a alguns minutos). On Jun 10, 2013 2:00 PM, Vitor George vitor.geo...@gmail.com wrote: Eles estão utilizando direto dos servidores do OpenStreetMap. Para checar: 1 - No Chrome, abram o Developer Tools apertando Control+1 ou buscando no menu; 2 - Clique na aba Network; 3 - Clique duas vezes em algum ponto do mapa para que ele carregue os tiles do OSM. Vocês vão ver as chamadas ao servidor de tiles do OSM listadas na tabela. Vitor 2013/6/10 Fernando Trebien fernando.treb...@gmail.com Se vamos comprar a briga é bom termos certeza. O que você viu no mapa da Globo que te deu certeza que era do OSM? Foi o contorno de algum bairro? Não poderia ter sido coincidência (Globo usando a mesma fonte pública importada no OSM)? On Jun 10, 2013 1:38 PM, Ronaldo Maia rom...@async.com.br wrote: Também de cara nào consegui ver que eram dados do OSM, mas clicando em uma região, pelo estilo do mapa, parece ser do osm mesmo. 2013/6/10 Fernando Trebien fernando.treb...@gmail.com: Hm como você sabe que os dados vieram do OSM? Tem alguma característica que você reconheceu? Tentei olhar no código-fonte da página e não achei referências (também não fui a fundo nas chamadas dos scripts). Bem, uma primeira sugestão (e fácil) é tornar isso público. Twitter, Facebook, etc. Talvez a OSMF possa nos ajudar, mas acho que os recursos legais dependeriam da nossa legislação e eles provavelmente não sabem dos detalhes. 2013/6/10 Arlindo Pereira openstreet...@arlindopereira.com: Olá pessoal, vi que O Globo está usando o OpenStreetMap em um infográfico sobre o trânsito carioca: http://oglobo.globo.com/infograficos/acidentes-transito-mutilados/ infelizmente não há créditos ao OSM na matéria. Enviei a mensagem abaixo através do Fale Conosco. O que mais vocês sugerem? []s Arlindo Pereira Olá, como colaborador carioca do OpenStreetMap, é com satisfação que vejo O Globo fazendo uso do mapa, através do infográfico O mapa da violência no trânsito carioca (http://oglobo.globo.com/infograficos/acidentes-transito-mutilados/). Entretanto, não pude deixar de notar que não há créditos ao projeto. A licença do OpenStreetMap PERMITE o uso comercial (como o feito pelo jornal) DESDE QUE na página do mapa haja os créditos ao projeto, por exemplo numa nota de rodapé no final da matéria. Para maiores informações, visualize os seguintes links: http://www.openstreetmap.org/copyright e http://wiki.openstreetmap.org/wiki/Legal_FAQ Atenciosamente, Arlindo Pereira ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Ronaldo Maia ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
