Estruturaça£o do trabalho de desenvolvimento

[Haigh]

Antes de qualquer coisa, parabéns pela iniciativa. A qualidade de tudo o que está sendo feito aqui é realmente impressionante. parabéns por terem montado um Wiki dos manuais e documentos de referência, afinal de contas é um projeto colaborativo.

Gostaria de dar uma sugestão para estruturar o trabalho de desenvolvimento do Tracksource Roteável. Aliás é uma sugestão para estruturar o desenvolvimento do Tracksource como um todo. A base do conceito é que colaborar precisa ser mais fácil e divertido e menos técnico para atrair mais colaboradores. Tenham paciência que o texto ficou longo, mas vou explicar todo o conceito abaixo.

Sou um apaixonado por GPS e só agora comecei a me envolver no projeto. Estou estudando o material e os softwares para poder começar a colaborar.

Pelo que entendi a construção de mapas vetoriais roteáveis com um banco de POIs vasto é um esforço grande que vem sendo desenvolvido pela equipe usando uma estrutura de compilador / desenvolvedor / colaborador para manter a ordem e qualidade do produto final. A forma oficial de colaboração tem sido a troca de documentos no formato do TrackMaker, o que faz todo o sentido do mundo quando estamos construindo a parte vetorial gráfica do mapa (ruas, avenidas, rios, lagos, fronteiras) mas pode não ser a mais adequada para POIs e certamente não tem os recursos necessários para as informações de roteamento das tabelas de nós.

Apesar do TrackMaker ser relativamente fácil de usar, a complexidade da manipulação de arquivos e incapacidade de trabalho com dados diretamente em estrutura de banco (útil para POIs e tabelas de nós) afugenta possíveis colaboradores justamente nas atividades que irão precisar do maior número possível de ajudantes, cadastro e validação de POIs e levantamento de campo para tabelas de nós de roteamento.

Sugiro quebrarmos o problema de construção dos mapas em 4 etapas e tratá-las de maneira distinta:

1) Construção e atualização dos mapas gráficos
2) Input e validação de POIs
3) Construção e atualização das tabelas de nós
4) Input e validação dos tags de roteamento das vias e das restrições de nós

1) Construção e atualização dos mapas gráficos - é a fase de desenho dos tracks, nomeação e formatação das vias. Esta etapa requer obrigatoriamente o uso e conhecimento específico do TrackMaker. É uma etapa trabalhosa mas que requer mais conhecimento técnico do que braço. Pode ser executada por um número limitado de pessoas (os atuais desenvolvedores) e uma vez completada com qualidade, requer baixo nível de atualização (somente com a construção de novas vias). Para muitos municípios existe alguma forma de mapa vetorial para ser usada de base. O processo desenvolvido atualmente é extremamente satisfatório para a execução desta etapa. A contribuição de colaboradores irá sempre requerer o uso do GPS para levantamento de campo, a construção no TrackMaker de um subconjunto do mapa atualizado e seu envio para um tratamento trabalhoso pelo desenvolvedor. Por este motivo o número de colaboradores será sempre reduzido.

