por Thundercel » 05 Jul 2016, 16:22
Me faz um favor já que compilou mapa sem os poligonos.
Veja na busca se encontra o seguinte endereço:
Rua Aquino Araújo 77, Vila Velha, ES
Na verdade esse endereço de porta 77, na verdade e na minha opinião, não é um POI e sim um endereço de porta configurado como entrada na estrutura de um poligono residencial.
por afmenez » 06 Jul 2016, 09:15
Thundercel escreveu: Me faz um favor já que compilou mapa sem os poligonos.
Não estou no carro agora, mas vou testar sim. Mas já testei com outros endereços de porta aqui em PoA com sucesso.
por Thundercel » 06 Jul 2016, 10:11
Devemos lembrar que existem inumeras maneiras de configuração de endereço de porta.
A que me refiro é a maneira de se configurar em um nó do polígono como a do exemplo que dei configurado por mim mesmo em Você precisa esta logado para ver os links. Registre-se.
Testou voce com sucesso alguma numeração de porta configurada dessa maneira?
por afmenez » 06 Jul 2016, 14:05
afmenez escreveu: Não estou no carro agora, mas vou testar sim. Mas já testei com outros endereços de porta aqui em PoA com sucesso.
Na verdade testei os dois tipos de polígono, com e sem o ponto de entrada/saída, inclusive o do meu prédio que fica em uma esquina (http://www.openstreetmap.org/node/4286263127). Me pareceu mostrar o local correto nos dois casos.
por Thundercel » 06 Jul 2016, 16:01
Observando o ponto informado identifico que configurou voce o endereço no poligono e não na entrada.
Quando configuramos no poligono o ponto com o endereço na busca fica no centro geometrico do poligono e não na entrada.
Olhe a busca do endereço no mapsource:
Isso gera problema de roteamento para o endereço porque por vezes fica o ponto do centro geometrico afastado da via.
Para que isso não ocorra sempre configuro o endereço no nó de entrada e no poligono deixo somente o nome do predio
Vou hoje compilar um mapa com a alteração e testar
Por gentileza coloque o comando do stylle aqui
por Thundercel » 06 Jul 2016, 22:49
Fiz o teste com seu polygons e identifiquei que não se perde a numeração de porta quando configurada no nó de entrada. Bom sinal.
Apesar disso vi um problema que não me simpatizei com ele.
Muitos editores desenham vias de pedestre levando a entrada de algum prédio.
Aqui em Vitória me chamou a atenção a quantidade de caminhos de pedestre desenhados no campus da Universidade Federal do Espírito Santo que pode ser vista em Você precisa esta logado para ver os links. Registre-se.
Retirando o poligono os caminhos de pedestre ficam soltos no nada como pode ser visto na imagem do mapa no mapsource
Devemos levar em consideração que os poligonos, quando começarmos a desenvolver o arquivo TYP, serão representados por cores que definirão o objeto.
por afmenez » 07 Jul 2016, 01:40
O arquivo que eu passei remove todos os polígonos de prédios, que é o que funcionou melhor para mim. A maioria das categorias de "amenity" está listada individualmente e pode ser reativada se necessário quando for colocado o tratamento de typ. Inclusive existe uma linha para "amenity=university" que pode restaurar os prédios que faltaram no teu mapa, caso estejam marcados assim.
por Thundercel » 07 Jul 2016, 08:45
Como citei anteriormente, esse problema de atraso identificado por voce em seu aparelho não foi por mim identificado nos meus dois aparelhos (nuvi 3490 e nuvi 3597) e tampouco observei na NET algum reporte a respeito.
Não podemos deixar de considerar que a tendência natural de um mapa é seu crescimento em quantidade de dados e, na minha opinião, não devemos reduzir dados para atender aqueles processadores que não os suportam.
A Nokia, que desenvolve o mapa City Navigator, foi inteligente ao disponibilizar separadamente um arquivo IMG que estampa os prédios. Esse arquivo só funciona com o mapa dela e pode ser habilitado ou não pelo utilizador. Isso deve atender aos navegadores com processador limitado.
Está em nossa lista de tarefas desenvolver um TYP padrão para o Cocar e ainda não iniciamos essta tarefa porque estamos estudando como atender as diferentes resoluções de aparelhos. Os modelos Garmin de baixa resolução empregam icones de 24x24 Px e os de alta 48x48 px.
Na minha opinião, comentar no style os building fazendo com que eles não apareçam vai impactar no nosso trabalho de TYP quando iniciado. Necessitaremos da apresentação dos poligonos porque cada um guarda em si um código garmin que será empregado para o TYP.
O descomentar "amenity=university" resolve o problema da faculdade apontada por mim no exemplo que dei, mas não resolve para outros objetos diferentes de faculdade e que tenham caminhos de pedestre, vias de serviço ou bikes levando a eles.
Observei também o Shopping Vila Velha aqui na cidade que resido ( Você precisa esta logado para ver os links. Registre-se. ). Nele existem duas situações:
1 - corredor de estacionamento formatado como tunnel
2 - caminhos de pedestre que levam as portas do shopping (existem duas, a oeste e a leste)
Sem dúvida a solução desse também seria voltar a comentar o processamento do poligono dele e por aí vai uma analise acurada de quais poligonos voltariam.
por afmenez » 07 Jul 2016, 11:00
Eu acredito que na base do OSM, quanto mais informação, melhor. Essa base tem que ser completa, pois é usada para várias finalidades diferentes: o que é essencial para uma finalidade pode ser irrelevante para outra. Mas existem várias maneiras de visualizar esses dados, e nem todos os dados são relevantes para cada visualização. O site principal do OSM, por exemplo, não mostra por padrão nem metade das informações que estão na sua base (endereços de POIs, informações de altitude, altura dos prédios, inclinação das vias). O próprio site disponibiliza vários tipos de visualização para finalidades diferentes (ciclístico, trasporte público, etc). E isso não é estático, há itens que aparecem e somem com o tempo, conforme os templates de visualização evoluem.
No mapa para navegação veicular, eu acredito que devam ser filtrados os dados que não agregam nenhum valor para essa tarefa, pois eles só tornam mais difícil a interpretação dos dados que realmente importam. Na minha primeira mensagem dessa thread, eu sugeri que fossem removidos apenas os edifícios sem nenhuma classificação. Para isso, como testado, basta comentar uma linha no arquivo de polígonos. Na minha experiência, isso faz com que sumam mais de 90% dos polígonos, tornando o mapa muito mais limpo, e dando mais destaque para os prédios que têm alguma função. Acho que é um compromisso interessante por enquanto.
Eu cheguei a implementar a compilação com múltiplos estilos em uma versão anterior do kit (rodoviário, marítimo e ciclismo), mas não levei adiante porque não fiquei satisfeito com o resultado dos mapas marítimo e ciclismo. Acho que seria uma solução para essa questão: uma versão limpa, só com informação essencial para navegação rodoviária, e uma versão completa, como toda a informação possível de ser extraída do OSM. Vou tentar implementar isso novamente no kit atual.
Quanto ao problema de lentidão, é uma questão de percepção, e o que é irritante para um usuário pode ser indiferente para outros. Creio que existem mais usuários que seriam beneficiados por um mapa mais leve, nem que seja por uma pequena redução no tempo de dowload do site e de boot to aparelho.
por afmenez » 07 Jul 2016, 11:04
Thundercel escreveu: A Nokia, que desenvolve o mapa City Navigator, foi inteligente ao disponibilizar separadamente um arquivo IMG que estampa os prédios. Esse arquivo só funciona com o mapa dela e pode ser habilitado ou não pelo utilizador. Isso deve atender aos navegadores com processador limitado.
Sim! Conforme comentei anteriormente, uso esse arquivo com os prédios 3D com o mapa Cocar, e funciona muito bem com o meu navegador. Mas conforme já relatei, os prédios não aparecem se houverem muitos polígonos no mapa.