Aun Johnsen, infelizmente não pode ver o vídeo. Nele mostro os problemas existentes no mapa do Brasil fornecido pelo http://garmin.openstreetmap.nl/
Os problemas existentes e ali mostrados são facilmente tratados a nível Mkgmap, em seus styles, o que infelizmente o mapa NL não faz, pelo menos para o Brasil. Está você testando a indexação por Rua, entretanto o problema ocorre na indexação por cidade / estado e não por Rua. Problemas de indexação por tipo de via ( Rua, Avenida, estrada, etc) são facilmente corrigidos pelo Mkgmap com o comando “x-split-name-index”. Renderizado com esse comando a busca por endereço se torna fácil sem a necessidade de se buscar digitando o tipo de via a frente do nome. Ele indexa com somente a digitação do nome, sem o tipo. De qualquer forma volto a solicitar que seja padronizado o emprego de tags nas relações boundary e nos POI de city, town, etc. Não existindo uma padronização se torna complicado a qualquer renderizador extrair dos dados alguma tag que vá refletir aquele objeto. Para terem noção do problema cito como exemplo o emprego do admin_centre na relação boundary. Os desenvolvedores do Mkgmap, por nossa solicitação, criaram uma regra nele de quando da existência do admin_centre na relação boundary, que a função add-poi-to-area não criasse um POI virtual no centro geométrico da área. Com essa ação passamos a não mais ter o POI da cidade duplicado no mapa, entretanto em alguns lugares do Brasil continua essa duplicação simplesmente porque o membro admin_centre não está incluído em algumas relações boundary, em especial do estado de São Paulo. Pelo que já lemos relação boundary no OSM é um fato relativamente recente em se comparando as outras funções. Talvez por isso o mapa para o Brasil ainda não foi totalmente ajustado as novas regras. Outra situação foi a apresentada para São Carlos – SP e outras cidades do estado. Muitos renderizadores ainda não tratam relações boundarys. Eles tratam os POI, os place=city, town, etc. Se observarmos a maioria das cidades do estado de São Paulo estão vinculadas as correspondentes relações boundary como admin_centre, entretanto não existe o POI da cidade tratado isoladamente, fora da relação, como é tratado o POI de Concórdia – SC citado. Nele, se observarem, existe como resultado da busca a relação boundary e o POI city. Vão dizer que o renderizador tem de se adaptar aos dados OSM e até concordo com essa ponderação, mas convenhamos que em não existindo um padrão fica difícil ao desenvolvedor do renderizador estabelecer uma regra para dos dados extrair o que é desejado. Se desejamos alavancar o OSM no Brasil sou de opinião que devemos nos esforçar em padronizar o emprego de tags e identificar erros grosseiros existentes no mapa. Felizmente mais utilizadores estão empregando o mapa COCAR e com isso estamos recebendo inúmeros “feedbacks” de erros existentes no mapa. Recentemente recebemos uma critica de um utilizador que reside em Ponte Nova – MG. Disse ele que não empregava o mapa COCAR porque não era loteável em sua cidade. Fomo verificar o porque e identificamos que o editor Elias Lopes desenhou as vias mas não as interligou nos entroncamentos. Enviamos mensagem para ele, mas infelizmente não nos respondeu. Decidimos então corrigir o problema interligando as vias, entretanto muitas continuam por serem interligadas como, por exemplo, http://www.openstreetmap.org/way/346557829 Outro utilizador, agora residente em São Luís – MA, também fez critica quanto ao roteamento pela cidade. Fomo identificar e realmente existem inúmeros problemas ali que aos poucos estamos corrigindo. Perdoem o desabafo, mas como abraçamos a causa e estamos divulgando o mapa OSM nos sites que administramos, acabamos por ser o receptor de elogios e também de críticas. []s Marcio From: Lists Sent: Saturday, June 13, 2015 9:02 AM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] São Carlos, SP Marcio Desculpa que nao pode ver o video voce me mando nem atualizar as mapas, to offshore Patagonia e meu conecao internet nao dar para ver youtube e nem baixar arquivos grandes. Bem, vejo algum de seus problemas sobre garmin.openstreetmap.nl, principalmente em calcular tempo nos roteamentos, como voce dis não uso regras especificas por brasil, que resultando velocidade padrão no autoestrada (highway=motorway) ser 250km/h, no trunk 130 e no primary 90km/h por exemplo. Mas seus problemas de indexacao não parecendo valido por esse mapa. Eu nao tem mapas do link ES que voce mandou e não pode relatar resultado ai. Como mapas do garmin.openstreetmap.nl indexando as ruas e POI certas, o problema com indexacao nao e no banco dados OSM, mas provavelmente nos regras voce utilizando. Antes de começar mexer com o banco dados, verificar se ha problemas indicados nos ferramentas QA que tem monte, e também verificar se problema também existe no outro fontes do mapa Garmin. Proximo vez voce encontrando problemas assim, se e com indexo, roteamento, ou outros coisas, me manda informação sobre o problema, sobre como voce testando, o que testes não dar resultado que voce espero, e o resultado voce espero. Assim eu posso te ajudar reproduzir esses problemas para verificar que realmente e no banco dados ou se consigo identificar outro fonte de problema. Eu sei que tem monte erros no mapa, enquanto tava tentando entender seu problema encontrou ruas com nomes sigintes: “Rua !”, “Rua -1”, "A", "1", "(7)", "(Trevo)", "(Rua Do Estacionamento Do Atacadao E Dicico Usada Pela Comunidade Como Saida Do Transito Da Parada De Taipas)”, "Avenida 1? de Maio" Também parecendo que temos muitos ruas com erros tipo “Ria” em vez de “Rua”, em monte abreviações errados “R. A” e mais Antes que começando corregir no banco dados que não dar erro no outros fontes, temos um monte a concertar. Aun Johnsen On Jun 13, 2015, at 08:36, <[email protected]> <[email protected]> wrote: Aun Johnsen, perdoe, mas ontem fui obrigado a me ausentar e não pude lhe responder na lista. Conforme comentei anteriormente, os mapas do Brasil produzidos e fornecidos em http://garmin.openstreetmap.nl/ ou http://mapas.alternativaslibres.es/descargas.php não atendem as necessidades brasileiras porque eles empregam os styles default do Mkgmap, sem o devido tratamento para o Brasil. Testamos esses mapas exaustivamente e concluímos que quando empregados no Brasil geram inúmeros problemas aos utilizadores, em especial aos inexperientes. Visando melhor demonstrar os problemas desses mapas, decidi gravar um vídeo tutorial mostrando o que ocorre quando os styles do Mkgmap não são tratados pelo utilizador. Por gentileza veja o vídeo em https://www.youtube.com/watch?v=mwQNV0ndR44 onde nele aponto o problema empregando o mapa do Brasil renderizado no dia 10/06/2015 pelo http://garmin.openstreetmap.nl/ []s Marcio From: Lists Sent: Friday, June 12, 2015 8:32 PM To: OpenStreetMap no Brasil Subject: Re: [Talk-br] São Carlos, SP Marcio Me notei nomes de algumas ruas no São Carlos e fiz busca por nome da rua, tudo deles achei sem problema. Se consigo busca pelo nome da rua significando que e indexado, ne? Isso e com mapas do garmin.openstreetmap.nl compilado 29-03-2015, reproducido no BaseCamp e no meu Garmin Nüvi 50 https://i.imgur.com/Xk4FdoK.png Aun Johnsen _______________________________________________ Talk-br mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-br -------------------------------------------------------------------------------- _______________________________________________ Talk-br mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-br
_______________________________________________ Talk-br mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-br