2) Input e validação de POIs - O número de POIs possíveis é virtualmente infinito (Metroguide USA tem mais de 6 milhões) e precisa de constante atualização. Empresas mudam de endereço, mudam de telefone, fecham e abrem todo dia. Por este motivo o número de colaboradores necessários para criar e manter esta parte da base será sempre maior do que o do mapa gráfico. Tecnicamente o banco de POIs não precisa ser atualizado via TrackMaker. Na realidade a interface do TrackMaker é bastante trabalhosa para a inclusão de um grupo grande de POIs. A sugestão é tratar os POIs como um banco de dados, usando uma interface simples de manipulação de tabelas, nas quais qualquer colaborador possa rapidamente criar listas longas de POIs com todos os parâmetros necessários. Pode até ser uma tabela do Excel bem formatada e com regras de validação dos parâmetros. Estas tabelas poderiam ser importadas e exportadas do MapSource (que quase todos os usuários sabem usar) como waypoints para facilitar a localização precisa referente aos mapas do tracksource. O tratamento em banco facilita muito a vida de colaboradores que tem acesso a tabelas com dados para algum tipo específico de POI, como o cadastro nacional de ATMs ou a lista de franquias de um restaurante ou agencias de um banco. Estes colaboradores poderiam facilmente compartilhar esta informação sem ter que se tornarem experts em TrackMaker. A gestão para validar e anexar os dados ao mapa principal poderia ser feita pelo desenvolvedor / compliador do mapa ou poderiamos ter um coordenador específico para POIs. O coordenador poderia ser por região ou por tipo de POI uma vez que tanto os colaboradores como os desenvolvedores têm afinidade/interesse por um tipo de POI. Alguem poderia, por exemplo, ser responsável por todos os POIs relativos a Bancos e ATMs, padronizando a nomenclatura para facilitar a classificação. Este responsável poderia contatar os bancos ou funcionários e conseguir que as próprias instituições fornecessem as informações de maneira estruturada (na tabela padrão de formato) uma vez que São interessadas em manter os dados atualizados. Os usuários interessados no monitoramento das posições dos radares se organizariam para manter a base de POIs específica atualizada. Outros usuários poderiam trabalhar por região, monitorando os estabelecimentos perto de onde residem. A estrutura de um banco centralizado permitiria esta gestão geográfica e por tipo simultaneamente. Além disso, poderia ser criado um mecanismo de validação com outros usuários visitando e validando as entradas feitas por outros colaboradores. Um POI só entraria na base Após validação por um número x de usuários. Eu poderia baixar uma lista de POIs na minha região ou de um dado tipo que precisassem de validação. O banco poderia Também ter a idade da última validação do POI para gerar automaticamente listas de revalidação de POIs antigos para limpeza do banco. Desta maneira o trabalho de manutenção da base de POIs se tornaria estruturado e mais simples, atraindo mais colaboradores. Eu poderia me interessar por gerir os POIs de supermercados (caso fosse do ramo) ou montar um programa de final de semana de visitar POIs de restaurantes perto de casa que precisassem de validação. Precisamos tornar o trabalho estruturado e divertido. Contribuir precisa ser mais fácil e gostoso senão atrai somente os muito dedicados.

3) Construção e atualização das tabelas de nós a¢â‚¬â€œ já li o manual de roteamento e o processo todo é bastante complexo, ainda está em definição e vai requerer bastante conhecimento técnico. Minha sugestão é dividi-lo em duas etapas. A primeira é a construção da tabela de nós. De maneira análoga ao desenho do mapa gráfico, esta etapa precisa ser bem feita uma vez e só é atualizada com a construção de novas vias. É a parte mais técnica do roteamento, requer profundo conhecimento dos softwares, do processo de roteamento, das regras de criação de mapas e nós e do mapa gráfico desenhado. Sugiro que os desenvolvedores do mapa gráfico sejam responsáveis pela criação dos mapas com tabelas de nós para roteamento.

4) Input e validação dos tags de roteamento das vias e das restrições de nós a¢â‚¬â€œ A população da tabela de nós e vias com informações e restrições de roteamento é um trabalho que requer conhecimento técnico (pela complexidade do banco de dados e codificação das restrições) e muito braço, pelo volume de nós e dados a capturar por nó e por via, pela falta de informações existentes e pela constante mudança nas restrições (mãos mudando, retornos abrindo e fechando, etc.) A idéia é análoga ao tratamento do mapa e POI. O desenvolvedor se responsabiliza por gerar uma tabela de nós com identificação constante para cada nó e é gerada uma interface simples para preenchimento das restrições e tags de vias e nós. Pode Também ser criada uma regra de visitação e validação dos nós por um número x de colaboradores para garantir a qualidade da informação. Esse sistema Também concentraria os esforços em áreas com nós ainda não classificados e validados. Dessa forma um programa de sábado para um colaborador poderia ser baixar uma lista de nós a visitar como waypoints no GPS e passear pela cidade capturando informações de restrições de maneira estruturada em um formulário em papel ou no PDA ou laptop que seria inputado na interface web de um sistema para compilação pelo desenvolvedor.

Dessa maneira as partes que requerem braço (etapas 2 e 4) seriam simplificadas tecnicamente e tornadas mais divertidas para cativarem mais colaboradores, livrando os desenvolvedores experientes para assumirem mais regiões para as etapas técnicas (1 e 3), acelerando o desenvolvimento do projeto. Um núcleo de desenvolvedores experientes poderia assumir a função de manutenção dos mapas e tabelas de nós e gestão do sistema de captura de informações de restrições de nós dos colaboradores, garantindo padronização e qualidade. Outro grupo poderia se responsabilizar pela qualidade e tipo de informações de POIs.
Dessa maneira o trabalho ficaria mais estruturado e permitiria o envolvimento de mais colaboradores.

Gostaria de discutir essas idéias aqui no fórum e ajudar na estruturação do desenvolvimento. Espero que seja do interesse do grupo.

