Xamanian

João, faz um bom tempo que escrevi sobre este assunto, mas vira e mexe ele aparece novamente. A questão é a seguinte: o Primo "faz confusão" com a numeração dos cinco primeiros types, ou seja, há uma troca na numeração adotada e a numeração reconhecida. Em linhas gerais é assim: - Type 0 é reconhecido como categoria 1 (radar fixo); - Type 1 é reconhecido como categoria 5 (radar móvel); - Type 2 ok (radar no semáforo -- não confundir com Red Light and Speed Camera/Semáforo com radar, que é o type 11); - Type 3 é reconhecido como categoria 3 (Câmera de velocidade média); - Type 4 é reconhecido como categoria 3 (Câmera no semáforo). Do type 6 por diante, sem surpresas. Cabe alguns comentários, mas falarei de memória (ou seja, pode haver imprecisão). No Primo, internamente, os types totalizam 32, mas começando pelo type 0 e chegando ao type 31. Mas pelo que entendi e me lembro, havia um interesse em manter as categorias já existentes no iGO8/Amigo, onde a ideia era manter a compatibilidade. Isto funcionou na Europa, por exemplo, mas aqui em nosso país houve uma lambança, um mal entendimento, que culminou na ideia de que as categorias já existentes no iGO8 seriam as mesmas do Primo, depois conclui-se que não, logo uma bagunça surgiu, mas a coisa ficou. Por exemplo, o type 2 semáforo com radar, o mesmo do type 11. Só que o type 2, aqui em nosso país, ficou para o iGO8/Amigo, enquanto o type 11 ficou para o Primo. Não havia motivos para isso. As diferenças ocorrem de fato nos type 1 que é reconhecido internamente como type 5 ou 37; type este (o 5) não reconhecido na tabela. Idem para os types 3 e 4, que são invertidos. Independentemente da confusão, o certo é que a classificação do MapaRadar, bem como aquelas originais do Hélio (Point), estão completamente de acordo com as skins que normalmente usamos por aqui, a padrão e a diMka. Durante um bom tempo o Fidelis tocou o projeto do Hélio e tudo funcionava bem. Quando houve esta mudança recente, uma independência, digamos, muitos problemas surgiram e continuam surgindo. A ideia de sugerir que os próprios usuários entre em uma plataforma e cadastrem os pontos de alerta está gerando um problemão e que poucos parecem ter dado conta. Tem gente cadastrando passagem de pedestre em plena rodovia, em lugar que não existe tal faixa, mas próximo de um radar fixo. O que acontece? O navegador dá um falso aviso de faixa de pedestre e ignora o aviso real de um radar, dada a proximidade entre ambos. Isto está acontecendo muito. Tem vários casos do tipo, só citei um exemplo. Mas tem radares conflitantes com o do mapa radar, tem posto policial cadastrado, mas que é inexistente, tem de tudo. Sobre lombadas, nem comento. Ou seja, de tempos para cá o banco de pontos de alerta deixou de ser confiável. O banco de dados do MapaRadar continua funcionando muito bem e é muito confiável, pois lá há filtro e controle. A regrinha que tenho usado e com algum resultado positivo/satisfatório: usar o banco de dados do MapaRadar (menos pedágios), o banco de dados novo do Fidelis, mas apenas com os arquivos conhecidos da época do Hélio, isto é, nada de radar, semáforo isso ou aquilo, pois não são confiáveis, são péssimos e cheio de erros. Estou falando sobre túneis, área escolar, área hospitalar, etc.; estes ainda funcionam razoavelmente bem, mas já se tem uma enormidade de dados falsos nestes dados também. Se continuar assim, muito em breve não será mais possível usar, pois realmente virou uma bagunça. Motivo da bagunça: as pessoas cadastram os pontos corretamente, mas clicam em types errados. Tipo, o que era para ser radar fixo pode aparecer como faixa de pedestre; o que poderia ser câmera no semáforo é cadastrado como lombada; e assim por diante. Quando não há filtro e controle, erros e mais erros surgem. E para piorar, será muito difícil corrigir o tamanho da lambança feita. :wacko: Insisto, nada de errado com as skins e nem com os dados do MapaRadar, sem erros e sem conflitos. Abraços!

WHM, não tem nada neste pacotinho, apenas que ele foi pensado para a resolução 800x480, mas também serve como base para 480x272. Uso o mesmo aqui e sem problema; aliás, outros já testaram e disseram ok. Tente testar, antes, apenas na forma básica (só com conteúdos, sem outras skins, módulos ux, etc.) e só depois teste com outros complementos. Travamentos estão relacionados com incompatibilidade de skin, módulos ux e muito raramente com schemes (por exemplo, se um Magellan ou aparelho do tipo, que é necessário usar um sistema de boot específico). Antes de testar com algumas skins, tente antes a skin padrão. Depois insira outras skins e veja se dá certo. Módulos ux adicionais também merecem atenção. Pasta Save: não copie de outro navegador, apenas deixe sem nenhuma, pois, ao reiniciar, o Primo gerará outra totalmente limpa e nova. Somente após isso é que recomendo usar outras skins e módulos ux. Teste aí, qualquer coisa me fale novamente. Abraços!

