Re: [Talk-br] Nova proposta de classificação viária - Votação encerrada
Acho que usar a população como critério geral é uma ótima forma para gerar a base do mapa, e é o que deve estar na regra. É simples, objetivo e facilmente verificável. Os demais critérios (RGI, REGIC, portos, aeroportos, etc.) podem servir de base para estudos que identifiquem e justifiquem as exceções, não cobertas pela regra geral. É importante lembrar que o que existe hoje pode não existir amanhã (ex: micro e meso-regiões). No entanto, a população sempre vai existir. Outro fator a considerar, principalmente na região norte, é que o modal rodoviário nem sempre é o melhor. Em alguns casos a ligação no nível trunk pode ser feito por hidrovias, ou até por via aérea (por exemplo, a BR-363 está completamente isolada do resto da malha rodoviária). Em seg., 29 de jun. de 2020 às 13:14, Fernando Trebien < fernando.treb...@gmail.com> escreveu: > Eu gostaria de sugerir que aqueles que fizeram apontamentos nos seus > votos abram discussão a respeito deles na página de discussão da > proposta. [1] Lá é o lugar ideal para discutir e depois votar > alterações e refinamentos na proposta. > > Acho que já existe um consenso substancial de que a regionalização por > RGInts (parte da regra 2.2) e talvez também por RGIs (parte da regra > 3.1) não seria a mais adequada. Alguns colegas propuseram e começaram > a explorar os resultados de regionalizar usando as categorias das > REGICs para adicionar alguns pólos ao conjunto considerado. As rotas > preliminares que foram apresentadas por eles no Telegram fazem um > certo sentido para mim, então, havendo interesse de outros colegas, > não me oponho à substituição. As que foram apresentadas produzem um > resultado melhor do que as RGInts, no sentido de identificarem melhor > os eixos indutores do desenvolvimento regional. > > Apesar disso, o número de diferenças em relação ao resultado final das > demais regras tem se mostrado relativamente pequeno, de forma que > essas rotas adicionais poderiam ser tratadas na lista de exceções > junto com outras exceções que possam ser levantadas, por exemplo, como > já foi citado por colegas diferentes algumas vezes, os acessos a > grandes portos e aeroportos. Ou seja, é necessário mais estudo e > comparação dos casos particulares. > > [1] > https://wiki.openstreetmap.org/wiki/Talk:Brazil/Classifica%C3%A7%C3%A3o_das_rodovias_do_Brasil > > > On Sun, Jun 28, 2020 at 11:49 AM santamariense > wrote: > > > > A proposta está recebendo novas propostas de variáveis as quais > > precisarão passar por novas votações, quer pontualmente, quer em > > conjuntos. Várias observações foram feitas, muitas poderão ser votadas > > em breve e outras tantas poderão ser votadas com o amadurecimento da > > implantação em mapa do que está sendo proposto. > > > > Como já foi falado em várias ocasiões, a discussão não acaba aqui, mas > > sim evolui com o andar do mapeamento. Vou declarar a proposta > > aprovada, uma vez que há a aprovação da maioria dos que votaram e por > > respeito a quem dedicou o tempo que tinha para estudar a proposta e > > dar seu voto. E para que possamos virar a página e a partir desse > > momento votar casos pontuais conforme forem surgindo, bem como ajustes > > no texto da proposta que se julgar necessário. > > > > ___ > > Talk-br mailing list > > Talk-br@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-br > > > > -- > Fernando Trebien > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nova proposta de classificação viária - Votação encerrada
Acho que a proposta base pode ser considerada aprovada e os questionamentos levantados devem ser discutidos e votados separadamente. Alguns itens da proposta também precisa de ajustes na terminologia (que não mudam o sentido da proposta, mas deixam ela mais uniforme): Trunk: mudar "Principal rota rodoviária pavimentada ligando 2 centros urbanos..." para "Principal rodovia pavimentada ligando centros urbanos..." Primary: mudar "Rodovia pavimentada que é rota ideal entre centros urbanos..." para "Principal rodovia pavimentada ligando centros urbanos..." Secondary: mudar "Rodovia/estrada que é rota ideal entre centros urbanos..." para "Principal rodovia/estrada ligando centros urbanos..." Tertiary: mudar "Rodovia/estrada que é rota ideal entre os demais núcleos urbanos" para "Principal rodovia/estrada ligando os demais núcleos urbanos" Em qui., 18 de jun. de 2020 às 16:23, santamariense escreveu: > Encerrado o processo de votação, alguém se opõe em declarar a proposta > aprovada? O próximo passo é atualizar textos da Wiki, que tratam sobre > o assunto. Passarei aqui as correções a serem feitas para apreciação > da comunidade. Também há uma orientação em manter a página de votação > onde está, a qual pode ser usada de referência e ser linkada por > outras páginas. > > > > Registro aqui o encerramento da votação da nova proposta de > > classificação viária o qual ocorreu na data de 29/05/2020, às > > 23:59:59, horário de Rio Branco/AC. > > > > Foram um total de 11 votos, onde 7 concordaram, 3 discordaram e 1 > absteve. > > > > Existem alguns pontos que foram levantados por colegas e poderão > > entrar na proposta passando por nova votação, como de costume. > > > > Também existem páginas da wiki que precisariam ser revisadas, conforme > > citei no email [1] que enviei no encerramento da votação, antes do > > pedido de prorrogação. > > > > [1] - > https://lists.openstreetmap.org/pipermail/talk-br/2020-May/012834.html > > > > Alguma sugestão? > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nova proposta de classificação viária
Olhei por alto o mapa. Ficou interessante. Acho que as rotas devem ser mais ou menos aquelas, mas ajustes são necessários. Um critério fundamental para o Brasil é que todas as trunk devem ser pavimentadas. Em outros países, pode ser aceitável uma trunk não pavimentada, como no caso do Canadá, onde boa parte do ano a estrada está coberta de neve, mas no Brasil a erosão das chuvas deixa várias estradas não-pavimentadas inviáveis (às vezes até as pavimentadas). Um exemplo é a rota entre Boa Vista e Georgetown, que não é pavimentada no lado da Guyana. Faria mais sentido, ao invés dessa rota, classificar como trunk a rota entre Boa Vista e Ciudad Guayana, na Venezuela, que é pavimentada e imagino que tenha um fluxo de veículos bem maior. Acho que o trabalho ficou bom como exemplo ilustrativo, mas as rotas devem ser discutidas com calma, talvez focando em um estado de cada vez. É importante também incluir critérios físicos, como foi feito no RS (rodovias duplicadas com mais de 10 km de extensão são trunk). Se a rodovia foi duplicada é porque ela tem importância. É muito caro duplicar uma rodovia. Parabéns pelo trabalho. Em sex., 13 de mar. de 2020 às 11:26, santamariense escreveu: > Compartilho com vocês o resultado [1] da interconexão de rotas entre > as cidades com mais de 200 mil habitantes, as quais deverão ser parte > da malha trunk do nosso país. Todos os trechos tem quais rotas passam > por ele com a tag R*. A mesma relação de rotas é possível ser > encontrada na tabela que também está contida no arquivo zip a ser > baixado. É ainda possível averiguar uma rota completa, com todos os > trechos selecionados, selecionando um dos trechos, selecionando nas > tags a rota desejada, clicando com o botão direito e selecionando a > opção 'buscar chave/valor', ou algo parecido. Em caso de divergência > entre a tabela e o mapa, a rota da última deve prevalecer. > > Conurbações foram consideradas como sendo apenas uma cidade, logo, as > cidades conurbadas devem ter sua malha urbana pensa em conjunto, e, > por conseguinte, trunks adicionais podem existir dentro dessas áreas > conurbadas. > > As conexões que passam a fronteira do Brasil são meramente > ilustrativas da rota completa entre cidades interconectáveis. Porém é > importante lembrar que a classificação fora do território brasileiro > não será modificada sem diálogo com os nossos vizinhos. > > Divergências dos resultados podem ser discutidas pontualmente de modo > a se adicionar ou excluir trechos, bem como modificar as rotas. > > [1] - > https://github.com/santamariense/ClassViarBR/raw/master/Mapa%20e%20tabela%20trunk%20v20200313.zip > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Geometria de lagos com margens muito variáveis
Parabéns pelo trabalho. Isso é um assunto que incomoda, porque cada imagem
de satélite é diferente da outra. Creio que ficaria interessante se a
representação mostrasse as linhas das marés baixa e alta, bem como a maré
média. Na minha opinião, isso ficaria claro se, nos trechos em que a maré
varia muito, a coastline ficasse na maré média e a área de wetland fosse da
linha da maré baixa até a linha da maré alta. Na região indicada [1],
parece (dentro dessa lógica) que as ilhas estão entre a linha de maré média
e a linha de maré alta, e que no resto da costa a maré média coincide com a
maré alta. Eu sei que não é assim, mas é como ficou a representação no mapa.
[1]
https://www.openstreetmap.org/?mlat=-31.8076=-51.8015#map=13/-31.8076/-51.8015
Em sex, 8 de mar de 2019 às 12:40, Fernando Trebien <
fernando.treb...@gmail.com> escreveu:
> Olá a todos,
>
> Tenho atualizado a geometria da Lagoa dos Patos no RS, uma lagoa rasa,
> com margens quase planas em diversos locais. O nível da água depende
> das marés próximo do oceano, e dos ventos em terra [1], e com isso às
> vezes invade áreas com centenas de metros e às vezes mais de um
> quilômetro. A minha dúvida é se estou representando corretamente no
> OSM:
>
> 1. A área dentro da variação do nível da água
> - Praias de areia: natural=beach + surface=sand + tidal=yes/no ("no"
> na parte seca, "yes" na parte às vezes submersa)
> - Outras áreas periodicamente submersas: natural=wetland +
> wetland=tidalflat
>
> 2. Os limites da lagoa com a terra seca: no OSM as coastlines devem
> aproximar a média astronômica da maré alta [2], ou "mean high water
> spring" (MHWS) [3]. Como não temos essa informação, tenho comparado as
> imagens do Bing e do ESRI e escolhido a que tem a maré mais alta para
> atualizar essa geometria, e a de maré mais baixa para definir a área
> periodicamente alagada (item anterior).
>
> 3. Os limites administrativos definidos em termos dos limites da
> lagoa: tenho colocado junto à maré baixa, que é mais próxima da
> geometria do IBGE e me parece mais próxima também do que seriam a
> Linha do Preamar Média (LPM) e da Linha Média de Enchentes Ordinárias
> (LMEO) definidas em 1831, quando o nível da água era mais baixo que o
> atual. A LPM e a LMEO de 1831 estão sendo levantadas pelo governo
> federal já faz uns anos. [5]
>
> http://www.planejamento.gov.br/assuntos/gestao/patrimonio-da-uniao/plano-nacional-de-caracterizacao
>
> Escolhi uma área [4] mais complicada para avaliar a aplicação dessas
> definições e gostaria de ouvir opiniões sobre se parece correto ou se
> algo deveria ser diferente.
>
> A aplicação dessas definições parece ter sido um tanto inconsistente
> no exterior. [6]
>
> [1] https://acervo.popa.com.br/diversos/ventos_lpatos.htm
> [2] https://wiki.openstreetmap.org/wiki/Coastline
> [3] https://commons.wikimedia.org/wiki/File:Tide_terms.png
> [4]
> https://www.openstreetmap.org/?mlat=-31.8076=-51.8015#map=13/-31.8076/-51.8015
> [5]
> http://www.planejamento.gov.br/assuntos/gestao/patrimonio-da-uniao/plano-nacional-de-caracterizacao
> [6]
> https://lists.openstreetmap.org/pipermail/tagging/2018-April/035654.html
>
> --
> Fernando Trebien
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
--
Flávio Bello Fialho
bello.fla...@gmail.com
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Como interpretar direction em pontos de alerta?
onde ele olha. >> >> [2] Usar forward/backward tem a vantagem de ficar imune a alterações no >> traçado que implicariam em atualização também do valor da direction em >> graus. Mesmo em caso de inversão do traçado o ID e o JOSM ajustam >> automaticamente. >> >> Uma observação adicional: nas vias de mão única a direction é >> dispensável. Acho até melhor não usar pois evita essas dúvidas. O mesmo >> acontece nas vias de mão dupla em que o alerta atua nos dois sentidos. >> >> Abraços, >> -- >> Fidelis Assis >> ___ >> Talk-br mailing list >> Talk-br@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-br >> > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > > -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Como interpretar direction em pontos de alerta?
ria como? >> É outro X que fica ao usar direction dessa forma. >> > > Isso eu comentei, sugeri uma forma em mensagem anterior, você não deve ter > visto. Vamos representar um radar fixo tradicional que é composto por uma > câmera, 2 sensores (2 para poder medir a velocidade) e uma lógica associada > que monitora os sensores, mede a velocidade e dispara a câmera quando o > valor medido é superior ao limite permitido. > > Normalmente a direção da câmera não interessa, a que interessa é a de > fiscalização. Mas quero também, por qualquer razão, representar a da > câmera. Vamos então precisar de uma relação de enforcement. > > A relação é composta por 3 elementos: um nó normalmente fora da via para o > DEVICE, um nó na via para o FROM e outro na via para o TO. Podemos > associar o que a relação modela com a realidade pensando no DEVICE como a > câmera, o FROM como o primeiro sensor e o TO como o segundo. Com isso, a > direção de fiscalização sai automaticamente dos dois pontos FROM e TO. > Mas e a da câmera? Bom, nós já temos um nó que representa apenas a câmera, > logo basta colocar p.ex direction=90 no DEVICE para indicarmos que a > câmera aponta para o Leste, 270 para o Oeste, etc. > > Completando, indicamos que é uma relação de enforcement do tipo maxspeed > e adicionamos a etiqueta maxspeed com o valor da velocidade máxima. > > Isso atende? A maior complexidade foi por causa do desejo de se > representar a direção da câmera. Precisamos mesmo disso se a intenção for > representar apenas a direção de fiscalização? > > Agora um exercício simples: se não precisarmos da direção da câmera, por > que do nó DEVICE? Vamos descartá-lo. Ah isso não pode porque o DEVICE é > obrigatório, só o TO é opcional quando FROM e DEVICE estão na mesma via. > OK, é só um exercício. Beleza, com isso reduzimos um pouco a complexidade > e ainda representamos a direção de fiscalização que é o que interessa. > > Podemos simplificar mais? Sim, os dois nós dos sensores, FROM e TO, podem > ser substituídos por um único, o FROM p. ex. e considerarmos o outro como > implícito, é o seguinte na via (ou anterior se o FROM for o último e ai a > gente pensa nele como TO). No caso dos radares fixos tradicionais os > sensores FROM e TO ficam próximos. > > Já que ficamos com apenas um nó de sensor, por que precisamos da relação? > Vamos descartar a relação e colocar as etiquetas highway=speed_camera [1] > e direction=forward/backward indicando direção de fiscalização no nó que > sobrou, o FROM. Já que não temos mais câmera mesmo, essa direction não > representa direção da câmera. > > Dessa forma eliminamos a relação e sua complexidade com apenas um nó na > via - na prática é isso que tem sido feito, só não é visto assim. Claro, a > primeira reação é muita estranheza, quebra muitas regras, sai do conforto, > etc. Mas é apenas uma sugestão para pensar. > > Para evitar alongamentos nesse assunto, vamos focar então em maxspeed: > forward/maxspeed:backward como forma padrão para indicar direção de > fiscalização de radares unidirecionais em vias de mão dupla? É simples, > consistente, dispensa relação e longas discussões. > > > [1] Seria legal se tivéssemos outra etiqueta para isso, ex speed_sensor > para evitar pensar em câmera. Sim, sei que tem até recomendação sobre não > usar isso, mas entendo que o contexto lá é outro. Aqui seria bem razoável. > Ou outro nome distinto: buried_speed_sensor, etc. > > > Abraços, > -- Fidelis > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > > -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Como interpretar direction em pontos de alerta?
A direção que a câmera está apontando é irrelevante. O que importa, na prática é o sentido da via que está sendo monitorado. Dessa forma, para highway=speed_camera, recomendo usar direction=forward ou direction=backward, em casos de via de mão dupla, ou não usar o tag, em caso de vias de mão simples (nesse caso, o sentido é óbvio). Em qualquer caso, o tag maxspeed deve sempre ser especificado. Quanto aos sinais de Pare (highway=stop), o pressuposto é que eles sempre se aplicam ao cruzamento mais próximo, sendo geralmente desnecessário o uso do tag direction. A exceção é caso de dois cruzamentos muito próximos em uma via de mão dupla, com o highway=stop no meio, em que o cruzamento alvo não é óbvio. Nesses casos, recomenda-se usar direction=forward ou direction=backward, para indicar a direção do cruzamento ao qual se aplica o highway=stop. Lembro ainda que, no caso de um "all-way stop", em que todos devem parar, o tag "highway=stop" deve ser colocado no cruzamento, ao passo que em outros casos deve ser colocado na via, um pouco antes do cruzamento. Em 27 de março de 2018 22:09, Fidelis Assis <fidelis.as...@gmail.com> escreveu: > > > Em 27 de março de 2018 20:19, Nelson A. de Oliveira <nao...@gmail.com> > escreveu: > >> Para este fim não dá para usar direction para highway=speed_camera ou >> similares. >> >> O direction indica apenas o lado que está apontando, mas não a direção >> a que se aplica. >> Por exemplo, pode ter câmera apontando para o sentido do fluxo >> (pegando o carro pela parte de trás) ou apontando contra o sentido do >> fluxo (pegando o carro pela frente). >> > > Comentei sobre isso, direção da câmera, justamente para enfatizar que não > se trata da direção da câmera. Esta não ajuda nada nesse caso. > > Aproveitando que o nome no iD não é câmera, mas 'sensor de velocidade', > aliás muito bem escolhido por quem o fez, creio que se pode falar da > direção dele assim como se fala da direção da respectiva placa de > sinalização, para onde ela está voltada. > > A ideia/sugestão seria uma generalização, imaginar um guarda postado no > local do alerta (seja sensor de velocidade, lombada, parada obrigatória, > etc) e assim associarmos a direção do olhar do guarda com um hipotético > olhar da lombada, do sensor, etc. Dessa forma a direction seria útil na > extração da direção de atuação do alerta. > > Inverter o direction da câmera para gerar um aviso seria incorreto, >> portanto. >> > > Mas nos dois casos as directions mapeadas não são as das câmeras. São > direções até opostas às delas, compatíveis com a direção do deslocamento. > Dá para ver com street view. E não vejo sentido mesmo em mapear a direção > da câmera num nó da via que representaria o *sensor* (normalmente sob o > asfalto). Se você conferir, vai ver que a maioria dos sensores com > direction no Brasil não representam a direção da câmera, mas o sentido do > fluxo. O problema é que há dúvidas se deveriam representar sentido de fluxo > ou para onde "olham". Assim, dependendo do mapeador temos um caso ou outro. > > Pessoalmente acho que deveriam sempre representar para onde olham quando o > valor for graus ou pontos cardeais, como vale em geral para direction (*The > key direction is used in a variety of situations to specify the direction > of a feature*). No caso de forward/backward já existe uma prática em > diversos países de que indicam a direção do fluxo afetado, como exemplo o > mapeamento de parada obrigatória. Interessante é que se você especificar > forward numa parada obrigatória em via de mão única (desnecessário mas não > errado conforme a prática) o viewfield do iD olha para trás, indicando para > onde o alerta "olha" (ou a placa respectiva), o contrário do sentido do > fluxo. > > >> Sem relação de enforcement não dá para representar a direção a que se >> aplica. >> > > Concordo que a relação de enforcement é uma solução definitiva mas é mais > difícil de mapear. Há 600 sensores de velocidade em SP, apenas 19 deles com > relação de enforcement. No Brasil são cerca de 6772, apenas 311 como > enforcement. Minha sugestão foi primeiro para interpretar o mapeamento de > 'sensor de velocidade' em nó de via como representando o sensor > propriamente dito e não a câmera. Em segundo, aproveitar essa forma mais > simples de mapear já largamente usada (apenas um nó na via) indicando > direção apenas quando necessária e com forward/backward conforme as mesmas > regras usadas para parada obrigatória em vários países. > > Abraços, > -- Fidelis > > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > > -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Mapeamento hidrológico
A proposta "major/big/small" não me parece inútil. Pelo contrário, parece ser bastente útil para definir quais cursos representar em diferentes escalas do mapa, além de ser simples de implementar. A Otto Codificação é muito interessante e permite identificar bacias individuais. Nada impede que se usem as duas, pois não são incompatíveis. Na minha opinião, o mais crítico é traçar a hidrografia no mapa. Tenho algumas dúvidas: 1. Qual é o critério para diferenciar "waterway=stream" de "waterway=river"? 2. Sempre que for traçado um "waterway=river" deve-se traçar também uma área com tag "waterway=riverbank"? 3. Como definir os limites de "natural=wetland"? Em 30 de agosto de 2017 10:57, Cassio Eskelsen <cas...@3geo.com.br> escreveu: > A proposta de definir como "major/big/small" considero inútil e que não > agrega nada. > > A outra proposta é interessante. O número de Strahler é comumente > utilizado em GIS, mas no Brasil não é tão usado já que nos acostumados com > a Otto Codificação. > A Otto Codificação é mais complexa, não sei se eles aceitariam, até pq não > se usa tanto la fora. > > Cássio Rogério Eskelsen > 3Geo > > 2017-08-30 8:20 GMT-03:00 Nelson A. de Oliveira <nao...@gmail.com>: > >> Dá uma olhada nessas propostas (que são recentes e estão sendo >> discutidas na tagging): >> >> https://wiki.openstreetmap.org/wiki/Proposed_features/Waterw >> ays_classification >> https://wiki.openstreetmap.org/wiki/Proposed_features/Rivers >> _Classification >> >> ___ >> Talk-br mailing list >> Talk-br@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-br >> > > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > > -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Numeração da Av paulista em SP - SP
Sugiro utilizar o número principal no way do edifício e colocar points com os outros endereços no local da porta de entrada dos outros números. Pelo que eu entendi, os outros números são de lojas no andar térreo. Quando uma pessoa vai para os andares de cima do edifício, em qual número ela entra? Em 18 de maio de 2017 21:32, Nelson A. de Oliveira <nao...@gmail.com> escreveu: > 2017-05-18 18:41 GMT-03:00 Marcos Fedato <heroij...@hotmail.com>: > > Se os numeros forem da mesma rua poderia se utilizar o ponto e virgula > para cada numero. > > Em geral funciona com várias chaves no OSM, mas não para endereços. > Para os vários números precisa representar separadamente mesmo. > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Dúvida na identificação de Rodovias
Art. 1º Esta Lei tem por objetivo consolidar as Leis que dispõem sobre denominação de bens públicos no âmbito do Estado de Santa Catarina, nos termos da Lei Complementar nº 589, de 18 de janeiro de 2013. Parágrafo único. Esta Lei consolidadora não gera qualquer novo direito, mas mantém integralmente todos os direitos plenamente adquiridos nos termos das Leis consolidadas referidas no art. 2º desta Lei. Art. 2º Ficam consolidadas, nos termos desta Lei e seus Anexos I e II, a Lei ... 12.353, de 11 de julho de 2002 ... Em 14 de fevereiro de 2017 11:23, Nelson A. de Oliveira <nao...@gmail.com> escreveu: > 2017-02-14 11:19 GMT-02:00 Flavio Bello Fialho <bello.fla...@gmail.com>: > > Anexo I da lei, na parte de Lages, está especificado: "Denomina Enedino > > Batista Ribeiro o trecho da Rodovia SC-438 entre o Rio Lavatudo/Divisa > com o > > Município". > > Do que entendo o anexo é apenas a referência das leis que foram > revogadas, e não uma nova lei que denomina a rodovia. > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Dúvida na identificação de Rodovias
Cheguei tarde na discussão, mas acho ela importante. Parece que há dois pontos sendo discutidos ao mesmo tempo, que estão se confundindo: 1. Como nomear rodovias. 2. Como atribuir endereços aos locais. O segundo ponto pode ser melhor discutido, mas o primeiro, para mim, está bem definido. O lugar do código da rodovia é no tag "ref" (ref=SC-114). O lugar da denominação (nome) da rodovia é no tag "name" (name=Rodovia Enedino Batista Ribeiro). As rodovias que não tem nome não devem ter o tag "name". Se a rodovia é conhecida por mais de um nome, ela deve ter, além do tag "name" (com o nome oficial), o tag "alt_name" (alt_name=Rodovia da Discórdia). O código da rodovia não deve ir nos tags "name" ou "alt_name", mas apenas no tag "ref". Em 13 de fevereiro de 2017 20:58, <thunder...@gpsinfo.com.br> escreveu: > Tá complicado tudo isso. > > Particularmente não confundo SIGLA de rodovia com NOME. > > No Brasil existem inúmeras Rodovias que não estão ainda nomeadas e algumas > nem nome ainda tem. Essas tem o campo NAME em branco. > > Até onde sei, numeração de porta em rodovia geralmente é dada por Km. Até > gostaria de saber onde existe numeração de porta em rodovia sem ser por Km > e um exemplo se existir. > > Confesso não ser prudente incluirmos a SIGLA no campo NAME porque isso vai > gerar duplicidade de informação em texto e na instrução em voz nos > navegadores. > > []s > Marcio > > *From:* Roger C. Soares > *Sent:* Monday, February 13, 2017 4:31 PM > *To:* OpenStreetMap no Brasil > *Subject:* Re: [Talk-br] Dúvida na identificação de Rodovias > > Olha essa placa do DEINFRA/SC: > > http://2.bp.blogspot.com/-jOvA28xtNTg/VC7Jh67PYAI/ > BMw/uTmz5C54QTo/s1600/placa%2Bda%2Brodovia%2BEnedino.jpg > > O nome que eles usam é: *Rodovia Enedino Batista Ribeiro*. Não é trecho, > é rodovia. O SC-438 aparece separado. > > No caso dos correios, estando o CEP correto, a carta deveria ser entregue > usando a sigla ou o nome da rodovia... > > Uma opção é colocar no name como é sinalizado, e em alt_name o Rodovia > sigla, para aparecer como opção de endereçamento dos edifícios... > > Atenciosamente, > Roger. > > -- > Em 13-02-2017 14:54, Jairo Duarte escreveu: > > Ok Arlindo, vou adotar desta forma. > > name: Rodovia SC-114 > > official_name: Trecho Enedino Batista Ribeiro. > > Editei e vi que no endereçamento dos prédios aparecem as duas opções. > > Em 13-02-2017 14:36, Arlindo Pereira escreveu: > > Sem querer me posicionar na treta de qual deve ser o nome oficial a ser > utilizado na tag "name", ao menos troque de "name1" para "official_name", > assim ambos poderão ser localizados. > > Mais detalhes em http://wiki.openstreetmap.org/wiki/Key:name > > > []s > Arlindo Pereira > > 2017-02-13 14:32 GMT-02:00 Nelson A. de Oliveira <nao...@gmail.com>: > >> 2017-02-13 14:30 GMT-02:00 Jairo Duarte <jairo.fazgra...@gmail.com>: >> > name1: Trecho Enedino Batista Ribeiro >> >> "name1" não existe. >> Nada vai entender isso. >> >> ___ >> Talk-br mailing list >> Talk-br@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-br >> > > > > ___ > Talk-br mailing > listTalk-br@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-br > > > > > ___ > Talk-br mailing > listTalk-br@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-br > > > -- > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > > > > ------ > [image: Avast logo] > <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient> > > Este email foi escaneado pelo Avast antivírus. > www.avast.com > <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient> > > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > > -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Dúvida na identificação de Rodovias
Dê uma lida melhor na Lei 16.720. Ela só revoga a Lei 12.353 (e várias outras) porque consolida várias leis numa só. A rodovia permanece com o nome "Enedino Batista Ribeiro". No Anexo I da lei, na parte de Lages, está especificado: "Denomina Enedino Batista Ribeiro o trecho da Rodovia SC-438 entre o Rio Lavatudo/Divisa com o Município". Em 13 de fevereiro de 2017 13:11, Nelson A. de Oliveira <nao...@gmail.com> escreveu: > No caso desse trecho da SC-114, a lei que dá denominação é essa > http://server03.pge.sc.gov.br/LegislacaoEstadual/2002/ > 012353-011-0-2002-001.htm > Então se há lei, é o nome do trecho. > > MAS a lei foi revogada em > http://server03.pge.sc.gov.br/LegislacaoEstadual/2015/ > 016720-011-0-2015-001.htm > por causa de "atribuir nome de pessoa viva e de pessoa falecida que > tenha praticado ato de lesa-humanidade, tortura ou violação de > direitos humanos, a bem público, de qualquer natureza, pertencente ao > Estado ou a pessoas jurídicas da Administração Indireta." > > Ou seja, a não ser que exista outra lei dando nome ao trecho, essa > parte em específico não possui nome (não deve ter nenhum "name" no > OSM, muito menos "Rodovia SC-117", mas apenas "ref"). > > Pegando um outro trecho de rodovia, como a SC-157. > No documento do DEINFRA temos "ENGº FÉLIX MALBURG" como denominação. > > Ao procurar pela lei temos a confirmação de que o nome de fato está > correto: http://server03.pge.sc.gov.br/LegislacaoEstadual/2016/ > 017027-011-0-2016-001.htm > > Se a dúvida é achar que "Rodovia SC-XXX" é o nome, basta olhar na leis. > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Projeto de teste para integração com overpass
Por favor são saia quebrando trechos por aí. As coisas são como são por algum motivo. Quebre apenas se as características dos trechos forem diferir (nº de pistas, velocidade, participação em relações, etc.). Quebrar tudo vai tornar a edição um pesadelo. Em 23 de setembro de 2016 08:26, George Silva <georger.si...@gmail.com> escreveu: > Assim, colocando um pouco de lenha na fogueira... > > Eu imagino que é muito mais fácil de juntar as partes de caminhos > quebrados do que o contrário. Atualmente as ferramentas que temos a > disposição para processar geometrias torna isso bem tranquilo. > > É uma questão de conceito mesmo. Eu preferio ter o átomo (trecho de > logradouro), pois o agregado sai fácil. Se eu tiver N trechos, posso > uni-los com base em suas características (trechos da av. fulano com 2 > pistas). Agora quebrar já é um problema bem mais complexo, pois você > precisa não só do dado que você quer fatiar, mas também dos dados do > entorno. Nelson, onde não conseguimos unir os diversos trechos? > > Uma vantagem do OSM em favor do argumento do "trecho quebrado" é que toda > a edição é topológica, ou seja, você trabalha com um nó amarrado. Se mexer > no trecho quebrado, as duas partes dele continuarão juntas. > > Falando especificamente do meu problema, vou fazer alguns testes para > "nodar" as vias que estou fazendo download, mas acho que vai ser complicado > num cenário JavaScript. Já olhei o Turf.js e sei que ele não vai me dar as > funcionalidades que preciso para quebrar os trechos. Estou achando que > terei de pré-processar isso em Python. > > Outra coisa: estamos discutindo sobre algo que não existe uma guideline, > correto? > > > 2016-09-23 0:39 GMT-03:00 Nelson A. de Oliveira <nao...@gmail.com>: > >> 2016-09-23 0:30 GMT-03:00 Vítor Rodrigo Dias <vitor.d...@gmail.com>: >> > Pra ser sincero não sei por que o OSM não quebra segmentos de rua >> naturalmente. Até onde eu sei, todos os outros sistemas de mapeamento >> colaborativo quebram segmentos automaticamente. >> >> Eu já não consigo ver vantagem nisso :-) >> >> Uma que vai gerar um objeto para cada pedaço (imagina o tanto de >> objetos que seriam criados no mundo apenas para quebrar as vias). >> Outra que também não ajudaria na hora de mapear: você vai selecionar >> todo um trecho de rodovia para definir a superfície, número de faixas, >> nome, etc. Vai precisar clicar em trecho por trecho, segurando Shift, >> para selecionar todos? >> >> Caminhos completos permitem processamento posterior, se necessário (é >> possível quebrá-los automaticamente nas interseções, se alguma >> aplicação assim quiser). >> Mas a volta nem sempre é garantida: unir automaticamente os trechos >> quebrados não é possível em vários casos. >> >> ___ >> Talk-br mailing list >> Talk-br@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-br >> > > > > -- > George R. C. Silva > Sigma Geosistemas LTDA > > http://www.sigmageosistemas.com.br/ > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > > -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Site do IBGE Usando o OpenStreetMap.
É interessante observar a diferença entre o traçado dos limites da cidade de Recife do OSM e do IBGE.O do OSM está bem mais preciso (dá para ver bem nos casos em que o limite municipal acompanha um rio). Entretanto, em poucos lugares, há uma divergência maior, que deve ser investigada (por exemplo, no limite sul-sudoeste da cidade do Recife, perto do bairro COHAB). Podemos usar o site do IBGE como ferramenta para verificar em quais lugares existe essa divergência e pesquisar aonde está o limite real (que deve ser definido em alguma lei). Nesses casos, é bom citar o número da lei no tag source. De qualquer forma, a notícia é ótima. Ajuda a divulgar o OSM e pode contribuir para melhorar os mapas. Em 15 de junho de 2016 17:58, raphaelmirc . <raphaelm...@gmail.com> escreveu: > *Boa Noite Amigos do Grupo!! * > > >Acessando o Site do *IBGE* Hoje eu me deparei com o Mapa do Open > Street Map nas pesquisas, achei muito legal, tudo que eu coloquei no mapa > está disponível para consulta no Bairro da Cohab, vi algumas pessoas > falando que o IBGE estava disponibilizando os mapas do openstreetmap e > pude comprovar que era verdade mesmo!! > > > *Segue o Link para Consulta direto do IBGE.* > http://cidades.ibge.gov.br/xtras/perfil.php?codmun=261160 > > > Att; > Um Forte Abraço, > > > > > *Raphael de Assis.* > Recife/PE > raphaelm...@gmail.com > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > > -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Votação: uso de boundary=administrative para meso/micro-regiões do IBGE
Discordo: Primeiro, o tema é polêmico e acho a votação precipitada. Segundo, as macro e microrregiões são utilizadas para fins administrativos, mesmo que não haja uma estrutura administrativa formal estabelecida, não sendo apenas uma divisão artificial para fins de censo. Não vejo justificativa suficiente para alterar a estrutura existente. -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] RES: Limite de cidades com distritos
O assunto das divisões administrativas é evidentemente polêmico. Há opiniões divergentes e é difícil chegar a um consenso. Há outros assuntos igualmente polêmicos, que volta e meia retornam à lista. Na minha opinião, nesses casos, deve-se deixar o mapa como está (para evitar guerras de edição) e passar a outros assuntos em que haja consenso, enquanto cada um amadurece melhor a ideia. Em relação aos limites administrativos, tenho um assunto a levantar: eles NÃO estão corretos. Foram importados da base do IBGE, com uma resolução que se aproxima bastante do real, mas há muitos erros. Por exemplo, em vários casos, o limite administrativo oficial (ditado pela lei) acompanha um rio (ou, às vezes, uma estrada). No mapa, existe um caminho para o rio e outro para o limite administrativo, que não coincidem e frequentemente não coincidem com o curso real do rio. A minha proposta, nesses casos é: 1. Verificar, na lei, se o limite administrativo é mesmo o rio (à). 2. Unir os caminhos de limite administrativo e rio num só caminho, cuidando para preservar os tags e relações. 3. Corrigir o trajeto do caminho, com base em imagens de satélite ou outra fonte, de forma que ele siga o percurso do rio. A parte mais difícil é o item 1. É trabalhoso achar a lei que estabelece a divisa dos municípios (geralmente é a lei de criação do município, mas os limites podem ter sido alterados por uma lei posterior), e mais trabalhoso ainda conseguir interpretar o texto descrevendo os limites, que é bastante confuso. Entretanto, o resultado é compensador. O mapa fica bem melhor e se corrige hidrografia e limites administrativos ao mesmo tempo. Fiz isso em alguns (poucos) locais no Rio Grande do Sul, e já notei que eu não fui o único. Alguém tem interesse em ajudar? -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] duvida de tunnel=culvert
Normalmente, não se deve conectar rio com rua, mas eu tenho uma dúvida: No caso de um limite municipal ser definido pelo rio e depois pela estrada, ambos farão parte da relação que define o contorno do município. O problema é como fazer a conexão entre os três (rio, estrada e limite municipal): 1. Fazer com todos compartilhem um ponto, definindo layer=1 na rodovia (no caso, o ponto será em cima de uma ponte). Isso gera uma mensagem de erro no JOSM. 2. Criar dois pontos muito próximos e uni-los com um segmento muito curto que existe apenas para fechar o contorno do município. Acho isso uma gambiarra desnecessária pior que o ponto compartilhado. 3. Outra opção (favor explicar). Por enquanto, usei a opção 1, ignorando a mensagem do JOSM (até porque não são tantos casos assim), pois acho que faz mais sentido, mas seria bom que tivéssemos uma orientação sobre o assunto. Em 23 de novembro de 2015 02:04, Nelson A. de Oliveira <nao...@gmail.com> escreveu: > 2015-11-23 1:58 GMT-02:00 Helio Cesar Tomio <hcto...@gmail.com>: > > Mas depois disto aparece a mensagem "tunel em objeto suspeito" na > > verificação do JOSM. > > > > Em cruzamentos destes tipos, é errado mapear como ponto? > > Sim. tunnel=* só pode ser utilizado em caminhos, não em pontos (nós). > Por isso você vê um aviso quando utilizado em nós. > > E outra coisa que está errada nos seus exemplos, é que o nó está > conectando o rio com a rua. Isso não deve acontecer. > Não deve existir nó compartilhado entre os dois. > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Classificação de vias (agora com 50km/hora), como fica? Tarcisio Oliveira
O fluxograma não é consenso. Eu também não uso. Se a via é duplicada sem cruzamento em nível, é motorway. Se é duplicada com cruzamento em nível, é trunk. Fiquem à vontade para pensar diferente. Em 30 de setembro de 2015 22:03, Ivaldo Nunes de Magalhães < ivald...@gmail.com> escreveu: > Gente, na verdade o foco não era bem a tag maxspeed, mas é sempre bom > quando um tema é aprofundado. > > Mas minha dúvida se dá em relação à classificação da via, ou seja, se a > velocidade é preponderante, especificamente em função do critério > velocidade (= ou > que 80km/h) está contido no fluxograma de classificação > de vias (suponho que extensamente debatido pela "comunidade" BR) e está > disposto nesse endereço: > http://wiki.openstreetmap.org/w/images/1/12/Br-classification-flowchart-pt.png > . > > Nesse ponto, entendo que os atributos estruturais (nº de faixas, > duplicada, acostamento, canteiro central...) deveriam se sobrepor à > velocidade, mas o citado fluxograma dá a entender que a velocidade > deve/deveria ser considerado na classificação. > > Em suma: se tenho uma via com características estruturais de ser do tipo > expressa, mas com velocidade de 50km/h, como devo classificá-la? Óbvio que > sem considerar a velocidade, vais ser expressa mesmo, mas se for > considerado o contido no fluxograma, vai ser secundária ou terciária. > > Percebem como um elemento (velocidade) isolado muda bastante o > classificação? De modo que se a velocidade não for relevante, seria bom > alterar o fluxograma. Embora não o utilize por o achar "um rabo de pavão > muito enfeitado" (preferindo uma classificação própria já apresentada aqui > antes). > > > > > ___ > Talk-br mailing list > Talk-br@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-br > > -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Ponte Anita Garibaldi
Já consertei a relação. Alguém precisa passar pelo trecho com GPS (de preferência mais de uma vez) para marcar o trajeto novo. Do jeito que está agora, parece que não foi duplicado, o que eu acho estranho, mas não duvido. Alguém tem que confirmar in loco. Me lembro que haviam alguns desvios da última vez que passei lá, que devem ter mudado. Em 21 de julho de 2015 20:32, Helio Cesar Tomio hcto...@gmail.com escreveu: Colegas, Mapeador adicionou a nova ponte de Laguna / SC (Ponte Anita Garibaldi), mas não tomou o devido cuidado com as relações da BR 101(Rota Rodoviária Governador Mário Covas). Não sou entendedor do assunto a ponto de corrigir o problema. Será que alguém se habilitaria? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Classificação de rodovias no Brasil
Ivaldo, A tua idéia é boa. Eu só sugiro uma pequena modificação: A diferença entre motorway (auto-estrada) e trunk (via expressa), do modo que eu mapeio, é que a motorway não tem cruzamento em nível (uma rua ou retorno atravessando a rodovia) e a trunk tem. Isso faz bastante diferença na segurança da via. Fora isso, o teu esquema é coerente e está compatível com o que eu acredito que normalmente se faça. Bom trabalho! Em 14 de abril de 2015 19:41, Ivaldo Nunes de Magalhães ivald...@gmail.com escreveu: Olá wille, como está o DF? Veja, não é meu propósito opinar sobre qualquer padrão aqui, pois tem gente mais gabaritada para isso, mas meus dedos cóçam quando vejo algo que não entendo claramente e aí tenho que escrever. Eu ordenei mais ou menos por uma lógica crescente de importância, procurando inclusive seguir o OSM (os desenhosinhos que representam os tipos de vias, acho eles bem intuitivos), tendo como parâmetro: separação de vias, a quantidade de faixas e o acostamento. Não levei em conta o asfaltamento. Eu queria algo assim, mas simples e pratico. Acho que pode ser feito. Meu empolguei e fiz algumas alterações, incluindo as suas sugestões. Até que ficou bom. Acho que vou seguir esse. Auto estrada: - duplicada (canteiro central entre as mãos); - mínimo 2 faixas por sentido; - acostamento em ambos os lados do sentido; - exemplo: Rodovia Castelo Branco (SP-270). Via expressa: - duplicada (canteiro central ou algum tipo de obstáculo entre as mãos, não pode ser tartaruga); - mínimo 2 faixas por sentido; - acostamento em 1 dos lados do sentido (direito); - exemplo: Rodovia Raposo Tavares (SP-280). Via primária: - não duplicada (sem canteiro central entre as mãos); - 1 ou 2 faixas por sentido; - acostamento em 1 dos lados do sentido (direito); - exemplo: Rodovia BR-163/MS. Via secundária: - não duplicada (sem canteiro central entre as mãos); - 1 faixa por sentido; - sem acostamento (acostamento menor que 1 faixa e não cabe 1 carro); - exemplo: Rodovia MS-320. Via terciária: - não duplicada (sem canteiro central entre as mãos); - 1 faixa por sentido - sem acostamento e não asfaltada; - exemplo: Rodovia Benevenuto Ottoni/MS. Abraços Ivaldo Oi, IvaldoGostei muito desse seu resumo. Algumas correções: - Secundária não tem acostamento (ou, se tiver, é aquele acostamento que não cabe um carro e parte dele fica na faixa de rolamento). -Terciária não é pavimentada. Proponho que coloquemos esse esquema no wiki para complementar a página. abraços, wille On 11-04-2015 22:09, Ivaldo Nunes de Magalhães wrote: * Alexandre, obrigado pela indicação. Já tinha visto essa imagem. No meu ** entender ela é de difícil interpretação e análise para o ambiente de ** produção do OSM, que requer uma decisão rápida. ** Acho que deveríamos convertê-lo numa tabela mais enxuta e simples, tipo: ** Auto estrada: ** - canteiro central entre as mãos (duplicada); ** - mínimo 2 faixas por sentido; ** - acostamento em ambos os lados do sentido; ** - exemplo: Rodovia Castelo Branco (SP-270). ** Via expressa: ** - canteiro ou algum tipo de obstáculo central entre as mãos, não pode ** ser tartaruga (duplicada); ** - mínimo 2 faixas por sentido; ** - acostamento em 1 dos lados do sentido (direito); ** - exemplo: Rodovia Raposo Tavares (SP-280). ** Via primária: ** - Sem canteiro central entre as mãos (não duplicada); ** - mínimo 2 faixas por sentido; ** - acostamento em 1 dos lados do sentido (direito); ** - exemplo: Rodovia BR-267/MS. ** Via secundária: ** - Sem canteiro central entre as mãos (não duplicada); ** - mínimo 1 faixas por sentido; ** - acostamento em 1 dos lados do sentido (direito); ** - exemplo: Rodovia BR-158/MS. ** Via terciária: ** - Sem canteiro central entre as mãos (não duplicada); ** - mínimo 1 faixas por sentido; ** - sem acostamento; ** - exemplo: Rodovia BR-262/MS. ** Isso é um exemplo de uma classificação simples, mas clara. * *Ivaldo* ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Classificação de rodovias no Brasil
), sem se preocupar com detalhes físicos como largura, pistas, acostamento, pavimento ou falta dele, etc. [1] http://wiki.openstreetmap.org/wiki/Pt-br:How_to_map_a#Fluxograma_de_classifica.C3.A7.C3.A3o_.28esquema_br2013.29 [2] http://wiki.openstreetmap.org/w/index.php?title=Pt-br%3AHow_to_map_adiff=1129896oldid=1051591 [3] http://forum.openstreetmap.org/viewtopic.php?id=25892 [4] http://forum.openstreetmap.org/viewtopic.php?id=26067 [5] http://wiki.openstreetmap.org/wiki/User:Ftrebien/Drafts/Classifica%C3%A7%C3%A3o_de_vias_em_Porto_Alegre ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Marginal Tiete é autoestrada ? (Flavio Bello Fialho)
Sim, nesse caso colocam-se os dois tags. Por exemplo, tem caso em que a velocidade máxima para veículos leves é 110km/h, para ônibus é 100km/h e para caminhões é 90km/h. Nesse caso, colocam-se três tags: maxspeed=110 maxspeed:bus=100 maxspeed:hgv=90 Isso vale em qualquer via em que as velocidades são diferentes. Em 7 de março de 2015 04:34, belnu...@pop.com.br escreveu: Só para que eu possa entender melhor : - é mantida a velocidade máxima para veículos leves , que no caso é de 90 Km/h e é adicionada a etiqueta : maxspeed:hgv ? Isto se aplica a todas as vias ? A Marginal Tiete e a Marginal Pinheiros são motorway. A diferença entre motorway e trunk é que a motorway não tem cruzamentos em nível e a trunk sim. Ela também faz parte da rota BR-116 (é por ela que a BR-116 cruza a cidade de São Paulo). Quanto à velocidade, se puderes, por favor coloque o tag maxspeed nos trechos correspondentes. Em locais onde a velocidade é diferente para caminhões, use também maxspeed:hgv. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Marginal Tiete é autoestrada ?
A Marginal Tiete e a Marginal Pinheiros são motorway. A diferença entre motorway e trunk é que a motorway não tem cruzamentos em nível e a trunk sim. Ela também faz parte da rota BR-116 (é por ela que a BR-116 cruza a cidade de São Paulo). Quanto à velocidade, se puderes, por favor coloque o tag maxspeed nos trechos correspondentes. Em locais onde a velocidade é diferente para caminhões, use também maxspeed:hgv. Em 5 de março de 2015 10:52, belnu...@pop.com.br escreveu: 1. Re: Marginal Tiete é autoestrada ? (belnu...@pop.com.br) 2. Re: Marginal Tiete é autoestrada ? (Gerald Weber) 3. Re: Marginal Tiete é autoestrada ? (Nelson A. de Oliveira) Message: 1Date: Wed, 04 Mar 2015 10:21:59 -0300From: belnu...@pop.com.br To: talk-br@openstreetmap.orgSubject: Re: [Talk-br] Marginal Tiete é autoestrada ? naoliv : você fez duas criticas e nenhuma resposta . Se ela é uma auto-estrada ( auto-estrada faz ligações entre bairros ou zonas leste/oeste e sul/oeste ? ) , eu desfaço o que fiz de errado .- Message: 2Date: Wed, 4 Mar 2015 11:05:42 -0300 From: Gerald Weber gwebe...@gmail.comTo: OpenStreetMap no Brasil talk-br@openstreetmap.org Subject: Re: [Talk-br] Marginal Tiete é autoestrada ? Message-ID:CAKoZzo24= k+sja1cc23xmfoqc8ca2geuuh6h_iaf5-bu5vn...@mail.gmail.comContent-Type: text/plain; charset=utf-82015-03-02 20:36 GMT-03:00 belnu...@pop.com.br :A via expressa das marginais Tiete e Pinheiros estão classificadas como Autoestrada e tem como referência SP-015 e BR-116 ( https://www.openstreetmap.org/#map=17/-23.52882/-46.59551 ) . Isto está correto ? Faz tempo que não passo por São Paulo, mas até onde me recordo a classificação motorway faz bastante sentido. Semelhante ao Anel Rodoviário aqui de BH.A classificação motorway é um misto de formato (duplicada, acessosespeciais, não pode ser atravessada etc) e hierarquia de roteamento.É muito difícil, senão impossível, determinar uma classificação de rodovias somente por regras fixas (há tantos detalhes, exceções). Além disto é preciso que os mapeadores da região discutam e concordem numa classificação, especiamente quando as regras não podem ser 100% seguidas.Agora, considerando o tanto que o OSM-Brasil ainda é incompleto, minharecomendação é esta:*Se está pronto, não mexa. Procure fazer o que falta.*um grande abraço e bons mapeamentos Gerald Um anexo em HTML foi limpo...URL: http://lists.openstreetmap.org/pipermail/talk-br/attachments/20150304/7be42df9/attachment-0001.html -- Message: 3Date: Wed, 4 Mar 2015 11:21:00 -0300 From: Nelson A. de Oliveira nao...@gmail.comTo: OpenStreetMap no Brasil talk-br@openstreetmap.org Subject: Re: [Talk-br] Marginal Tiete é autoestrada ? Message-ID:CAARFvTW-MpeizTywSn6G9N_5Baa5jnL= ddlqnujqes3c16t...@mail.gmail.comContent-Type: text/plain; charset=ISO-8859-12015-03-04 10:21 GMT-03:00 belnu...@pop.com.br:naoliv : você fez duas criticas e nenhuma resposta . Se ela é uma auto-estrada ( auto-estrada faz ligações entre bairros ou zonas leste/oeste e sul/oeste ? ) , eu desfaço o que fiz de errado .Eu apenas disse que precisa conversar antes de modificar, independente do caso ou da pessoa.Não é uma alfinetada pessoal.Pela classificação geral do OSM a via é motorway:The tag highway=motorway is used to identify the highest-performanceroads within a territory. Typically, these controlled-access highwayshave a minimum of two lanes in each direction that are separated by abarrier.Pela nossa classificação também encaixa (possui separação entre os dois sentidos, sem obstrução, sem semáforo, sem cruzamentos em nível,asfaltada, com várias faixas, 90 Km/h, etc). A via é, no fundo, uma rodovia com uma cidade ao redor. Eu manteria motorway.Talvez o vgeorge pode informar/confirmar melhor sobre a via.-- Pra mim como usuário as duas se encaixariam como vias expressas , principalmente a marginal Pinheiros , que tem trechos com velocidade de 60 Km e ao longo tem duas velocidades máximas permitidas : a de 90 Km ( para veículos leves ) e de 70 Km ( para veículos pesados ) , mas vou desfazer aquilo que fiz de errado , voltando a etiqueta de Autoestrada . ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] BR-116 split and cleanup
Reorganizei a divisão da BR-116 por região, em três partes: Nordeste (CE, PB, BA), Sudeste (MG, RJ, SP) e Sul (PR, SC, RS), para facilitar a edição dentro de cada estado. Corrigi também os links no Wiki, de forma que eles não estão mais quebrados. Se algum lugar ainda estiver com os links antigos, as relações novas são 4551466, 4551468 e 4551469, respectivamente. A página com a lista das rodovias federais agora mostra a BR-116 dividida em três: https://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Rodovias_Federais Pretendo fazer o mesmo com a BR-101, que é a outra rodovia problemática, atualmente com 3134 segmentos. Em 13 de fevereiro de 2015 00:21, Lists li...@gimnechiske.org escreveu: Tem uns 2 ou 3 rodovias mais que teoricamente pode ser divido similares, mas estes passa principalmente nas areas com pouco mapeamento, e assim as trechos mais logos e menus atividade. Aun Johnsen On Feb 12, 2015, at 23:13, Flavio Bello Fialho bello.fla...@gmail.com wrote: Entendo que o histórico estava muito longo e que a rodovia tem muitos segmentos. Entretanto, dividir a rodovia em relações pequenas prejudica o controle. Quando eu vejo que uma rodovia ficou descontínua, eu baixo a rodovia no JOSM e conserto o que ficou errado. Geralmente, aproveito para corrigir a rodovia no trecho afetado, detalhando os cruzamentos e colocando as restrições de conversão, de forma que a rodovia fique correta e o usuário não precise mexer de novo. Assim, é bom que os trechos sejam longos, pois eu verifico uma grande extensão numa tacada só. Se for para dividir, proponho que seja dividido por região (Sul, Sudeste, Nordeste, Norte e Centro-Oeste). Assim, a BR-116 ficaria dividida em 3 relações (NE, SE e S) e fica mais fácil para as equipes de cada estado trabalharem. Dessa forma, quando eu verificasse a integridade da BR-116, já o faria em 3 estados (RS, SC e PR). Até agora, as únicas rodovias realmente grandes (em número de segmentos) são a BR-116 e a BR-101. 2015-02-12 22:48 GMT-02:00 Nelson A. de Oliveira nao...@gmail.com: A separação que o Paul fez foi emergencial (para remover alguns dados do OSM). Foi caso isolado. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Prioridades em rodovias com mais de uma ref=
Bom, se existe a possibilidade de uma BR-XXX ter um trajeto diferente de uma RSC-XXX então é essencial que nos trechos em que de fato coincidam tenhamos ambos as referências no trecho. Por favor, me mostre um caso em que isso ocorre. Veja as mensagens anteriores. Este é o argumento do Claiton, eu mesmo não conheço nenhum caso. Mas não vou ficar surpreso se isto existir. Se existir, eu mesmo mudo todas as RSC para RSC;BR. Não existe. Ter ambas as referências não polui o mapa, e eu como usuário, acho extremamente útil. Se todas as RSC coincidem com BR, é completamente inútil De modo algum. Você está esquecendo que *nós aqui da lista* conhecemos esses códigos de rodovia e sabemos o que significa. Já o usuário comum não tem obrigação de saber que RSC-XXX e BR-XXX são a mesma coisa, então para o usuário comum esta informação é valiosa. Não estou convencido de que isso não é redundante (por favor me convença, me mostrando um contra-exemplo). Considere o exemplo de um turista estrangeiro que tem como endereço uma pousada na BR-262 em Sabará. Mas a única coisa que ele encontra é a MGC-262. E agora? Para complicar ainda existe a MG-262 na região (que nada tem a ver com a BR-262/MGC-262). Eu quis dizer um contra-exemplo onde uma RSC não segue o trajeto planejado de uma BR. Hoje (se ninguém apagar) ele vai encontrar isto no OSM: http://www.openstreetmap.org/#map=15/-19.8747/-43.8459 a BR-262 marcada junto com a MGC-262, aí vai entender de que se trata da mesma rodovia. Pronto, problema resolvido e a informação redundante teve sua utilidade. Antes de conhecer esses códigos de rodovia eu já passei por situação semelhante, por isto eu sei que este exemplo é válido. Nas placas em Sabará aparece ora MGC-262 ora BR-262, mas a população local so fala na BR (vamos alí na BR). Ninguém vai passar um endereço na MGC-262, todo mundo só fala na BR-262. O tag ref é para informações oficiais. O tag para nomes alternativos pelos quais a população local conhece uma via é alt_name, loc_name ou reg_name, dependendo do caso. Existe ainda a possibilidade de nat_ref, reg_ref ou loc_ref. Se a preocupação é essa, talvez esse caso possa ter dois tags: ref=MGC-262 e nat_ref=BR-262. Se for possível, é melhor evitar valores múltiplos para o mesmo tag. No Rio Grande do Sul (onde estou mapeando e organizando as relações de todas as rodovias), vou colocar apenas RSC no tag ref. Seria bom que se usasse o mesmo padrão em todo o país, mas se a comunidade de Minas Gerais decidir fazer diferente, fiquem à vontade. -- Flávio Bello Fialho ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Prioridades em rodovias com mais de uma ref=
Eu uso sempre a informação do Ministério dos Transportes e do DAER-RS. Para mim, vale o que está lá. A BR-287/RSC-287 está assim (nos dois lugares): RSC-287: km 0 a 21,49 BR-287: km 21,49 a 28,03 RSC-287: km 28,03 a 232,54 BR-287: km 232,54 a 536,11 Os códigos das rodovias são excludentes, em cada trecho. Ou é BR ou é RSC. É redundante colocar os dois códigos, pois TODAS as RSC (antigas RST) pertence ao trajeto planejado da BR. Não se perde informação alguma deixando o código da BR fora dos trechos da RSC, e o mapa fica mais limpo. Sempre que eu vejo uma RSC, eu sei que ela faz parte do trajeto planejado de uma BR. Caso contrário, seria ERS ou VRS. O termo coincidente, apesar de ser a denominação oficial, pode estar causando confusão. Coincidente mesmo é, por exemplo, o trecho (da BR-287) entre os km 115,70 e 158,16, em que a RSC-287 coincide com os km 326,32 a 368,78 da BR-153 (ou, nesse caso, RSC-153). Nesse trecho o tag correto deve ser ref=RSC-153;RSC-287. Ficaria inconveniente etiquetar esse trecho como ref=BR-153;BR-287;RSC-153;RSC-287. O tag ref vai em dois lugares: 1. Na relação, em que o tag ref=BR-287 aparece uma única vez e vale para toda a relação. 2. Nos trechos da relação, em que cada trecho pode ser ref=BR-287 ou RSC-287 (ou ref=RSC-153;RSC-287, ref=BR-287;BR-386, etc.). Quanto à relação para a RSC-287, acho desnecessária, uma vez que ela seria um subconjunto da BR-287. Se eu encontrar alguma relação desse tipo, irei deixá-la quieta. Em 13 de fevereiro de 2015 13:54, Gerald Weber gwebe...@gmail.com escreveu: 2015-02-13 13:09 GMT-02:00 Claiton Neisse claiton.nei...@gmail.com: Enfim, minha proposta é: - As rodovias RSC-XXX que foram construídas sobre diretrizes de rodovias federais planejadas terem as suas próprias relações; - RSC-XXX deve constar na primeira posição, seguido de BR-XXX, na tag ref dos trechos coincidentes; - A denominação da BR-XXX, caso possua, não deve constar nos trechos coincidentes nem na relação da RSC-XXX. Com o devido respeito, estou tendo problemas com raciocínio empregado no seu argumento. O que exatamente você entende por coincidentes? Para mim, quando alguém diz que o feriado coincide com um domingo, significa que é feriado e domingo, ambas as coisas. Não deixa de ser domingo por ser feriado. No seu argumento dá a entender que quando for coincidente, então não se usa ambos os códigos. Lamento, mas não entendi isto. Se a rodovia é coincidente (ou seja se são ambas as coisas) porque não devo colocar ambas as referências? No meu entendimento, RSC-XXX deve constar quando for de administração estadual, e somente se a administração faz mesmo esta distinção. Já BR-XXX deve, na minha opinião, constar *sempre*, sendo de administração estadual ou não, em adição a RSC-XXX. Em particular, não vejo que mal faz em relacionar ambos os códigos. É importante, por outro lado, não começar a inventar códigos RSC-XXX se a própria administração estadual não as emprega. Em Minas tem várias BRs que não tem um código MGC, mesmo sendo de administração estadual. Agora se você quiser se dar ao trabalho em construir duas relações separadas, uma para RSC-XXX e oura BR-XXX, não vejo problema algum nisto, muito embora manter estas relações de rota tenha se tornado uma tarefa bastante ingrata. um grande abraço Gerald ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Prioridades em rodovias com mais de uma ref=
Bom, se existe a possibilidade de uma BR-XXX ter um trajeto diferente de uma RSC-XXX então é essencial que nos trechos em que de fato coincidam tenhamos ambos as referências no trecho. Por favor, me mostre um caso em que isso ocorre. Depois da discussão anterior fica assim para mim ref=RSC-XXX;BR-XXX significa que RSC-XXX segue o mesmo trajeto de BR-XXX ref=RSC-XXX (somente) significa que a RSC-XXX segue um trajeto mas a BR-XXX segue outro. Ter ambas as referências não polui o mapa, e eu como usuário, acho extremamente útil. Se todas as RSC coincidem com BR, é completamente inútil Além do mais omitir informação para deixar o mapa mais limpo não é o procedimento adequado, é etiquetar para o renderizador. O renderizador é que decide se mostra uma, duas ou mais referências. Não estou omitindo informação alguma, a menos que exista uma BR-XXX ter um trajeto diferente de uma RSC-XXX. Peço enfaticamente que me mostre um caso em que isso ocorre na prática (qual trecho de qual rodovia?). O termo coincidente, apesar de ser a denominação oficial, pode estar causando confusão. Coincidente mesmo é, por exemplo, o trecho (da BR-287) entre os km 115,70 e 158,16, em que a RSC-287 coincide com os km 326,32 a 368,78 da BR-153 (ou, nesse caso, RSC-153). Nesse trecho o tag correto deve ser ref=RSC-153;RSC-287. Não. O significado é este mesmo, veja aqui http://www.der.mg.gov.br/saiba-sobre/rede-rodoviaria/652-rodovias-estaduais-coincidentes Rodovia Coincidente, levando um C adicional no código, como MGC ou RSC. A BR-040 e a BR-262 coincidem em certos trechos no anel rodoviário de BH, mas não estão relacionadas como rodovias coincidentes. É o que eu estou dizendo. Esses trechos da BR-040 e a BR-262 são rodovias que coincidem, mas não são coincidentes. Ficaria inconveniente etiquetar esse trecho como ref=BR-153;BR-287;RSC-153;RSC-287. É o que temos feito e não vejo problema algum nisto. Não estou convencido de que isso não é redundante (por favor me convença, me mostrando um contra-exemplo). abraço Gerald -- Flávio Bello Fialho ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] erros x relações
list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Prioridades em rodovias com mais de uma ref=
, Uma dúvida me veio à cabeça. Em rodovias que se sobrepõem, qual a ref= que vem antes? Tenho utilizado por padrão, em casos de rodovias de redes (network=) diferentes, a rodovia nacional primeiro, mas não tenho certeza se é o mais correto a se fazer. Abraços! -- Vítor Rodrigo Dias Revisor de textos Tradutor port/ing/port e port/esp/port Telefone: (31) 7360-9421 - TIM ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Prioridades em rodovias com mais de uma ref=
Não sei como é em Minas. No RS, a BR-287 tem trechos em que é federal (BR-287) e trechos em que é estadual (RSC-287), mas nunca ambos. Na relação, fica o tag ref=BR-287, mas no trecho, o tag é ref=RSC-287 ou ref=BR-287 (mas não os dois). Em 12 de fevereiro de 2015 22:01, Gerald Weber gwebe...@gmail.com escreveu: Quanto à ordem no tag ref, se não há placa, eu faço o que o Aun sugeriu (primeiro BR, em ordem numérica, depois RSC, em ordem numérica, depois ERS, em ordem numérica, depois VRS, em ordem numérica). Lembro que BR e RSC com o mesmo número no mesmo trecho são excludentes, ou seja, ou vai um ou vai outro no tag ref. Se houver placa, o ref da placa vai primeiro. Você pode por ambas no ref, separados por ponto-e-vírgula ref=BR-262;MGC-262 eu acho bastante útil como usuário do mapa abraço Gerald ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] BR-116 split and cleanup
Entendo que o histórico estava muito longo e que a rodovia tem muitos segmentos. Entretanto, dividir a rodovia em relações pequenas prejudica o controle. Quando eu vejo que uma rodovia ficou descontínua, eu baixo a rodovia no JOSM e conserto o que ficou errado. Geralmente, aproveito para corrigir a rodovia no trecho afetado, detalhando os cruzamentos e colocando as restrições de conversão, de forma que a rodovia fique correta e o usuário não precise mexer de novo. Assim, é bom que os trechos sejam longos, pois eu verifico uma grande extensão numa tacada só. Se for para dividir, proponho que seja dividido por região (Sul, Sudeste, Nordeste, Norte e Centro-Oeste). Assim, a BR-116 ficaria dividida em 3 relações (NE, SE e S) e fica mais fácil para as equipes de cada estado trabalharem. Dessa forma, quando eu verificasse a integridade da BR-116, já o faria em 3 estados (RS, SC e PR). Até agora, as únicas rodovias realmente grandes (em número de segmentos) são a BR-116 e a BR-101. 2015-02-12 22:48 GMT-02:00 Nelson A. de Oliveira nao...@gmail.com: A separação que o Paul fez foi emergencial (para remover alguns dados do OSM). Foi caso isolado. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] BR-116 split and cleanup
Não concordo com essa quebra da BR-116. Eu uso a relação para testar a integridade das rodovias e isso me atrapalhou bastante. Não consigo mais checar a BR-116, cuja relação eu vinha mantendo intacta. Antes de fazer algo desse tipo, devemos ter uma discussão adequada para decidir se deve ou não ser feito, aviso de que isso será feito (na lista, no fórum e no wiki) e tempo suficiente para que todos se manifestem. As rodovias federais do Rio Grande do Sul estão listadas em http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/RS/Rodovias_Federais (testo elas regularmente) e a lista de todas as rodovias federais está em http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Rodovias_Federais . Com a alteração, os links para a BR-116 não estão mais funcionando. Em 2 de fevereiro de 2015 10:28, Nelson A. de Oliveira nao...@gmail.com escreveu: Como o problema de relações de rota não está relacionado com o DWG não é preciso incluí-los (DWG e Paul) nas respostas. Também não há necessidade de continuar a discussão em inglês (já que é a comunidade brasileira que deve decidir qual a melhor forma de manter as relações). O Paul gentilmente avisou sobre a divisão de uma rota apenas porque foi necessário quebrá-la para facilitar algumas reversões e remoções de objetos. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Opinião: motorways e cruzamentos em nível
Gerald, Não se trata de retorno em nível. Concordo contigo: um retorno em nível, em que há uma pista para desaceleração do lado esquerdo, seguida pelo retorno e por uma pista de aceleração do lado esquerdo oposto (as pistas de desaceleração e aceleração são adjacentes à divisão central) não é cruzamento, e é perfeitamente aceitável em motorway. O caso é outro: há uma pista para desaceleração do lado esquerdo, uma placa de PARE, fazendo o veículo parar no meio da pista e esperar que não haja transito em nenhuma pista em sentido contrário, o veículo atravessa completamente a via em sentido oposto, entra numa via auxiliar que coloca ele no sentido oposto ao que ele vinha e depois há uma pista de aceleração do lado DIREITO da via. Isso ocorre (talvez) porque a divisória central é estreita e não comporta um retorno direto. A diferença fundamental é que no primeiro caso não se atravessa a via e no segundo sim. O primeiro caso é compatível com motorway. O segundo não. Em 9 de julho de 2014 19:28, Gerald Weber gwebe...@gmail.com escreveu: Já deixei minha opinião. Retorno em nível não é cruzamento. Se for usar isto como critério então nenhuma rodovia pode ser motorway já que em princípio você pode cruzá-la em qualquer ponto simplesmente mudando de uma faixa para outra. abraço Gerald 2014-07-09 16:06 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Pessoal, Sugeriram que algumas vias que se encaixam no critério pra motorway (seguindo o esquema no wiki) não são motorway quando é possível atravessá-las (fazer o retorno) em nível (ou seja, sem viadutos/trincheiras) em vários pontos. Se vocês concordam/discordam, deixem uma opinião lá no fórum. Se muita gente concordar, isso tem que ir pras recomendações de classificação. [1] http://forum.openstreetmap.org/viewtopic.php?pid=435567#p435567 -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Opiniões sobre reclassificação
O que eu fiz foi reverter para o estado em que a rodovia estava quando foi criada e da forma como ficou durante 3 anos. Se alguém modificou a rodovia arbitrariamente, foi o Fernando. A classificação atual da rodovia (trunk) está de acordo com o histograma que ele mesmo propôs, bem como com a definição do wiki. Pelo fluxograma, uma rodovia com intersecções (que a rodovia em questão tem muitas), deve ser trunk, que é a forma como a rodovia sempre esteve classificada. Uma motorway é a Freeway (BR-290) ou a BR-116 próxima a Porto Alegre. Fernando, eu não quero brigar contigo. Acho que esse tipo de coisa não leva a nada. Eu estou há tempo mapeando a Serra Gaúcha assim como tu estás mapeando Porto Alegre. Não gostei da forma como ficou Porto Alegre, mas não mexi justamente para não acontecer esse tipo de coisa. Aliás, deixei de contribuir em Porto Alegre para evitar conflitos. Por favor, deixe a classificação do jeito que sempre esteve e vamos nos concentrar em coisas mais produtivas. Em 11 de julho de 2014 14:53, Fernando Trebien fernando.treb...@gmail.com escreveu: Bem, se ninguém se manifesta, vou dar a minha opinião. Devemos reverter. Motivo: ignorando a recomendação com a qual concordamos há 1 ano, claramente pra ele tanto faz o que pensamos. Uma alteração no mapa num momento de uma controvérsia central pra comunidade só serve pra colocar mais lenha na fogueira e não para nos ajudar a chegar a um consenso. Não serve nem para ilustrar o ponto que ele defende. Se deixarmos isso assim, vamos ter que aceitar mais casos de contestações impopulares seguidas de edições diretas nos dados. E se for assim, vai ser praticamente impossível alguém fazer QA no OSM. 2014-07-11 12:50 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Pessoal, Estamos no meio de um debate sobre classificação sobre motorways, trunks e primárias [1], sem consenso , e um dos participantes do debate, o Flavio Bello Fialho (fbello), decidiu alterar a classificação de algumas das vias debatidas [2][3][4], deixando-as em desacordo com a classificação recomendada pela comunidade [5] que já discutimos muito. O Flavio não forneceu uma explicação para a alteração, nem usando a etiqueta note nos elementos, nem na descrição dos changesets (que aliás acho muito vaga). Particularmente no RS temos 5 opiniões manifestas sobre as vias afetadas a favor ou parcialmente a favor da classificação anterior (eu, Augusto, naoliv, Gerald, PauloCarvalho) e apenas 2 a favor da nova (fbello e Linhares). [2] O que vocês acham que devemos fazer? Reverter para o estado anterior (deixando em acordo com a recomendação da comunidade) até que se chegue a um consenso? Deixar assim? [1] http://forum.openstreetmap.org/viewtopic.php?id=26233 [2] http://forum.openstreetmap.org/viewtopic.php?id=26067 [3] http://www.openstreetmap.org/changeset/24071613 [4] http://www.openstreetmap.org/changeset/24074004 [5] http://wiki.openstreetmap.org/wiki/Pt-br:How_to_map_a -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] highway=primary e highway=secondary no contexto de uma cidade pequeno do interior
Use o bom senso. Em 26/04/2014 21:00, Alexandre Magno Brito de Medeiros alexandre@gmail.com escreveu: Olá! Segundo interpreto do diagrama, quando uma BR ou Estadual corta a cidade pequena do interior, sem canteiros e acostamentos, ela é como uma arterial e deve ser highway=primary. Por outro lado, ainda fora da cidade, se ela não tem acostamento e a velocidade pode ser maior ou igual a 80 Km/h, ela deve ser highway=secondary. Mas aí... a renderização fica estranha, não é?! Pois fica vermelha dentro da cidade e laranja fora. O que dizem? Alexandre Magno ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Relação BR-101
Eu acho melhor deixar uma só relação para a rodovia inteira. Assim, se algum problema ocorre, a chance dele ser detectado é maior. Em 25/04/2014 00:00, Raffaello Bruno Limongi Freire raffaellobr...@hotmail.com escreveu: Johnsen, eu ainda não entendo de relações, mas acho que essa hierarquia que você propõe facilitará a correção no caso de alguém quebrar essa relação novamente. Raffaello Bruno -- From: li...@gimnechiske.org Date: Thu, 24 Apr 2014 23:02:38 -0300 To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Relação BR-101 Raffaello, Fui mesmo, veja https://www.openstreetmap.org/relation/53556 O fixme dizendo que tinha problemas perto do Paraty, mas agora e vazio mesmo Tem tempo eu pensei em dividir BR-101 em um relação por estado juntado num master-relation, talvez um solução assim pode reduce o risco este acontecer denovo? Aun Johnsen On Apr 24, 2014, at 22:54, Raffaello Bruno Limongi Freire raffaellobr...@hotmail.com wrote: Oi, alguém poderia por favor verificar se eu fiz alguma besteira com o changeset https://www.openstreetmap.org/changeset/21920550 , pois, na hora do upload pelo JOSM, apareceu o aviso Relation is empty route (BR-101, 0 members)? Aparentemente eu quebrei a relação BR-101... Obrigado. Raffaello Bruno ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Relação BR-101
Se dividirmos e um problema acontecer num segmento pouco monitorado, ele pode persistir por muito tempo. Deixando uma relação única, qualquer problema é detectado mais rápido (mais gente monitorando) e a reversão tende a ser mais imediata. Eu revisei toda a BR-101 há alguns meses atrás, e isso fica mais fácil se for uma só relação. Quanto à operadora, prefiriria que essa informação não ficasse na relação, e sim nos segmentos. Por falar em BRs, precisaríamos mapear as que estão faltando. Em 25/04/2014 08:52, Lists li...@gimnechiske.org escreveu: Aun Johnsen On Apr 25, 2014, at 8:25, John Packer john.pack...@gmail.com wrote: Aun, Tu sabes se tem algum lugar onde podemos ver uma lista de operadores e onde eles começam/terminam? Se isto depender de coleta de dados pessoalmente, acredito que vai inviabilizar este critério. Outra coisa, como você adicionou o twitter da operadora? operator:twitter=* ou algo assim? Se nao me engano, eu usei twitter=* ou contact:twitter=* Eu credito que DER tem um lista oficial com operadores, não sei se e no site DER federal ou no DER do cada estado. Eu preciso investigar este, se não algum outro quer fazer. Infelizmente não vai ter tempo este semana ou semana que vem, mas vou dar um olhada depois. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Mapear bairros como área.
Eu uso os objetos existentes, se possível. Vários limites de município são rios. Na minha opinião, temos que mapear da forma correta sempre. Se o limite é o rio, o rio é o limite. Em 04/04/2014 16:40, Paulo Carvalho paulo.r.m.carva...@gmail.com escreveu: O que é o recomendado fazer? Utilizar objetos existentes ou criar um polígono novo? Em 4 de abril de 2014 16:28, Arlindo Pereira openstreet...@arlindopereira.com escreveu: E a desvantagem é que usuários que editarem alguma dessas ruas utilizando editores que não suportem relações corretamente, irá quebrar a relação do bairro. []s Arlindo 2014-04-04 16:26 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Uma vantagem de você usar um objeto existente como limite é que se ele mudar de posição por alguma razão, o limite muda junto. Se mantiver em objetos diferentes, tem que lembrar de editar dois (talvez mais) objetos. Em 4 de abril de 2014 16:19, Lists li...@gimnechiske.org escreveu: Hmmm, Tudos os limites administrativo no Espírito Santo e importado do IBGE, não procurei os leis defini-los, mas olhando vejo que muitos passa nos estradas/ruas ou rios/córregos/canais. Talvez em futuro pode fazer um “limpeza”. Ja fiz no algumas pontos onde e bem evidente que o limite passando no uma rio, mas não fiz onde passando nos estradas. Aun Johnsen On Apr 4, 2014, at 15:53, Paulo Carvalho paulo.r.m.carva...@gmail.com wrote: Hmmm... Interessante e inteligente isso. Você definiu um bairro usando rios e ruas como limites, tal como nas leis municipais que os definem. [ ]s Paulo Em 4 de abril de 2014 10:08, Bráulio brauliobeze...@gmail.comescreveu: Exemplo: Pitimbu: http://www.openstreetmap.org/relation/388146 Procurando por uma rua de dentro do bairro, o nominatim retorna assim: Via Terciária Avenida dos Pintassilgos, Pitimbu, Natal, RN, Northeast Region, 59067-530, Brasil 2014-04-04 9:47 GMT-03:00 Lists li...@gimnechiske.org: boundary=administrative + admin_level=10 + name=* no um relação Aun Johnsen On Apr 4, 2014, at 9:36, Paulo Carvalho paulo.r.m.carva...@gmail.com wrote: Pessoal, Gostaria de saber como se faz para mapear bairros de forma que as buscas no nomitatim, etc. funcionem bem. Achei algo no fórum, mas não encontrei uma resposta objetiva (tinha muita filosofia). Acho que deve haver uma resposta objetiva que não encontrei. [ ]s Paulo ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Mapear bairros como área.
O limite dos bairros pode ser um dos lados da rua e não a rua em si. Nesse caso, deve ser traçado outra linha. Se a divisa for a própria rua, então use-a. Sempre use relações para limites administrativos. Em 06/04/2014 19:32, Paulo Carvalho paulo.r.m.carva...@gmail.com escreveu: Obrigado pelas dicas. A colocação dos polígonos deve aumentar a precisão do Nominatim, além de permitir a inclusão do bairro na indexação no Garmin. Já incluí esta funcionalidade no kit de compilação, mas só funciona se o bairro estiver como polígono. []s Paulo Em 6 de abril de 2014 19:26, Blademir Andrade de Lima blademi...@hotmail.com escreveu: Após aprender a trabalhar com relações, trabalhei em alguns municípios que se dividem por rios, mas por bairros é mais complicado, nem sempre uma rua divide um bairro. Ja até consegui alguns dados do Plano Diretor de minha cidade, mas descobri que o mesmo tinha falhas e não era confiável. Tive que deixar minha cidade sem bairros definidos. Só tome cuidado ao usar ruas para dividir bairros, as vezes os dois lados da rua fazem parte do bairro, o limite esta no final dos lotes casas de algum dos lados. Qualquer problema adiciona a TAG addr:suburb do bairro na Rua. Att, BladeTC -- Date: Sun, 6 Apr 2014 19:01:58 -0300 From: paulo.r.m.carva...@gmail.com To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Mapear bairros como área. Obrigado. Em 6 de abril de 2014 07:34, Flavio Bello Fialho bello.fla...@gmail.comescreveu: Eu uso os objetos existentes, se possível. Vários limites de município são rios. Na minha opinião, temos que mapear da forma correta sempre. Se o limite é o rio, o rio é o limite. Em 04/04/2014 16:40, Paulo Carvalho paulo.r.m.carva...@gmail.com escreveu: O que é o recomendado fazer? Utilizar objetos existentes ou criar um polígono novo? Em 4 de abril de 2014 16:28, Arlindo Pereira openstreet...@arlindopereira.com escreveu: E a desvantagem é que usuários que editarem alguma dessas ruas utilizando editores que não suportem relações corretamente, irá quebrar a relação do bairro. []s Arlindo 2014-04-04 16:26 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Uma vantagem de você usar um objeto existente como limite é que se ele mudar de posição por alguma razão, o limite muda junto. Se mantiver em objetos diferentes, tem que lembrar de editar dois (talvez mais) objetos. Em 4 de abril de 2014 16:19, Lists li...@gimnechiske.org escreveu: Hmmm, Tudos os limites administrativo no Espírito Santo e importado do IBGE, não procurei os leis defini-los, mas olhando vejo que muitos passa nos estradas/ruas ou rios/córregos/canais. Talvez em futuro pode fazer um “limpeza”. Ja fiz no algumas pontos onde e bem evidente que o limite passando no uma rio, mas não fiz onde passando nos estradas. Aun Johnsen On Apr 4, 2014, at 15:53, Paulo Carvalho paulo.r.m.carva...@gmail.com wrote: Hmmm... Interessante e inteligente isso. Você definiu um bairro usando rios e ruas como limites, tal como nas leis municipais que os definem. [ ]s Paulo Em 4 de abril de 2014 10:08, Bráulio brauliobeze...@gmail.com escreveu: Exemplo: Pitimbu: http://www.openstreetmap.org/relation/388146 Procurando por uma rua de dentro do bairro, o nominatim retorna assim: Via Terciária Avenida dos Pintassilgos, Pitimbu, Natal, RN, Northeast Region, 59067-530, Brasil 2014-04-04 9:47 GMT-03:00 Lists li...@gimnechiske.org: boundary=administrative + admin_level=10 + name=* no um relação Aun Johnsen On Apr 4, 2014, at 9:36, Paulo Carvalho paulo.r.m.carva...@gmail.com wrote: Pessoal, Gostaria de saber como se faz para mapear bairros de forma que as buscas no nomitatim, etc. funcionem bem. Achei algo no fórum, mas não encontrei uma resposta objetiva (tinha muita filosofia). Acho que deve haver uma resposta objetiva que não encontrei. [ ]s Paulo ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo
Re: [Talk-br] Lixo na base
Não concordo com correções automáticas. O que pode ser feito é adicionar um tag fixme aos caminhos com nome suspeito, de forma a facilitar uma busca simples com o JOSM e permitir correções manuais (se o fixme já existe, adicionar o texto ao final do existente). Se o none da rua está errado, ele deve ser revisto manualmente de qualquer forma. Em 25/03/2014 02:35, Erick de Oliveira Leal erickdeoliveiral...@gmail.com escreveu: Carlos, aproveita e deixa como vc fez... Em 25 de março de 2014 01:42, Erick de Oliveira Leal erickdeoliveiral...@gmail.com escreveu: Muito bom, Carlos. Em 25 de março de 2014 01:36, A. Carlos anorcar...@hotmail.comescreveu: Voltando a sujeira no mapa. O site espanhol que tem compilação diária, tem la um link com os erro gerados em cada mapa BR fica em http://mapas.alternativaslibres.es/errors_Brazil.zip A lista é separada ali e grande,como ele geram isso com erro, provavelmente não entra no mapa abrindo ele, é como catar uma agulha no palheiro. Alguém conhece uma ferramenta que possa ler estes erro e mostrar na tela ? *___* *Anor C. A. de Souza Co* *ncórdia SC * 49-8808-4963 -- Date: Tue, 25 Mar 2014 01:30:35 -0300 From: erickdeoliveiral...@gmail.com To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Lixo na base Opa que bom então. Valeu Nelson e Roger Em 25/03/2014 00:32, Roger C. Soares rogersoa...@gmail.com escreveu: O overpass-turbo que o Nelson mandou realmente é muito bom. A busca por highway+name com ? no Brasil todo foi bem mais rápida do que eu esperava. Tinham poucos casos então já removi. Atenciosamente, Roger. -- Em 24-03-2014 15:43, Fernando Trebien escreveu: 2014-03-24 15:33 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Erros onde o nome só contém caracteres do tipo ? eu tenho certeza q sim... rsrsrs. Heh, ok, este caso em particular poderia ser considerado um erro. Mas daí não vale à pena o esforço de fazer um validador para um caso que acontece só umas poucas vezes né. Melhor fazer um script que liste os IDs objetos e depois nos permita editá-los manualmente, como você disse. (Precisamos de scripts assim pra muitas outras coisas parecidas.) Mas ainda seria mais interessante um script que nos desse os ids dos objetos com erros e fizessemos uma força tarefa para corrigi-los. Mas acho que os erros do tipo sem logradouro são muitos, então esses teriam que ser postergados. Agora só corrigiriamos esses casos estranhos mesmo. Mas tem algum jeito de encontrar isso fácil? Em 24 de março de 2014 15:22, Fernando Trebien fernando.treb...@gmail.com escreveu: Erros são matemáticos. Você tem certeza absoluta de que todos esses casos, sem exceção, presente ou futura, constituem erros? On Mar 24, 2014 2:29 PM, thunder...@gpsinfo.com.br wrote: Os erros existentes são fatos e requerem correção. Na minha opinião correção automática até porque são tantos que uma correção manual, com poucos colaboradores, exigiria muito esforço e tempo. Corrigiríamos os existentes, mas como evitar que novos surjam? Continuo defendendo a função VALIDADOR (como erro e não aviso) quando da edição. Pelo menos por meio dele novos erros desse tipo não devem voltar a ocorrer. []s Marcio *From:* Fernando Trebien fernando.treb...@gmail.com *Sent:* Monday, March 24, 2014 1:52 PM *To:* OpenStreetMap no Brasil talk-br@openstreetmap.org *Subject:* Re: [Talk-br] Lixo na base Mas vocês querem fazer isso para todo o Brasil de forma automática ou deixar para cada um na sua cidade fazer? Nem 1% das cidades brasileiras tem representantes aqui na lista. 2014-03-24 13:23 GMT-03:00 John Packer john.pack...@gmail.com: Dá para utilizar regex no overpass para obter ruas que não iniciem com Rua|Avenida|etc Esses dias eu corrigi via JOSM as ruas que não tinham nenhum prefixo na minha cidade. O filtro que eu utilizei era algo estilo: possui as etiquetas `highway` e `name` e não pode começar com: Rua, Avenida, Servidão, Ponte, Estrada. E talvez precise de Beco (mas não foi o caso na minha cidade). Creio que seja seguro adicionar o prefixo Rua quando for verificado que não tem nenhum prefixo em uma rua. 2014-03-24 13:06 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: Dá para utilizar regex no overpass para obter ruas que não iniciem com Rua|Avenida|etc ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of
Re: [Talk-br] Traçar linhas com tag definidas
Erick, Podes traçar as linhas sem tags, depois selecionar todas e colocar o tag em todas ao mesmo tempo. Em 24/03/2014 23:39, Erick de Oliveira Leal erickdeoliveiral...@gmail.com escreveu: É possível no JOSM você ir traçando uma linha e ela já vir preenchida com highway=residential? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Pergunta rápida sobre pontos de ônibus
Eu prefiro não inventar nomes. Temos muito trabalho não polêmico a fazer e sugiro que nos concentremos nesse trabalho, por enquanto. Por exemplo, há muitas e muitas ruas e estradas que não estão sequer traçadas. Em 20/03/2014 18:30, Fernando Trebien fernando.treb...@gmail.com escreveu: Bem, eu concordo plenamente. Só pra esclarecer, não quero que entendam vamos fazer desse jeito. Nem que este é o jeito certo. A idéia era só ver se mais alguém considerava interessante. 2014-03-20 17:53 GMT-03:00 Márcio Vinícius Pinheiro marcioviniciu...@gmail.com: Entendi o seu ponto sobre as conexões inventadas, entendo isso como um problema de mapeamento, não apenas de aplicativos. Nesse caso, não há (ainda) como inserir a informação de retorno proíbido e isso é um problema de mapeamento. A incapacidade dos aplicativos de reconhecer ou não esse retorno é uma consequência. A solução encontrada, por enquanto, é a conexação inventada (que o tutorial resalta como tendo que ser de deometria o mais próximo do real possível) e isso resolve provisória e precariamente o problema de mapeamento e por consequência o problema de interpretação do aplicativo. No caso dos nomes dos pontos de ônibus, todas as informações (de referência) já estão (ou poderiam/deveriam estar) no mapa, já estão mapeadas. A capacidade de um aplicativo de roteamento encontrar essas informações e interpretá-las não está no processo de mapeamento. O mapeador pode ajudar da forma mais simplista colocando as referências diretamente no nome ou de forma mais complexa criando relações do ponto com as referências (não tenho a menor ideia de como isso pode ser feito, se é que pode ser feito). Mas acredito que, nesse caso, a solução seria mais direta se fosse aplicada na programação do app, por exemplo possibilitando que ele informe a última esquina antes do ponto de ônibus na rota. Do ponto de vista de um usuário humano, basta olhar para o mapa, não precisamos de nomes inventados, nem relações marcadas. Não sou programador, sou urbanista, posso ajudar de forma muito mais efetiva mapeando. Se a solução encontrada for ajudar os aplicativos mapeando e não programando, farei o que estiver a meu alcance de acordo com o que for combinado. Só acho importante discutir antes para que não haja trabalho dobrado ou em vão. Enfim, como eu disse antes, não me oponho terminantemente a nomes inventados, desde que bem fundamentados (para mitigar a possibilidade de confusão), devidamente notificados (como na sugestão do tutorial dos retornos e como em algumas mensagens nessa discussão) e sob os riscos já informados. - - - · Atenciosamente, Márcio Vinícius Pinheiro http://about.me/Doideira Em 20 de março de 2014 16:57, Fernando Trebien fernando.treb...@gmail.com escreveu: Estou apenas alertando para o fato de que devemos mapear o real, e não sugerir novas realidades. Sem dúvida. Mas afinal, o que é o nome de algo? Se estiver na placa, concordo que seja esse o nome. Mas e se não tiver placa, não tem nome então? Seria como consta nos registros do governo? (official_name) Ou como as pessoas chamam? (loc_name) Ou... é como vai aparecer no mapa? Tem várias coisas que você pode dizer que é responsabilidade da aplicação, e no entanto, se ninguém está se dedicando às aplicações para incorporar esses recursos, isso quer dizer que o benefício chegará muito mais tarde até as pessoas. Considere nesse contexto este outro problema que nos acompanha há alguns anos (veja a nota no final da seção): http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o#Linha_como_intermedi.C3.A1rio 2014-03-20 16:21 GMT-03:00 Márcio Vinícius Pinheiro marcioviniciu...@gmail.com: Não estamos falando de mapeamento, então, mas de programação. Provavelmente, uma simples linha programação no app de roteamento, poderia incluir a esquina mais próxima no texto da rota. Pode-se, sim, colocar referências para que programas de navegação/roteamento possam listar essas referências, mas, me desculpem se eu estiver errado, a etiqueta name não é esse lugar. Entendo que mapear é localizar objetos conforme ele se apresenta no mundo real (ou naquele que se quer mapear), quanto mais referências melhor, mas essas referências devem estar devidamente identificadas pelas etiquetas certas. A etiqueta ref seria o local correto para, por exemplo, um número oficial como 100182, pelo exemplificado Marcelo. O nome pode ser em teoria, qualquer uma das sugestões dadas aqui. Não me oponho terminantemente a nenhuma delas. Estou apenas alertando para o fato de que devemos mapear o real, e não sugerir novas realidades. Acho a ideia de colocar os nomes das esquinas mais próximas boa (embora eu conheça diversos casos em que vários pontos teriam nomes iguais com numerção), muito melhor do que eleger
Re: [Talk-br] Validador nacional
O tag layer deve ser relativo à superfície da terra ou água (layer=0). Qualquer coisa acima deve ter layer positivo e qualquer coisa abaixo deve ter layer negativo. Em 12/03/2014 17:57, Fernando Trebien fernando.treb...@gmail.com escreveu: Ah bom, então tá perfeito. :D 2014-03-12 16:24 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: 2014-03-12 16:16 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com : Bem, posso estar falando bobagem (não cheguei a testar esse caso com o validador ainda), só acho que não deveria ser tratado como erro, só como aviso (ou alerta), pra seguir a mesma idéia dos outros avisos do validador do JOSM. Mas não é erro :-) É um aviso. E a mensagem do aviso começa justamente com verificar: ... ___ Talk-br mailing list Talk-br@openstreetmap.org https://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 https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Validador nacional
Layer e level são coisas diferentes. Layer 0 está no nível da superfície. Quando duas coisas se sobrepõem, a que não está no nível da superfície fica com layer=1 (ex: ponte) ou layer=-1 (ex: túnel). Um rio só deve ter layer=-1 quando estiver embaixo da terra, canalizado. Lençol freático é uma coisa completamente diferente. Level não tem nada a ver com layer. É o andar de um edifício. Em 13/03/2014 13:48, Fernando Trebien fernando.treb...@gmail.com escreveu: Valor 0 para algo no nível do chão vale só para level, em layer a escolha é livre porque não representa a altura (no sentido físico) e sim a ordem de desenho. 2014-03-13 12:43 GMT-03:00 Flavio Bello Fialho bello.fla...@gmail.com: O tag layer deve ser relativo à superfície da terra ou água (layer=0). Qualquer coisa acima deve ter layer positivo e qualquer coisa abaixo deve ter layer negativo. Em 12/03/2014 17:57, Fernando Trebien fernando.treb...@gmail.com escreveu: Ah bom, então tá perfeito. :D 2014-03-12 16:24 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: 2014-03-12 16:16 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Bem, posso estar falando bobagem (não cheguei a testar esse caso com o validador ainda), só acho que não deveria ser tratado como erro, só como aviso (ou alerta), pra seguir a mesma idéia dos outros avisos do validador do JOSM. Mas não é erro :-) É um aviso. E a mensagem do aviso começa justamente com verificar: ... ___ Talk-br mailing list Talk-br@openstreetmap.org https://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 https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://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 https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Validador nacional
The layer provides absolutely no information about relative or absolute height difference of objects which do not immediately cross or overlap. A change in layer should not be used to indicate a change in elevation. Traduzindo: O layer não fornece absolutamente nenhuma informação a respeito da diferença de altura relativa ou absoluta de objetos que não se cruzam ou se sobrepõem. Uma mudança no layer não deve ser usada para indicar uma mudança em elevação. O que isso diz é que não há uma relação direta entre a altura e o layer. Se uma estrada está em cima de um morro e outra no fundo de um vale, o layer é zero nos dois casos, apesar da ELEVAÇÃO (=ALTITUDE) ser diferente nos dois casos. É ISSO que está sendo dito no wiki: A bridge is at layer 1 even if it is only several feet above sea level while the peak of Mount Everest is at layer 0 even though it is 8848 meters above sea level. A mesma página ainda diz: Use the smallest suitable layer value. Only use layer=2 for a bridge that passes over a feature that is already at level 1; similarly only use layer=-2 for a tunnel that passes below another tunnel. O menor valor possível é zero. Como a imensa maioria dos atributos mapeados está na superfície, ela é mapeada no layer 0. É a forma que mantém os valores no seu mínimo. Por favor, cite uma situação em que não seja útil que a superfície esteja no layer 0, pois não consigo imaginar nenhum caso. Features at layer 0 should not normally have a layer tag Ou seja, não só não é obrigatório, é recomendável que se elimine o tag layer quando ele for igual a zero. A página cita explicitamente que rios NÃO devem estar no layer -1: Rivers and streams should not be tagged with layer -1 along their entire length or long sections Em 13/03/2014 20:54, Fernando Trebien fernando.treb...@gmail.com escreveu: The layer provides absolutely no information about relative or absolute height difference of objects which do not immediately cross or overlap. A change in layer should not be used to indicate a change in elevation. [http://wiki.openstreetmap.org/wiki/Key:layer] Portanto, não é obrigatório que layer=0 seja aplicado a algo que está na superfície. Pode até ser costume (ou um bom costume), mas não é obrigatório, e certamente há situações em que não é muito útil seguir essa regra. Além disso, não é obrigatório colocar layer=0 porque esse é o valor padrão. (Diz isso no mesmo artigo.) 2014-03-13 20:15 GMT-03:00 Flavio Bello Fialho bello.fla...@gmail.com: Layer e level são coisas diferentes. Layer 0 está no nível da superfície. Quando duas coisas se sobrepõem, a que não está no nível da superfície fica com layer=1 (ex: ponte) ou layer=-1 (ex: túnel). Um rio só deve ter layer=-1 quando estiver embaixo da terra, canalizado. Lençol freático é uma coisa completamente diferente. Level não tem nada a ver com layer. É o andar de um edifício. Em 13/03/2014 13:48, Fernando Trebien fernando.treb...@gmail.com escreveu: Valor 0 para algo no nível do chão vale só para level, em layer a escolha é livre porque não representa a altura (no sentido físico) e sim a ordem de desenho. 2014-03-13 12:43 GMT-03:00 Flavio Bello Fialho bello.fla...@gmail.com : O tag layer deve ser relativo à superfície da terra ou água (layer=0). Qualquer coisa acima deve ter layer positivo e qualquer coisa abaixo deve ter layer negativo. Em 12/03/2014 17:57, Fernando Trebien fernando.treb...@gmail.com escreveu: Ah bom, então tá perfeito. :D 2014-03-12 16:24 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: 2014-03-12 16:16 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Bem, posso estar falando bobagem (não cheguei a testar esse caso com o validador ainda), só acho que não deveria ser tratado como erro, só como aviso (ou alerta), pra seguir a mesma idéia dos outros avisos do validador do JOSM. Mas não é erro :-) É um aviso. E a mensagem do aviso começa justamente com verificar: ... ___ Talk-br mailing list Talk-br@openstreetmap.org https://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 https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://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] Pergunta rápida sobre pontos de ônibus
Arlindo, Está escrito Francisco Sá bem embaixo de BRS, na parada. Em 12/03/2014 08:30, Arlindo Pereira openstreet...@arlindopereira.com escreveu: Aí é que está. A tag name seria usada para o nome da parada, facilmente identificado pelo passageiro. Por ser facilmente identificado, presume-se que seja um nome *na parada*, facilmente visível ou pelo menos encontrável. Por exemplo, esta é a parada Francisco Sá do BRS 1 Copacabana: http://bancodeimagens.fetranspor.com.br/image.php?mediaID=OTgxYWMyOWVjM2RkNg==type=samplefolderID=N2FjMjllYzNkZDY=seo=Painel-do-BRS-em-Copacabana Se o nome é popular, mas não indicado em lugar nenhum, presume-se um conhecimento local, ou que ele pergunte para alguém etc.; se ficar procurando por nome na parada não irá encontrar. De novo, no exemplo aqui do Rio, caso as paradas do BRS não tivessem nomes oficiais, poderia-se até inventar um nome para elas, de acordo com os pontos de referência, mas pelo o que tenho visto o nome delas sempre utiliza o nome das ruas transversais. Isto posto, eu não vejo problema que um nome não-oficial conste na tag name=* da parada, desde que isso seja documentado. []s 2014-03-12 7:46 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com: Srs, Fiquei agora sem entender pq tanta discussão em torno de um detalhe que já está previsto. Vejam o que está escrito na página de Transporte Público -BR ( http://goo.gl/AxuKUB), para a identificação de Paradas de Ônibus : ... Chave ValorDescricãotype site sitetextbus_stop refnumber or textcódigo identificador único, veja secão sobre ele abaixo nametext Nome da parada, facilmente identificável pelo passageiroAuthority textAutoridade responsável pelo local ... A tag name serve exatamente para se colocar um nome popular da parada de ônibus. Recentemente inclui paradas em Recife e região e usei o exemplo acima. No caso específico daqui, a empresa de transporte local usa um código para identificar cada parada, que está impresso nas paradas, para esta informação usei a tag ref, nos moldes que está definido tb na mesma página. Alguem poderia me explicar porque não usar este modelo ? Existe algum erro que não estou vislumbrando ? Att, Marcelo Pereira ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] BR-101
Eu tinha acertado toda a relação da BR-101 no Brasil inteiro. Se está quebrada é porque quebraram depois. Ela não existe no Paraná e no extremo sul de São Paulo eu não tenho certeza do local exato, mas fora isso estava pronta. Em 28/02/2014 21:56, Fernando Trebien fernando.treb...@gmail.com escreveu: Tem o plugin public_transport do JOSM que ajuda a mapear rotas de ônibus, mas a sua vantagem principal é reconhecer as paradas e incluí-las na relação da rota. Se você só quer consertar a rota, o editor genérico do JOSM até dá menos trabalho. Os passos são sempre os mesmos: criar uma relação (se não existir) ou baixá-la no JOSM (menu Arquivo/Ficheiro Descarregar Objeto), e adicionar os membros que faltam. Pra garantir que não sobraram buracos, tem um botão no editor de relações do JOSM que põe em ordem os membros da relação de acordo com a ordem em que se conectam, e daí a terceira coluna (destaque #2 da primeira imagem aqui: http://wiki.openstreetmap.org/wiki/File:Tutorial-restricoes-07-exemplo-05-linha-como-intermediario.png ) indica em que trechos a via não está conectada (onde faltam pedaços ou onde há pedaços que se sobrepõem). Use o botão, olhe a coluna, inclua os trechos que faltam, ordene de novo, observe a coluna de novo, repita até não sobrarem falhas. É um trabalho chato, mas não tem jeito melhor de fazer (ainda). E em algumas situações, não há uma correção óbvia: você tem que parar e descobrir como a rota era originalmente pra descobrir qual membro reincluir na relação. Ah, e o validador do JOSM também avisa sobre relações de rota com trechos desconectados. 2014-02-28 21:36 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Confesso que andei quebrando umas rotas, porém não consegui consertar. É muito complicado de fazer no JOSM, ainda mais essas rotas que são muito extensas. Há algum plugin ou tutorial que ensine a desenhar essas rotas de transporte público? Em 28 de fevereiro de 2014 20:20, John Packer john.pack...@gmail.com escreveu: Pessoal, sobre a BR-101, A relação dela está bem quebrada. Isso sempre foi assim, ou quebraram com o tempo? Achei engraçado que uma igreja se adicionou na relação por alguma razão. Link da relação: http://www.openstreetmap.org/relation/53556 Abs, João ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- 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 https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Postos de salva-vidas
amenity=lifeguard parece ser adequado, por hora. Se a comunidade internacional decidir por outra coisa, fica fácil mudar. Não interessa se é renderizado ou não. Isso é uma questão a ser trabalhada no renderizador. Em 18/02/2014 10:43, Fernando Trebien fernando.treb...@gmail.com escreveu: Joguei pra lista tagging, vamos ver o que dizem. -- Forwarded message -- From: Fernando Trebien fernando.treb...@gmail.com Date: Tue, Feb 18, 2014 at 10:40 AM Subject: Tagging lifeguard watch towers To: Tag discussion, strategy and related tools tagg...@openstreetmap.org Hello everyone, Which tags would you use for tagging lifeguard watch towers on beaches? (as they are described here: http://en.wikipedia.org/wiki/Lifeguard) There's a discussion going on in the Brazilian community on which is the best tag for this. Among the suggestions are: - emergency_service=lifeguard - health_facility:type=first_aid Thinking from the point of view of applications (rendering and geocoding), I kind of feel that this may be a health amenity similar to amenity=doctors/clinic/hospital. I wonder if this would also be a case of surveillance=outdoor + surveillance:type=guard. -- 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 https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Postos de salva-vidas
Ok. Concordo com emergency_service=lifeguard. O importante é padronizar. Em 19/02/2014 18:38, Arlindo Pereira openstreet...@arlindopereira.com escreveu: +1 []s On Wed, Feb 19, 2014 at 6:29 PM, Bráulio brauliobeze...@gmail.com wrote: Concordo que emergency_service seja melhor. E também não acho uma boa jogar mais uma coisa dentro de amenity. On Wed, Feb 19, 2014 at 6:21 PM, Fernando Trebien fernando.treb...@gmail.com wrote: Amenity=lifeguard não está em nenhuma proposta, as demais tags mencionadas já estão. Eu acho que emergency_service=lifeguard seria a melhor por ora. On Wed, Feb 19, 2014 at 4:31 PM, Flavio Bello Fialho bello.fla...@gmail.com wrote: amenity=lifeguard parece ser adequado, por hora. Se a comunidade internacional decidir por outra coisa, fica fácil mudar. Não interessa se é renderizado ou não. Isso é uma questão a ser trabalhada no renderizador. Em 18/02/2014 10:43, Fernando Trebien fernando.treb...@gmail.com escreveu: Joguei pra lista tagging, vamos ver o que dizem. -- Forwarded message -- From: Fernando Trebien fernando.treb...@gmail.com Date: Tue, Feb 18, 2014 at 10:40 AM Subject: Tagging lifeguard watch towers To: Tag discussion, strategy and related tools tagg...@openstreetmap.org Hello everyone, Which tags would you use for tagging lifeguard watch towers on beaches? (as they are described here: http://en.wikipedia.org/wiki/Lifeguard) There's a discussion going on in the Brazilian community on which is the best tag for this. Among the suggestions are: - emergency_service=lifeguard - health_facility:type=first_aid Thinking from the point of view of applications (rendering and geocoding), I kind of feel that this may be a health amenity similar to amenity=doctors/clinic/hospital. I wonder if this would also be a case of surveillance=outdoor + surveillance:type=guard. -- 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 https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://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 https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] spell check
Marcelo, Boa iniciativa. Como disseste que estás corrigindo tudo a mão e só usas o script para localizar os potenciais erros, não vejo necessidade de tags adicionais (acho que até atrapalha). Em 03/02/2014 13:19, Marcelo Pereira pereirahol...@gmail.com escreveu: Srs, Postei no fórum o script e a explicação do processo, para análise. Att, Marcelo Pereira Em 3 de fevereiro de 2014 17:40, Paulo Carvalho paulo.r.m.carva...@gmail.com escreveu: Em 3 de fevereiro de 2014 17:17, Marcelo Pereira pereirahol...@gmail.com escreveu: Me interesso em continuar a fazer isso no OSM, pois assim o fiz nos mapas do Tracksource, e considero isso uma boa forma de contribuir para o projeto, pois já estou acostumado com ele, apesar de chato e repetitivo. Porém não quero que ele seja motivo para problemas ou que eu tenha que ficar gastando mais tempo explicando do que trabalhando no mapa. O processo que uso neste script é quase igual ao usado nos scripts anteriores que usei para substituir as abreviações pelos seus extensos, por exemplo, Dr. Prof, Av. Trav, e por aí vai. Nesse caso o scripts foram publicados no fórum. Também acho interessante poder passar o script para corrigir tais erros. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- ... Edileuz, eu não tem nada a ver com Creuza, É mentira da Ivete, não é meu esse caniveete... Halley, Luiz - Poeta, Cantor, Compsitor ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Ruas residenciais em subúrbios: residential ou living_street?
Eu discordo. Por sorte, vi esse email a tempo. Gostaria de propor duas coisas: 1. Vamos usar as definições internacionais, e não ficar inventando novas (alley é uma coisa bem clara e específica). 2. Vamos nos concentrar em mapear aquilo que não é polêmico. Ainda temos MUITO trabalho pela frente. 3. Vamos reduzir um pouco o número e o comprimento dos emails. Em 9 de janeiro de 2014 12:27, Fernando Trebien fernando.treb...@gmail.comescreveu: Se ninguém discordar, vou converter as living streets de Porto Alegre nesse tipo de via então. On Jan 9, 2014 12:12 PM, Nelson A. de Oliveira nao...@gmail.com wrote: 2014/1/9 Fernando Trebien fernando.treb...@gmail.com: Como poderia ficar pra nós: é uma via de serviço entre propriedades ou um logradouro com calçamento inadequado e/ou passagem difícil para veículos, frequentemente com pedestres na pista. alley é o que faz mais sentido, apesar de originalmente ter sido concebido como serviço. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Excesso de living street em Porto Alegre
18 mensagens em 4 horas nesse thread. Eu desisti de Porto Alegre por enquanto, apesar de ter nascido e morado boa parte da minha vida lá, em função da zona que virou a classificação das ruas. A Barão do Amazonas está como living street? É o que acontece quando se tenta reinventar os critérios de mapeamento do nada. Gostaria muito que outros mapeadores se manifestassem sobre a situação de Porto Alegre. Fernando, eu respeito o teu trabalho e admiro a tua dedicação. Precisamos de mais mapeadores com a paixão que tu tens pelo projeto. Só que essa forma de classificação das vias gera um mapa horroroso. Não me leve a mal, mas acho que podemos aproveitar melhor a nossa energia de outra forma. Quanto a living street, é uma via em que pedestres têm preferência sobre veículos. Até podemos mapear ruas residenciais muito estreitas assim, mas julgar quais ruas são inadequadas e classificá-las como living street é totalmente impróprio. Se eu mapeasse Porto Alegre, a Barão do Amazonas seria tertiary. Em 07/01/2014 00:56, Fernando Trebien fernando.treb...@gmail.com escreveu: Vou usar o link como referência para a tradução de living street, que será via de espaço compartilhado. :D Interessante que o artigo usa outro termo que já foi sugerido extra-oficialmente pela comunidade: via mista para carros e pedestres 2014/1/7 Wille wi...@wille.blog.br: A definição de living street é de ruas em que os pedestres têm o direito legal de trafegar na pista a qualquer momento, onde os carros têm menos preferência que os pedestres e precisam parar para eles. A rigor, living streets não existem no Brasil, então, a rigor, elas não poderiam ser usadas em lugar nenhum por aqui. Até o carnaval deve ser inaugurada a primeira etapa de uma living street no Bairro da Barra. em Salvador: Com investimentosde R$ 50 milhões, em recursos da prefeitura e do Ministério do Turismo, a intervenção na orla da Barra traz o conceito do espaço compartilhado, comum em cidades da Europa e dos Estados Unidos. Assim, está previsto que, no trecho entre o Porto da Barra e as ruas Marques de Leão e Afonso Celso seja implantado um piso que deve ser utilizado tanto por pedestres quanto por veículos. Com a implantação do piso, a velocidade com que os automóveis podem trafegar nessas ruas deve mudar também: passa a ser de 20 km/h. Fonte: http://www.correio24horas.com.br/detalhe/noticia/orla-da-barra-fecha-para-construcao-de-pista-mista-para-carros-e-pedestres/?cHash=65d29c4c593d8c0f261323ca04cc6b80 Nunca tinha imaginado esse caso de uso do valor living_street em aglomerados subnormais, mas me parece o mais adequado para se utilizar quando não há calçadas e a área é residencial. Mas living streets podem ser úteis pra representar algo similar ao conceito original. A idéia é que as living streets serviriam como uma espécie de alerta ao motorista, não de região pobre ou de região perigosa e sim de via com pedestres na pista (por qualquer razão que fosse). Ao contrário do que você disse, nas últimas discussões aqui na lista, o critério da largura foi o que despertou mais críticas (mas eu ainda acho ele bastante interessante) e o do compartilhamento da pista entre pedestres e veículos foi o que despertou mais interesse. Tal compartilhamento acontece em algumas situações, e uma delas é dentro dos aglomerados, onde normalmente faltam calçadas largas o suficiente para que dois pedestres andem lado a lado, sendo assim obrigados a andar na pista. Faz pouco tempo que me dei conta que esse critério (o de falta de calçadas) pode ser mais útil do que algo vago como pedestres dividem espaço com os carros, pois é um critério mais mensurável. Atualmente, a constatação de que algo é living street não se dá nem pelo Street View oficialmente, a princípio a melhor fonte seria a opinião de um morador local ou de alguém que trafega frequentemente pela via. Não havendo tal opinião, não se classifica assim. Havendo, se registra na tag note. Sem poder considerar inteiramente esse último critério, foram os outros motivos que me levaram a marcar as vias dentro dos aglomerados em Porto Alegre como living streets. É bem provável que algum refinamento seja necessário ainda. Já o último critério eu usei para as ruas do centro; note que essas ruas não estão numa região menos favorecida, pelo contrário: ali o que existe é o hábito de os pedestres não respeitarem os carros, de simplesmente atravessarem na sua frente sem esperar. Um motorista que passar por lá sem saber disso (ex.: um turista) acaba tendo mais chance de se envolver num acidente, sem falar que a passagem seria mais demorada. Existe uma tag proposta há 7 anos atrás e que nunca foi votada que serve para demarcar perigos, mas li numa discussão que não seria para questões de segurança pessoal: http://wiki.openstreetmap.org/wiki/Proposed_features/hazard Se o roteador que você está usando for o
Re: [Talk-br] Rodovias com duas ref (estadual e nacional)
Estou usando relações em todas as rodovias nacionais e estaduais que mapeio. Coloco o tag ref na relação. Alguns trechos coincidentes fazem parte de mais de uma relação. A dúvida é quanto ao ref do segmento, que creio que deve ser igual o que aparece nas placas. Não acho que seja interessante criar um tag nat_ref. Creio que o ref das relações já inclui a informação necessária. Em 06/01/2014 00:43, Nelson A. de Oliveira nao...@gmail.com escreveu: Estava pensando, não seria mais correto nas rodovias que possuem a ref multivalorada (por exemplo, ref=SP-270;BR-374) utilizar a ref com o valor estadual (ref=SP-270) e nat_ref para o valor nacional (nat_ref=BR-374)? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Vias separadas e linha contínua: atualização
Roteamento não é a única utilidade de um mapa. Por favor, não coloquem duas vias onde só existe uma. Usem restrições de conversão. Em 03/01/2014 12:44, Fernando Trebien fernando.treb...@gmail.com escreveu: Bom saber que não sou o único, Paulo. Se alguém mais achar essa idéia interessante, eu a apóio, mas eu entendo que, nas definições atuais do OSM e pelos princípios que as aplicações de roteamento adotam em relação ao que diz a lei, a não-separação estaria correta e talvez mais correta do que a separação. No entanto, eu raramente penso em certo e errado no OSM (as definições são livres demais pra se adotar uma postura dogmática) e sim no mais útil e menos útil. Eu sinceramente acho que a separação em duas linhas quando há canteiro fictício tem muitas vantagens para a qualidade do roteamento, desde que dentro da malha urbana (fora dela acho que gera mais problemas do que resolve). A rota calculada sempre faz o motorista chegar ao destino pelo lado mais conveniente, sem precisar cruzar o tráfego contrário e sem atrapalhar o tráfego que vem atrás dele. Geralmente onde há canteiro fictício na cidade é porque o tráfego já é bastante intenso no local, então parar pra chegar no destino (e quem sabe esperar por minutos até conseguir atravessar o tráfego contrário) diminui bastante a eficiência do fluxo local. E é bem mais perigoso também. Por que isso não vale tanto fora da cidade: porque o tráfego é menos intenso, porque os trechos de estradas onde há faixa contínua são mais curtos e raramente há destinos interessantes ao redor, e porque uma separação raramente alteraria a rota calculada já que quase nunca há malha alternativa ao redor de uma estrada. (Uma separação ainda seria interessante, mas não seria algo muito importante pra se mapear.) De volta à cidade. Danos ao mapear como linha separada: trabalho de mapeamento dobrado, possível confusão visual com vias com separador físico (embora não sei que impactos negativos isso teria na prática, mesmo pra pedestres ou ciclistas). Danos ao mapear como linha única: maior dificuldade de chegar ao destino e talvez maior risco de acidente, inconvenientes ao tráfego local. 2014/1/3 Paulo Carvalho paulo.r.m.carva...@gmail.com: Na minha época de Tracksource, sempre mapeava como linhas separadas. Acho que se mantiver a linha única, creio que se deva tomar o cuidado de colocar restrições de manobra à esquerda. Em 31 de dezembro de 2013 17:13, Gerald Weber gwebe...@gmail.com escreveu: Tanto, que quando a linha não pode ser transposta tem que ter avisos. É o caso da Rua Conceição do Mato Dentro em BH que tem placas textuais neste sentido. Linha contínua apenas impede a ultrapassagem (overtaking=no). Além do mais mapear as vias em separado pode confundir o pedestre que ao olhar o mapa não conseguirá identificar o canteiro central. Então não creio que seja mesmo uma boa idéia mapear separado para fins de roteamento. abraço Gerald 2013/12/31 Fernando Trebien fernando.treb...@gmail.com Pessoal, Só pra deixar registrado. Uns tempos atrás eu defendi o mapeamento de vias com linha contínua como separadas, uma para cada sentido. Há pouco estava revisando as traduções (http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Referência), incorporando a terminologia do CTB, e me deparei com o termo canteiro fictício. Fui pesquisar, descobri que nunca foi definido formalmente, mas acabei descobrindo no manual de sinalização horizontal do DNIT ( http://www.dnit.gov.br/rodovias/operacoes-rodoviarias/prosinal/20-manual-vol-iv-sinalizacao-horizontal-resolucao-236.pdf ) que é permitido transpor a linha contínua (chamada no manual de LFO-3) para acesso a lotes (residências). Então, de fato, atualmente não há exigência legal que nos levaria a mapear separadamente, nem para corrigir o roteamento. Mapear como linhas separadas, contudo, tende a produzir um roteamento mais seguro e cômodo para o motorista, especialmente em áreas muito movimentadas da cidade, e pelo que lembro das nossas discussões anteriores, segurança é algo importante. Mesmo assim, vou desfazer os poucos casos em que implementei uma separação baseada nessa característica. -- 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 https://lists.openstreetmap.org/listinfo/talk-br -- Dr. Gerald Weber gwebe...@gmail.com Personal website Departamento de Física/Universidade Federal de Minas Gerais Department of Physics/Federal University of Minas Gerais Campus da Pampulha Av. Antônio Carlos, 6627, 31270-901 Belo Horizonte, MG, Brazil mobile: +55-(0)31-96462277 (mudou/changed 02/07/2013)
Re: [Talk-br] revisão da BR-262
Se alguém pudesse trafegar pela rodovia com um GPS e fazer um upload da trilha, pode-se mapear com source=GPS e resolver o problema. Alguém já fez isso? Em 05/01/2014 18:20, Nelson A. de Oliveira nao...@gmail.com escreveu: 2014/1/5 Fernando Trebien fernando.treb...@gmail.com: Se tem canteiro central, acho que não precisaria colocar o note, a menos que o objetivo seja evitar que as pessoas reclassifiquem considerando somente a imagem de satélite desatualizada. Isso, é justamente para não mudarem de volta se olharem a imagem. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Mapnik: idéias para representar vias não-pavimentadas
Vários mapas em papel usam linhas tracejadas (ex: Guia 4 Rodas). Acho uma boa idéia e fica bem claro. Em 01/01/2014 23:25, Fernando Trebien fernando.treb...@gmail.com escreveu: Obrigado, passei adiante a informação. Se você (ou alguém mais) quiser acompanhar a discussão, a issue original no Github é esta: https://github.com/gravitystorm/openstreetmap-carto/issues/110 E a sequência de mensagens na lista tagging é esta: http://gis.19327.n5.nabble.com/Tags-useful-for-rendering-of-roads-in-poor-conditions-td5791303.html 2014/1/1 Gerald Weber gwebe...@gmail.com: Oi Fernando Vocês que já usaram outros sistemas (Garmin, iGO, etc.) podem informar se eles representam essa situação de forma especial? O Mapsource, programa para PC da Garmin representa com bordas tracejadas. Posso fazer um screenshot para mandar se houver interesse. Na opinião dele, a melhor forma de representar essas ruas seria com uma borda tracejada (ao invés da borda contínua), mas isso em parte é porque ele é holandês, e é assim que ele viu essa informação sendo representada em sistemas holandeses. Eu penso que este formato é o melhor pois pode ser aplicado a qualquer tipo de via (residential, tertiary etc) e é praticamente auto-explicativo. abraço Gerald ___ Talk-br mailing list Talk-br@openstreetmap.org https://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 https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Erros comuns encontrados nos dados
Uma boa fonte de informação é a prefeitura das cidades. A delimitação dos bairros, por exemplo, geralmente é definida por lei, e as leis não têm problema de direitos autorais, pois são leis. O plano diretor geralmente está disponível no site da prefeitura e pode incluir as leis relevantes. Em 01/01/2014 19:20, Fernando Trebien fernando.treb...@gmail.com escreveu: Ok. Sugeri isso porque achei que poderia extrair a informação facilmente a partir de alguma listagem oficial do IBGE. Quanto à subdivisão da cidade em partes, acho que você pode fazer como lhe parecer mais lógico. Fiquei curioso pra saber qual dos meus comentários você leu (eu faço tantos, e sobre tantas coisas diferentes :P). Talvez você tenha lido algo no artigo do wiki sobre Porto Alegre, onde eu apenas dividi a cidade por bairro (acaba fazendo sentido pro dia em que houver 1 mapeador por região/bairro) e os coloquei numa ordem específica (pro caso de eu continuar sendo o único mapeando a cidade por muito tempo). Na época eu tentei várias heurísticas, mas a que me pareceu mais natural foi assim: - o primeiro da sequência é o Centro - o segundo é o bairro adjacente mais famoso (famoso segundo o Google Trends) - o terceiro é o mais famoso que é adjacente aos dois anteriores - o quarto é o mais famoso adjacente aos três anteriores E assim por diante. Acho que funciona pra qualquer cidade de tamanho médio, provavelmente pra Recife também. São Paulo, por exemplo, exigiria uma subdivisão diferente, é tão grande que pode-se dizer que tem vários centros - mas uma vez eleitos, daria pra seguir um critério similar pra cada um. O resultado aqui em Porto Alegre é bem razoável: a região coberta atinge gradualmente um equilíbrio entre distância do centro e distância até a linha de desenvolvimento pro leste. Por que usar o famoso como critério na ordenação: porque o mais famoso (seja boa ou má fama) é provavelmente o que as pessoas mais vão procurar no mapa, então é mais importante que esteja correto antes dos outros. Pro usuário, ter o famoso coberto é sinal de que o mapa atende às suas necessidades mais comuns, e encontrar um erro numa região dessas é um sinal bem pior do que encontrar um erro numa região afastada (onde o usuário teria um pouco mais de tolerância). Só por isso. Por que usar o adjacente como critério: pra que eu não ficasse saltando de uma área pra outra, pra que as conexões entre as áreas não tendessem a ser ignoradas. 2014/1/1 Marcelo Pereira pereirahol...@gmail.com: Lembro que não identifiquei erros nos nomes das vias aqui, só a falta do identificador, por isso acredito que nomear tudo como Rua e depois sair consertando, pode ser mais danoso do que fazer certo de uma vez só, mesmo que muito mais demorado. De um jeito ou de outro, eu me candidato a revisar tudo, ou pelo menos o que eu puder. Para os limites de Recife é mais fácil, pois eu tenho fontes boas de pesquisa, para as outras cidades, mesmo as vizinhas, a quantidade de informação disponível cai assustadoramente, por isso tende a ser mais dificil a revisão. Quando falei no GPS, eu não tinha a intenção de usar isso como desculpa para a falta de identificadores, foi só um exemplo. Partindo para a prática, pelo que vi são duas opções, a primeira inclui Rua em todas as vias e depois passa pente fino, a segunda começa a consertar manualmente. É isso ? Se sim voto na segunda opção, mesmo que seja mais trabalhoso. Fernando, quanto à lista de não ruas de Recife, vou ver o que consigo e lhe envio em pvt, mas pode demorar um pouco até compilar tudo, certo ? Marcelo P Em 1 de janeiro de 2014 17:37, Fernando Trebien fernando.treb...@gmail.com escreveu: Claro que pode. Ou poderíamos fazer melhor: Marcelo, seria possível conseguir uma listagem de tudo aquilo que não contém o nome Rua em Recife? Talvez a partir do IBGE? Isso pode ser fonte de dados para uma revisão posterior a essa edição. Talvez o número total de elementos nessa situação seja pequeno (uns 100 ou 200), daí poderíamos deixar a tag fixme de lado caso você se comprometesse a revisar isso logo em seguida. Quanto a soar melhor no GPS, sua decisão não deve se basear nesse critério. Chamos isso de mapear para a aplicação. No caso, a aplicação pode decidir se quer retirar o prefixo (rua, avenida, etc.) caso exista, mas seria estranho (e frequentemente errado) ela acrescentar um prefixo padrão caso eles não existam nos dados. Por isso, ter o prefixo dá às aplicações a possibilidade de decidir. 2014/1/1 Nelson A. de Oliveira nao...@gmail.com: 2014/1/1 Fernando Trebien fernando.treb...@gmail.com: Essa escolha produz resultados menos incorretos, mas nos prende num estado que não leva ao resultado mais correto ao longo do tempo. Por isso, eu aceitaria um aumento temporário na incorreção. Posso sugerir também incluir um FIXME=Verificar nome da rua (ou algo parecido) nessas
Re: [Talk-br] Orchard vs farmland
Como eles classificam cana-de-açúcar? É uma lavoura com ciclo maior que um ano, mas deve ser farmland. Erva-mate deve ser considerada forest, da mesma forma que seringueira, eucalipto ou pinus. Já o café é orchard, como a laranja, a menos que haja uma categoria específica para ele, como vineyard para uva. O manejo de uma plantação de café é intenso como outros pomares. Em 09/11/2013 16:10, Fernando Trebien fernando.treb...@gmail.com escreveu: Hm pois é, seringueira deveria ser landuse=forest porque é uma plantação (=manejada) de árvores usadas para o extrativismo (do látex) e não para a alimentação. Por outro lado, ninguém marcaria uma plantação de café ou de chá como pomar, embora caiam na definição de orchard do OSM. Mas enfim, pomar parece ser a tradução mais aproximada mesmo. 2013/11/9 Nelson A. de Oliveira nao...@gmail.com Pra deixar mais claro: não pode levar a classificar plantações permanentes de plantas não-frutíferas como orchard? ___ Talk-br mailing list Talk-br@openstreetmap.org https://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 https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Etiquetas para casos especiais
Pode ser assim. Eu acho importante ter alguma forma de identificar uma escola de idiomas como tal, e a combinação de amenity=school e training=language funciona. Em 04/09/2013 18:41, Fernando Trebien fernando.treb...@gmail.com escreveu: Bem, um dos problemas com amenity=language_school é que nenhuma aplicação a suporta no momento (nem o Nominatim). Isso pode deixar alguns usuários confusos. Em office=educational_institution, entendi pelo texto do wiki que seria para mapear o escritório de uma escola, e não a escola em si. Então acho que não se aplica. Que tal usar então amenity=school e training=language? Essa combinação seria fácil de detectar e ajustar quando surgisse uma proposta mais concreta, não me parece tão semanticamente incorreta, e funcionaria com todas as aplicações atuais. Relacionado a isso, poderíamos daí propor mapear cursos pré-vestibular com training=tutoring. http://en.wikipedia.org/wiki/Cursinho http://en.wikipedia.org/wiki/Cram_school Vou perguntar sobre isso (pois deve acontecer no exterior também) e já propor isso na lista tagging. 2013/9/2 Wille wi...@wille.blog.br: Oi, Fernando Eu tenho usado amenity=school para escola de idiomas. Talvez fosse mais adequado ter uma tag amenity=education e outra para definir o tipo de curso, pois há vários outros tipos de escola que não estão contempladas nas tags atuais, como cursos profissionalizantes e pré-vestibulares... Achei inclusive uma proposta nesse sentido: http://wiki.openstreetmap.org/wiki/Proposed_features/training amenity=language_school não foi definida no wiki, mas já foi usada 40 vezes: http://taginfo.openstreetmap.org/tags/?key=amenityvalue=language_school#overview Se for usar office, a mais adequada seria educational_institution http://wiki.openstreetmap.org/wiki/Tag:office%3Deducational_institution Porém essa tem que ser uma discussão global, pois não é uma demanda apenas brasileira. On 31-08-2013 13:11, Fernando Trebien wrote: Poderia ser office=company nesses casos entao, enquanto ninguem faz uma proposta melhor. Que tal? 2013/8/31 Pedro Geaquinto pedrodi...@gmail.com: Entendi. Nunca tinha visto dessa forma. Bom, até faz sentido em certos institutos como o que curso atualmente a língua russa, que se chama Centro de Cultura Eslava. Além de línguas, há debates e conversas mais culturais mesmo. Mas alguns outros mais industriais como Wizard e Yazigi (esse ultimo eu já fiz alemão), acho que pedem uma tag nova. On Aug 31, 2013 9:49 AM, Fernando Trebien fernando.treb...@gmail.com wrote: Como que você as mapepu? Se foi só 1 não é tão grave. :P Como você fez? Quando eu mapeei as escolas de línguas aqui em Porto Alegre eu pesquisei a melhor tag a ser usada e achei uma discussão sobre isso na comunidade internacional. O argumento era que essas escolas frequentemente ensinam não só a língua como também a cultura de um outro país, muitas vezes através de eventos ligados à arte (exposições, debates, exibição de filmes, etc.). Muitas inclusive incentivam os seus alunos a exercitarem outras formas de arte (literária, canto, cinema, teatro, etc.) desde que no contexto da língua ensinada. Se não for arts_centre, então acho que só sobraria office=company. Ou uma tag nova, como você sugeriu. On Aug 31, 2013 6:32 AM, Pedro Geaquinto pedrodi...@gmail.com wrote: Já houve discussão para escolas de línguas? Eu vou ter que revisar um POI pelo menos, usava a tag errada. :p Eu acho que usar arts_centre seria muito estranho, acho que isso pede uma tag em específico. On Aug 31, 2013 3:06 AM, Fernando Trebien fernando.treb...@gmail.com wrote: Acrescentei o caso do motel. Quase coloquei o 3 do Arlindo como comentario. :P Concordo que deveriamos criar issues pro iD, mas o que voce tem em mente exatamente? Criar itens no menu da esquerda que soh aparecam para os brasileiros? 2013/8/30 Arlindo Pereira openstreet...@arlindopereira.com: Esqueci de comentar. De resto, concordo com tudo. Agora seria muito bom criarmos issues (principalmente) no iD para implementar esses casos diretamente no editor. []s Arlindo 2013/8/30 Arlindo Pereira openstreet...@arlindopereira.com Eu que propus o amenity=love_hotel. Gostaria de ver um 3 renderizado no Mapnik um dia. :-P Por mim, usamos as duas juntas, sendo a primeira meio que um tagging-for-the-renderer (motéis (no sentido brasileiro) não deixam de ser um hotel de beira de estrada, que você vai com o carro numa viagem - só não são na beira da estrada como em viagem), e a segunda para pegar os tipos específicos de motéis brasileiros. On Fri, Aug 30, 2013 at 7:47 PM, Nelson A. de Oliveira nao...@gmail.com wrote: E quanto a classificação do motel? No Brasil faz sentido tourism=motel + amenity=love_hotel (as duas juntas)
Re: [Talk-br] Etiquetas para casos especiais
O problema que eu vejo de repetir endereços é na hora de localizar um endereço num mecanismo de busca. Se existirem vários iguais, qual posição deve ser retornada pelo sistema? Em 04/09/2013 18:53, Fernando Trebien fernando.treb...@gmail.com escreveu: Acho que a sua pergunta tem um pouco a ver com a idéia da relação site: http://wiki.openstreetmap.org/wiki/Relation:site No início, as pessoas (da comunidade internacional) andavam agrupando tudo que dizia respeito a um lugar (a sua área, os seus prédios, caminhos, etc.) numa relação, e às vezes colocando o endereço nela. A última recomendação que eu tenho é que esse não é o jeito certo de fazer isso. A aplicação tem que poder determinar quando um prédio está dentro de uma área, sem precisar de uma relação pra especificar isso. site então deve ser usado para lugares (campi) que se quebram em duas ou mais partes. Partindo disso, o que eu tenho feito é o seguinte: - se o lugar é um prédio ocupando todo o seu terreno, mapeio só o prédio com endereço e sem a tag landuse - se o lugar tem uma área externa (um estacionamento, por exemplo), mapeio a área total com a tag landuse, o(s) edifícios com a tag building, e coloco o endereço: - no edifício, se for só 1 - na área, se houver mais de 1 edifício Se os edifícios tiverem algum nome (às vezes número) que os identifique, daí coloco o endereço neles também com a tag addr:housename. Se você quiser, pode colocar o endereço sempre na área, pra ficar mais uniforme essa regra. Há pouco tempo comecei a ter vontade de mudar de método e fazer assim pra tudo. Mas acho que isso é meio livre. O iD recomenda que estabelecimentos sejam mapeados como ponto, mesmo quando ocupam o prédio inteiro. Eu suspeito que essa recomendação tem algo a ver (entre outras coisas) com evitar a repetição das tags de endereço em vários objetos. Mas se você repetir, também não estará errado. Nunca usei, não sei quão bem suportado é, mas acho que um jeito de evitar a repetição é usando a relação associatedStreet: http://wiki.openstreetmap.org/wiki/Relation:associatedStreet 2013/9/2 Augusto Stoffel arstof...@yahoo.com.br: Uma questão mais genérica é como especificar o campus de uma empresa. Quando a sede possui de uma empresa possui vários prédios, o mais adequado me parece ser demarcar o terreno inteiro com landuse=commercial + name=Empresa X. (Onde seria mais apropriado adicionar tags de endereço? No terreno ou no prédio principal?) Me pergunto também o que seria o mais apropriado para entidades do governo. A combinação building=commercial + office=government está prevista na wiki, então acho que o no caso de uma entidade do governo com vários prédios, também faria sentido também usar landuse=commercial para o terreno. On 09/02/2013 06:48 AM, Arlindo Pereira wrote: Tenho usado assim por aqui, mas podemos ver uma tag mais específica. []s 2013/9/2 Pedro Geaquinto pedrodi...@gmail.com mailto:pedrodi...@gmail.com Outro caso especial que seria legal discutir: garagens de ônibus. Seria adequado landuse=commercial + name=Garagem da Empresa X? 2013/8/31 Augusto Stoffel arstof...@yahoo.com.br mailto:arstof...@yahoo.com.br Aparentemente o valor public não está previsto para a tag access. Outras possibilidades seriam fee=no, ou operator=SUS ou seja qual for o orgão do governo que gere o local. On Sat, 2013-08-31 at 14:54 -0300, Arlindo Pereira wrote: Gostei dessa. Tenho usado hospital por falta de opção melhor. On Aug 31, 2013 1:19 PM, Fernando Trebien fernando.treb...@gmail.com mailto:fernando.treb...@gmail.com wrote: Postos de saude: que tal amenity=clinic + access=public? 2013/8/31 Fernando Trebien fernando.treb...@gmail.com mailto:fernando.treb...@gmail.com: Poderia ser office=company nesses casos entao, enquanto ninguem faz uma proposta melhor. Que tal? 2013/8/31 Pedro Geaquinto pedrodi...@gmail.com mailto:pedrodi...@gmail.com: Entendi. Nunca tinha visto dessa forma. Bom, até faz sentido em certos institutos como o que curso atualmente a língua russa, que se chama Centro de Cultura Eslava. Além de línguas, há debates e conversas mais culturais mesmo. Mas alguns outros mais industriais como Wizard e Yazigi (esse ultimo eu já fiz alemão), acho que pedem uma tag nova. On Aug 31, 2013 9:49 AM, Fernando Trebien fernando.treb...@gmail.com mailto:fernando.treb...@gmail.com
Re: [Talk-br] Etiquetas para casos especiais
Usar amenity=language_school tem a vantagem de podermos mudar tudo facilmente no futuro, se um padrão for definido. Em 02/09/2013 22:11, Wille wi...@wille.blog.br escreveu: Oi, Fernando Eu tenho usado amenity=school para escola de idiomas. Talvez fosse mais adequado ter uma tag amenity=education e outra para definir o tipo de curso, pois há vários outros tipos de escola que não estão contempladas nas tags atuais, como cursos profissionalizantes e pré-vestibulares... Achei inclusive uma proposta nesse sentido: http://wiki.openstreetmap.org/** wiki/Proposed_features/**traininghttp://wiki.openstreetmap.org/wiki/Proposed_features/training amenity=language_school não foi definida no wiki, mas já foi usada 40 vezes: http://taginfo.openstreetmap.**org/tags/?key=amenityvalue=** language_school#overviewhttp://taginfo.openstreetmap.org/tags/?key=amenityvalue=language_school#overview Se for usar office, a mais adequada seria educational_institution http://wiki.openstreetmap.org/**wiki/Tag:office%3Deducational_** institutionhttp://wiki.openstreetmap.org/wiki/Tag:office%3Deducational_institution Porém essa tem que ser uma discussão global, pois não é uma demanda apenas brasileira. On 31-08-2013 13:11, Fernando Trebien wrote: Poderia ser office=company nesses casos entao, enquanto ninguem faz uma proposta melhor. Que tal? 2013/8/31 Pedro Geaquinto pedrodi...@gmail.com: Entendi. Nunca tinha visto dessa forma. Bom, até faz sentido em certos institutos como o que curso atualmente a língua russa, que se chama Centro de Cultura Eslava. Além de línguas, há debates e conversas mais culturais mesmo. Mas alguns outros mais industriais como Wizard e Yazigi (esse ultimo eu já fiz alemão), acho que pedem uma tag nova. On Aug 31, 2013 9:49 AM, Fernando Trebien fernando.treb...@gmail.com wrote: Como que você as mapepu? Se foi só 1 não é tão grave. :P Como você fez? Quando eu mapeei as escolas de línguas aqui em Porto Alegre eu pesquisei a melhor tag a ser usada e achei uma discussão sobre isso na comunidade internacional. O argumento era que essas escolas frequentemente ensinam não só a língua como também a cultura de um outro país, muitas vezes através de eventos ligados à arte (exposições, debates, exibição de filmes, etc.). Muitas inclusive incentivam os seus alunos a exercitarem outras formas de arte (literária, canto, cinema, teatro, etc.) desde que no contexto da língua ensinada. Se não for arts_centre, então acho que só sobraria office=company. Ou uma tag nova, como você sugeriu. On Aug 31, 2013 6:32 AM, Pedro Geaquinto pedrodi...@gmail.com wrote: Já houve discussão para escolas de línguas? Eu vou ter que revisar um POI pelo menos, usava a tag errada. :p Eu acho que usar arts_centre seria muito estranho, acho que isso pede uma tag em específico. On Aug 31, 2013 3:06 AM, Fernando Trebien fernando.treb...@gmail.com wrote: Acrescentei o caso do motel. Quase coloquei o 3 do Arlindo como comentario. :P Concordo que deveriamos criar issues pro iD, mas o que voce tem em mente exatamente? Criar itens no menu da esquerda que soh aparecam para os brasileiros? 2013/8/30 Arlindo Pereira openstreetmap@arlindopereira.**comopenstreet...@arlindopereira.com : Esqueci de comentar. De resto, concordo com tudo. Agora seria muito bom criarmos issues (principalmente) no iD para implementar esses casos diretamente no editor. []s Arlindo 2013/8/30 Arlindo Pereira openstreetmap@arlindopereira.**comopenstreet...@arlindopereira.com Eu que propus o amenity=love_hotel. Gostaria de ver um 3 renderizado no Mapnik um dia. :-P Por mim, usamos as duas juntas, sendo a primeira meio que um tagging-for-the-renderer (motéis (no sentido brasileiro) não deixam de ser um hotel de beira de estrada, que você vai com o carro numa viagem - só não são na beira da estrada como em viagem), e a segunda para pegar os tipos específicos de motéis brasileiros. On Fri, Aug 30, 2013 at 7:47 PM, Nelson A. de Oliveira nao...@gmail.com wrote: E quanto a classificação do motel? No Brasil faz sentido tourism=motel + amenity=love_hotel (as duas juntas) __**_ 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-brhttp://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-brhttp://lists.openstreetmap.org/listinfo/talk-br __**_
Re: [Talk-br] Excesso de tertiary em Porto Alegre
Fernando, não tenho trabalhado em Porto Alegre, porque vi que há outras pessoas trabalhando na cidade e acho mais produtivo concentrar o serviço onde ele é mais necessário (nas cidades da serra, por exemplo). Não é minha intenção criar uma guerra de edições, por isso mesmo que faz muito tempo que não mexo em Porto Alegre. Fico feliz que tu estejas te dedicando a mapear a cidade. Em algum dos posts, te referiste a um usuário novo que estaria editando alguma coisa com perda de informação. Acho uma boa idéia entrares em contato com ele e orientá-lo sobre como editar sem desfazer o trabalho dos outros. Não vi em detalhes o que ele mudou, mas se ele não copiou dados ilegalmente, acho melhor tentar conciliar as contribuições dele (se é que fez alguma) com as tuas, ao invés de reverter tudo, o que pode desestimulá-lo. Sempre precisamos de mais mapeadores, e talvez, com orientação, ele possa vir a ajudar bastante. Quanto à classificação das vias, também estou cansado dessa discussão. Acho uma boa idéia pararmos por um tempo e focarmos em coisas mais produtivas. Só te peço que mantenha a tua forma de classificação restrita a Porto Alegre, por enquanto. Podemos pensar numa maneira melhor de conduzir o assunto no futuro. Acho uma boa idéia incluir as informações de sinaleiras (highway=traffic_signals) e placas de pare (highway=stop) no mapa, pois essa informação pode ser usada por roteadores para decidir o caminho mais rápido. -- Flávio Bello Fialho ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Excesso de tertiary em Porto Alegre
Os critérios objetivos podem ser discutidos. A questão principal é que a classificação por preferência não funciona e não deve ser usada. Que critério define se uma via é arterial ou não? Por quê a classificação das primary funcionou muito melhor que a das secondary e tertiary? As secondary e tertiary desligadas do mapa não são uma mera questão estética. Uma via secundária deve dar acesso a uma via principal (diretamente ou através de outra secondary). Um mapa só com as motorway, trunk e primary deve fazer sentido (no caso de Porto Alegre, faz). Um mapa com esses três tipos e as secondary também deve fazer sentido (no caso de Porto Alegre, não faz: o mapa ficaria com ruas desconectadas, aparentemente ligando nada a coisa alguma). O mesmo vale para as tertiary. É fácil definir regras que podem ser seguidas por qualquer um. O difícil é fazer com que elas gerem mapas bons. É certo que devemos tentar uniformizar os critérios o máximo possível, mas existe (e sempre existirá) alguma subjetividade no mapeamento. É o que nos torna diferentes de máquinas. É o que faz com que mapear seja tanto uma arte quanto uma ciência. A propósito, em http://www.openstreetmap.org/#map=17/-30.05257/-51.21590(uma área que classificaste como boa) não há motivo para a Marcílio Dias, a Barão do Triunfo e a Visconde do Herval serem tertiary, se elas nem atravessam a Érico Veríssimo (pelo menos até algum tempo atrás, a Barão do Triunfo tinha até feira que bloqueava a rua uma vez por semana), assim como não há por quê a Botafogo não ser tertiary no trecho entre a Múcio Teixeira e a Getúlio Vargas, o que permitiria ir diretamente por ela da Praia de Belas até a Azenha. Pela classificação por preferência, se uma rua residencial for cortada por outra rua residencial, ela automaticamente vira tertiary, mas se ela seguir sem transversais ela continua residential. ISSO é o problema da classificação por preferência, e é por isso que eu digo que ela está errada em sua natureza, não importa quais outras regras se usem para corrigí-la. O que podemos fazer a respeito? Adotar algum critério para as secondary e tertiary semelhante ao que foi feito para primary. Eu fiz uma proposta. Aparentemente, a palavra importante atrapalhou. Alguém tem outra sugestão? Acho que é bem mais fácil e produtivo decidir localmente (com a comunidade que conhece a cidade) o grau de importância (ou algum outro critério que se definir) de uma via do que tentar criar uma regra geral e complexa que se adate a todas as situações. O que aconteceu em Porto Alegre não é normal, e não adianta tentar culpar a prefeitura por falta de planejamento urbano. A maioria das cidades do mundo é assim. Temos que usar isso como um aprendizado e reformular os critérios, mas não há nada melhor que o conhecimento local para gerar um mapa bom. -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Excesso de tertiary em Porto Alegre
Só a título de comparação, eis algumas partes típicas de mapas (Porto Alegre tem muito mais tertiary, às vezes 6 ou mais ruas paralelas são tertiary, uma ao lado da outra): Porto Alegre: http://www.openstreetmap.org/#map=14/-30.0150/-51.1361 Londres: http://www.openstreetmap.org/#map=14/51.4816/-0.0560 Paris: http://www.openstreetmap.org/#map=14/48.9261/2.5092 Nova York: http://www.openstreetmap.org/#map=14/40.7624/-73.9145 Atlanta: http://www.openstreetmap.org/#map=14/33.7449/-84.2234 Los Angeles: http://www.openstreetmap.org/#map=14/34.0745/-118.1863 Rio de Janeiro: http://www.openstreetmap.org/#map=14/-22.9087/-43.2226 São Paulo: http://www.openstreetmap.org/#map=14/-23.5413/-46.6852 Vitória: http://www.openstreetmap.org/#map=14/-20.2867/-40.2884 Em 27 de agosto de 2013 10:08, Leandro Motta Barros l...@stackedboxes.orgescreveu: Olás, TL;DR: Que tal regras do tipo uma via precisa ter pelo menos 2km de extensão para ser classificada como secundária, senão deve ser rebaixada para terciária ? --- Eu acompanhei as discussões muito de longe, e acho que não fiz nenhuma contribuição nelas (ou seja: não tenho muita moral para reclamar...) Mas fiquei bem feliz de ver que, depois de várias discussões similares que não deram em nada no passado, dessa vez chegamos a algo concreto. Ainda assim, tenho que admitir que, há umas semanas atrás, fiquei um pouco chocado ao ver o mapa de Porto Alegre com as vias reclassificadas. Minha primeira reação foi um puxa, se esse é o resultado das novas regras, então tem algo de muito errado com as novas regras. Agora nessa nova discussão, vi alguns bons argumentos que me fizeram pensar que talvez as novas regras não estejam tão ruins assim (por exemplo, o mapa não parece ter uma hierarquia de vias porque de fato nÃo existe uma hierarquia de vias, não temos cidades bem planejadas, etc). De qualquer modo, acho que podemos tentar algumas variações das regras (como estão sendo sugeridas agora) antes de dar um caráter mais oficial a elas e começar a aplicá-las sistematicamente a outras cidades. Uma coisa que pensei foi em exigir extensões mínimas para que vias tenham uma determinada classificação. Por exemplo (estou inventando os números): uma via precisa ter pelo menos 2km de extensão para ser classificada como secundária, senão deve ser rebaixada para terciária. Isso só uma ideia, não sei nem dizer se é uma boa ideia. Não gostaria de deixar as regras muito complexas. (Pra dizer a verdade, eu acho que o ideal seria simplificá-las, não adicionar ainda mais condicionais -- e não, não faço ideia de como simplificar as regras sem torná-las inócuas :-/ ) Abraço, LMB -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Excesso de tertiary em Porto Alegre
-br -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Excesso de tertiary em Porto Alegre
Por favor, olhem o mapa de Porto Alegre e comparem com qualquer outra cidade grande do mundo, especificamente nesses critérios: 1. Número de vias tertiary, em relação ao número total de vias. 2. Presença de vias secondary ou tertiary não ligadas ao restante do mapa por vias de igual ou maior importância. Se a maioria dos usuários achar que Porto Alegre está mapeada de forma semelhante às demais cidades, segundo esses critérios, eu não digo mais nada. Alguém além de mim vê alguma coisa estranha em Porto Alegre ou sou eu que estou vendo coisas? Em 23/08/2013 21:19, Fernando Trebien fernando.treb...@gmail.com escreveu: 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
Re: [Talk-br] Excesso de tertiary em Porto Alegre
de outras pessoas :D. Talvez devamos criar uma seção ali registrando os casos em que a classificação deve divergir do fluxograma. Tenho umas alterações pendentes pro fluxograma (alguém sugeriu definir claramente o que é considerado um acostamento aceitável, não tive tempo de pesquisar um critério adequado, mas seria um critério relacionado à largura: provavelmente 2m ou 3m). Se você quiser retomar essa discussão sobre classificação, sugiro fazer isso no fórum. 2013/8/23 Flavio Bello Fialho bello.fla...@gmail.com: Olhei agora o mapa de Porto Alegre e, na minha opinião, está um caos. Metade das ruas são tertiary, o que está completamente incoerente com o mapa de qualquer outro lugar. A classificação das ruas deve ajudar a escolher a melhor rota. Do jeito que está, mais atrapalha do que ajuda. As secondary também apresentam problemas. Há trechos curtos de ruas secondary que não se ligam a ruas de importância igual ou maior. Já as primary estão bem coerentes e compatíveis com a realidade. O que aconteceu com as secondary e tertiary? -- 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) -- 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 -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Excesso de tertiary em Porto Alegre
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.comescreveu: 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
Re: [Talk-br] linha de ônibus
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
Re: [Talk-br] Definição de canteiro central
canteiro central deve ser qualquer coisa que impossibilite fisicamente que um carro passe para o outro lado (ou seja, vale bloco de concreto, mas não olho de gato). Em 20/07/2013 10:26, Blademir Andrade de Lima blademi...@hotmail.com escreveu: Pelo que percebi no Google eles fazem a marcação dos canteiros anexados aos nós das vias, no OSM, nós traçamos no canteiro exato, procede? Ja a questão da divisória, em grandes cidades usam muito essa mureta de perfil baixo, que pode ser fixa ou movel. Em rodovias não tem muita serventia, mas ajuda a detalhar. Blademir Andrade de lima -- Date: Sat, 20 Jul 2013 02:22:37 -0300 From: fernando.treb...@gmail.com To: talk-br@openstreetmap.org Subject: 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 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] Hierarquia das rodovias
obstruções, acesso por entradas e saídas. 5. O texto acostamento (que decide entre primary e secondary) deve ser mudado para mais de 1 faixa por sentido ou acostamento largo o suficiente para estacionar um carro. Há vias com acostamento em que cabe apenas meio carro, que devem ser classificadas como secondary. 6. O texto - sem interseções; - comprimento = 400m; - velocidade média = 40km/h não deixa claro se todos os itens devem ser satisfeitos (E) ou se apenas um dos itens é necessário (OU). Acho também difícil avaliar a velocidade média na pista. Sugiro mudar o texto para Sem interseções E comprimento 400 m E velocidade permitida 40 km/h. ou eliminar completamente esse item e manter apenas a promoção por preferência. Creio também que vias urbanas não pavimentadas não devam ser classificadas como tertiary ou secondary. Creio que esses são os pontos principais. Por enquanto, sugiro que se evite mudar a classificação das rodovias existentes enquanto a discussão não estiver bem madura. Em 14 de junho de 2013 16:42, Fernando Trebien fernando.treb...@gmail.comescreveu: 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. -- Flávio Bello Fialho bello.fla...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Importar X mapear
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=-22.9115943908691 []s 2013/6/6 Fernando Trebien fernando.treb...@gmail.com Pessoal, O IBGE possui um cadastro do que ele chama de aglomerados subnormais (populações de renda extremamente baixa) que na grande maioria das vezes são vilas e favelas. Há algum tempo eu importei esses dados em Porto Alegre manualmente (com ajustes) e agora me pediram para fazer o mesmo em BH. O cadastro é acessível aqui: http://www.ibge.gov.br/home/estatistica/populacao/censo2010/aglomerados_subnormais/aglomerados_subnormais_tab_base_zip.shtm Como é necessário transformar alguns dados (tirar tags que estão em multipolígonos e passá-las para os próprios polígonos), acabei fazendo um script, e com isso há a flexibilidade de automatizar algumas outras coisas, como a formatação dos nomes. Já que foi feito esse script, eu pergunto: alguém mais tem interesse nessa importação? Alguém prefere que não seja feita na sua região? Sei que na cidade do RJ seria um pouco mais complicado uma importação automática porque lá as comunidades já foram importadas de outra fonte. Mas não sei de outros lugares que tenham feito o mesmo. Os dados importados seriam um polígono para cada comunidade, contendo uma tag
Re: [Talk-br] bairros de Porto Alegre
Se tens os limites oficiais dos bairros, de fonte confiável (como o site da prefeitura), fique à vontade para inseri-los. Em 06-12-2012 00:34, Wille escreveu: Olá, Não moro em Porto Alegre, mas percebi que o mapa de lá não tem quase nenhuma informação de nomes de bairros. Fiquei em dúvida se deveria adicionar os bairros que conheço... alguém planeja importar os limites dos bairros de alguma fonte ou só não tem os nós identificando o bairro porque ninguém nunca adicionou mesmo? abraços, wille ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br -- Aviso de confidencialidade: Esta mensagem da Empresa Brasileira de Pesquisa Agropecuária (Embrapa), empresa pública federal regida pelo disposto na Lei Federal nº 5.851, de 7 de dezembro de 1972, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco. Confidentiality note: This message from Empresa Brasileira de Pesquisa Agropecuária (Embrapa) a government company established under Brazilian law (5.851/72) is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Classificação de vias
Nada é nunca. O mais importante é usar o bom senso. Supõe-se que uma estrada municipal não liga um município a outro, então a sua importância para o fluxo de veículos seria baixa. Pode haver alguma exceção. Por exemplo, se a estrada municipal não pavimentada é a principal via de ligação de um distrito (com centro urbano) à sede do município, talvez seja mais adequado classificá-la como tertiary. É difícil prever todas as possibilidades. Em 15-06-2012 04:06, Hermann Peifer escreveu: Olá, Tenho uma pergunta relacionada as definições de rodovias em áreas rurais [1]: É verdade que uma estrada municipal não-pavimentada nunca pode ser na categoria tertiary? Este tipo de estrada tem que ser mapeado como: unclassified ? As definições do Wiki: --- snip --- unclassified = Estrada não pavimentada, de administração municipal. tertiary = Estrada não pavimentada, federal ou estadual, ou rodovia pavimentada municipal. --- snip --- Abs, Hermann [1] http://wiki.openstreetmap.org/wiki/Pt-br:Guia_de_Mapeamento_do_Territ%C3%B3rio_Brasileiro On 14/06/2012 16:20, Flavio Bello Fialho wrote: Alterei o Wiki. Agora as duas definições estão coerentes. Em 12-06-2012 12:40, martin137-hi6y0cq0...@public.gmane.org escreveu: Olá, encontrei algumas incoerências na classificação das vias urbanas no wiki e queria perguntar qual é a versão oficial. Dum lado existe uma classificação segundo limites de velocidade e as categorias trânsito rápido, arterial, coletora e local: http://wiki.openstreetmap.org/wiki/Pt-br:Guia_de_Mapeamento_do_Territ%C3%B3rio_Brasileiro Dum outro lado existe uma tradução do tag highway que até o tradutor não achou oficial (e que ignora os aspectos acima): http://wiki.openstreetmap.org/wiki/Pt-br:Key:highway Alguém pode me dizer qual versão devíamos seguir? E se for a primeira, onde em geral posso achar a classificação das vias na cidade? Acabei de ver que São Paulo tinha uma tal lista ([1]), mas não sei onde achar essas classificações para outras cidades. Abraço Martin [1] http://www.prefeitura.sp.gov.br/cidade/secretarias/habitacao/departamentos/aprov/index.php?p=3303 ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br -- Aviso de confidencialidade: Esta mensagem da Empresa Brasileira de Pesquisa Agropecuária (Embrapa), empresa pública federal regida pelo disposto na Lei Federal nº 5.851, de 7 de dezembro de 1972, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco. Confidentiality note: This message from Empresa Brasileira de Pesquisa Agropecuária (Embrapa) a government company established under Brazilian law (5.851/72) is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Classificação de vias
Acho que highway=track fica bom para uma estrada de acesso a uma fazenda, que passa por dentro da fazenda e não é usada para ir de uma localidade a outra. Em 15-06-2012 12:32, Rodrigo Avila escreveu: Pela descrição do wiki essa tag se aplica mais a uma estrada de roça do que a uma estrada de interior... Rodrigo Avila Em 15/06/2012 12:24, vitor vitor.geo...@gmail.com mailto:vitor.geo...@gmail.com escreveu: Talvez 'highway=track', não? http://wiki.openstreetmap.org/wiki/Tag:highway=track Vitor George mapaslivres.org http://mapaslivres.org twitter.com/mapaslivres http://twitter.com/mapaslivres 2012/6/15 Hermann Peifer pei...@gmx.eu mailto:pei...@gmx.eu Olá, Tenho uma pergunta relacionada as definições de rodovias em áreas rurais [1]: É verdade que uma estrada municipal não-pavimentada nunca pode ser na categoria tertiary? Este tipo de estrada tem que ser mapeado como: unclassified ? As definições do Wiki: --- snip --- unclassified = Estrada não pavimentada, de administração municipal. tertiary = Estrada não pavimentada, federal ou estadual, ou rodovia pavimentada municipal. --- snip --- Abs, Hermann [1] http://wiki.openstreetmap.org/__wiki/Pt-br:Guia_de_Mapeamento___do_Territ%C3%B3rio_Brasileiro http://wiki.openstreetmap.org/wiki/Pt-br:Guia_de_Mapeamento_do_Territ%C3%B3rio_Brasileiro On 14/06/2012 16:20, Flavio Bello Fialho wrote: Alterei o Wiki. Agora as duas definições estão coerentes. Em 12-06-2012 12:40, martin137-hi6Y0CQ0nG0@public.__gmane.org mailto:martin137-hi6y0cq0...@public.gmane.org escreveu: Olá, encontrei algumas incoerências na classificação das vias urbanas no wiki e queria perguntar qual é a versão oficial. Dum lado existe uma classificação segundo limites de velocidade e as categorias trânsito rápido, arterial, coletora e local: http://wiki.openstreetmap.org/__wiki/Pt-br:Guia_de_Mapeamento___do_Territ%C3%B3rio_Brasileiro http://wiki.openstreetmap.org/wiki/Pt-br:Guia_de_Mapeamento_do_Territ%C3%B3rio_Brasileiro Dum outro lado existe uma tradução do tag highway que até o tradutor não achou oficial (e que ignora os aspectos acima): http://wiki.openstreetmap.org/__wiki/Pt-br:Key:highway http://wiki.openstreetmap.org/wiki/Pt-br:Key:highway Alguém pode me dizer qual versão devíamos seguir? E se for a primeira, onde em geral posso achar a classificação das vias na cidade? Acabei de ver que São Paulo tinha uma tal lista ([1]), mas não sei onde achar essas classificações para outras cidades. Abraço Martin [1] http://www.prefeitura.sp.gov.__br/cidade/secretarias/__habitacao/departamentos/aprov/__index.php?p=3303 http://www.prefeitura.sp.gov.br/cidade/secretarias/habitacao/departamentos/aprov/index.php?p=3303 _ Talk-br mailing list Talk-br@openstreetmap.org mailto:Talk-br@openstreetmap.org http://lists.openstreetmap.__org/listinfo/talk-br http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org mailto: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 -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br -- Aviso de confidencialidade: Esta mensagem da Empresa Brasileira de Pesquisa Agropecuária (Embrapa), empresa pública federal regida pelo disposto na Lei Federal nº 5.851, de 7 de dezembro de 1972, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco. Confidentiality note: This message from Empresa Brasileira de Pesquisa Agropecuária (Embrapa) a government company established under Brazilian law (5.851/72) is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure
Re: [Talk-br] Classificação de vias
Alterei o Wiki. Agora as duas definições estão coerentes. Em 12-06-2012 12:40, martin...@gmx.net escreveu: Olá, encontrei algumas incoerências na classificação das vias urbanas no wiki e queria perguntar qual é a versão oficial. Dum lado existe uma classificação segundo limites de velocidade e as categorias trânsito rápido, arterial, coletora e local: http://wiki.openstreetmap.org/wiki/Pt-br:Guia_de_Mapeamento_do_Territ%C3%B3rio_Brasileiro Dum outro lado existe uma tradução do tag highway que até o tradutor não achou oficial (e que ignora os aspectos acima): http://wiki.openstreetmap.org/wiki/Pt-br:Key:highway Alguém pode me dizer qual versão devíamos seguir? E se for a primeira, onde em geral posso achar a classificação das vias na cidade? Acabei de ver que São Paulo tinha uma tal lista ([1]), mas não sei onde achar essas classificações para outras cidades. Abraço Martin [1] http://www.prefeitura.sp.gov.br/cidade/secretarias/habitacao/departamentos/aprov/index.php?p=3303 -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br -- Aviso de confidencialidade: Esta mensagem da Empresa Brasileira de Pesquisa Agropecuária (Embrapa), empresa pública federal regida pelo disposto na Lei Federal nº 5.851, de 7 de dezembro de 1972, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco. Confidentiality note: This message from Empresa Brasileira de Pesquisa Agropecuária (Embrapa) a government company established under Brazilian law (5.851/72) is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Subbairros
É melhor usar admin_level=11 do que confundir bairros com subbairros. Quanto aos mapas, procure em: http://wiki.openstreetmap.org/wiki/List_of_OSM_based_Services http://maps.cloudmade.com/editor Não se preocupe em renderizar corretamente. Mapeie corretamente. Não use village para coisas que não são village. O padrão que eu uso (e creio que a maioria dos mapeadores brasileiros também) é: place=city Cidades com mais de 100 mil habitantes place=town Cidades entre 10 mil e 100 mil habitantes place=village Cidades (sede de municípios) com menos de 10 mil habitantes place=hamlet Locais isolados da sede do município Há ainda: place=suburb Bairro de cidades maiores place=neighbourhood Sub-bairro de cidades maiores ou bairro de cidades menores (ver http://wiki.openstreetmap.org/wiki/Place) Em 23-05-2012 11:03, Eduardo Medeiros escreveu: O admin_level=11 já foi aceito? Achei que ainda fosse somente proposta. Foi citado que o mapnik seria uma de muitas representações. Poderiam citar os outros meios? Preciso visualizar o bairro com os subbairros. No momento enquanto não funciona, estava registrando com 'village', que embora saiba que esta incorreto, renderiza corretamente, para depois atualizar para 'neighbourhood'. Pelo que vi no projeto mapnik, ele renderiza baseado no arquivo 'default.style', que provavelmente não deve ter uma definição padrão, para o recém aceito neighbourhood. []s, Eduardo Medeiros ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Dúvidas sobre mapeamento de praças
verde. Ex.: Praça da Liberdade [2], Praça Raul Soares [3] - Parques: Regiões verdes maiores e presentes apenas dentro de cidades. Podem possuir construções, mas são majoritariamente verdes. Ex: Parque do Ibirapuera [4], Parque Municipal de Belo Horizonte [5], Parque Portugal [6] - Bosques: Áreas verdes pequenas dentro de cidades. Normalmente possuem poucas ou nenhuma regiões pavimentadas. Ex.: Bosque dos Italianos [7] Estas são apenas as classificações mais comuns que imaginei. Devem haver diversos outros tipos menos comuns. Após ler diversas páginas da wiki eu interpretei o seguinte: - Praças pavimentadas: seriam mapeadas como áreas e com highway=pedestrian e area=yes. Caso hajam árvores, elas podem ser mapeadas como nós com a chave natural=tree - Praças verdes: seriam mapeadas como áreas com a chave landuse=village_green - Bosques: mapeados como áreas com a chave landuse=forest - Parques: seriam mapeados como áreas com a chave leisure=park Entretanto, eu não percebi estas regras serem seguidas nas cidades que estou ajudando a mapear. E, infelizmente, não consegui levantar um padrão. Existem mapeamentos mais completos, como a Praça Raul Soares, que são muito bem vindos e devem ser melhor discutidos a forma de mapeá-los. Qual é a opinião de vocês? Já existe um padrão que eu não percebi? Referências: [1] - http://pt.wikipedia.org/wiki/Pra%C3%A7a_Sete_de_Setembro [2] - http://pt.wikipedia.org/wiki/Pra%C3%A7a_da_Liberdade_%28Belo_Horizonte%29 [3] - http://pt.wikipedia.org/wiki/Pra%C3%A7a_Raul_Soares [4] - http://pt.wikipedia.org/wiki/Parque_do_Ibirapuera [5] - http://pt.wikipedia.org/wiki/Parque_Municipal_de_Belo_Horizonte [6] - http://pt.wikipedia.org/wiki/Parque_Portugal [7] - http://www.bosquedositalianos.org.br/ Abraços, -- Tulio Magno ___ 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 -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br -- Aviso de confidencialidade: Esta mensagem da Empresa Brasileira de Pesquisa Agropecuária (Embrapa), empresa pública federal regida pelo disposto na Lei Federal nº 5.851, de 7 de dezembro de 1972, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco. Confidentiality note: This message from Empresa Brasileira de Pesquisa Agropecuária (Embrapa) a government company established under Brazilian law (5.851/72) is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Evento Comunitário no FISL
Esse ano infelizmente não vou poder participar, mas acho MUITO importante a divulgação do OSM no FISL, principalmente para recrutar novos mapeadores. Em 05-05-2011 11:04, Samuel Vale escreveu: Olá pessoal, Eventos comunitários do FISL podem ser inscritos até dia 10/05/2011. http://softwarelivre.org/fisl12/atracoes/eventos-comunitarios Em 2010 tivemos uma palestra com um público razoável, e tivemos um mini encontro de mapeadores presentes. Estavam lá Arlindo, Claudomiro, Flávio, Richs (mapper da Latvia(?) que estava por lá), Djavan e eu. Me perdoe se esqueci alguém. Acho que foi bem proveitoso, e comentamos de tentar fazer algo mais prático este ano, ou tentar complementar palestra com algo mais prático. Eu ainda não confirmei se irei desta vez, mas estou lançando a ideia aí, para o caso de alguém que esteja planejando aparecer por lá quiser propor algo. Que acham? Abraço, ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br -- Aviso de confidencialidade: Esta mensagem da Empresa Brasileira de Pesquisa Agropecuária (Embrapa), empresa pública federal regida pelo disposto na Lei Federal nº 5.851, de 7 de dezembro de 1972, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco. Confidentiality note: This message from Empresa Brasileira de Pesquisa Agropecuária (Embrapa) a government company established under Brazilian law (5.851/72) is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Duvida Public GPS traces
Eu uso source=gps quando uso a informação do GPS sem maiores detalhes, e source=survey quando, além disso, coleto informações complementares no local, como velocidade máxima, número de pistas, nome e sentido da rua, tipo de pavimentação, etc. Em 03-02-2011 10:19, Leandro Motta Barros escreveu: 2011/2/2 David Kurkadavid.ku...@gmail.com: 2011/2/2 Leandro Motta Barroslmbar...@gmail.com 2011/2/2 David Kurkadavid.ku...@gmail.com: [...] Tendo imagens de alta resolução do Bing disponíveis, vale a pena investir em traces gps? (pessoas além do Alexandre podem me responder isso também! :)) Se eu não sonhei, eu li em lugar (Wiki do OSM, provavelmente) que esses traces são bons até como uma prova em uma eventual ação legal (nós não copiamos, olha só: teve colaborador nosso passando por ali) a melhor forma de identificar isso, é através da tag source, certo? logo, ruas com tag source=gps devem ter prioridade à source=gps? Er, prá mim, source=gps é a mesma coisa que source=gps ;-P OK, sério agora: acho que o pessoal já respondeu aí, mas o que eu também costumo fazer é colocar source=survey nas vias por onde eu passei com GPS e gravador. (Muitas vezes uso survey junto com outras fontes, como source=survey, Bing, IBGE) Fora isso, para mim, a forma mais divertida de mapear é usar um GPS e um gravador de som. Dá para pegar muitos detalhes (POIs, em particular) que não dá para ver pelas imagens aéreas. eu também acho bem divertido... eu tava quase terminando de andar de bicicleta por todas as ruas de barão geraldo (distrito de Campinas), quando chegaram as imagens do bing... :) agora deu mais preguiça de continuar... OSM faz bem pra saude! :) ;-) LMB ___ 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] Censo 2010
Rodar o script com 250 municípios resulta em 250*249=62250 rotas. Rodar o script com 5500 municípios resulta em mais de 30 milhões de rotas, o que é inviável. Sugiro rodar o script para todos os municípios separado por estado, ou seja, fazer uma tabela por estado. Em estados muito grandes (Ex: Minas Gerais), talvez seja interessante dividir o estado em partes e rodar o script para todos os municípios de cada parte. Em 18-12-2010 12:14, vitor escreveu: Oi Bráulio, Eu rodei o Brasil 250 cidades recentemente e vi que o nível de conexões ultrapassou 80%. Assim que tiver um tempo, enviarei o relatório. Para a próxima etapa, estou almejando ligar todos os municípios brasileiros no mapa, que são aproximadamente 5500. Como é bem trabalhoso identificar as coordenadas do municípios manualmente, vou usar o osmosis e outras ferramentas para atualizar/criar nós place com os municípios, e criar rotas a partir deles. Com isso, eu poderia colocar a população, se não for difícil. Mas eu acho melhor colocar o código IBGE da cidade, ao invés da população. Assim, garantirmos que as cidades estejam geo-referenciadas definitivamente, e quem quisesse levar em conta população, população rural, população feminina ou qualquer outro aspecto do censo atual, futuro ou anteriores, poderia usar um banco de dados paralelo, geo-referenciando pelo código IBGE. Vitor 2010/12/17 Bráulio brauliobeze...@gmail.com mailto:brauliobeze...@gmail.com Pessoal, Saíram alguns resultados do censo 2010. Quem está afim de atualizar a população de todos municípios do Brasil? :P http://www.ibge.gov.br/home/estatistica/populacao/censo2010/populacao_por_municipio.shtm Também tem várias coisas coisas legais no resto do site do censo: http://www.censo2010.ibge.gov.br/index.php ___ Talk-br mailing list Talk-br@openstreetmap.org mailto: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 -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br -- Aviso de confidencialidade: Esta mensagem da Empresa Brasileira de Pesquisa Agropecuária (Embrapa), empresa pública federal regida pelo disposto na Lei Federal nº 5.851, de 7 de dezembro de 1972, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco. Confidentiality note: This message from Empresa Brasileira de Pesquisa Agropecuária (Embrapa) a government company established under Brazilian law (5.851/72) is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Diferença entre GPX/Imagens de Satél ite
Em 26-11-2010 17:34, Johan Dahlin escreveu: São Carlos tem mesmo problema, veja aqui: http://yfrog.com/5j979kp Mas o error é bem minor. Acho em caso vale pena mudar todos os pontos para ser alinhadas com os dados do Bing. NÃO FAÇA ISSO! As imagens de satélite têm erro. O GPS está correto, pelo menos na média. Pode acontecer de uma trilha estar deslocada por erro de leitura do GPS, mas o mapa deve corresponder à realidade, e não à imagem de satélite. Se o GPS for passado várias vezes em dias diferentes no mesmo local, o traço médio estará correto. É comum ver a mesma estrada em dois lugares diferentes no limite entre imagens no Google. Isso acontece por erro na ortorretificação ou na amarração da imagem de satélite ao campo (que deve ser feito com GPS). O melhor é tentar deslocar a imagem de forma que traços conhecidos coincidam com o GPS e depois traçar o que falta com a imagem. -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br -- Aviso de confidencialidade: Esta mensagem da Empresa Brasileira de Pesquisa Agropecuária (Embrapa), empresa pública federal regida pelo disposto na Lei Federal nº 5.851, de 7 de dezembro de 1972, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco. Confidentiality note: This message from Empresa Brasileira de Pesquisa Agropecuária (Embrapa) a government company established under Brazilian law (5.851/72) is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Diferença entre GPX/Imagens de Satél ite
É bom deixar o aparelho ligado alguns minutos antes de começar a registrar a trilha. Áreas com muita interferência (canyons, prédios, serra, mato) são um problema. Por isso é melhor traçar as rotas mais de uma vez antes de usá-las como referência para corrigir as imagens. Creio que as imagens do Bing sejam ortorretificadas, se não não haveria sentido em usá-las, mas não sei sobre a precisão do processo. De qualquer modo, eu confio mais em cinco trilhas de GPS do que numa imagem. Em 29-11-2010 10:43, Ricardo Padilha escreveu: Na minha opinião, o maior problema não são imagens deslocadas. Como o Claudomiro disse basta um script para pegar a área e aplicar um delta nas coordenadas. O problema maior de se basear em imagens é se elas não são corretamente achatadas (ortoretificadas). Nesse caso, podem haver distorções muito difíceis de corrigir com um simples script. Alguém sabe se o problema é apenas deslocamento ou se temos problemas de rotação e/ou distorção tridimensional? Além disso, eu não confiaria muito nos dados do GPS... não antes de dar uma boa olhada no HDOP (Horizontal Dilution Of Precision [1]), que indica a precisão dos dados. Já me aconteceu várias vezes de ter um error de vários metros entre a posição real e a posição indicada no GPS, principalmente logo depois de ligar o aparelho ou quando estou em áreas com muita interferência. Alguém sabe se algum dos softwares leva em conta o HDOP? Seria legal que mostrassem a trilha com uma espessura de linha proporcional ao erro. Att, Ricardo [1]: http://en.wikipedia.org/wiki/Dilution_of_precision_(GPS) 2010/11/29 Claudomiro Nascimento Junior claudom...@claudomiro.com mailto:claudom...@claudomiro.com Eu também acho que se já houver uma boa base de dados coletada com GPS, não se deve mover tudo para bater com as fotos de satélite. Tanto no Potlatch como no JOSM é possível deslocar as imagens pra bater com os dados existentes. Agora, nas cidades onde não há quase nenhum dados antes da disponibilidade das fotos, acho que é mellhor usar as fotos como referência e em algum ponto no futuro fazer um trabalho de ajuste fino para seguir uma referência mais exata. 2010/11/29 Flavio Bello Fialho be...@cnpuv.embrapa.br mailto:be...@cnpuv.embrapa.br Em 26-11-2010 17:34, Johan Dahlin escreveu: São Carlos tem mesmo problema, veja aqui: http://yfrog.com/5j979kp Mas o error é bem minor. Acho em caso vale pena mudar todos os pontos para ser alinhadas com os dados do Bing. NÃO FAÇA ISSO! As imagens de satélite têm erro. O GPS está correto, pelo menos na média. Pode acontecer de uma trilha estar deslocada por erro de leitura do GPS, mas o mapa deve corresponder à realidade, e não à imagem de satélite. Se o GPS for passado várias vezes em dias diferentes no mesmo local, o traço médio estará correto. É comum ver a mesma estrada em dois lugares diferentes no limite entre imagens no Google. Isso acontece por erro na ortorretificação ou na amarração da imagem de satélite ao campo (que deve ser feito com GPS). O melhor é tentar deslocar a imagem de forma que traços conhecidos coincidam com o GPS e depois traçar o que falta com a imagem. -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br mailto:be...@cnpuv.embrapa.br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br -- Aviso de confidencialidade: Esta mensagem da Empresa Brasileira de Pesquisa Agropecuária (Embrapa), empresa pública federal regida pelo disposto na Lei Federal nº 5.851, de 7 de dezembro de 1972, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco. Confidentiality note: This message from Empresa Brasileira de Pesquisa Agropecuária (Embrapa) a government company established under Brazilian law (5.851/72) is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Importação incorreta no Brasil
Parece ser alguém de Curitiba, pelas outras edições. Sugiro que alguém desfaça o conjunto de alterações #6234414, pois parece ser lixo. Em 09-11-2010 09:27, vitor escreveu: Alguém pode contatar este usuário sodeiro? Ele tentou enviar uma planta dwg sem preparar o arquivo para a projeção correta. -- Forwarded message -- From: *MP* singular...@gmail.com mailto:singular...@gmail.com Date: Tue, Nov 9, 2010 at 1:17 AM Subject: [OSM-talk] Changeset 6234414 To: t...@openstreetmap.org mailto:t...@openstreetmap.org Does anybody have idea what it is? Seems to be large lot of untagged lines in middle of the ocean and I don't see what it could be (coral reefs? some under-sea features?). http://www.openstreetmap.org/browse/changeset/6234414 What should be done with similar uploads, if the ways are untagged and it is not very clear what they should be? Google translate told the summary is map made in autocad and being passed on to the OSM which isn't very explanatory about source and purpose of the data. Martin ___ talk mailing list t...@openstreetmap.org mailto:t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] A BR-101 sumiu
Tudo bem. Consegui restaurar a mão, seguindo os passos em: http://wiki.openstreetmap.org/wiki/Undoing_Deletions#Recover_deleted_Relations Agora está funcionando: http://www.openstreetmap.org/browse/relation/53556 Em 27-09-2010 14:30, Samuel Vale escreveu: On Seg, 2010-09-27 at 14:03 -0300, Flavio Bello Fialho wrote: Alguém pode restaurar? Eu não sei como. Apesar das obras, tenho certeza que a BR-101 ainda existe no mundo real. Em 27-09-2010 13:53, Ronaldo Maia escreveu: Não seria o caso de restaurar, ou entrar em contato com quem apagou? Pode ter sido apagada por engano. Parece ser um mapeador novo: http://www.openstreetmap.org/user/fsbrace []s Opa, Eu posso reverter o changeset dele inteiro, se constarmos se houve o apagamento. Infelizmente ele fez um changeset enorme :(, vamos voltar muita coisa. Abraço, ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br -- Aviso de confidencialidade: Esta mensagem da Empresa Brasileira de Pesquisa Agropecuária (Embrapa), empresa pública federal regida pelo disposto na Lei Federal nº 5.851, de 7 de dezembro de 1972, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco. Confidentiality note: This message from Empresa Brasileira de Pesquisa Agropecuária (Embrapa) a government company established under Brazilian law (5.851/72) is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] A BR-101 sumiu
Alguém sabe o que houve com a BR-101? http://www.openstreetmap.org/browse/relation/53556 -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br -- Aviso de confidencialidade: Esta mensagem da Empresa Brasileira de Pesquisa Agropecuária (Embrapa), empresa pública federal regida pelo disposto na Lei Federal nº 5.851, de 7 de dezembro de 1972, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco. Confidentiality note: This message from Empresa Brasileira de Pesquisa Agropecuária (Embrapa) a government company established under Brazilian law (5.851/72) is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] A BR-101 sumiu
Alguém pode restaurar? Eu não sei como. Apesar das obras, tenho certeza que a BR-101 ainda existe no mundo real. Em 27-09-2010 13:53, Ronaldo Maia escreveu: Não seria o caso de restaurar, ou entrar em contato com quem apagou? Pode ter sido apagada por engano. Parece ser um mapeador novo: http://www.openstreetmap.org/user/fsbrace []s -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br -- Aviso de confidencialidade: Esta mensagem da Empresa Brasileira de Pesquisa Agropecuária (Embrapa), empresa pública federal regida pelo disposto na Lei Federal nº 5.851, de 7 de dezembro de 1972, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco. Confidentiality note: This message from Empresa Brasileira de Pesquisa Agropecuária (Embrapa) a government company established under Brazilian law (5.851/72) is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] A BR-101 sumiu
Uma rodovia pode ter dois números sem problemas. O ideal é que haja uma relação para cada rota, ou seja, uma relação para a BR-101 (no caso, a 53556), uma para a BR-376, etc. No Paraná, a BR-101 está apenas planejada, conforme http://www.transportes.gov.br/bit/trodo/br-101/gbr-101.htm, contendo os seguintes trechos: DIV SP/PR - ENTR PR-405 ENTR PR-405 - ENTR PR-340 (ANTONINA) ENTR PR-340 (ANTONINA) - ENTR BR-277 ENTR BR-277 - DIV PR/SC (ENTR BR-376) Sugiro verificar o trajeto das BRs em http://www.transportes.gov.br/bit/br/BRs.htm O problema foi que, na edição, foi deletada a relação da BR-101. Sugiro que inicies usando o Potlatch. O JOSM é mais complicado e pode resultar, por acidente, em problemas como esse. Ainda precisamos restaurar a relação da BR-101, que já estava na versão 340. Em 27-09-2010 14:25, Fabrício Souza escreveu: Olá Estou inscrito na lista, porém não sei porque não estou recebendo os e-mails, apenas alguns (Já verificado configurações do mailing) Vamos aos fatos: Adicionei o trecho da BR-376 que somente no Paraná ela tem esse nome. O trecho adicionado é da represa do Vossoroca até a divisa do estado de Santa Catarina - Norte Sul. Adicionado o Pedágio que fica na altura da cidade de Garuva, Adicionado o trevo que liga a PR-416 em Garuva a BR-101. Todo o trajeto foi feito baseado no meu GPS, pois trafeguei pela rodovia. Obs. Tenho observado que quando atualizado uma parte do mapa ou adicionado ruas, elas demoram quase um dia para aparecer na pagina do OSM, e estou verificado agora a pagina do OSM e a BR está lá. Grato pela atenção e desculpa pelo inconveniente. Abraços Fabrício S. Souza +55 41 9686-4187 Em 27 de setembro de 2010 14:07, Rafael Gassner rafael.gass...@gmail.com mailto:rafael.gass...@gmail.com escreveu: Olá Estou falando com o Fsbrace, e ele disse que apenas renomeou para BR 376 no Paraná e adicionou uns trechos novos. Recomendei para que ele entre na lista. Abraço, 2010/9/27 Flavio Bello Fialho be...@cnpuv.embrapa.br mailto:be...@cnpuv.embrapa.br Alguém pode restaurar? Eu não sei como. Apesar das obras, tenho certeza que a BR-101 ainda existe no mundo real. Em 27-09-2010 13:53, Ronaldo Maia escreveu: Não seria o caso de restaurar, ou entrar em contato com quem apagou? Pode ter sido apagada por engano. Parece ser um mapeador novo: http://www.openstreetmap.org/user/fsbrace []s -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br mailto:be...@cnpuv.embrapa.br -- Aviso de confidencialidade: Esta mensagem da Empresa Brasileira de Pesquisa Agropecuária (Embrapa), empresa pública federal regida pelo disposto na Lei Federal nº 5.851, de 7 de dezembro de 1972, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco. Confidentiality note: This message from Empresa Brasileira de Pesquisa Agropecuária (Embrapa) a government company established under Brazilian law (5.851/72) is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure. ___ Talk-br mailing list Talk-br@openstreetmap.org mailto:Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Rafael Gustavo Gassner 55 41 9821-8368 ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br -- Aviso de confidencialidade: Esta mensagem da Empresa Brasileira de Pesquisa Agropecuária (Embrapa), empresa pública federal regida pelo disposto na Lei Federal nº 5.851, de 7 de dezembro de 1972, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco. Confidentiality note: This message from Empresa Brasileira de Pesquisa Agropecuária (Embrapa) a government company established under Brazilian law (5.851/72) is directed exclusively to its addressee and may contain confidential data
Re: [Talk-br] Ajuda para iniciantes
Bem-vindo(a) ao projeto. Eu mapeei uma parte (pequena) de Porto Alegre. Não moro em Porto, mas estou perto. A melhor forma é usar essa lista para tirar dúvidas, coordenar esforços, etc. Uma dica é visitar a página do projeto no Brasil: http://wiki.openstreetmap.org/wiki/WikiProject_Brazil O mapeamento da Restinga está bem fraco, por enquanto: http://www.openstreetmap.org/?lat=-30.1543lon=-51.1337zoom=14layers=M Toda ajuda é bem-vinda. Em 15-08-2010 20:07, venu...@riseup.net escreveu: Olá todos e todas mapeadoras. Estou iniciando o uso do open e gostaria de fazer contato direto com mapeadores em Porto Alegre. Como seria isso? Grande abraço da Restinga ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] FISL
Estou no FISL. A palestra do OSM está marcada para amanhã (23/7) às 16:00h. Espero encontrar alguém lá. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Ilha mapeada como lago
O problema não é no Mapnik. Lá o render funciona. O problema é no Osmarender. Em 18-06-2010 19:03, Claudomiro Nascimento Junior escreveu: É um processo a parte que gera esses quadrados de cor errada. Mesmo após a linha costeira ter sido corrigida, pode-se ter que esperar um pouco até a correção aparecer http://wiki.openstreetmap.org/wiki/Coastline#Main_Mapnik_Layer 2010/6/18 Arlindo Pereiraopenstreet...@arlindopereira.com: Já tentou ritual de exorcismo na ilha??? :D Brincadeirinha. Bom, não faço ideia, tentei botar um /dirty no final como os tiles gerados pelo Mapnik para ver, mas não funciona com o Osmarender. Meu chute seria inverter o sentido da via que compõe as ilhas. []s Em 18 de junho de 2010 17:24, Flavio Bello Fialhobe...@cnpuv.embrapa.br escreveu: Há um lugar no meio da Lagoa dos Patos que tem duas ilhas. O Osmarender insiste em mapear o Tile como terra e as ilhas como lagos: http://www.openstreetmap.org/?lat=-31.763lon=-52.077zoom=12layers=0B00FTF O que está acontecendo e como corrigir a situação? -- Flávio Bello Fialho ___ 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 -- Flávio Bello Fialho ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] FISL 11 - 21 a 24/07 em Porto Alegre
O prazo para inscrição de palestras no FISL se encerra segunda-feira. Arlindo, já que te dispõe, peço que inscreva a palestra, creio que na seção Tópicos Emergentes: http://softwarelivre.org/fisl11 Acho que a palestra é um bom local para nos reunirmos. Como já foi dito, o objetivo é dar visibilidade ao projeto e aumentar o número de membros do projeto. Vitor George escreveu: Oi Mauro, Com certeza o que interessa agora é trazer visibilidade ao projeto. Entra no www.mapaslivres.org http://www.mapaslivres.org que lá tem um vídeo introdutório que fiz. Abraços, Vitor 2010/5/3 Mauro Borowsky mauro...@gmail.com mailto:mauro...@gmail.com Pessoal, Sou de Porto Alegre, se precisarem acho que estarei disponível, não todo o tempo, para ajudar no FISL. Que coisa, estava pensando agora sobre isto e até hoje não sei se tem mais pessoas daqui no OSM, e se tem, quem são? Vou dar minha opinião: se o que o OSM precisa é de pessoas interessadas, precisamos aproveitar o FISL para divulgar, seria interessante ter algum brinde para sorteio ou camisetas para vender, isto é um excelente chamariz, não sei qual é a política do OSM quanto a isto. Também acho que é importante conseguir pessoas nos estados/cidades que entendam muito de OSM e fazer encontros mensais o bimestrais para ensinar como fazer as coisas certas, acho que simplesmente dizer que tem o WIKI para aprender não da muito resultado, as pessoas não vão procurar a informação e também não vão ter a certeza de estar fazendo a coisa correta. O melhor é colocar a Mão na massa e aprender praticando e em grupo já tiraria duvidas comuns. Quem sabe criar vídeos explicativos, não sei se já existe, em português e colocar no Youtube ou outro site Também só estou dando idéias, fazer que é bom neneca de pitibiriba, o meu problema, e creio que de todos, é tempo para se dedicar. Muito do que fiz no OSM foi por tentativa e erro, e de ver como os outros fizeram, e isto acho que não ajuda muito. Bem, só coloquei lenha na fogueira, mas o que queria dizer mesmo é que estou a disposição do que precisarem, o que estiver ao meu alcance, podem contar comigo. Ah!!! só não pesam para eu ficar dia 22/07 no FISL11, é meu aniversário hehehehehe Mauro R J Borowsky. Em 03/05/2010 12:00, talk-br-requ...@openstreetmap.org mailto:talk-br-requ...@openstreetmap.org escreveu: Send Talk-br mailing list submissions to talk-br@openstreetmap.org mailto:talk-br@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstreetmap.org/listinfo/talk-br or, via email, send a message with subject or body 'help' to talk-br-requ...@openstreetmap.org mailto:talk-br-requ...@openstreetmap.org You can reach the person managing the list at talk-br-ow...@openstreetmap.org mailto:talk-br-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-br digest... Tópicos de Hoje: 1. Re: FISL (Samuel Vale) 2. Re: FISL (Claudomiro Nascimento Junior) 3. Re: FISL (Samuel Vale) 4. Re: FISL (Arlindo Pereira) 5. Re: FISL (Claudomiro Nascimento Junior) 6. Re: FISL (Samuel Vale) 7. Re: Cartão de Visitas (Vitor George) -- Message: 1 Date: Mon, 03 May 2010 11:17:58 -0300 From: Samuel Vale srcv...@minaslivre.org mailto:srcv...@minaslivre.org Subject: Re: [Talk-br] FISL To: talk-br@openstreetmap.org mailto:talk-br@openstreetmap.org Message-ID: 1272896278.3711.74.ca...@paladino.holoscopio.com mailto:1272896278.3711.74.ca...@paladino.holoscopio.com Content-Type: text/plain; charset=utf-8 Em Seg, 2010-05-03 às 10:28 -0300, Flavio Bello Fialho escreveu: Estão abertas as inscrições para o 11º Fórum Internacional de Software Livre (FISL). Para quem não conhece, é o maior evento de software livre do mundo (8244 participantes no ano passado) e acontece em Porto Alegre de 21 a 24 de julho. Eu mesmo conheci o OSM numa palestra do FISL. Até dia 9/5, as inscrições são com desconto. Estão abertas também as inscrições para palestras. Acho que seria uma boa oportunidade para divulgar o projeto do OSM, com uma palestra, do tipo: Openstreetmap: Mapas livres ou coisa parecida. Quem se habilita? Ainda diria mais: há espaço para eventos de comunidade. Estive conversando com o Vitor, sobre isso. Se 4 de nós toparem ir ao Fisl, já é interessante fazer isso. Vejam os detalhes aqui: http://softwarelivre.org/fisl11/grupo-de-usuarios É uma boa oportunidade de fazer um encontro nacional do Talk-BR. Mas isso não impede de
Re: [Talk-br] Cartão de Visitas
Não inventa. Explica o projeto, te identifica de forma honesta e diz o quanto os dados podem contribuir para o benefício da sociedade. Arlindo Pereira escreveu: Galera, amanhã o gerente do setor de GIS da prefeitura irá dar uma palestra no mesmo evento em que eu palestrarei no dia seguinte, e eu pretendo abordá-lo com a questão da liberação dos dados para o OSM, e gostaria de passar uma impressão mais profissional, entregando um cartão de visitas. Daí o que vocês acham razoável, me identificar no cartão como Colaborador OpenStreetMap, inventar um cargo fictício tipo Coordenador do Rio de Janeiro ou qualquer outra coisa? Ou mesmo escrever em inglês? :D Ou desencanar da ideia de cartões? Eu gostaria muito de importar esses dados, seria um adianto e tanto para o projeto... Alguém já teve experiência em lidar com gente do governo nessa questão de GIS poderia dar dicas? []s ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br -- Aviso de confidencialidade: Esta mensagem da Empresa Brasileira de Pesquisa Agropecuária (Embrapa), empresa pública federal regida pelo disposto na Lei Federal nº 5.851, de 7 de dezembro de 1972, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco. Confidentiality note: This message from Empresa Brasileira de Pesquisa Agropecuária (Embrapa) a government company established under Brazilian law (5.851/72) is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] FISL
Nunca teve palestra sobre o OSM no FISL. Ele foi citado numa palestra sobre alguma outra coisa. É um mega-público e tenho certeza que o assunto interessa. Vem gente importante do mundo inteiro. Acho que não podemos perder a oportunidade. A inscrição está 80 reais até dia 9/5. Eu já me inscrevi. Se alguém for como palestrante, acho que a organização pode patrocinar a ida, mas tem que submeter uma proposta de palestra até dia 8/5 (neste sábado). Acho que teria que ser algo na linha de apresentar o OSM para a comunidade do FISL. Arlindo Pereira escreveu: Eu irei. Vamos nos encontrar! Posso dar uma palestra Apresentando o OpenStreetMap também, mas se já teve palestra sobre o OSM no FISL talvez seja o caso de fazer algo mais específico, talvez na linha do http://nighto.net/state-of-the-map-brazil-9-months-later/ apresentando os nossos projetos. Vou ver se consigo um busão da faculdade... []s Em 3 de maio de 2010 11:26, Samuel Vale srcv...@minaslivre.org mailto:srcv...@minaslivre.org escreveu: Em Seg, 2010-05-03 às 11:21 -0300, Claudomiro Nascimento Junior escreveu: Eu toparia, depende mais das datas e do investimento ($$$) 2010/5/3 Samuel Vale srcv...@minaslivre.org mailto:srcv...@minaslivre.org: Em Seg, 2010-05-03 às 10:28 -0300, Flavio Bello Fialho escreveu: Estão abertas as inscrições para o 11º Fórum Internacional de Software Livre (FISL). Para quem não conhece, é o maior evento de software livre do mundo (8244 participantes no ano passado) e acontece em Porto Alegre de 21 a 24 de julho. Eu mesmo conheci o OSM numa palestra do FISL. Até dia 9/5, as inscrições são com desconto. (...) O evento será de 21 a 24 de Julho, em Porto Alegue. Em anos anteriores, grupos de usuários recebiam descontos (ou isenção, não me recordo) na inscrição. Abraço, -- Samuel Vale srcv...@minaslivre.org mailto:srcv...@minaslivre.org ___ Talk-br mailing list Talk-br@openstreetmap.org mailto: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 -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br -- Aviso de confidencialidade: Esta mensagem da Empresa Brasileira de Pesquisa Agropecuária (Embrapa), empresa pública federal regida pelo disposto na Lei Federal nº 5.851, de 7 de dezembro de 1972, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco. Confidentiality note: This message from Empresa Brasileira de Pesquisa Agropecuária (Embrapa) a government company established under Brazilian law (5.851/72) is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure. ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Deface construtivo aqui no Rio
, que eu vejo aqui no Rio [1]. Já mandei uma mensagem pedindo que ele mude o tagueamento, não que ele apague as vias, mas que escolha outras tags que não as que aparecerão no mapa para não confundir as pessoas, tipo usar project=light_rail e project=railway:station ao invés de railway=*. Ou vocês acham que é o caso de um revert mesmo? Pensei em reverter de cara, mas de repente é um contato com a galera da UFRJ que ser frutífero. (Sim eu vejo o lado positivo mesmo de um deface) :) []s 1: monitorando no http://twitter.com/osm_rio ___ Talk-br mailing list Talk-br@openstreetmap.org mailto:Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org mailto:Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org mailto:Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org mailto:Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org mailto: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 -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Mapeamento Estado de Goiás
Eu estou criando relations para TODAS as rodovias federais e estaduais do Rio Grande do Sul (as que já não existem, claro). As relations ajudam bastante na verificação. Alguns trachos de rodovias pertencem a quas rotas (Ex: BR-116 e BR-290 entre a ponte do Guaíba e a saída para Canoas, em Porto Alegre). As relation ajudam bastante nesse e em outros aspectos. Experimente os links das rodovias na página: http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/RS/Rodovias_Estaduais Sugiro que cries a página http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/GO/Rodovias_Estaduais de forma semelhante, se não for incômodo. Uma coisa importante é criar a relation com role de forward (ou, excepcionalmente, backward) no caso de trechos onde a rota é apenas num sentido (mão única ou, em alguns casos, mão dupla em que apenas um dos sentidos faz parte da rota). Flávio Henrique escreveu: Ufa! Enfim, após alguns meses, terminei de analisar todas as rodovias do Estado de Goiás e as interliguei. Teoricamente todos os municípios goianos devem estar ligados. Vou rodar o script para ver se há algum problema com as rotas. Próxima etapa é reclassificar os municípios com base na tag /place/ e depois mapear a Capital. Durante a correção das rodovias surgiram algumas dúvidas: no Guia de Mapeamento do projeto http://wiki.openstreetmap.org/wiki/PT:Guia_de_Mapeamento_do_Territ%C3%B3rio_Brasileiro há um link dizendo Use Relações http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Rela%C3%A7%C3%B5es para rodovias maior (sic).. 1) Qual a importância de uma Relation? 2) Qual a influência dela no mapa? 3) Algum critério mais objetivo do que rodovias maior (sic) ? Obrigado e até a próxima! Flávio Henrique ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Key:place
Para quem usa o mapa, o que interessa é o tamanho da cidade. Não faz sentido Guarulhos/SP e Campinas/SP, ambas com mais de 1 milhão de habitantes, terem a mesma classificação que Borá/SP ou Serra da Saudade/MG, ambas com menos de 1000. Sugiro que fique como está: city 100.000 (273 municípios) town 10.000 (2741 municípios) village 1000 (2549 municípios) hamlet 1000 (2 municípios) Como exceção, acho razoável que Borá/SP (pop=837) e Serra da Saudade/MG (pop=890) sejam classificados como village, já que são os dois únicos municípios brasileiros com menos de 1000 habitantes. Sempre colocar também a população, usando como fonte o IBGE: ftp://ftp.ibge.gov.br/Estimativas_Projecoes_Populacao/Estimativas_2009/UF_Municipio.zip Flávio Henrique escreveu: Eu não tenho óbice em nenhuma das duas formas de classificação. Tenho a tendência em gostar mais da opção proposta por você Alexandre. Entretanto, tenho uma dúvida no seguinte trecho: pois em certos municípios do brasil teríamos varias villages, e não seria possível definir qual a sede do município. Qual o impacto disso no osm? Até o presente momento não vi onde estas informações influenciam no mapa. Grato. Flávio Henrique On Thu, Mar 4, 2010 at 23:34, Alexandre Parente Lima alexandre.pare...@gmail.com mailto:alexandre.pare...@gmail.com wrote: Bom dia. Segundo a wiki do openstreetmap, /In //most// Western //countries//, //the// status //of// a //location// (//whether// //it// //is// a //city/town///etc.), //is// //decided// //by// //the// //government//, //and// //is// //not// a //function// //of// //size//. //But// //most// //OSM// //communities// //of// //those// //countries// //have// made a //convention// to use //the// //population// to decide //which// //place// //tag// to use, to //ensure// a more //common// //way// //of// //tagging// //across// //the// //globe//, //and// //not// to //end// up //with// //cities// //of// 1000 //residents// for //example//. In //any// case, //check// //the// //country// //pages// //on// //this// //wiki// to decide //how// to //tag// a //place// in //each// //specific// //country//./ Dessa forma, gostaria de um posicionamento quanto ao uso da tag /place/. Hoje, utilizamos o numero de habitantes para definir se um aglomerado urbano é uma /city//, //town//, , //village//, //halmet/. Acredito que isso não contribui com muita em termos de informação, pelo contrario, pode até confundir, pois em certos municípios do brasil teríamos varias villages, e não seria possível definir qual a sede do município. Minha sugestão seria: *Capitais :* /City/ *Municípios:* /Town/ *Distritos: */Village/ *Vilas, Assentamentos rurais , comunidades, etc, etc : */Halmet/ *Junto ao uso da **tag**:** *population=number Alexandre Parente Lima ___ Talk-br mailing list Talk-br@openstreetmap.org mailto: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 -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Relatório Semanal: 17/02/2010
Duas considerações: 1. No grid, é melhor deixar a lista com a sigla do estado primeiro e depois o nome da cidade. Assim fica mais fácil visualizar problemas locais (que é onde as correções efetivamente ocorrem). 2. Na lista da 2ª fase, ficaram fora 3 cidades da 1ª fase: Santana do Livramento, RS (que estava listada só como Livramento), União da Vitória, SC e São Matheus, ES. A primeira é uma cidade de fronteira e é importante que esteja no grid, para podermos conectar o Brasil inteiro. Pela segunda passa muito do fluxo entre o oeste de SC e RS e o sudeste do Brasil (quem já foi de ônibus de lá para São Paulo conhece). A terceira eu não conheço, mas estava na lista da 1ª fase. Coloquei-as de volta na lista. Vitor George escreveu: *Status dos Projetos OSM-br* * B250C - Brasil 250 Cidades* Página do Projeto: http://wiki.openstreetmap.org/wiki/WikiProject_Brazil/Brasil_250_Cidades *1a. fase* - *CONCLUÍDA!!!* *2a. fase* Conectividade em *36.96%* Grid Atualizado (html): http://mapaslivres.org/cidades-distancias.html (13 Mb) Grid Atualizado (zip): http://mapaslivres.org/cidades-distancias.zip http://mapaslivres.org/cidades-distancias.html (2 Mb) *JOSM - Tradução ao português* Página do Projeto: https://translations.launchpad.net/josm/trunk/+pots/josm Indicador: Percentual de strings traduzidas em *57.83% (+10,59% na semana)* *Site osm.org http://osm.org - Tradução ao português * Página do Projeto: http://translatewiki.net/wiki/Translating:OpenStreetMap/stats/trunk/site Indicador: String Traduzidas em* 92.25% (+0.06% na semana)* *Potlach* - *Tradução ao português* Página do Projeto: http://translatewiki.net/wiki/Translating:OpenStreetMap/stats/trunk/potlatch Indicador: String Traduzidas em *100%*! ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho Pesquisador, Embrapa Uva e Vinho be...@cnpuv.embrapa.br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Pardais
Eu sei que pelo menos alguns aparelhos Garmin poderiam usar a informação para avisar sobe pardais. Já vi sites que disponibilizam listas de pardais para usar nesses aparelhos. Será que haveria como fazer um patch no mkgmap ou fazer algum outro script para que possamos usar a informação do OSM nos GPS de carro? Rodrigo Avila escreveu: Eu já. Fiz da forma como o Samuel comentou. Só que eles não são renderizados no mapa, e o mkgmap também não se aproveita deles. -- Rodrigo de Avila Analista de Desenvolvimento +55 51 9733.3488 • rodr...@avila.net.br • www.avila.net.br 2010/2/1 Flavio Bello Fialho be...@cnpuv.embrapa.br: Alguém já mapeou pardais? -- Flávio Bello Fialho ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br -- Flávio Bello Fialho ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Pardais
Alguém já mapeou pardais? -- Flávio Bello Fialho ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