Abraços
Robert

[Wallace]

Oi Robert,

Entendo que São coisas completamente diferentes.
Primeiro acho que temos que considerar no minimo 2 projetos diferente.
O estadual que em algum momento a curto medio prazo acredito que vai ser substituido pelo roterizado se não existir problemas com a compilação do mesmo que é feito por terceiros.
O outro os municipiais que não vejo como ser roterizado a não ser a longo prazo, principalmente nas grandes cidades, onde alias ele seria mais util.
não vejo nenhum problema nos metodos atuais tanto para a se incluir novas vias ou POIs.
Os roteaveis entendo que São mais trabalhosos na etapa inicial que é migrar os dados antigo e fazer as adapatação iniciais necessaria, a medio prazo fica como o projeto estadual normal.
Uma coisa que já esta tomando um ciclo mais longo de tempo que antigamente é a data final da contribuição para o lançamento da nova Versão do projeto. As suas sugestões entendo que vai tornar este ciclo ainda mais longo.
Entendo que isso junto com a demora de alguns desenvolvedores de incluirem as contribuições São os maiores problemas de desistimulam as contribuições.
Acho o que precisa basicamente é se aumente o numero de desenvolvedores e que cada um faça sua contribuição mesmo que pequena, 1 hora por semana em quase todos os casos é mais que suficiente.
Também tenho visto pouca colaboração, principalmente nos POIs.
Eu, por exemplo, sou desenvolvedor de mais municipios que gostaria e atualmente estou com varios disponiveis para outros desenvolvedores e tenho me dedicado no momento ao municipio de Bragança Paulista a qual tenho um mapa já em TrackMaker mas desenhado em quadras e não em ruas como o projeto requer.
Assim como não tem os nomes nem mais informações das vias.
Mas aos poucos vou terminar este trabalho e vou partir em seguida para outro, isso sem deixar de lado os outros municipios que sou desenvolvedor, o que alias quase não geram trabalho.
Destaco que sou desenvolvedor de municipios que numca fui nem conheço, já que muitas vezes isso nem é necessário.
então acho que hoje o que poderia ser feito é a compilação estadual e municipal ser feita por pessoas diferente, o que antes deixava a compilação mais rápida e sem sobrecaregar ninguem.
E num incentivo ao desenvolvimento e colaboração.

[nqnnospam]

Haigh,

Com relação aos POIs, já temos um banco em http://www.tracksource.org.br. está em fase inicial, é verdade, e não está dividido da forma que você sugere, mas é um banco. Por enquanto ele aceita entrada de POIs através da interface WEB, ou através de arquivos .gtm.txt. Outras formas de entrada podem ser implementadas, mas seriam necessários voluntários para implementar estas soluções. sugestões São bem-vindas, é claro, mas infelizmente não temos "man-power" para implementar tudo.

A questão dos roteáveis é mais complexa. Criar um banco de dados para entrada das restrições esbarra no mesmo problema anterior, voluntários para implementar isso, e as ferramentas necessárias para converter este banco de dados num dos formatos de mapa digitais suportados pelo programa compilador Roteável. Infelizmente o GTM não tem recursos para tratar os nós nem as restrições de roteamento, e isto gera uma limitação séria. Antes de implementar um banco de dados de restrições, temos que solucionar esta questão do GTM.

Estamos buscando pessoas (voluntários) com conhecimentos de programação e tempo, para implementar tais soluções.

[casaretto]

Haigh

Extremamente oportuna e lúcida sua proposta.
Alguns detalhes faltam a voce. Vou usar os mesmos tópicos que voce usou:

1) Construção e atualização dos mapas gráficos
Uma futura interface gráfica com uma base GIS, poderá facilitar a criação de mapas e recuperação de colaborações. Nada a curto prazo.

2) Input e validação de POIs .
O desenvolvimento da atual base foi feita utilizando as informações existente nas tabelas do grupo de emails no Yahoo que não tinham nenhuma consistencia e apresentavam inúmeros erros. Tanto que foi necessário um recadastramento dos desenvolvedores para podermos validar os nomes e emails. O banco utilizado é Mysql 4, que não tem suporte a GIS. Todos o trabalho de modelagem, busca de soluções e posterior criação das bases e interfaces de entrada e manutenção foram feitas por uma única pessoa, nas horas de folga e até às vezes sofrendo críticas pelo trabalho.
O maior impedimento de alimentação de POIs em lote, como é sua sugestão, é a validação nos padrões do grupo. Só se pode alimentar na base POIs dentro do padrão. Como a mão de obra é finita, optou-se por aceitar somente POIs em lote já validados no GTM ou inicialmente através de tela com o desenvolvimento de uma validação na interface.
até hoje estamos dependentes e já solicitamos na lista pessoal para ajudar no desenvolvimento de uma rotina de validação.
Suas propostas São ótimas, mas só poderão ser implementadas se vierem acompanhadas de ajuda para desenvolver.

