Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download
PessoALL, Sou do Rio de Janeiro e estou dando manutenção no OSM desde novembro de 2013 (estou aprendendo bastante!) e vim pedir ajuda, principalmente aos colaboradores do Rio de Janeiro que conhecem bem os trechos que irei falar... Fiquei bastante contente ao conseguir minha primeira compilação, depois de algumas tentativas e erros, finalmente tenho um script que roda liso. Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns problemas: Mapa RJ: A ponte Rio/Niterói só vai até a ilha de Mocanguê sentido Niterói/Rio e aparece uma outra estrada ao lado que parece ser ela. O contorno da orla vindo pela Av. do Contorno está dentro d'água e vai assim por toda orla de Niterói, as ruas da Ilha da Conceição(Niterói) estão sobre a Baia de Guanabara. Tracei uma rota de São Gonçalo (onde moro) até João Pessoa e para minha surpresa, o GPS começa a rota por uma estrada(possivelmente a BR-101) só que pelo meio de São Gonçalo e não pela orla (onde ela realmente passa), esta estrada virtual no visual fica por baixo do mapa, só aparece em alguns trechos. Mapa Brasil: A ponte Rio/Niterói aparentemente está correta. Porém a estrada virtual aparece no meio de São Gonçalo e os problemas visuais da orla, ruas dentro d'água continuam. Os mapas disponíveis no projeto COCAR estão com os mesmos problemas, e o do site oficial do OSM tem um problemas parecido no bairro de Alcantara/São Gonçalo, algumas ruas não aprecem no mapa compilado (no GPS). Obrigado pela atenção, Hélio Coutinho. Date: Tue, 11 Mar 2014 11:21:56 -0300 From: paulo.r.m.carva...@gmail.com To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download 335 é o código IBGE para SP. Na verdade 35. O 3 a mais seria região sudeste. Isso é para nos certificar de que não haja colisão de IDs caso o usuário instale mais de um mapa. O do RJ é 333. Mas esse código poderia ser qualquer um que quiséssemos inventar, desde que seja único. Colocarei um link lá no Cocar. Aliás tenho que fazer uma página com a relação de mapas, (que tende a crescer) e citar a cortesia. Os links no menu não vão dar certo. [ ]s e obrigado. Paulo 2014-03-11 9:43 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: --mapid não existe Para family-id e product-id, tem algo em específico para serem 335? Tirando isso, o de SP está aqui: http://naoliv.iq.unesp.br/mapas/gmapsupp.img ___ 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] Why Imports in OpenStreetMap Are Controversial
Há um novo texto no blog do Serge sobre a dificuldade de manutenção de dados importados no OSM: http://blog.emacsen.net/blog/2014/03/13/the-maintenance-of-imported-data-in-openstreetmap/ On 04-02-2014 19:59, Wille wrote: Compartilho um texto muito bom sobre a questão das importações no OSM: http://blog.emacsen.net/blog/2014/01/25/why-imports-in-openstreetmap-are-controversial/ ___ 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] São Paulo capital, tag reg
Taí uma tag que eu nunca entendi como preencher, REF Sempre que rodo o validador do JOSM, aparecem críticas relacionadas. E é tanta coisa colocada lá que fica dificil saber o que é mesmo para ficar. Marcelo 2014-03-13 23:53 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: On Thu, Mar 13, 2014 at 11:47 PM, Erick de Oliveira Leal erickdeoliveiral...@gmail.com wrote: http://www.openstreetmap.org/way/38709823 http://www.openstreetmap.org/way/237689576 Parece o CEP http://www.openstreetmap.org/way/16973487 http://www.openstreetmap.org/way/37396062 http://www.openstreetmap.org/way/154255950 Inicial de quem inseriu (pedro vida torta - PVT). Pode apagar (é considerado graffiti) Aproveita e manda mensagem para a pessoa parar com isso. ___ 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
Re: [Talk-br] São Paulo capital, tag reg
ref é uma etiqueta genérica para Código de referência (corrijo o que disse antes, não é número, é código). Assim como para a etiqueta name, tem outras etiquetas relacionadashttp://wiki.openstreetmap.org/wiki/Refpara usos similares, como loc_ref, old_ref, ref:* e outros. A etiqueta ref pode ser utilizada para coisas como números de saída de uma rodovia(junto com motorway_junction=*) e código de identificação de pontos de ônibus. Não é algo tão comum assim de usar. Abs, João Em 14 de março de 2014 09:12, Marcelo Pereira pereirahol...@gmail.comescreveu: Taí uma tag que eu nunca entendi como preencher, REF Sempre que rodo o validador do JOSM, aparecem críticas relacionadas. E é tanta coisa colocada lá que fica dificil saber o que é mesmo para ficar. Marcelo 2014-03-13 23:53 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: On Thu, Mar 13, 2014 at 11:47 PM, Erick de Oliveira Leal erickdeoliveiral...@gmail.com wrote: http://www.openstreetmap.org/way/38709823 http://www.openstreetmap.org/way/237689576 Parece o CEP http://www.openstreetmap.org/way/16973487 http://www.openstreetmap.org/way/37396062 http://www.openstreetmap.org/way/154255950 Inicial de quem inseriu (pedro vida torta - PVT). Pode apagar (é considerado graffiti) Aproveita e manda mensagem para a pessoa parar com isso. ___ 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] São Paulo capital, tag reg
2014-03-14 9:12 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com: Taí uma tag que eu nunca entendi como preencher, REF De forma bem resumida, no Brasil ref vai ser comumente utilizada nas saídas de rodovias (quando na placa tem Saída 430A você vai colocar 430A na ref) e nas rodovias (por exemplo, SP-300 ou BR-101). ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] São Paulo capital, tag reg
Alterei a tradução de *Reference* no editor iDhttps://www.transifex.com/projects/p/id-editor/translate/#pt_BR/presets/11487835?q=refpara Código de referência. Em 14 de março de 2014 09:23, Nelson A. de Oliveira nao...@gmail.comescreveu: 2014-03-14 9:12 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com: Taí uma tag que eu nunca entendi como preencher, REF De forma bem resumida, no Brasil ref vai ser comumente utilizada nas saídas de rodovias (quando na placa tem Saída 430A você vai colocar 430A na ref) e nas rodovias (por exemplo, SP-300 ou BR-101). ___ 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] Kit para compilação Garmin em Windows e mapas Garmin para download
2014-03-14 8:13 GMT-03:00 Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com: Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns problemas: Por acaso você está usando o poly daqui http://downloads.cloudmade.com/americas/south_america/brazil/rio_de_janeiro para extrair o estado? Caso sim, esse poly possui um buraco entre Rio e Niterói. Esse http://naoliv.iq.unesp.br/osm/RJ.poly é o contorno do estado definido no OSM. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download
Eu uso http://gaemin.openstreetmap.nl/ Depois um tempo p gerar (muitos vezes instantanio) a mapa com qualquer poligonio voce quer ser disponível, geralmente gerando somente Brazil, mas dezembro passado girei Brazil com Portugal no mesmo mapa Os arquivos e disponíveis em os mais usados formatos p garmin, eu teve nenhuma problema instalar atravez windows ou mac Aun Johnsen On Mar 14, 2014, at 10:03, Nelson A. de Oliveira nao...@gmail.com wrote: 2014-03-14 8:13 GMT-03:00 Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com: Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns problemas: Por acaso você está usando o poly daqui http://downloads.cloudmade.com/americas/south_america/brazil/rio_de_janeiro para extrair o estado? Caso sim, esse poly possui um buraco entre Rio e Niterói. Esse http://naoliv.iq.unesp.br/osm/RJ.poly é o contorno do estado definido no OSM. ___ 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
Osmanianos, Lendo a frase Rivers and streams should not be tagged with layer -1 along long sections of their length, eu entendo que a tag layer NÃO deve ser usada em longas seções de rios e ( seja-lá-o-que-for ) streams. Mas deduzo que é possível usá-la em rios nos pontos/trechos onde estiver em uma camada diferente da entidade que ele cruza. Mais uma frase : 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. Aqui interpreto que toda a superficie da terra, rios e mares é layer=0, que é o default e por isso não recomendado explicitar, e só se registra layer onde houver claramente uma diferença de camada em um cruzamento. Assim ... Um exemplo prático e mais extremo: suponha que seja um rio com várias pontes atravessando-o, como é o caso do arroio Dilúvio em Porto Alegre. Você teria que colocar layer=1 em cada uma das 54 pontes que o cruzam, versus layer=-1 somente no arroio. 54 tags vs 1 tag. (Só pra constar: eu revisei uma por uma, e mapeei as que faltavam.) Usando a minha interpretação da frase inicial, o uso neste exemplo dado pelo Trebien, seria a de se incluir layer=1 em todas as pontes, ou layer=-1 em todos os trechos do arroio que cruzam as pontes, sejam pequenos trechos ou pontos, não em toda sua extensão. E de acordo com a segunda frase, teríamos que usar o layer=1 para as pontes e não o layer=-1 para o rio, pois esse ainda faz parte da superfície da terra ( layer=0), o elemento adicional são as pontes. Adicionando uma questão a discussão, que diferença faz usar layer=1 na ponte ou layer=-1 no rio ? - Pra renderização o que ficaria melhor ? - Pra roteamento, o que funcionaria melhor ? - Será que não seria bom padronizar ? ( no caso de comportamentos diferentes para cada caso ) Marcelo P Em 14 de março de 2014 06:58, Flavio Bello Fialho bello.fla...@gmail.comescreveu: Fernando, acho que não entendeste. Leia a página http://wiki.openstreetmap.org/wiki/Key:layer com calma. Ela diz explicitamente: Do not use layer=-1 to hide warnings about crossing or overlapping ways. Either fix them or leave the easily visible warning so that others can fix them. When ways are passing on different levels apply layer=* only to the way which also has the bridge/tunnel attribute. Only ways with one of the tags/attributes tunnel=*, bridge=*, highway=steps, highway=elevator, covered=* should be tagged with the layer tag, similar for railways and waterways. Rivers and streams should not be tagged with layer -1 along long sections of their length Eles estão dizendo explicitamente para NÃO fazer isso que queres fazer. Se tens alguma dúvida, discuta na comunidade internacional. Esse é o meu último post sobre esse assunto. Em 14 de março de 2014 02:08, Fernando Trebien fernando.treb...@gmail.com escreveu: Mais além: na verdade, em alguns casos, chega a ser pior marcar as pontes com layer=1 porque isso altera a priorização da renderização no Mapnik. Por exemplo, highway=secondary_link com layer=1 é renderizado por cima de highway=primary (com ou sem layer=0). Isso é o oposto do normal e faz o desenho ficar feio. Mas o Mapnik não é o único parâmetro. No wiki diz que algumas ferramentas de QA (mas não todas) exigem que o rio tenha layer=-1 e a ponte tenha layer=1. Nada no restante do artigo sugere que isso é, de fato, necessário (pelo contrário). Pra mim, parece uma escolha arbitrária sem muita justificativa (ou seja, um dogma). Colocar layer=-1 no rio ou layer=1 na ponte estão ambos corretos, mas frequentemente uma das opções requer menos trabalho e resulta numa representação menos complexa. E se o próprio artigo diz que não é necessário colocar layer=0 nos casos em que seria esse o valor, me parece que o ideal é, quase sempre, marcar o rio com layer=-1, e nada mais. Claro, daí algumas pessoas poderiam pensar que não precisam marcar a ponte que passa por cima. Por isso concordo que o validador nacional aponte esses casos como aviso - que deve ser interpretado com bom senso (assim como os demais avisos do validador do JOSM) de acordo com a definição da tag, não necessariamente como erro. On Mar 14, 2014 1:34 AM, Fernando Trebien fernando.treb...@gmail.com wrote: Só complementando, o que layer=0 realmente significa é: desenhe este objeto depois dos que têm layer=-1, e antes dos que tÊm layer=1. Não significa nada além disso. 2014-03-14 1:30 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Exemplo fácil (inclusive já tinha citado antes): 1 rio + 2 linhas de uma via separada. É mais fácil colocar layer=-1 no rio do que colocar 2 tags layer=1, uma para cada linha da via. Um exemplo prático e mais extremo: suponha que seja um rio com várias pontes atravessando-o, como é o caso do arroio Dilúvio em Porto Alegre. Você teria que colocar layer=1 em cada uma das 54 pontes que o cruzam, versus layer=-1 somente no arroio. 54
Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download
Obrigado!Vou tentar o novo Poly indicado para o Rj.Uma pergunta, e quanto ao mapa do Brasil, aparecem praticamente os mesmos problemas. Você teria como me indicar um outro arquivo Poly para o Brasil? Não querendo abusar, quando faço pesquisa de endereço no GPS com esses mapas, aparecem após a cidade/pais o seguinte ,ABC e as pesquisas ficam incoerentes. O que pode ser isso? Abs, From: li...@gimnechiske.org Date: Fri, 14 Mar 2014 10:06:45 -0300 To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download Eu uso http://gaemin.openstreetmap.nl/ Depois um tempo p gerar (muitos vezes instantanio) a mapa com qualquer poligonio voce quer ser disponível, geralmente gerando somente Brazil, mas dezembro passado girei Brazil com Portugal no mesmo mapa Os arquivos e disponíveis em os mais usados formatos p garmin, eu teve nenhuma problema instalar atravez windows ou mac Aun Johnsen On Mar 14, 2014, at 10:03, Nelson A. de Oliveira nao...@gmail.com wrote: 2014-03-14 8:13 GMT-03:00 Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com: Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns problemas: Por acaso você está usando o poly daqui http://downloads.cloudmade.com/americas/south_america/brazil/rio_de_janeiro para extrair o estado? Caso sim, esse poly possui um buraco entre Rio e Niterói. Esse http://naoliv.iq.unesp.br/osm/RJ.poly é o contorno do estado definido no OSM. ___ 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] Validador nacional
- Pra renderização o que ficaria melhor ? Depende do seu renderizador. Para o Mapnik, layer=0 nas pontes fica melhor nesse caso específico porque daí ele consegue conectar o preenchimento e o contorno da via da ponte ao preenchimento e contorno das vias em que a ponte se conecta. Daí, o rio ficaria com layer=-1. Se não quiser colocar layer=-1 no rio todo, pode colocar só no trecho próximo da ponte. Se quiser colocar layer=-1 no rio ou layer=1 na ponte, está correto. Se quiser colocar layer=0 no rio e layer=1 na ponte, está correto. Se quiser colocar layer=-3 no rio e layer=-2 na ponte, está correto. Não é o que se esperaria tipicamente, mas está correto. Todas essas formas levam exatamente ao mesmo rendering, exceto pela questão da conexão entre a ponte e o resto da malha, que pode ser vista como defeito do renderizador. - Pra roteamento, o que funcionaria melhor ? Não faz absolutamente nenhuma diferença, essa é uma tag voltada exclusivamente à renderização. - Será que não seria bom padronizar ? ( no caso de comportamentos diferentes para cada caso ) Acho melhor entender a semântica da tag. Há muitas outras coisas em que uma padronização seria muito mais importante, nesse caso uma padronização rígida não faz diferença na prática. 2014-03-14 10:21 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com: Osmanianos, Lendo a frase Rivers and streams should not be tagged with layer -1 along long sections of their length, eu entendo que a tag layer NÃO deve ser usada em longas seções de rios e ( seja-lá-o-que-for ) streams. Mas deduzo que é possível usá-la em rios nos pontos/trechos onde estiver em uma camada diferente da entidade que ele cruza. Mais uma frase : 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. Aqui interpreto que toda a superficie da terra, rios e mares é layer=0, que é o default e por isso não recomendado explicitar, e só se registra layer onde houver claramente uma diferença de camada em um cruzamento. Assim ... Um exemplo prático e mais extremo: suponha que seja um rio com várias pontes atravessando-o, como é o caso do arroio Dilúvio em Porto Alegre. Você teria que colocar layer=1 em cada uma das 54 pontes que o cruzam, versus layer=-1 somente no arroio. 54 tags vs 1 tag. (Só pra constar: eu revisei uma por uma, e mapeei as que faltavam.) Usando a minha interpretação da frase inicial, o uso neste exemplo dado pelo Trebien, seria a de se incluir layer=1 em todas as pontes, ou layer=-1 em todos os trechos do arroio que cruzam as pontes, sejam pequenos trechos ou pontos, não em toda sua extensão. E de acordo com a segunda frase, teríamos que usar o layer=1 para as pontes e não o layer=-1 para o rio, pois esse ainda faz parte da superfície da terra ( layer=0), o elemento adicional são as pontes. Adicionando uma questão a discussão, que diferença faz usar layer=1 na ponte ou layer=-1 no rio ? - Pra renderização o que ficaria melhor ? - Pra roteamento, o que funcionaria melhor ? - Será que não seria bom padronizar ? ( no caso de comportamentos diferentes para cada caso ) Marcelo P Em 14 de março de 2014 06:58, Flavio Bello Fialho bello.fla...@gmail.com escreveu: Fernando, acho que não entendeste. Leia a página http://wiki.openstreetmap.org/wiki/Key:layer com calma. Ela diz explicitamente: Do not use layer=-1 to hide warnings about crossing or overlapping ways. Either fix them or leave the easily visible warning so that others can fix them. When ways are passing on different levels apply layer=* only to the way which also has the bridge/tunnel attribute. Only ways with one of the tags/attributes tunnel=*, bridge=*, highway=steps, highway=elevator, covered=* should be tagged with the layer tag, similar for railways and waterways. Rivers and streams should not be tagged with layer -1 along long sections of their length Eles estão dizendo explicitamente para NÃO fazer isso que queres fazer. Se tens alguma dúvida, discuta na comunidade internacional. Esse é o meu último post sobre esse assunto. Em 14 de março de 2014 02:08, Fernando Trebien fernando.treb...@gmail.com escreveu: Mais além: na verdade, em alguns casos, chega a ser pior marcar as pontes com layer=1 porque isso altera a priorização da renderização no Mapnik. Por exemplo, highway=secondary_link com layer=1 é renderizado por cima de highway=primary (com ou sem layer=0). Isso é o oposto do normal e faz o desenho ficar feio. Mas o Mapnik não é o único parâmetro. No wiki diz que algumas ferramentas de QA (mas não todas) exigem que o rio tenha layer=-1 e a ponte tenha layer=1. Nada no restante do artigo sugere que isso é, de fato, necessário (pelo contrário). Pra mim, parece uma escolha arbitrária sem muita justificativa (ou seja, um dogma). Colocar layer=-1 no rio ou layer=1 na ponte estão ambos corretos, mas frequentemente
Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download
2014-03-14 10:39 GMT-03:00 Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com: Uma pergunta, e quanto ao mapa do Brasil, aparecem praticamente os mesmos problemas. Você teria como me indicar um outro arquivo Poly para o Brasil? Tem esse aqui: https://raw.github.com/osmandapp/OsmAnd-misc/master/osm-planet/geo-polygons/south-america/brazil.poly Não querendo abusar, quando faço pesquisa de endereço no GPS com esses mapas, aparecem após a cidade/pais o seguinte ,ABC e as pesquisas ficam incoerentes. O que pode ser isso? Essa parte eu já não sei te dizer (eu não tenho um Garmin para testar). ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download
Em 14 de março de 2014 08:13, Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com escreveu: PessoALL, Sou do Rio de Janeiro e estou dando manutenção no OSM desde novembro de 2013 (estou aprendendo bastante!) e vim pedir ajuda, principalmente aos colaboradores do Rio de Janeiro que conhecem bem os trechos que irei falar... Fiquei bastante contente ao conseguir minha primeira compilação, depois de algumas tentativas e erros, finalmente tenho um script que roda liso. Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns problemas: *Mapa RJ:* A ponte Rio/Niterói só vai até a ilha de Mocanguê sentido Niterói/Rio e aparece uma outra estrada ao lado que parece ser ela. Parece ter a ver com o arquivo .poly usado, conforme falado pelo Nelson. Coisa de simples solução. O contorno da orla vindo pela Av. do Contorno está dentro d'água e vai assim por toda orla de Niterói, as ruas da Ilha da Conceição(Niterói) estão sobre a Baia de Guanabara. Pode ser o arquivo de oceano default que vem no mkgmap. Devemos usar um outro e passar para o compilador. Tracei uma rota de São Gonçalo (onde moro) até João Pessoa e para minha surpresa, o GPS começa a rota por uma estrada(possivelmente a BR-101) só que pelo meio de São Gonçalo e não pela orla (onde ela realmente passa), esta estrada virtual no visual fica por baixo do mapa, só aparece em alguns trechos. Isso precisa ser melhor explicado. É problema que veio do mapa-base? Está só no GPS? *Mapa Brasil:* A ponte Rio/Niterói aparentemente está correta. Porém a estrada virtual aparece no meio de São Gonçalo e os problemas visuais da orla, ruas dentro d'água continuam. Que rua virtual é essa? Tem como postar uma captura de tela? Está com outros mapas habilitados no GPS? Os mapas disponíveis no projeto COCAR estão com os mesmos problemas, e o do site oficial do OSM tem um problemas parecido no bairro de Alcantara/São Gonçalo, algumas ruas não aprecem no mapa compilado (no GPS). Ruas faltantes no mapa podem ser acrescentadas editando o mapa. Não estamos mais no Tracksource. ;-P Obrigado pela atenção, Hélio Coutinho. -- Date: Tue, 11 Mar 2014 11:21:56 -0300 From: paulo.r.m.carva...@gmail.com To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download 335 é o código IBGE para SP. Na verdade 35. O 3 a mais seria região sudeste. Isso é para nos certificar de que não haja colisão de IDs caso o usuário instale mais de um mapa. O do RJ é 333. Mas esse código poderia ser qualquer um que quiséssemos inventar, desde que seja único. Colocarei um link lá no Cocar. Aliás tenho que fazer uma página com a relação de mapas, (que tende a crescer) e citar a cortesia. Os links no menu não vão dar certo. [ ]s e obrigado. Paulo 2014-03-11 9:43 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: --mapid não existe Para family-id e product-id, tem algo em específico para serem 335? Tirando isso, o de SP está aqui: http://naoliv.iq.unesp.br/mapas/gmapsupp.img ___ 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] Kit para compilação Garmin em Windows e mapas Garmin para download
Nelson, Obrigado mais uma vez! Este Poly que você me indicou só tem 5KB o que usei tem 2133KB, é isso mesmo? Abs, Date: Fri, 14 Mar 2014 10:53:03 -0300 From: nao...@gmail.com To: talk-br@openstreetmap.org Subject: Re: [Talk-br]Kit para compilação Garmin em Windows e mapas Garmin para download 2014-03-14 10:39 GMT-03:00 Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com: Uma pergunta, e quanto ao mapa do Brasil, aparecem praticamente os mesmos problemas. Você teria como me indicar um outro arquivo Poly para o Brasil? Tem esse aqui: https://raw.github.com/osmandapp/OsmAnd-misc/master/osm-planet/geo-polygons/south-america/brazil.poly Não querendo abusar, quando faço pesquisa de endereço no GPS com esses mapas, aparecem após a cidade/pais o seguinte ,ABC e as pesquisas ficam incoerentes. O que pode ser isso? Essa parte eu já não sei te dizer (eu não tenho um Garmin para testar). ___ 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
Do not use layer=-1 to *hide warnings* about crossing or overlapping ways. Either *fix them* or leave the easily visible warning so that others can fix them. Quem disse está sendo feito assim para esconder alertas? Eu tratei cada um dos alertas originais, e por fim coloquei layer=-1 no rio. Está de acordo com a instrução. When ways are passing on different levels apply layer=* only to the way which also has the bridge/tunnel attribute. Only ways with one of the tags/attributes tunnel=*, bridge=*, highway=steps, highway=elevator, covered=* should be tagged with the layer tag, similar for railways and waterways. (...) Rivers and streams should not be tagged with layer -1 along long sections of their length Não há uma explicação de por que isso é ruim/errado. Tem algumas pessoas na página Discussion que pensam diferente. Vou copiar alguns trechos: - For complex motorway junctions, bridges may themselves be bridged. In other circumstances, tunnels may themselves be tunneled under. So bridges can be layer +1, +2, etc. A bridge may go over something which has layer -1, so the bridge would be *layer 0* etc. etc. Richard B 12:40, 3 September 2008 (UTC) - It's hardly a big issue to have a few objects tagged in this way. *Just remember also how the renderer works.* Objects in layer -5 are drawn first. Then objects in layer -4 are drawn on top. Then objects in layer -3 etc. Finally objects in layer +5 are drawn last. That has got to be simpler than requiring the renderers to have filters based on defaults for some objects, and still requiring layer tags for more complicated examples. Remember that bridges might be tagged bridge=yes, bridge=true, or even ones that specify what type of bridge it is, bridge=swing etc.For what it's worth, data for the UK shows (on ways tagged bridge=yes and bridge=true); 2 bridges with layer=-2 (0.0%) 59 bridges with layer=-1 (0.4%) 22 bridges with layer=0 (0.2%) 12813 bridges with layer=1 (91.7%) 896 bridges with layer=2 (6.4%) 126 bridges with layer=3 (0.9%) 43 bridges with layer=4 (0.3%) 9 bridges with layer=5 (0.1%) So nearly 10% of all bridges are tagged in a different layer than 1. Tagging something with a layer tag can only be redundant if one implies the other. It clearly does not. Looking at the stats for tunnels in European tagging suggests there are *tunnels tagged between layer=3 and layer=-6*. - *Only the relative order is important*, *not the actual values used*, so there is nothing wrong with non-consecutive layers (e.g. object with layer=4 directly over object with layer=-2), and bridges having negative and tunnels having positive layers. - I use the layer key on all *bridges and tunnels. Usually this means layers 1 and -1*, respectively, but *it gets more complicated in urban environments*. *Rivers through cities typically get layer=-1 because they consistently pass under the street level*. *Bridges over such rivers are often layer=0*, especially if they have intersecting streets immediately at one or both ends of the bridge. The same is true when a motorway is below street level. And when a motorway or rail line is consistently above street level, the whole thing gets layer=1 and not just the parts that are actually on bridges. I also try to make both parts of a divided highway be on the same layer (assuming they're physically at the same level) and make the transition from one layer to another at about the same point. Generally speaking, for any two features that cross or are very close to each other, I try to represent the relative physical height difference. Not only is this a good semantic representation of the physical world, but doing it this way (as opposed to bare-minimum use of the layer key) tends to produce slightly better map renders. That's a win-win. Vid the Kid 23:07, 13 April 2009 (UTC) - This seems self-contradictory: *If layer has no meanings for absolute heights*, then *it doesn't matter whether to put the layer on the stream or the bridge*, and whether to choose layer=-1 for the bridge and layer=-4 for the stream, or 1 and 0 resp. Eu acho que o problema que você quer evitar vem na resposta a essa última observação: - Of course layer is relative, and you could tag the waterway as layer=-5 and the bridge as layer=-4, but *usually the waterway will not be split into a small piece* under the bridge and everything else, so the layer=-5 applies to the whole waterway - and *that is bad*. SvenR 21:07, 23 January 2009 (UTC) Não faz sentido considerar errado, já que não afeta nenhuma aplicação - a não ser validadores, que bem poderiam estar validando uma regra um pouco mais inteligente como esta: alertar quando 2 linhas com o mesmo valor em layer (incluindo layer=0 implícito) se cruzam: - sem ponto compartilhado: quaisquer tipos de vias - com ponto compartilhado: vias de tipos diferentes (highway+waterway) Dito isto, como é feito na prática? O rio Tâmisa, em Londres, o rio Sena, em Paris, e o rio Danúbio, em Viena, estão da forma que você
Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download
2014-03-14 11:07 GMT-03:00 Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com: Este Poly que você me indicou só tem 5KB o que usei tem 2133KB, é isso mesmo? Sim, está certo :-) É uma versão mais simplificada, com número menor de nós. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download
Boa, Nelson, vou incluir esse poly no kit. A propósito, você teria por aí os polys dos outros estados? []s PC Em 14 de março de 2014 10:03, Nelson A. de Oliveira nao...@gmail.comescreveu: 2014-03-14 8:13 GMT-03:00 Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com: Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns problemas: Por acaso você está usando o poly daqui http://downloads.cloudmade.com/americas/south_america/brazil/rio_de_janeiro para extrair o estado? Caso sim, esse poly possui um buraco entre Rio e Niterói. Esse http://naoliv.iq.unesp.br/osm/RJ.poly é o contorno do estado definido no OSM. ___ 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
Qual a origem desse dogma, na minha opinião: ao importar a hidrografia de uma certa região, alguns importadores acharam mais conveniente colocar layer=-1 em todos os rios pra se livrar dos alertas do JOSM do que deixar os alertas e, quem sabe, adicionar as pontes corretamente. Bem, tem 1 coisa errada com essa idéia: o JOSM deveria alertar sobre a falta de uma ponte nesses casos porque layer=-1 não significa subterrâneo. É bem possível também que o próprio importador estivesse entendendo alerta no JOSM como erro, mas são coisas diferentes. Tem outra coisa: o importador deveria ter previsto esse efeito colateral antes de importar. Por isso que não se pode sair importando as coisas de qualquer jeito sem conversar com a comunidade antes pra ver se vai funcionar. Caso isso tenha acontecido (como se pergunta no fim da página de discussão), a melhor forma de resolver a situação é: baixar o mapa, mudar a tag layer dos rios para layer=0 (ou simplesmente excluí-la), rodar o validador, e mapear as pontes onde o validador tiver dado um aviso. Tanto faz o valor que vai em layer, desde que a layer do rio seja inferior à layer da ponte (ou, equivalentemente, que a layer da ponte seja superior à do rio). Ou seja, depois de mapeadas as pontes, daria pra colocar layer=-1 (ou -2, ou -5) de novo nos rios (inclusive durante a mesma edição). Também daria colocar layer nas pontes. Enfim, a escolha é livre. 2014-03-14 10:52 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: - Pra renderização o que ficaria melhor ? Depende do seu renderizador. Para o Mapnik, layer=0 nas pontes fica melhor nesse caso específico porque daí ele consegue conectar o preenchimento e o contorno da via da ponte ao preenchimento e contorno das vias em que a ponte se conecta. Daí, o rio ficaria com layer=-1. Se não quiser colocar layer=-1 no rio todo, pode colocar só no trecho próximo da ponte. Se quiser colocar layer=-1 no rio ou layer=1 na ponte, está correto. Se quiser colocar layer=0 no rio e layer=1 na ponte, está correto. Se quiser colocar layer=-3 no rio e layer=-2 na ponte, está correto. Não é o que se esperaria tipicamente, mas está correto. Todas essas formas levam exatamente ao mesmo rendering, exceto pela questão da conexão entre a ponte e o resto da malha, que pode ser vista como defeito do renderizador. - Pra roteamento, o que funcionaria melhor ? Não faz absolutamente nenhuma diferença, essa é uma tag voltada exclusivamente à renderização. - Será que não seria bom padronizar ? ( no caso de comportamentos diferentes para cada caso ) Acho melhor entender a semântica da tag. Há muitas outras coisas em que uma padronização seria muito mais importante, nesse caso uma padronização rígida não faz diferença na prática. 2014-03-14 10:21 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com: Osmanianos, Lendo a frase Rivers and streams should not be tagged with layer -1 along long sections of their length, eu entendo que a tag layer NÃO deve ser usada em longas seções de rios e ( seja-lá-o-que-for ) streams. Mas deduzo que é possível usá-la em rios nos pontos/trechos onde estiver em uma camada diferente da entidade que ele cruza. Mais uma frase : 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. Aqui interpreto que toda a superficie da terra, rios e mares é layer=0, que é o default e por isso não recomendado explicitar, e só se registra layer onde houver claramente uma diferença de camada em um cruzamento. Assim ... Um exemplo prático e mais extremo: suponha que seja um rio com várias pontes atravessando-o, como é o caso do arroio Dilúvio em Porto Alegre. Você teria que colocar layer=1 em cada uma das 54 pontes que o cruzam, versus layer=-1 somente no arroio. 54 tags vs 1 tag. (Só pra constar: eu revisei uma por uma, e mapeei as que faltavam.) Usando a minha interpretação da frase inicial, o uso neste exemplo dado pelo Trebien, seria a de se incluir layer=1 em todas as pontes, ou layer=-1 em todos os trechos do arroio que cruzam as pontes, sejam pequenos trechos ou pontos, não em toda sua extensão. E de acordo com a segunda frase, teríamos que usar o layer=1 para as pontes e não o layer=-1 para o rio, pois esse ainda faz parte da superfície da terra ( layer=0), o elemento adicional são as pontes. Adicionando uma questão a discussão, que diferença faz usar layer=1 na ponte ou layer=-1 no rio ? - Pra renderização o que ficaria melhor ? - Pra roteamento, o que funcionaria melhor ? - Será que não seria bom padronizar ? ( no caso de comportamentos diferentes para cada caso ) Marcelo P Em 14 de março de 2014 06:58, Flavio Bello Fialho bello.fla...@gmail.com escreveu: Fernando, acho que não entendeste. Leia a página http://wiki.openstreetmap.org/wiki/Key:layer com calma. Ela diz explicitamente: Do not use layer=-1 to hide warnings about
Re: [Talk-br] Why Imports in OpenStreetMap Are Controversial
Bom, manter um mapa atualizado é um desafio. Não vejo porque esse seria um problema exclusivo da parte que é importada. Meu primeiro tracklog (enviado ao Tracksource) foi de uma rampa de asa-delta que visitei em Congonhal-MG em 2004. Nem sei se ainda existe. 2014-03-14 8:56 GMT-03:00 Wille wi...@wille.blog.br: Há um novo texto no blog do Serge sobre a dificuldade de manutenção de dados importados no OSM: http://blog.emacsen.net/blog/ 2014/03/13/the-maintenance-of-imported-data-in-openstreetmap/ On 04-02-2014 19:59, Wille wrote: Compartilho um texto muito bom sobre a questão das importações no OSM: http://blog.emacsen.net/blog/2014/01/25/why-imports-in-openstreetmap-are- controversial/ ___ 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] Kit para compilação Garmin em Windows e mapas Garmin para download
Paulo Carvalho, - O mapa base pego daqui (como está indicado na BAT do projeto COCAR): http://download.geofabrik.de/south-america/brazil-latest.osm.pbf - Captura: Não estou com o GPS aqui no trabalho, posso enviar a noite... - Procuro sempre habilitar um mapa por vez... - Não é o caso de acrescentar ruas, pelo ID as ruas estão lá bonitinhas e bem desenhadinhas (rsrs). Com as telas capturadas acho que será melhor de nos entendermos. Obrigado, Hélio Coutinho. Date: Fri, 14 Mar 2014 11:09:22 -0300 From: paulo.r.m.carva...@gmail.com To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download Boa, Nelson, vou incluir esse poly no kit. A propósito, você teria por aí os polys dos outros estados? []s PC Em 14 de março de 2014 10:03, Nelson A. de Oliveira nao...@gmail.com escreveu: 2014-03-14 8:13 GMT-03:00 Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com: Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns problemas: Por acaso você está usando o poly daqui http://downloads.cloudmade.com/americas/south_america/brazil/rio_de_janeiro para extrair o estado? Caso sim, esse poly possui um buraco entre Rio e Niterói. Esse http://naoliv.iq.unesp.br/osm/RJ.poly é o contorno do estado definido no OSM. ___ 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] Kit para compilação Garmin em Windows e mapas Garmin para download
Hélio, Se você apontar um exemplo (dando nome da Rua ou apontando no OSM) eu mesmo faço a verificação no meu GPS contra o mapa-base do OSM. [ ]s Paulo Em 14 de março de 2014 11:17, Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com escreveu: Paulo Carvalho, - O mapa base pego daqui (como está indicado na BAT do projeto COCAR): http://download.geofabrik.de/south-america/brazil-latest.osm.pbf - Captura: Não estou com o GPS aqui no trabalho, posso enviar a noite... - Procuro sempre habilitar um mapa por vez... - Não é o caso de acrescentar ruas, pelo ID as ruas estão lá bonitinhas e bem desenhadinhas (rsrs). Com as telas capturadas acho que será melhor de nos entendermos. Obrigado, Hélio Coutinho. -- Date: Fri, 14 Mar 2014 11:09:22 -0300 From: paulo.r.m.carva...@gmail.com To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download Boa, Nelson, vou incluir esse poly no kit. A propósito, você teria por aí os polys dos outros estados? []s PC Em 14 de março de 2014 10:03, Nelson A. de Oliveira nao...@gmail.comescreveu: 2014-03-14 8:13 GMT-03:00 Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com: Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns problemas: Por acaso você está usando o poly daqui http://downloads.cloudmade.com/americas/south_america/brazil/rio_de_janeiro para extrair o estado? Caso sim, esse poly possui um buraco entre Rio e Niterói. Esse http://naoliv.iq.unesp.br/osm/RJ.poly é o contorno do estado definido no OSM. ___ 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] Kit para compilação Garmin em Windows e mapas Garmin para download
2014-03-14 11:09 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Boa, Nelson, vou incluir esse poly no kit. A propósito, você teria por aí os polys dos outros estados? Posso gerar. Hoje e fim de semana está meio corrido, mas no máximo até segunda eu gero de todos. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download
Paulo, segue, https://www.openstreetmap.org/way/204618440#map=19/-22.82102/-42.99988 Rua Almirante Nestor Pinto Alves (ao lado do Supermercado Extra) aparece no ID e não aparece no mapa OSM no GPS, entre outras próximas. Abs, Hélio. Date: Fri, 14 Mar 2014 11:20:38 -0300 From: paulo.r.m.carva...@gmail.com To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download Hélio, Se você apontar um exemplo (dando nome da Rua ou apontando no OSM) eu mesmo faço a verificação no meu GPS contra o mapa-base do OSM. [ ]s Paulo Em 14 de março de 2014 11:17, Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com escreveu: Paulo Carvalho, - O mapa base pego daqui (como está indicado na BAT do projeto COCAR): http://download.geofabrik.de/south-america/brazil-latest.osm.pbf - Captura: Não estou com o GPS aqui no trabalho, posso enviar a noite... - Procuro sempre habilitar um mapa por vez... - Não é o caso de acrescentar ruas, pelo ID as ruas estão lá bonitinhas e bem desenhadinhas (rsrs). Com as telas capturadas acho que será melhor de nos entendermos. Obrigado, Hélio Coutinho. Date: Fri, 14 Mar 2014 11:09:22 -0300 From: paulo.r.m.carva...@gmail.com To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download Boa, Nelson, vou incluir esse poly no kit. A propósito, você teria por aí os polys dos outros estados? []s PC Em 14 de março de 2014 10:03, Nelson A. de Oliveira nao...@gmail.com escreveu: 2014-03-14 8:13 GMT-03:00 Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com: Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns problemas: Por acaso você está usando o poly daqui http://downloads.cloudmade.com/americas/south_america/brazil/rio_de_janeiro para extrair o estado? Caso sim, esse poly possui um buraco entre Rio e Niterói. Esse http://naoliv.iq.unesp.br/osm/RJ.poly é o contorno do estado definido no OSM. ___ 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] Kit para compilação Garmin em Windows e mapas Garmin para download
Nélson, não tenha pressa. Pensei que talvez você os já tivesse prontos. Mas se dispondo a gerá-los, só temos a agradecer. []s Paulo Em 14 de março de 2014 11:20, Nelson A. de Oliveira nao...@gmail.comescreveu: 2014-03-14 11:09 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Boa, Nelson, vou incluir esse poly no kit. A propósito, você teria por aí os polys dos outros estados? Posso gerar. Hoje e fim de semana está meio corrido, mas no máximo até segunda eu gero de todos. ___ 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
Pra quem quiser acompanhar: https://lists.openstreetmap.org/pipermail/tagging/2014-March/016865.html 2014-03-14 11:10 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Qual a origem desse dogma, na minha opinião: ao importar a hidrografia de uma certa região, alguns importadores acharam mais conveniente colocar layer=-1 em todos os rios pra se livrar dos alertas do JOSM do que deixar os alertas e, quem sabe, adicionar as pontes corretamente. Bem, tem 1 coisa errada com essa idéia: o JOSM deveria alertar sobre a falta de uma ponte nesses casos porque layer=-1 não significa subterrâneo. É bem possível também que o próprio importador estivesse entendendo alerta no JOSM como erro, mas são coisas diferentes. Tem outra coisa: o importador deveria ter previsto esse efeito colateral antes de importar. Por isso que não se pode sair importando as coisas de qualquer jeito sem conversar com a comunidade antes pra ver se vai funcionar. Caso isso tenha acontecido (como se pergunta no fim da página de discussão), a melhor forma de resolver a situação é: baixar o mapa, mudar a tag layer dos rios para layer=0 (ou simplesmente excluí-la), rodar o validador, e mapear as pontes onde o validador tiver dado um aviso. Tanto faz o valor que vai em layer, desde que a layer do rio seja inferior à layer da ponte (ou, equivalentemente, que a layer da ponte seja superior à do rio). Ou seja, depois de mapeadas as pontes, daria pra colocar layer=-1 (ou -2, ou -5) de novo nos rios (inclusive durante a mesma edição). Também daria colocar layer nas pontes. Enfim, a escolha é livre. 2014-03-14 10:52 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: - Pra renderização o que ficaria melhor ? Depende do seu renderizador. Para o Mapnik, layer=0 nas pontes fica melhor nesse caso específico porque daí ele consegue conectar o preenchimento e o contorno da via da ponte ao preenchimento e contorno das vias em que a ponte se conecta. Daí, o rio ficaria com layer=-1. Se não quiser colocar layer=-1 no rio todo, pode colocar só no trecho próximo da ponte. Se quiser colocar layer=-1 no rio ou layer=1 na ponte, está correto. Se quiser colocar layer=0 no rio e layer=1 na ponte, está correto. Se quiser colocar layer=-3 no rio e layer=-2 na ponte, está correto. Não é o que se esperaria tipicamente, mas está correto. Todas essas formas levam exatamente ao mesmo rendering, exceto pela questão da conexão entre a ponte e o resto da malha, que pode ser vista como defeito do renderizador. - Pra roteamento, o que funcionaria melhor ? Não faz absolutamente nenhuma diferença, essa é uma tag voltada exclusivamente à renderização. - Será que não seria bom padronizar ? ( no caso de comportamentos diferentes para cada caso ) Acho melhor entender a semântica da tag. Há muitas outras coisas em que uma padronização seria muito mais importante, nesse caso uma padronização rígida não faz diferença na prática. 2014-03-14 10:21 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com: Osmanianos, Lendo a frase Rivers and streams should not be tagged with layer -1 along long sections of their length, eu entendo que a tag layer NÃO deve ser usada em longas seções de rios e ( seja-lá-o-que-for ) streams. Mas deduzo que é possível usá-la em rios nos pontos/trechos onde estiver em uma camada diferente da entidade que ele cruza. Mais uma frase : 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. Aqui interpreto que toda a superficie da terra, rios e mares é layer=0, que é o default e por isso não recomendado explicitar, e só se registra layer onde houver claramente uma diferença de camada em um cruzamento. Assim ... Um exemplo prático e mais extremo: suponha que seja um rio com várias pontes atravessando-o, como é o caso do arroio Dilúvio em Porto Alegre. Você teria que colocar layer=1 em cada uma das 54 pontes que o cruzam, versus layer=-1 somente no arroio. 54 tags vs 1 tag. (Só pra constar: eu revisei uma por uma, e mapeei as que faltavam.) Usando a minha interpretação da frase inicial, o uso neste exemplo dado pelo Trebien, seria a de se incluir layer=1 em todas as pontes, ou layer=-1 em todos os trechos do arroio que cruzam as pontes, sejam pequenos trechos ou pontos, não em toda sua extensão. E de acordo com a segunda frase, teríamos que usar o layer=1 para as pontes e não o layer=-1 para o rio, pois esse ainda faz parte da superfície da terra ( layer=0), o elemento adicional são as pontes. Adicionando uma questão a discussão, que diferença faz usar layer=1 na ponte ou layer=-1 no rio ? - Pra renderização o que ficaria melhor ? - Pra roteamento, o que funcionaria melhor ? - Será que não seria bom padronizar ? ( no caso de comportamentos diferentes para cada caso ) Marcelo P Em 14 de março de 2014 06:58, Flavio Bello Fialho
[Talk-br] Porto Velho - Rios sobrepostos
Pessoal, qual devo deixar desses dois rios sobrepostos? http://www.openstreetmap.org/browse/way/151882080 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Porto Velho - Rios sobrepostos
2014-03-14 14:48 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Pessoal, qual devo deixar desses dois rios sobrepostos? http://www.openstreetmap.org/browse/way/151882080 Não é sobreposto. Um é o rio em si e o outro a área do rio. Está certo (só teria que ajustar a área dele) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Porto Velho - Rios sobrepostos
Pelo que eu sei, em rios vc pode desenhar uma área para marcar o espaço que ele ocupa, e também pode desenhar uma linha para marcar o seu curso (principalmente para ser usado quando for feito um planejamento de navegação), Talvez o que precise se feito ali é somente o ajuste do curso do rio. 2014-03-14 14:48 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Pessoal, qual devo deixar desses dois rios sobrepostos? http://www.openstreetmap.org/browse/way/151882080 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Ronaldo Maia ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Dúvidas em Natal
Troquei as respostas :-) Pra http://www.openstreetmap.org/way/42433318 você pergunta para a pessoa. Para http://www.openstreetmap.org/way/205363395 (no caso seria o outro lado da avenida e os trechos dela), deixa a avenida de forma correta (mão dupla). ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Dúvidas em Natal
Do jeito que está está correto. Está assim por causa das obras da copa. 2014-03-14 16:46 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Okay. Vou ver quem esta ativo lá e perguntar. Em 14/03/2014 16:41, Nelson A. de Oliveira nao...@gmail.com escreveu: Troquei as respostas :-) Pra http://www.openstreetmap.org/way/42433318 você pergunta para a pessoa. Para http://www.openstreetmap.org/way/205363395 (no caso seria o outro lado da avenida e os trechos dela), deixa a avenida de forma correta (mão dupla). ___ 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] Dúvidas em Natal
Braulio. Então nos dois casos é pra deixar? Em 14/03/2014 16:52, Bráulio brauliobeze...@gmail.com escreveu: Do jeito que está está correto. Está assim por causa das obras da copa. 2014-03-14 16:46 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Okay. Vou ver quem esta ativo lá e perguntar. Em 14/03/2014 16:41, Nelson A. de Oliveira nao...@gmail.com escreveu: Troquei as respostas :-) Pra http://www.openstreetmap.org/way/42433318 você pergunta para a pessoa. Para http://www.openstreetmap.org/way/205363395 (no caso seria o outro lado da avenida e os trechos dela), deixa a avenida de forma correta (mão dupla). ___ 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] Dúvidas em Natal
2014-03-14 16:52 GMT-03:00 Bráulio brauliobeze...@gmail.com: Do jeito que está está correto. Está assim por causa das obras da copa. Aqui onde a avenida Aminta Barros, na parte de cima, muda de direção na Rua Professor Antônio Campos (ficando com os dois sentidos dela para uma única direção), está certo? (até o lado direito da Campos é duas mãos; lado esquerdo 2 caminhos pro mesmo sentido) http://osm.org/go/PT3vaLN7v ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Dúvidas em Natal
Sim. Tanto a avenida Amintas Barros como a Miguel Castro (ao sul desta) estão com alguns trechos em mão única, mesmo onde há canteiro central. Há mais alterações além dessas, mas não estou conseguindo acompanhar :(. Mas pelo menos essa mais importantes e duradouras eu coloquei no mapa. 2014-03-14 16:53 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Braulio. Então nos dois casos é pra deixar? Em 14/03/2014 16:52, Bráulio brauliobeze...@gmail.com escreveu: Do jeito que está está correto. Está assim por causa das obras da copa. 2014-03-14 16:46 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Okay. Vou ver quem esta ativo lá e perguntar. Em 14/03/2014 16:41, Nelson A. de Oliveira nao...@gmail.com escreveu: Troquei as respostas :-) Pra http://www.openstreetmap.org/way/42433318 você pergunta para a pessoa. Para http://www.openstreetmap.org/way/205363395 (no caso seria o outro lado da avenida e os trechos dela), deixa a avenida de forma correta (mão dupla). ___ 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] Dúvidas em Natal
2014-03-14 16:57 GMT-03:00 Bráulio brauliobeze...@gmail.com: Sim. Tanto a avenida Amintas Barros como a Miguel Castro (ao sul desta) estão com alguns trechos em mão única, mesmo onde há canteiro central. Faltou um note explicando isso então ;-) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Dúvidas em Natal
Braulio. Eu não vou corrigir, vou deixar pra você que tem mais conhecimento do caso. Em 14/03/2014 17:03, Nelson A. de Oliveira nao...@gmail.com escreveu: 2014-03-14 16:57 GMT-03:00 Bráulio brauliobeze...@gmail.com: Sim. Tanto a avenida Amintas Barros como a Miguel Castro (ao sul desta) estão com alguns trechos em mão única, mesmo onde há canteiro central. Faltou um note explicando isso entã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