Maurício, você fez um comentário muito importante e que eu esqueci de comentar: você falou sobre o Nextgen para WinCE. O meu esquecimento se refere ao fato que minhas afirmações sobre o Nextgen são para este navegador rodando com o Android; não testei com o WinCE. A importância reside neste fato: quem ler os posts anteriores poderá pensar que eu falava sobre Nextgen qualquer, isto é, para WinCE e Android, mas na verdade eu só me referia para Android. E sim, isto pode fazer diferença na prática. Abraços!

Pessoal, vocês gostam de me dar trabalho, hein?!? :D É o seguinte: 1. Somente o arquivo FJV funciona no Primo; 2. Os dois arquivos, FJV e FJW, funcionam no Nextgen. Nas figuras abaixo, que usei no debate com um colega do GPS Power tempos atrás (consegui encontrá-las aqui), mostram o Nextgen funcionam com imagens de junções dos arquivos FJV e FJW (e, claro, com junções da NNG também). Notem que a data do conteúdo é antiga (2017.Q2). Na figura acima, (1) significa imagens de junções do arquivo FJV e (2) significa imagens de junções do arquivo FJW. Notem que ambos são reconhecidos e estão funcionais. A figura acima mostra que o arquivo FJW está sendo usado e é reconhecido pelo Nextgen. A última figura confirma que o arquivo FJV (o mesmo para Primo) é reconhecido pelo Nextgen e que o mesmo funciona corretamente. As duas figuras abaixo são telas capturadas no Nextgen onde cada figura é de um dos arquivos de junções (FJV e FJW): As duas figuras a seguir são telas capturadas usando-se o Primo com o arquivo JFV e licenças para placas foto realísticas: Basta comparar as figuras com o Nextgen e Primo para observar que são praticamente idênticas (Nexten em modo noturno e Primo em modo diurno). Não quero me alongar com um post gigante, mas na época o colega me pediu para fazer vários testes e exibir as imagens de junções em cada situação. Basicamente foi o seguinte: apenas o arquivo de mapa FBL (aparecia apenas junções da NNG no Here); depois só o FJW com o mapa (apareciam as junções foto realísticas; depois só o mapa com o FJV (apareciam as junções deste arquivo e já no formato foto realístico); por fim, mapa + JFV + FJW (a prioridade é pelo arquivo FJW, depois o FJV e por fim as junções da NNG). É isto! Abraços! Edit: na época usei um lang em inglês para facilitar a comunicação; não estranhem tal coisa.

Maurício, certeza absoluta que o FJV funciona no Nextgen. Tempos atrás, lá no fórum GPSPower, participei de um debate com uma figura muita conhecida e tratamos deste assunto das junções. Ele também não sabia que o arquivo FJV funcionava no Nextgen; aliás, ele jurava que este navegador só funcionava com o FJW. Então, em vários posts, mostrei através de muitos prints que ambos os arquivos funcionam no Nextgen, mas que somente o JFV funciona no Primo. Também falei que o efeito de placas foto realísticas nas junções do FJV deixam o efeito visual idêntico às junções do FJW (que já tem este efeito nativamente). Vai por mim, o FJV funciona no Nextgen; mais do que testado. Quanto a necessidade de licenças para este conteúdo no Nextgen, não sei dizer. Na verdade usei aquele pacote disponibilizado naquele outro fórum aqui do país que era específico para o Nextgen em sua essência; acho que tem este pacote aqui no fórum. Ou seja, não testei um Nextgen genuíno, mas um pacote montado. E neste pacote que usei para testes, tanto o JFV quanto o FJW funcionaram muito bem e são reconhecidos como conteúdos válidos (basta olhar lá em configurações, informações, conteúdos). ROP, você está correto. Porém um detalhe: estas licenças são para o Primo, não sei se funcionam no Nextgen. Note na figura que postou que a diferença que aparece na imagem de junção são as placas indicativas ("toponímicas"), que tem um efeito realístico. A NNG, desenvolvedora dos navegadores iGO, chama este efeito de imagens foto realísticas, mas é necessário ter um licença específica para isso. Caso tal licença não esteja na pasta devida, as placas de indicação serão básicas. Explico este "básico": aparecerá a figura da junção (fundo e setas verdes), mas as placas de indicação aparecerão na parte superior da tela em formato já conhecido, aquele mesmo que aparece na tela de navegação (veja figura à direita postada pelo Paulo em post mais acima), isto é, aquela figura "chapada" em verde e azul, que também aparece quando aparece imagem de junções da NNG. Em suma, as novas placas, acho que mais belas, exigem licença especial para a correta exibição; sem elas, placas comuns. Abraços aos amigos!

Luiz, não falou besteiras não, você é um mestre de fato e tem meu respeito e admiração. Apenas aproveito para comentar sobre mais algumas linhas (ausentes em seu post) e sobre as junções da NNG. [debug] show_junction_view=1 show_signpost=1 A primeira linha acima, na seção/paragráfo, é aquela que realmente habilita a visão das junções, ela também é necessária. A segunda habilita as placas de indicação (antes chamadas de "toponímicas"). Sobre as junções da NNG, o Luiz tem razão, sempre estiveram presentes nos mapas da TT e ausentes nos mapas da Here. Neste último sempre foi necessário usar o arquivo auxiliar de extensão .FJV para exibição de junções de formato exclusivo para os conteúdos da Here. Porém, de tempos para cá, a Here também tem usado junções da NNG em seu arquivo de mapa FBL, ficando, neste caso, com os dois formatos de junções: o específico e o nativo (NNG). A TT, aqui no Brasil, apenas junções da NNG. Ao selecionar o mapa/conteúdo da Here, poderia existir conflito entre os dois formatos de Junções. A resposta é não. O Primo, idem o Nextgen, trabalha com o conceito de prioridade. Assim, no caso das junções, havendo os dois tipos em um mesmo ponto, o Primo (no caso de conteúdo da Here apenas) dá prioridade para a imagem de junção do arquivo FJV (se este estiver presente), em seguida vem a imagem da NNG. Isto é, a imagem de junção da NNG só aparecerá, na prática, se não houver imagem de junção (naquele ponto) no arquivo FJV. Apesar de a Here está usando imagens de junções da NNG em seu arquivo de mapa, o trabalho ainda está muito no início, com poucas imagens presentes, sendo que aquelas do FJV são bem mais abundantes. Já as imagens de junções da NNG em mapas da TT são bem mais numerosas. Observo também que o arquivo de imagens de junções, extensão FJV, parece com os dias contados. Na Europa ele já não existe mais e outros países também, poucos ainda recebem este conteúdo de uso específico. A Here está migrando o conteúdo deste arquivo para o novo FJW, mas que é operacional apenas no Nextgen. Grosseiramente falando, o FJV usa arquivos no padrão bmp/jpg, enquanto que o FJW usa figuras vetoriais em formato eps, que ocupa menos espaço e diz perder menos qualidade gráfica. Este é o problema com o Primo, que não reconhece arquivo de extensão EPS, por isso ele não reconhece o FJW. Assim, nos países em que o FJV foi abandonado, só resta aos usuários de Primo as imagens de junções da NNG e que está integradas ao arquivo de mapa. Não sei como ficaria a situação do nosso país caso do FJV também seja excluído, no mínimo o Primo ficaria com enorme limitação gráfica, mas o Nextgen sem problemas. Por fim, observo que o Nextgen reconhece ambos os formatos, FJV e FJW; visualmente são praticamente idênticos. Abraços!

Lorenci, o system.ini na pasta Save\profiles\01 não muda sozinho; ou há uma má configuração em seu syx.txt ou há uma configuração interna no pacote que desabilita os avisos de pontos de alerta. Este último fato decorre de que alguns navegadores vêm configurados para não avisar pontos de alerta, pois isto é proibido em alguns países. Ou seja, é uma configuração padrão e que pode ser reabilitada mesmo que se desabilite nas configurações do navegador. Nem todos são assim, claro. No seu caso, parece que há algo configurado no sys.txt ou no igo9.ini (que fica no data.zip). Corrigir é simples, mas é preciso testar. Basta inserir as linhas abaixo no sys.txt de seu navegador: [warning] speedcam_warning=1 Muito provavelmente o seu pacote deve estar setado com o valor 0, que desabilita o aviso dos pontos de alerta. Se este for o caso (e acredito nisso), então ao reiniciar o navegador tudo que está no sys será lido pelo executável e, assim, os parâmetros no system.ini serão atualizados. Passando o valor para 1 no sys.txt, então o system.ini sempre seguirá esta lógica e os avisos sempre aparecerão como o esperado. Aliás, já cometei em outro tópico aqui mesmo neste fórum: todos os comandos que aparecem no system.ini, principalmente após configurar o navegador (o que é meio chato e toma tempo), pode ser inserido no sys.txt. Assim, não será necessário reconfigurar todos os parâmetros todas as vezes que for necessário apagar a pasta Save, por exemplo. Tente aí, qualquer coisa avise novamente. Abraços!

Lorenci, também passo pelos mesmos problemas com o Primo para Android, mas ainda não desisti. A questão depende muito da versão do sistema operacional, das configurações disponíveis para o áudio, que geralmente depende de ajustes feitos pelo desenvolvedor da CM, etc. Porém tenho algo adicional, que é para Primo Android e que você poderá tentar aí: [guidancecompressor] compressor=1 highpass_freq=0 thrs=-20dB ratio=8 ;gain=30 ;[Configurar este parâmetro somente se thrs e ratio não ajudar (thrs=-20 dB e ratio=8 implicam em gain=7)] Os valores acima não são necessariamente ótimos, mas são intuitivos. Sugiro tentar do jeito que está e observar se haverá ou não diferença em relação ao nível do volume atual. Depois é só ajustar os comandos e verificar se surte algum efeito. Abração!

Meyer, dê uma olhada no link presente no txt em anexo, leia o primeiro post com toda atenção, teste e reporte qualquer problema se for o caso. []'s GPS Clube.txt

Maurício, uso o Primo 2.4 desde seu lançamento e nunca tive problemas sérios, exceto em poucas versões (duas ou três). Tenho aparelhos como os citados por você e rodando o pacotinho que lhe passei. Claro, cortei muita coisa, principalmente skins que uso, pois isto ficaria gigantesco. Quando lhe enviei o link, pensei que fosse testar da forma básica, sem instalar mais nada. Ou seja, tente usar o pacotinho apenas com o arquivo de mapa e nada mais. Veja se funciona a voz da Loquendo e se esta mantém-se gravada após seleção. Não use outra skin, apenas a padrão e veja se está ok. Lembro que também enviei o link com a pasta Save totalmente vazia, o que é importante para novos testes (sei que sabe sobre isso, mas como já falei antes, deixo as coisas detalhadas para que outros possam ter acesso a certas informações). Isto é, mantenha a Save vazia, com a skin padrão e selecione as vozes. Veja se funciona. Sobre a skin do amigo Ziko, não sei dizer, pois ando tão sem tempo para assuntos GPS que não pude testar as últimas novidades dele. Não acredito que seja a skin dele, mas também não sei falar o que foi feito sobre o efeito "mute" adotado. Como você sabe, só uso skins diMka e com modificações que me atendem o suficiente, sem mais do que o necessário (o restante, caso eu queira, deixo para módulos ux). O pacotinho é uma versão para "consumo" próprio e que foi baseado nos antigos Enterprise e Star Wars, mas literalmente visando desempenho e estabilidade (ou seja, modifiquei muita coisa desde tais "primórdios"). O executável usado é o mais estável e funcional que já testei e usei, não o trocando por versões mais novas (todas problemáticas). Afirmo e reafirmo que tudo funciona muito bem, não apenas as vozes, como também reconfiguração das schemes, TMC, Wi-Fi, BT, etc.; tudo devidamente testado e comprovado. É esta base que uso para testes e que uso nos prints de tela que apresento aqui no fórum quando se trata de Primo 2.4 para WinCE. Faça backup de um de seus cartões e formate. Use FAT32 e insira o pacote básico. Tem que funcionar! Ah, pelos comentários seus, já descarto WinCE e cartão. Espero que nada tenha modificado seu sistema operacional, mas seria mais estranho ainda. Insisto, tem que funcionar nos aparelhos que mencionou, pois aqui, em similares, funciona muito bem. Vamos conseguir resolver; um passo por vez! Abraços!

Maurício, este que foi enviado para seus testes funciona em qualquer aparelho que tenho (e são vários), sem restrição de tipo algum. Não faz sentido não funcionar em seus aparelhos, mas pode dar algum problema caso esteja usando um WinCE não padrão. Neste caso não seria problema no Primo, mas sim no WinCE. Outra coisa que é bom dar uma olhada é sobre os canais de áudio: em alguns aparelhos é necessário configurar o Primo para apenas um canal de áudio (mono), pois não aceitam o estéreo. Isto é feito através do sys.txt: [sound] dev_channels=2 Tente mudar o valor de 2 para 1 e faça testes. Outra coisa que merece atenção: não me lembro de você ter dito que está fazendo testes em cartão de memória externo ou diretamente na memória interna. Caso o cartão esteja com algum problema, mesmo não acusado pelo sistema operacional, é claro que problemas podem surgir e não haver salvamento das configurações. Testar na memória interna e no cartão também pode ser uma boa. Não faz sentido não rodar o Primo por ser da versão 2.4, exceto nas condições que falei. Se for uma CM, então é bom verificar o nível de intensidade sonora para cada fonte de áudio. Falo isso porque a fonte de áudio para bipes é diferente para voz TTS em várias CMs, mas desconheço tal recurso em PNA (dispositivos GPS portáteis). Além disso, em CM é comum o uso de WinCE muito fora do padrão, o que pode gerar problemas. Em suma: não desconfie do Primo, mas sim do WinCE usado ou até mesmo do dispositivo, mas não custa dar uma olhada no cartão de memória, caso esteja este sendo usado nos testes. Abraços!

Maurício, tente este aqui: GPS Clube.txt Está bem limpo, sem skins e outras coisas, mas acredito que suficiente para seus testes. Abraços!

Maurício, o Primo 2.4 sempre foi "temperamental" em relação as vozes da Loquendo, não é qualquer versão que as aceita. Como observei que você não citou uma versão testada que coincida com uma que funciona (muito) bem, então tento lhe auxiliar novamente. Acho que não terá problemas com o data.zip, exceto se for algo muito específico. Tente: GPS Clube.txt Abraços!

Maurício, experimente os arquivos de voice presentes no txt em anexo; apesar das datas são os mais recentes que tenho. Abraços! GPS Clube.txt

Maurício, tente mais alguns testes aí: 1. Faça um backup da pasta Save; talvez tenha que apagá-la em algum momento. 2. Entre na pasta \save\profiles\01 e abra o arquivo system.ini. Localize o seguinte parágrafo e linhas (que provavelmente serão diferentes da exibidas aqui): [regional] lang_path_hint="lang\Lang_Portuguese-bra.zip" language_key="portuguese BRA" language_lcid="1046" units="1" voice_key="TTS_nua_por_bra_f1_lua-dri40-vssq5f22" voice_path_hint="voice\Voice_TTS Pro-Nuance_4.5_MF-PTBR - Raquel.zip" As duas últimas linhas estão setadas para a voz da Nuance. Apague apenas estas duas, salve o arquivo, reinicie o Primo e teste as vozes para verificar se ficaram ok. 3. Observo que uma voz TTS não salvar significa falha no arquivo info.ini no arquivo de voz (\content\voice) ou má configuração do mesmo ou ainda incompatibilidade com o engine. Quando não é isso, é falha nos arquivos da pasta Save. A sugestão é fazer backup, apagar a Save atual e fazer testes. 4. Caso algumas skins tenham algum recurso alterado, mas a ponto de modificar alguma voz, então haverá erro e poderá implicar em falhas das vozes. Alguns campos poderão ficar em cinza/esmaecidos/desativados, ou até mesmo a voz não será carregada. O problema, neste caso, estará no arquivo de voz (\content\voice). 5. Se for necessário apagar a pasta Save, então sugiro tentar configurar a voz TTS usando a skin padrão antes de mudar para qualquer outra skin. Se não funcionar, problema no arquivo de voz. 6. Se nada der certo, avise, pois tentarei upar as vozes que uso aqui para seus testes aí (ou seja, apenas os arquivos da pasta \content\voice, que me parece a fonte dos problemas). Abraços!

Maurício, o executável do Primo 2.4 que conheço apresentar problemas com a Loquendo 7 é a 9.6.13.267029, qualquer outra que testei (obviamente, nem todas existentes) não gerou problema. Se a voz da Nuance funciona corretamente, então não é problema de configuração (sys.txt e/ou igo9.ini). Logo, restam como possibilidades a falta das bibliotecas necessárias (arquivos de extensão .dll) ou algum arquivo corrompido. Se tudo isso ok, então será necessário ter os arquivos de vozes configurados corretamente (aqueles que ficam na pasta \content\voice). Diferentemente do Primo para Android, no caso do WinCE (sim, sei que você sabe, deixo detalhado caso seja útil para outras pessoas) é preciso ter um arquivo de voz para cada tipo de voz (Gabriela, Fernanda e Felipe). Veja se tudo isto está ok. Abração!

Miguel, o ajuste do nível de volume do Primo rodando sobre Android realmente não é trivial. Os comandos típicos para a versão WinCE e que funcionam muito bem (para ajustar o nível sonoro), não dão resultados na versão para Android. Uma ideia é tentar alguns ajustes no sys.txt. Se não tiver as linhas abaixo em seu sys.txt, basta inserir e testar: [android] navigation_audio_stream=1 A segunda linha acima é responsável pela seleção do tipo de transmissão de áudio. Os valores possíveis para a segunda linha acima (após o sinal de igual, "=") são os seguintes: 0 = chamada de voz, 1 = sistema, 2 = toques, 3 = música, 4 = alarmes, 5 = notificação. Observe que setei o valor para 1, ou seja, está habilitado "sistema". Outras possibilidades ficam claras com os valores acima, bastando trocar o valor 1 por outro. Aí não tem macete, é tentativa e erro, pois depende da versão do Android e como ele está configurado internamente. E já que falou sobre o rádio, não custa tentar o valor 3 caso o valor sugerido (1) não fique adequado. Claro, tente um valor por vez e veja se algum produz algum resultado superior aos demais. Para o Primo rodando em WinCE, os parágrafos e linhas a seguir são responsáveis pelo nível da intensidade sonora. Deixo-os aqui: [dynamiccompressor] compressor=1 gain=12 ; (define it only if thrs and ratio don't help [-20dB,8 gives 7 for gain]) highpass_freq=0 a0=56806 thrs=24703 ratio=9 ; (min=0 max=9) Não acredito que possa funcionar em Android, pois minha CM também usa este sistema e o sistema operacional ignora as linhas indicadas acima. Por outro lado, não custa tentar, pois como já falei, tudo depende da versão do Android. Boa sorte! .XA.

Paulo, nunca é possível usar uma ux feita para um sistema operacional (WinCE e Android, por exemplo) em outro sistema operacional (pois as subpastas têm nomes diferentes). Também não é possível usar uma ux feita para um navegador GPS em navegador de outro tipo (idem), dará conflito. No caso do Primo para WinCE e para Android, às vezes pequenos ajustes são suficientes para o correto funcionamento, pois a lógica usada na programação é a mesma. Mas no caso do Nextgen, muda muita coisa e raramente é possível usar algo deste navegador GPS no Primo (e vice-versa). A ideia para desenvolver um módulo ux de um navegador e migrar para outro consiste em pegar os parâmetros principais e refazer a programação. Não pode ser diretamente. Só para dar uma ideia: na skin do Pongo para Nextgen, no arquivo Navigatemap.ui, tem-se /**********/ <layer ui_city_reading z=5> <DIV class="cockpit"> <DIV class="city" visible=(!%lua.DragMode && %lua.city.show && !ui_PropLayer.SignpostVisible && !ui_PropLayer.splitscreenopen && !ui_PropLayer.JunctionViewVisible && !%lua.MenuIsOpened && !ui_Cockpit.ZoomOnCockpit && !ui_PropLayer.SplitScreen)> <HBOX class="city"> <HBOX class="city_container"> <SPRITE class="city" position="absolute"/> <TEXT class="city" textmodel_wstr="map.cursor.address.city"> </HBOX> </HBOX> </DIV> </DIV> </layer> Este comando <HBOX> (para abrir) e </HBOX> (para fechar), não é reconhecido pelo Primo, então é preciso mudar isso. Também é necessário localizar as funções usadas, como estas duas que aparecem no arquivo Models.lua: MODEL.SETPERSISTENT.lua.CityShow = INT_MODEL(0) MODEL.SETPERSISTENT.lua.city.show = BOOL_MODEL(false) Depois é preciso estudar como elas funcionam. Por exemplo, no arquivo Setting.ui encontra-se linhas do tipo: <userlist lm_SkinCockpit haspopover="bool" (...) <row prio=1400 text="Show City Name" haspopover=1 details=(sc_Town(%lua.CityShow)) onrelease='sc_SetPopoverListAndOpen("ui.lm_Town_popover")'/> <row prio=1500 text="Show the town district name" type="ChkOnOff" isselected="lua.city.show"/> (...) <userlist lm_Town_popover text="str" onrelease="ui" enable="bool" animate=-1 possiblevalues=-1> <default enable=1/> <row text="Off" onrelease='MODEL.lua.CityShow = 0 sc_ClosePopover()'/> <row text="City Name" onrelease='MODEL.lua.CityShow = 1 sc_ClosePopover()'/> <row text="City & Zip Code" onrelease='MODEL.lua.CityShow = 2 sc_ClosePopover()'/> E assim por diante, até conseguir-se encontrar todos os parâmetros e em todos os arquivos que estão presentes na skin do Pongo para Nextgen. Depois que tudo é encontrado é necessário refazer a programação segundo a lógica que é entendida pelo Primo. E para piorar, não há garantias de que funcionará corretamente no final. Motivo: não dá para saber o que o Pongo pensava ao programar este recurso, logo é quase um processo de adivinhação. Eu pelo menos procedo assim, pois programar tudo do zero tomar enorme tempo e esta forma já exige muito tempo também, tudo do zero é muito pior, só se já se tem algo muito bem pensado. E como tenho cada vez menos tempo, pior fica (no meu caso). Abraços!

Anor, somos das "antigas", se bem que eu comecei neste mundo GPS bem tarde (final de 2012 início de 2013). Não sabia nada, mas resolvi aprender por conta própria, porém consegui outros que queriam o mesmo e formamos um pequeno grupo de corajosos/audaciosos (ex., Adinis e Rafael). Aprendemos bastante e resolvemos compartilhar. Mais: peguei uma época de transição entre o iGO8 e o Primo, sendo que o Amigo parecia (naquela época, talvez ainda hoje) incompreendido por muitos. O iGO8 me deu muitas dores de cabeça, por ser limitado, então "investi" no Primo e acho que ainda é um bom navegador. Por outro lado, é bom dizer, ele está tão "velhinho" hoje quanto era o iGO8 quando iniciei. Porém não ouso "investir" no Nextgen, não por ser ruim ou algo do gênero, mas por não se estabilizar rapidamente -- a cada dia, uma coisa nova e muito diferente, não dá para fazer algo e ter que refazer pouquíssimo tempo depois, ninguém tem tempo para isso (eu não). Entre este vai e vem do Nextgen, é bom que se registre, tem-se a tentativa de fazer do mesmo o que o Primo já é. Poucos se dão conta disso, mas o Nextgen nasceu para ser diferente mesmo, mas ninguém quer abrir mão dos velhos e confiáveis recursos do Primo. É por isso que vira e mexe alguém pede algo para o Nextgen, e ele vai ficando com a cara do Primo, porém em recursos, não necessariamente do ponto de vista do visual (aparência). Afirmo: isto é bom! Mas nem por isso deixarei o Primo de lado... A confiabilidade e a interface de uma diMka não tem igual! Caro Anor, baixei sua ux e vou estudá-la (aliás, ux não, uma verdadeira skin que é do Pongo). Sempre questionei o fato de mapas da TT exibirem nomes de bairros e nos da Here, não. Não faz sentido, pois os bairros estão lá, nos mapas da Here também. Parece "perfumaria" ter nomes de bairros na tela de navegação, mas não é bem assim. Basta pensar em cidades desconhecidas... Primeiro a cidade, depois o bairro e só depois a rua/avenida; é a maneira natural de nos posicionarmos; faz falta sim. Vou me empenhar neste tema, espero conseguir, mesmo sem muito tempo. Grande abraço, .XA. PS: Sim, com os mesmos ideais...

Amigo Anor, disponibilize tal módulo ux para que eu possa dar uma estudada e analisar a viabilidade da migração para o Primo. Outra coisa, a figura postada foi usando mapa da Here ou da TT? Pergunto isso porque para os mapas da TT sempre é possível informar os nomes de bairros, a limitação só ocorre com mapas da Here. Se estiver funcionando (no Nextgen) com mapa da Here, então há chances de funcionar com o Primo também. Abraços!

ROP, as alterações de cores das vias, bem como dos rótulos contendo seus nomes, são feitas no arquivo color.ini no arquivo de scheme. Cito algumas linhas para os nomes de ruas/vias que você poderá tentar aí: label_road="", 0,0,0 label_roadlt="", 90,90,90 label_settlements="", 0,0,0 label_junction="", 128,0,0 label_poi="", 0,127,0 label_shapes="", 0,0,0 label_country_names="", 0,0,128 label_address_point="",255,255,255 label_poi_icon="", 33,69,181 roadlabel_fill="", 255,255,255 roadlabel_frame="", 255,0,0 roadlabel_stick="", 0,0,0 Naturalmente existem outras linhas, mas estas acima servem como um bom ponto de partida. Para editar o color.ini, sugiro usar o software ColorSchemes, que é um executável muito simples de usar. Existem várias linhas que se iniciam com planned_road, mas estas são para as vias em si. Por outro lado, os navegadores da família iGO usam, em alguns casos, as cores da via para as fontes usadas nos rótulos com os nomes das mesmas. Sim, o preenchimento do nome da via usa a cor da via, mas também usa uma borda, que pode ser configurada a parte. Lembrando que a cor da via diz respeito a cor para o/a tipo/natureza da via (e não para cada uma, isto é, não dá para personalizar neste nível). Caso queira algo mais específico, é só falar. Abração! ------------------------------------ Editado Quem quiser tem novas scheme aqui: http://gpsclube.com/forum/index.php?/topic/3325-novas-schemes/

João, tempos atrás fiz uma tabela semelhante a sua, mas nada de 7Ways e NextGen. Por outro lado, já não me recordo bem sobre os detalhes. :D Abaixo deixo um anexo contendo um link para um pdf que preparei (como sugestão), porém sendo baseado no seu, onde fiz algumas alterações de memória. Não alterei nada sobre o 7Ways e NextGen, mas corrigi algumas coisas nas traduções (as que uso), nos nomes originais e até mesmo nos códigos dos tipos de pontos de alerta (Primo e iGO8/Amigo). Na coluna iGO8 e Amigo fiz o que era possível; nosso amigo Cláudio é mais indicado para informar com mais precisão. Nesta coluna, onde marquei "Não disp." entendi que eram type não disponíveis para iGO8/Amigo. Se não me falha a memória, existem 14 types (nem todos usados) "oficialmente" reconhecidos por estes navegadores. Por outro lado, existem skins para estes navegadores que liberam outros types, mas que preferi não citar para evitar confusões. Observo que pode haver erros; aliás, muito provavelmente. Bem, minha ação é apenas uma tentativa de ajudar o amigo e na esperança que possa ser um (ótimo) material a ser compartilhado para todos em futuro próximo. Abração! GPS Clube.txt

Lorenci, você está correto, as rotas oferecidas pelos navegadores distintos, mesmo que do mesmo tipo (fácil, curta, etc.), são diferentes. Por outro lado, não é motivo para surpresa. Explico: o arquivo responsável pelo roteamento das rotas, ou seja, os tipos de rotas que serão consideradas durante o cálculo, é nomeado "default.vis", que fica no data.zip, na subpasta \ui_igo9\common. Em linhas gerais a coisa funciona assim: o tipo de rota (por exemplo, fácil) é, na verdade, um algoritmo que considera os vários tipos de vias que serão usadas no cálculo pelo navegador. Feito tal seleção, então o navegador "olha" como as vias são tratadas, ou seja, como são consideradas pelo navegador. É neste momento que o navegador "consulta" o arquivo default.vis para "ver" como as vias são consideradas. Feito isso, o cálculo é feito e uma proposta é apresentada ao usuário. Em virtude da natureza do executável do navegador, isto é, a maneira em que ele foi pensado e programado, o arquivo defautl.vis assume configurações distintas. Isto é natural, pois novos recursos vão surgindo e os navegadores vão evoluindo. Uma simples observação reside no fato de que os navegadores iGO8 e Amigo não reconhecem as imagens de junções, mas o Primo e o NextGen sim. Assim, as informações sobre junções são completamente ignoradas durante o cálculo de uma rota com os dois primeiros navegadores, porém são consideradas os outros dois. Mas veja bem, não estou falando sobre a exibição das junções na tela de navegação, mas sim o fato de ter ou não junções em determinada via. Isto vale para postos de pedágio, para aquilo que é uma via simples ou de várias faixas, etc. Se o default.vis não prevê certas coisas, então tais coisas não fazem parte do cálculo e, consequentemente, as rotas serão diferentes. Outra coisa que é importante considerar são os módulos ux e certas skins. Por exemplo, se o usuário tiver o módulo ux "área de rodízio" (ou o recurso estiver presente diretamente em uma skin) e se o mesmo estiver habilitado, então o navegador terá mais uma opção para usar durante o cálculo de uma rota. Além deste exemplo, cito o recurso das diMka "dar preferência por rodovia". É claro que será um novo tipo de rota e que poderá ter traçado diferente. Fora isso, ignorando o caso do TMC (que influencia muito uma rota), há os arquivos HSP e FSP. Estes arquivos são responsáveis por informações nas várias vias disponíveis no arquivo de mapa, assemelhando-se a uma espécie de "TMC offline", ou seja, contendo informação a cada hora do dia e a cada dia da semana sobre velocidade média da via ou fluxo (circulação de veículos). Tem navegadores que não reconhecem tais arquivos, logo não influenciará o cálculo de uma rota; já outros os reconhecem e os leva em consideração, onde ao final poder-se-á ter uma rota diferente. E para piorar o cenário, ainda temos usuários que usam o FSP (com data recente) misturado com os velhos HSP (2011-12), gerando conflitos ou cálculos deficientes e/ou imprecisos. Em suma, as rotas oferecidas são diferentes porque a natureza/proposta dos navegadores são distintas, de modo que não é possível comparar coisas desiguais. É por aí... Abraços, .XA.

Antônio, desconheço uma resposta definitiva, talvez alguém saiba mais. Desculpe-me por ousar comentar sem ter uma resposta completa. Bem, até onde eu sei, não há uma maneira de ajustar a informação de distância sobre uma rota alternativa. Este algoritmo leva em consideração informações presentes no arquivo de mapas (FBL) e no arquivo FSP (velocidade média), porém antes usava informações do HSP (histórico de velocidade; arquivo antigo para o nosso país e que sugiro não usar mais). A ideia do funcionamento é o seguinte: há no FBL uma informação (quando disponível, claro) sobre a velocidade da via e há também (em rota traçada) uma informação sobre o trajeto/percurso e, logo, a distância. Portanto há uma estimativa do tempo médio para esta rota. Se o recurso para oferecer rota alternativa estiver habilitado, então o Primo "observará" o tempo médio até certo ponto e oferecerá uma rota alternativa (caso exista) se o novo tempo médio for inferior ao atual. Ou seja, considera-se a velocidade da via, mas também a velocidade média (FSP) disponível e assim indica-se nova rota. Claro, havendo TMC ativo, então ele é considerado também. Todo este conjunto de informação é nomeado "rota inteligente" (smart route). E quando o Primo (e demais navegadores da família iGO) avisa sobre disponibilidade de rota alternativa? Quando a gente fica mais parado do que andando no trânsito! Isto faz com que a média de velocidade fique abaixo do esperado e o Primo tenta indicar uma nova rota mais rápida. Nem sempre a nova rota indicada (a a "alternativa") é boa, pois aqui neste país a maioria dos aparelhos não tem TMC, de modo que os dados usados são offline (FBL, FSP, HSP, etc.), que trabalham com médias coletadas e não em tempo real (TMC). Deste modo, a mensagem de rota alternativa pode surgir a qualquer momento, basta que o tempo estimado (para uma rota traçada) seja ultrapassado (ou seja, esteja além dos limites estipulados). Sei que não dá para mudar a distância para o aviso, pois no fundo o que está em jogo não é a distância, mas sim o tempo. Mas pode existir algo mais que desconheço e que me leva a acreditar na minha afirmação (errônea ou não). Daí meu cuidado desde o início deste post. Entendo que o aviso sobre rota alternativa é mais efetivo ao entrar e sair de cidades do que dentro das cidades. Uma dica (não me lembro o nome de quem disse usar tal coisa tempos atrás...) é, ao se deparar com um congestionamento, passar de modo de visualização 3D para 2D, ver a direção (setinhas) sobre as vias e ver pelas cores (de verde escuro até vermelho escuro) o fluxo médio indicado (FSP ou HSP) e tentar um novo caminho por conta própria. Nunca usei este método em momento de "sufoco", só para testes rudimentares, mas acredito que seja útil e funcional. Deixo a palavra com outras pessoas que possam contribuir melhor. Abraços!

Antônio, siga pelo caminho Configurações => Sons, avisos e alertas => Configurações de voz TTS Pro => Falar os pontos de alerta. Abrirá uma tela semelhante a esta (vai depender da skin, claro): Agora clique sobre o ícone de lombada (na verdade isto pode ser feito para qualquer ponto de alerta) e uma tela análoga a próxima será aberta: Observe na figura acima que o primeiro ponto tem as inscrições "Segunda frase (limite de velocidade)" e "ligado" no lado direito, indicando que o recurso (a segunda frase) está habilitado. Desmarque este campo; uma tela como a próxima será exibida: Agora clique no botão "Teste de voz". Você ouvirá apenas a distância até a lombada (ou outro ponto de alerta se o mesmo procedimento for usado). Pronto! Só isso e nada mais. Abraços!