3) Construção e atualização das tabelas de nós
Uma tabela de nós é dinâmica e reconstruida a cada rodada do Conversor. Por conceito não é um ponto físico e sim, resulta da interseção de dois tracks. Essa "entidade" não existe hoje no GTM e portanto não tem como termos propriedades e nem mesmo um identificador para ela. Estamos na busca de soluções e propostas São sempre bem vindas, mas a ideia de termos uma tabela fixa (ou algo parecido) que possa ser trabalhada, por enquanto é inviável.
Uma implementação de uma interface deverá ser feita através da vias que compõe o nó, bem mais fácil de aderir à realidade, como por exemplo esquina das Rua A com Rua B.


4) Input e validação dos tags de roteamento das vias e das restrições de nós
Algumas coisas já São possíveis (todas as propriedades que podem ser vinculadas ao track, como sentido, etc) e outras estão sendo desenvolvidas.
Um grande passo será dado, caso seja possível termos as vias num banco GIS e podermos representar graficamente estas vias e os nós. Com isso poderiam ser implementadas interfaces gráficas que facilitariam a alimentação e correção das restrições e outras propriedades.


Agradecemos sua proposta. está dentro das nossas metas e agradeceremos mais se vierem acompanhadas de ajuda para implementar.
Um grande abração,
Paulo

[speedcam]

A base de radares do projeto Tracksource precisa de muito trabalho !

Baixei uma em Out/07 e achei 40% errados (repetidos, mal posicionados, sem limite de velocidade, inexistentes, etc...).

A base deve ter hoje uns 1600 pontos !

Eu, sozinho, fiz uma base com 3000 pontos ! Ápenas pesquisando na Internet e usando o Google Earth ! A base tá show ! Tem até radares LAP (rodízio em SP) !

Recomendo ao numeroso grupo de colaboradores do projeto Tracksource que adote uma localidade, ou mesmo uma cidade, e atualize a base de radares ! Isso é fácil e vai trazer muito benefício para inúmeras pessoas !

Minha contribuição será a cidade do Rio de Janeiro ! Pois a base do projeto Tracksoruce para a cidade do Rio tem uns 12 radares apenas ! já tenho todos e estou auditando minha base para ter 100% de fidelidade ! Porém, só vou atualizar a base do Tracksource se outros fizerem o mesmo ! Tive muito trabalho e noites sem sono para conseguir isso !

Hoje, não sabemos a quantidade total de radares que o Brasil tem ! Existem 321 radares em estradas federais ! A cidade de São Paulo tem 84 sensores de semáforo e parada sobre faixas de pedestres ! já contei mais de 1000 radares em estradas estaduais de SP !!!!

Eu tenho feito isso ! Ao ver um radar e meu navegador não detectá-lo, eu anoto a posição e o limite de velocidade ! Pronto ! Resolvido ! radar cadastrado e auditado ao mesmo tempo !

Gostaria de ouvir mais opiniões a respeito desse assunto !

[Wallace]

Acho que voce erra ao falar em numeroso grupo de colaboradores.
Eu por exemplo "desenvolvo" mais de 50 mapas por falta de desenvolvedores.
Outra coisa é os radares estarem realmente funcionando.
Eu sigo as regras de transito então não tenho isso como prioridade nos meus mapas, mas incluo todas as contribuições e chego a marcar estes pontos Também.
Mas segundo amigos meus que São da area, uma minoria das instalações de radar tem um funcionamento efetivo.

[elderluis]

Particularmente sou contra o cadastramento de qualquer radar e até mesmo postos policiais em estradas. No meu simples e humilde entendimento isso serve apenas para estimular comportamentos imprudentes e suicidas, expondo tb a vida de outras pessoas desnecessariamente. Muitas pessoas (eu disse MUITAS, não disse TODAS) que usam o aviso de radar se sentem "garantidas" pela porcaria do beep do GPS e entre um beep e outro fazem verdadeiras anarquias homicidas e suicidas ao volante, sob a pseudo idéia de que "se beepar por causa de radar, eu tiro o pé", mas simplesmente ignoram outras centenas de fatores de risco pq acham quel ali "não pega nada".

Sou desenvolvedor de mapa e não cadastro nenhum radar, coloco apenas os que eventualmente São mandados como contribuição, mas como até agora não recebi nenhuma contribuição de radar, tá doce!

Se fossemos dinamarqueses, finlandeses ou escandinavos de maneira geral, eu até poderia pensar na possibilidade de cadastrar todos os radares, mas como somos brasileiros e a famosa "lei de gerson" que impera, sou contra. até mesmo para preservação da minha vida e de meus familiares.

Outra coisa, quem pensa que o radar é eterno em um determinado ponto, se engana. Obviamente existem radares fixos, mas existem muuuitos que São móveis e São mudados de local com certa constância, portanto, quem acha que está protegido por um beep de GPS, é bom se precaver....

[elderluis]

Ah detalhe: sou desenvolvedor da cidade que vc está usando o mapa como avatar, e por sinal, o ponto da imagem é do lado da minha casa!

[Hélcio Assis]

- Boa tarde a todos, concordo plenamente com as colocações do Wallace e do Elder.

[speedcam]

Agora entendo porque a base de radares do projeto Tracksource é tão antiga, desatualizada, incompleta e inconsistente !

[Fernando Lopes]

Particularmente sou contra o cadastramento de qualquer radar e até mesmo postos policiais em estradas ....

Concordo em linhas gerais com o seu pensamento, menos o de postos policiais em estradas, pois o seu cadastro não é apenas para diminuir a velocidade. O seu cadastro é importante. você pode parar para tirar informações sobre condições da estrada, denunciar motoristas que abusam ou cometeram alguma barbaridade, tomar um cafézinho (hehehe), sanitários e assim por diante. Eu Também não me importo se tem POI de radar mas o Posto Policial eu já acho interessante.

[elderluis]

Agora entendo porque a base de radares do projeto Tracksource é tão antiga, desatualizada, incompleta e inconsistente !

Pois é... não sou o chefe ou responsável por essa área do projeto, apenas desenvolvo o mapa de São Bernardo do Campo e assim como Wallace, não tenho como prioridade marcar pontos de radares no mapa, msm pq, como eu disse no outro post, os radares São dinâmicos, mudam de endereço constantemente, se formos acompanhar os deslocamentos dos radares, com certeza o restante do mapa irá perecer, o que não é vantagem para ninguém

Tenho um carro bom e de vez em quando gosto de dar umas pisadas mais fortes tb, mas isso é perigoso e não é nada saudável.

[Wallace]

Caro Marcelo,

Agora entendo porque a base de radares do projeto Tracksource é tão antiga, desatualizada, incompleta e inconsistente !

Ser ironico desta forma não é construtivo.

A base de radares do projeto Tracksource precisa de muito trabalho !

Sim e voce pode perfeitamente assumir este trabalho.

Baixei uma em Out/07 e achei 40% errados (repetidos, mal posicionados, sem limite de velocidade, inexistentes, etc...).

Otimo pelo visto o trabalho você já faz pelo menos uma grande parte.

A base deve ter hoje uns 1600 pontos !

Eu, sozinho, fiz uma base com 3000 pontos ! Ápenas pesquisando na Internet e usando o Google Earth ! A base tá show ! Tem até radares LAP (rodízio em SP) !

Otimo, então já pode colaborar imediatamente.

Recomendo ao numeroso grupo de colaboradores do projeto Tracksource que adote uma localidade, ou mesmo uma cidade, e atualize a base de radares ! Isso é fácil e vai trazer muito benefício para inúmeras pessoas !

Seria otimo, mas eu no momento estou convertendo os mapas que posso do TM para o TRU a fim de termos mapas roteaveis que voce vai concordar comigo que São algo muito mais importante que os radares, mas cada um pode se dedicar uma parte para beneficio de todos.

Minha contribuição será a cidade do Rio de Janeiro ! Pois a base do projeto Tracksoruce para a cidade do Rio tem uns 12 radares apenas ! já tenho todos e estou auditando minha base para ter 100% de fidelidade ! Porém, só vou atualizar a base do Tracksource se outros fizerem o mesmo ! Tive muito trabalho e noites sem sono para conseguir isso !

Como assim, voce vai propositalmente o egoistamente sonegar algo que tem pronto.
Se for para mostrar trabalho pode ir tirando um ano de ferias no minimo para se dedicar ao projeto de tempo integral para eventualmente chegar perto do que alguns aqui já contibuiram com o projeto em tempo e trabalho.
Eu por exemplo a anos ajudo o projeto e normalmente dedico no minimo 1 hora ao dia a trabalho no projeto, fora outras atividades relacionadas.
3 mil pontos que voce citou é muito menos pontos que tem que ser revisado e trabalhados num unico mapa grande do projeto para ter ele perfeito para permitir ter um mapa roteavel.

[elderluis]

Concordo com o Wallace.... 3 mil pontos foi o que eu encarei em UM dos mapas que eu fiz a conversão, fora os outros, e os mapas estão disponíveis para qualquer pessoa do planeta baixar, basta ter um acesso a internet. Aliás, vc conhece os famosos diamantes vermelhos?

O projeto poderia até analisar a conveniência de setorizar essa questão de radares, mas como o próprio lema ou doutrinha do projeto na página principal: "Mapeando o Brasil" ... portanto creio que os esforços, tempo, paciência dedicados ao projeto, poderiam ser para um bem maior do que radares, podendo ser desenvolvimento de mapas, inserção de pontos realmente de interesse e não convenientes, etc.... acho que o custo/benefício é bem melhor para TODOS e não só para anda por aí furando o assoalho do carro com o pé e não quer entrar no lápis.

http://www.tracksource.org.br/uploads/s ... otrack.gif

[betocardoso]

Concordo com o Wallace e o Elder e procedo da mesma forma nos meus mapas, mas acho que o POI de polícia rodoviária é útil.

Beto

[Hélcio Assis]

Seria otimo, mas eu no momento estou convertendo os mapas que posso do TM para o TRU a fim de termos mapas roteaveis que voce vai concordar comigo que São algo muito mais importante que os radares, mas cada um pode se dedicar uma parte para beneficio de todos.

Como assim, voce vai propositalmente o egoistamente sonegar algo que tem pronto.
Se for para mostrar trabalho pode ir tirando um ano de ferias no minimo para se dedicar ao projeto de tempo integral para eventualmente chegar perto do que alguns aqui já contibuiram com o projeto em tempo e trabalho.
Eu por exemplo a anos ajudo o projeto e normalmente dedico no minimo 1 hora ao dia a trabalho no projeto, fora outras atividades relacionadas.
3 mil pontos que voce citou é muito menos pontos que tem que ser revisado e trabalhados num unico mapa grande do projeto para ter ele perfeito para permitir ter um mapa roteavel.

- parabéns Wallace pelas felizes colocações citadas por você.

[paulocarvalho]

Porém, só vou atualizar a base do Tracksource se outros fizerem o mesmo ! Tive muito trabalho e noites sem sono para conseguir isso !

Por que então você não me manda os dados ( paulo.r.m.carvalho@gmail.com ou paulocarvalho@rio.rj.gov.br ) ? Se você mandá-los para mim, enviarei o mapa para compilação no dia seguinte.

Eu contribuo com dados, tempo (tente adivinhar quanto vale a hora de um programador Java com 10 anos de experiência), e dinheiro para o projeto (muito trabalho e noites sem sono Também), e o resultado está disponível para todos INDEPENDENTEMENTE de outros terem feito o mesmo ou não.

[nqnnospam]

não vou entrar no assunto dos radares, mas os POIs de polícia São de extrema importância, tanto nos mapas rodoviários quanto nos municipais.

Como foi mencionado anteriormente, São pontos onde se pode obter informações, apoio, socorro, relatar a ocorrência de acidentes, etc. Inclusive, é interessante que os POIs contenham, sempre que possível, o contato telefônico do posto policial.

[elderluis]

Como foi mencionado anteriormente, São pontos onde se pode obter informações, apoio, socorro, relatar a ocorrência de acidentes, etc. Inclusive, é interessante que os POIs contenham, sempre que possível, o contato telefônico do posto policial.

Via de regra, através do telefone 190 (em todo país) vc pode obter informações e orientações do posto policial mais próximo e demais orientações que vc precisar nesse sentido, ainda que seja em rodovias federais.

[nqnnospam]

Desculpe, mas, para ligar para o 190 é necessário ter um telefone por perto (fixo ou celular). Além disso não sei se 190 funciona em todas as estradas do país (tenho quase certeza de que não funciona).

Via de regra não há telefones nas estradas do Brasil fora das regiões Sul e Sudeste. Celular então nem pensar.

Por isso é indiscutível a importância dos POIs de Polícia, pois com eles é possível determinar qual o posto mais próximo, e não perder tempo procurando por socorro.